1 Reply Latest reply: Nov 25, 2012 3:51 PM by gimbal2 RSS

    Project Lombok - easier getters and setters

    768023
      I came across [Project Lombok|http://projectlombok.org/] recently and I think it greatly simplifies common Java patterns. All those getters and setters needed to satisfy JPA, JSF, and CDI make conceptually trivial classes become hundred-line monsters. If you need to change a type (e.g. int to long) or a name, then you need to do the same thing three or more times, or you can delete and generate everything again, but this can be risky: you might delete and regenerate a method that contained some little but necessary extra logic (a null check with ?:, for example), which could be indistinguishable from boilerplate code at first sight.

      I know this will be met with resistance, but I think a Lombok-like project should be incorporated into Java SE 8 or 9. Look at the great productivity improvements we had with Java 5 and Java 7 (specifically Project Coin). Look how easy it is to create an EJB in Java EE 6. People that would never consider EJBs in the past are now using them (me included) and enjoying!

      Maybe Java tools could at least provide official tools to support Lombok, because it currently uses unsupported interfaces to do its work.

      I think this post, if taken as an official feature request, would be off-topic here, but hey, I already have an account here and the conversation must start somewhere :-)
        • 1. Re: Project Lombok - easier getters and setters
          gimbal2
          MarcusF. wrote:
          All those getters and setters needed to satisfy JPA, JSF, and CDI make conceptually trivial classes become hundred-line monsters.
          Only when you're doing something very wrong design-wise. Getters and setters are no problem, you generate them anyway. But go ahead, keep believing the incredibly trivial is what is keeping you from being productive.
          Look how easy it is to create an EJB in Java EE 6.
          Yes its easier to CREATE an EJB. But it is still as hard as ever to understand the nuances of the technology and properly apply it without cutting into your own fingers. You still need to properly understand transaction management for example. But also stateless design, remote invocation, messaging, concurrency, etc. etc. Its still very, very hard. But yeah, annotations in stead of XML crud. That made -all- the difference right?

          It isn't code that makes things easier. It never was and it never will be. But people keep focusing on simplifying the actual programming by spitting out API after API and framework after framework and in the mean time the technology never gets any easier, or better. Because the code is not where the problem is.

          IMO of course.