Evil Field Injection vs. Annotatiomania™ with Lombok

Spring was the framework that has originally brought us dependency injection, e.g. through the utterly magic @Autowired, or the equally magic JEE @Inject. Now in this week, I’ve come across an interesting blog post by Oliver Gierke, a prominent Spring developer. Oliver claims that “field injection is evil.” Hear ye! So, dependency injection isn’t unanimously promoted within Spring / Pivotal?

Oliver makes good points about testability and the fact that injected fields may be null under some circumstances that might not resemble productive environments. He then elaborates on creating immutable state through the usage of constructors. This is also advertised by JIRM, the Java Immutable object Relational Mapper by Adam Gent. And obviously, immutability is also advertised by the creators of the Scala language, who systematically distinguish mutable from immutable collections.

Now, Oliver tries to solve this problem by using Project Lombok, a tool that takes advantage of Java’s annotation processing capabilities as can be seen in this tutorial. Here’s his solution in code:

class MyComponent {

  final @NonNull MyCollaborator collaborator;

  public void myBusinessMethod() {

As you might guess, the above example will generate a constructor taking all members as arguments and annotates that constructor with the JEE @Inject annotation. Now, this solution certainly works and helps avoid boiler plate that you would have if you wrote the constructor code yourself.

But is this really our “brave new world”? Did we really want to put those annotations all over the place? Or is it just me, feeling that Annotatiomania™ is going mad at us? Check out this example from Code That Made Me Cry that makes use of the JPA 2.1 @SqlResultSetMapping annotation. All that code that has been moved from readable, imperative writing to declarative annotations.

Solving things on a language level

Now we can argue whether dependency injection is good or prone to abuse. But this third-party annotation-processing code generation is just crazy. Let’s have a look at how the Scala language resolves such things (as can be seen in this forum thread):

class MyComponent @Inject() 
     (collaborator : MyCollaborator) {

  def myBusinessMethod() {

Now, this looks much leaner, doesn’t it? I really wish we could have “Scala, the good parts” in Java too. Mixing constructors and immutable state with the class declaration is just plain awesome. This is how an object-oriented language should be done. And it has been repeated in RedHat’s Ceylon.

Stay tuned for a future blog post about borrowing Scala’s and Ceylon’s good parts.

4 thoughts on “Evil Field Injection vs. Annotatiomania™ with Lombok

  1. I personally dislike Lombok for two reasons:

    Reason#1: Lombok relies on undocumented and implementation specific features of the Java compiler. No matter how stable those internal features are: they are non guaranteed.

    Reason#2: If Java happens to open up and define guaranteed api to modify the AST during compile time the way like groovy does, then they open a bottle full of malevolent ifrits. Then we should expect the proliferation of unreadable and not-well-thought annotation constructs like those listed in your article.

    On the other hand Lombok really has some nice features, like automatic setter/getter generations, delegator creation and so on. The problem is that the developers of Lombok are just humans like you and me and want to use their hammer for everything. When everything becomes a nail it may hurt.

    • Yeah, I remember your playing around with Java’s APT capabilities for fluflu. It really appears to be a bit esoteric. Even Scala’s much more powerful macros aren’t well documented. These things are just a sign of how hard a problem is at conception time, and a sign of how the designers might not have spent enough time to properly think stuff through. But as you say it, it happens to the best 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s