Approximating Java Case Objects without Project Lombok

10 thoughts on “Approximating Java Case Objects without Project Lombok”

  1. I agree. I always found the excessive amount of “magic” involved in Lombok not worth the effort. I much prefer the apache method. I don’t think the drawbacks are that severe. You can always just throw those implementations into any class you need them if you don’t want to use up the super class. They are much cleaner than the alternative.

  2. I’m curious if You know about “annotation processing” support in NetBeans 6.9? It makes using project Lombok as simple as referencing Lombok Jar in project properties. I know there still is some magic involved behind the scenes.

    1. I think its cool that projects like Lombok get made because they are interesting and push the language forward, but I will probably never use it for exactly the reason you mention about Netbeans 6.9. If I have to assume that the person reading my code is using this tool AND is using a specific IDE in order to be able to see it… that’s just a complete loser for me. If you work on a large team you simply can’t make those kinds of assumptions. Even if you all happen to use the same IDE now, will you later?

      I might consider it if I was working on a project by myself, but I would probably go with Groovy or Scala first, which gives you some of this and much much more, although it has its own drawbacks.

      1. First of all, Lombok is not NetBeans only. Currently NetBeans and Eclipse are supported, as well as products based on Eclipse. IntelliJ support is unfortunately still missing but is high on the priority list.

        So your main point is that people might not understand the way your code works if they don’t a Lombok supported IDE. But I don’t think you need an IDE to understand any code. Of course you need to understand the workings, but I’d argue that that’s the case for all annotation based frameworks.

        I think that this problem would be solved if more people would actually use Lombok in their projects 🙂 Currently the adoption of Lombok is still progressing, so I invite you to review your decision in a few month.

      2. Roel, I went to look at the Lombok.org video. Before this I’d only heard about it several times on the Java Posse. I think I changed my mind. I don’t think I’ll be partaking in the one that throws checked exceptions without declaring them, but the @Data one looks like a huge win. Eclipse was easy to set up and its easy to use. There were some concerns by my teammates about debugging the less trivial methods but using delombok makes that less of an issue.

        Thanks for poking me. I’ll definitely try this out.

  3. Clearly everybody has got his own standard, but after years of “liberation” from frameworks that mandated to extend a base class (such as EJB 2) I can’t imagine anything worse than having to extend a class… for equals()/hashcode()/toString(). It’s inheritance used for factoring out common code, and it’s a known anti-pattern.

    1. I think that the superclass is a side note here and the main point is to have a ready made correct implementation of equals/hashcode and tostring. The correct part is less critical with tostring but handcoded equals and hashcode can have enormous and very hard to find bugs in them. Even the IDE generated ones are tough because you have to remember to update them. Having a nice, tight, useful implementation of these methods is really helpful. I would personally be ok putting these in the classes where I need them directly. I do that now but I do it with Eclipse’s generated ones which are like razor blades on the eyes.

      These classes also have lots of customization if you want more specific behavior but the defaults are pretty good.

      One other thing. I’m not entirely sure what you mean by inheritance used for factoring out common code is an anti-pattern. Isn’t that exactly what superclasses are? Logic that is common to all subclasses? I’m just not sure I got what you were going for with that thought.

    2. I second what John said. As well, where in EJB2 you were required to inherit from someone else’s base class in this case its a class that you write. Additionally, as John pointed out, you can even put these inside your own class if you really don’t like the super class idea.

  4. For those coding outside an IDE, Lombok supports the plain old java compiler javac, so no problem there. If you want to see the actual code Lombok generated you can use the delombok tool.

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