collections

Extrinsic vs intrinsic equality

The following article is purely theoretical. I don’t know if it fits a real-life use-case, but the point is just too good to miss :-) Java’s List sorting has two flavors: one follows the natural ordering of collection objects, the other requires an external comparator. In the first case, Java assumes objects are naturally ordered. From a code point of view, this means types of objects in the list must implement the Comparable interface. For example, such is the case for String

css javascript optimization webjars wro4j

WebJars and wro4j integration

WebJars is an easy way for server-side developers (such as your humble servant) to manage client-side resources such as Bootstrap, jQuery and their like, within the same package management tool they use for their server-side libraries. In essence, what WebJars does is package a set version of the client-side resource (CSS or JavaScript) in the META-INF/resources of a JAR and upload it on Maven Central. Then, any Java EE compatible web-container makes the resource available under a static URL. F

dependency guava

Guava is an heavyweight library and I would like this to change

Google Guava is an useful library that offers many different but unrelated features: For my Vaadin projects, I like using Event Bus to promote loose coupling along my componentsGuava offers Functional oriented collections handlingThere’s a lightweight Cache implementationetc. However, this article is not about those features but about offering a single heavyweight Uber JAR for all. From Google’s point-of-view, providing an Uber library for all projects makes sense: 'Hey guys, just a

JavaFX

Spreading some JavaFX love

I’m not a big fan of JavaFX: version 1 was just a huge failure, and investing in fat-client architecture in 2013 is either because you have very specific needs or are completely out of your mind. Nevertheless, I wanted to write about fat-client testing in Integration testing from the trenches, and JavaFX is the Java way for fat-client GUI. So I was searching for some easily available application I could take as an example when I stumbled upon the Ensemble samples project from Oracle itsel

javaconfig spring

Integrate Spring JavaConfig with legacy configuration

The application I’m working on now uses Spring both by parsing for XML Spring configuration files in pre-determined locations and by scanning annotations-based autowiring. I’ve already stated my stance on autowiring previously, this article only concerns itself on how I could use Spring JavaConfig without migrating the whole existing codebase in a single big refactoring. This is easily achieved by scanning the package where the JavaConfig class is located in the legacy Spring XML conf

javaconfig method injection spring

Spring method injection with Java Configuration

Last week, I described how a Rich Model Object could be used with Spring using Spring’s method injection from an architectural point of view. What is missing, however, is how to use method injection with my new preferred method for configuration, Java Config. My start point is the following, using both autowiring (shudder) and method injection. public abstract class TopCaller { @Autowired private StuffService stuffService; public SomeBean newSomeBean() { return ne

method injection rich domain object spring

Rich Domain Objects and Spring Dependency Injection are compatible

I’m currently working in a an environment where most developers are Object-Oriented fanatics. Given that we develop in Java, I think that it is a good thing - save the fanatics part. In particular, I’ve run across a deeply-entrenched meme that states that modeling Rich Domain Objects and using Spring dependency injection at the same time is not possible. Not only is this completely false, it reveals a lack of knowledge of Spring features, one I’ll be trying to correct in this ar

hack

getCaller() hack

As developers, we should only call public APIs. However, the Java language cannot differentiate between public API and private stuff: as soon as a class and one of its method is public, we can reference the former and call the later. Therefore, we are exposed to the Dark Side of the Force, and sometimes tempted to use it. A good example of this terrible temptation is the sun.reflect.Reflection.getCaller(int) method. As its name implies, this evil piece returns which class called your current co