Is it safe to use Project Lombok

Question

In case you don t know Project Lombok helps with some of the annoyances of Java with stuff like generating getters and setters with annotations and even simple JavaBean like generation with  Data  It could really help me  especially in 50 different event objects where you have up to 7 different fields that need to be constructed and hidden with getters  I could remove almost a thousand lines of code with this   However  I m worried that in the long run  it will be a regretful decision  Flamewars will erupt in the   Java Freenode channel when I mention it  providing code snippets will confuse possible helpers  people will complain about missing JavaDoc  and future commiters might just remove it all anyway  I would really enjoy the positive  but I m worried about the negative    So  Is it safe to use Lombok on any project  small or large  Are the positive effects worth the negatives

User · Answer

Just started using Lombok today   So far I like it  but one drawback I didn t see mentioned was refactoring support   If you have a class annotated with  Data  it will generate the getters and setters for you based on the field names   If you use one of those getters in another class  then decide the field is poorly named  it will not find usages of those getters and setters and replace the old name with the new name     I would imagine this would have to be done via an IDE plug-in and not via Lombok   UPDATE  Jan 22  13  After using Lombok for 3 months  I still recommend it for most projects   I did  however  find another drawback that is similar to the one listed above   If you have a class  say MyCompoundObject java that has 2 members  both annotated with  Delegate  say myWidgets and myGadgets  when you call myCompoundObject getThingies   from another class  it s impossible to know if it s delegating to the Widget or Gadget because you can no longer jump to source within the IDE     Using the Eclipse  Generate Delegate Methods     provides you with the same functionality  is just as quick and provides source jumping   The downside is it clutters your source with boilerplate code that take the focus off the important stuff   UPDATE 2  Feb 26  13  After 5 months  we re still using Lombok  but I have some other annoyances   The lack of a declared getter  amp  setter can get annoying at times when you are trying to familiarize yourself with new code     For example  if I see a method called getDynamicCols   but I don t know what it s about  I have some extra hurdles to jump to determine the purpose of this method  Some of the hurdles are Lombok  some are the lack of a Lombok smart plugin   Hurdles include     Lack of JavaDocs  If I javadoc the field  I would hope the getter and setter would inherit that javadoc through the Lombok compilation step  Jump to method definition jumps me to the class  but not the property that generated the getter  This is a plugin issue  Obviously you are not able to set a breakpoint in a getter setter unless you generate or code the method  NOTE  This Reference Search is not an issue as I first thought it was   You do need to be using a perspective that enables the Outline view though  Not a problem for most developers  My problem was I am using Mylyn which was filtering my Outline view  so I didn t see the methods   Lack of References search   If I want to see who s calling getDynamicCols args      I have to generate or code the setter to be able to search for references     UPDATE 3  Mar 7  13  Learning to use the various ways of doing things in Eclipse I guess   You can actually set a conditional breakpoint  BP  on a Lombok generated method   Using the Outline view  you can right-click the method to Toggle Method Breakpoint   Then when you hit the BP  you can use the debugging Variables view to see what the generated method named the parameters  usually the same as the field name  and finally  use the Breakpoints view to right-click the BP and select Breakpoint Properties    to add a condition   Nice   UPDATE 4  Aug 16  13  Netbeans doesn t like it when you update your Lombok dependencies in your Maven pom   The project still compiles  but files get flagged for having compilation errors because it can t see the methods Lombok is creating   Clearing the Netbeans cache resolves the issue   Not sure if there is a  Clean Project  option like there is in Eclipse   Minor issue  but wanted to make it known   UPDATE 5  Jan 17  14  Lombok doesn t always play nice with Groovy  or at least the groovy-eclipse-compiler   You might have to downgrade your version of the compiler  Maven Groovy and Java   Lombok  UPDATE 6  Jun 26  14  A word of warning  Lombok is slightly addictive and if you work on a project where you can t use it for some reason  it will annoy the piss out of you   You may be better off just never using it at all   UPDATE 7  Jul 23  14  This is a bit of an interesting update because it directly addresses the safety of adopting Lombok that the OP asked about   As of v1 14  the  Delegate annotation has been demoted to an Experimental status  The details are documented on their site  Lombok Delegate Docs    The thing is  if you were using this feature  your backout options are limited   I see the options as    Manually remove  Delegate annotations and generate handcode the delegate code  This is a little harder if you were using attributes within the annotation  Delombok the files that have the  Delegate annotation and maybe add back in the annotations that you do want  Never update Lombok or maintain a fork  or live with using experiential features   Delombok your entire project and stop using Lombok    As far as I can tell  Delombok doesn t have an option to remove a subset of annotations  it s all or nothing at least for the context of a single file  I opened a ticket to request this feature with Delombok flags  but I wouldn t expect that in the near future   UPDATE 8  Oct 20  14  If it s an option for you  Groovy offers most of the same benefits of Lombok  plus a boat load of other features  including  Delegate   If you think you ll have a hard time selling the idea to the powers that be  take a look at the  CompileStatic or  TypeChecked annotation to see if that can help your cause   In fact  the primary focus of the Groovy 2 0 release was static safety   UPDATE 9  Sep 1  15  Lombok is still being actively maintained and enhanced  which bodes well to the safety level of adoption   The  Builder annotations is one of my favorite new features   UPDATE 10  Nov 17  15  This may not seem directly related to the OP s question  but worth sharing   If you re looking for tools to help you reduce the amount of boilerplate code you write  you can also check out Google Auto - in particular AutoValue   If you look at their slide deck  the list Lombok as a possible solution to the problem they are trying to solve  The cons they list for Lombok are    The inserted code is invisible  you can t  see  the the methods it generates   ed note - actually you can  but it just requires a decompiler  The compiler hacks are non-standard and fragile  In our view  your code is no longer really Java    I m not sure how much I agree with their evaluation   And given the cons of AutoValue that are documented in the slides  I ll be sticking with Lombok  if Groovy is not an option    UPDATE 11  Feb 8  16  I found out Spring Roo has some similar annotations  I was a little surprised to find out Roo is still a thing and finding documentation for the annotations is a bit rough   Removal also doesn t look as easy as de-lombok   Lombok seems like the safer choice    UPDATE 12  Feb 17  16  While trying to come up with justifications for why it s safe to bring in Lombok for the project I m currently working on  I found a piece of gold that was added with v1 14 - The Configuration System   This is means you can configure a project to dis-allow certain features that your team deems unsafe or undesirable   Better yet  it can also create directory specific config with different settings   This is AWESOME   UPDATE 13  Oct 4  16  If this kind of thing matters to you  Oliver Gierke felt it was safe to add Lombok to Spring Data Rest   UPDATE 14  Sep 26  17  As pointed out by  gavenkoa in the comments on the OPs question  JDK9 compiler support isn t yet available  Issue  985   It also sounds like it s not going to be an easy fix for the Lombok team to get around   UPDATE 15  Mar 26  18  The Lombok changelog indicates as of v1 16 20  Compiling lombok on JDK1 9 is now possible  even though  985 is still open   Changes to accommodate JDK9  however  necessitated some breaking changes  all isolated to changes in config defaults   It s a little concerning that they introduced breaking changes  but the version only bumped the  Incremental  version number  going from v1 16 18 to v1 16 20   Since this post was about the safety  if you had a yarn npm like build system that automatically upgraded to the latest incremental version  you might be in for a rude awakening   UPDATE 16  Jan 9  19     It seems the JDK9 issues have been resolved and Lombok works with JDK10  and even JDK11 as far as I can tell    One thing I noticed though that was concerning from a safety aspect is the fact that the change log going from v1 18 2 to v1 18 4 lists two items as BREAKING CHANGE    I m not sure how a breaking change happens in a semver  patch  update  Could be an issue if you use a tool that auto-updates patch versions

User · Answer

There are long-term maintenance risks as well  First  I d recommend reading about how Lombok actually works  e g  some answers from its developers here   The official site also contains a list of downsides  including this quote from Reinier Zwitserloot      It s a total hack  Using non-public API  Presumptuous casting  knowing   that an annotation processor running in javac will get an instance of   JavacAnnotationProcessor  which is the internal implementation of   AnnotationProcessor  an interface   which so happens to have a couple   of extra methods that are used to get at the live AST        On eclipse  it s arguably worse  and yet more robust  - a java agent   is used to inject code into the eclipse grammar and parser class    which is of course entirely non-public API and totally off limits       If you could do what lombok does with standard API  I would have done   it that way  but you can t  Still  for what its worth  I developed the   eclipse plugin for eclipse v3 5 running on java 1 6  and without   making any changes it worked on eclipse v3 4 running on java 1 5 as   well  so it s not completely fragile    As a summary  while Lombok may save you some development time  if there is a non-backwards compatible javac update  e g  a vulnerability mitigation  Lombok might get you stuck with an old version of Java while the developers scramble to update their usage of those internal APIs  Whether this is a serious risk obviously depends on the project

User · Answer

I have used Lombok in almost all my projects for one year but unfortunately removed it  In the beginning it was a very clean way of development but setting up the development environment for new team members is not very easy and straightforward  When it became a headache I just removed it  But it is a good work and needs some more simplicity to setting up

User · Answer

I haven t tried using Lombok yet - it is was next on my list  but it sounds as if Java 8 has caused significant problems for it  and remedial work was still in progress as of a week ago   My source for that is https   code google com p projectlombok issues detail id 451

User · Answer

I know I m late  but I can t resist the temptation  anybody liking Lombok should also have a look at Scala  Many good ideas that you find in Lombok are part of the Scala language   On your question  it s definitely easier to get your developers trying Lombok than Scala  Give it a try and if they like it  try Scala   Just as a disclaimer  I like Java  too

User · Answer

Lombok is great  but     Lombok breaks the rules of annotation processing  in that it doesn t generate new source files  This means it cant be used with another annotation processors if they expect the getters setters or whatever else to exist   Annotation processing runs in a series of rounds  In each round  each one gets a turn to run  If any new java files are found after the round is completed  another round begins  In this way  the order of annotation processors doesn t matter if they only generate new files  Since lombok doesn t generate any new files  no new rounds are started so some AP that relies on lombok code don t run as expected  This was a huge source of pain for me while using mapstruct  and delombok-ing isn t a useful option since it destroys your line numbers in logs   I eventually hacked a build script to work with both lombok and mapstruct  But I want to drop lombok due to how hacky it is -- in this project at least  I use lombok all the time in other stuff

User · Answer

I have encountered a problem with Lombok and Jackson CSV  when I marshalized my object  java bean  to a CSV file  columns where duplicated  then I removed Lombok s  Data annotation and marshalizing worked fine

User · Answer

Go ahead and use Lombok  you can if necessary  delombok  your code afterwards http   projectlombok org features delombok html

User · Answer

Wanted to use lombok s  ToString but soon faced random compile errors on project rebuild in Intellij IDEA  Had to hit compile several times before incremental compilation could complete with success  Tried both lombok 1 12 2 and 0 9 3 with Intellij IDEA 12 1 6 and 13 0 without any lombok plugin under jdk 1 6 0 39 and 1 6 0 45  Had to manually copy generated methods from delomboked source and put lombok on hold until better times  Update The problem happens only with parallel compile enabled  Filed an issue  https   github com rzwitserloot lombok issues 648 Update  mplushnikov commented on 30 Jan 2016  Newer version of Intellij doesn t have such issues anymore  I think it can be closed here   Update I would highly recommend to switch from Java Lombok to Kotlin if possible  As it has resolved from the ground up all Java issues that Lombok tries to work around

User · Answer

My take on Lombok is that it merely provides shortcuts for writing bolilerplate Java code   When it comes to using shortcuts for writing bolilerplate Java code  I would rely on such features provided by IDE -- like in Eclipse  we can go to menu Source   Generate Getters and Setters for generating getters and setters  I would not rely on a library like Lombok for this    It pollutes your code with an indirection layer of alternative syntax  read  Getter   Setter  etc  annotations   Rather than learning an alternative syntax for Java  I would switch to any other language that natively provides Lombok like syntax  Lombok requires the use of a Lombok supported IDE to work with your code  This dependency introduces a considerable risk for any non-trivial project  Does the open source Lombok project have enough resources to keep providing support for different versions of a wide range of Java IDE s available  Does the open source Lombok project have enough resources to keep providing support for newer versions of Java that will be coming in future  I also feel nervous that Lombok may introduce compatibility issues with widely used frameworks libraries  like Spring  Hibernate  Jackson  JUnit  Mockito  that work with your byte code at runtime    All in all I would not prefer to  spice up  my Java with Lombok

User · Answer

Personally  and therefore subjectively  I ve found that using Lombok makes my code more expressive about what I m trying to achieve when compared to IDE own implementations of intricate methods such as hashcode  amp  equals   When using    EqualsAndHashCode callSuper   false  of      field1    field2    field3       it s much easier to keep Equals  amp  HashCode consistent and keep track of which fields are evaluated  than any IDE own implementation  This is especially true when you re still adding   removing fields regularly   The same goes for the  ToString annotation and its parameters which clearly communicate the desired behavior regarding included   excluded fields  usage of getters or field access and wether or not to call super toString     And again by annotating an entire class with  Getter or  Setter AccessLevel NONE   and optionally overriding any divergent methods  it s immediately clear what methods will be available for the fields   The benefits go on and on    In my mind it s not about reducing code  but about clearly communicating what you desire to achieve  rather than having to figure it out from Javadoc or implementations  The reduced code just makes it easier to spot any divergent-method implementations

User · Answer

I m not recommend it  I used to use it  but then when I work with NetBeans 7 4 it was messing my codes  I ve to remove lombok in all of files in my projects  There is delombok  but how can I be sure it would not screw my codes  I have to spends days just to remove lombok and back to ordinary Java styles  I just too spicy

User · Answer

When I showed the project to my team the enthusiasm was high  so I think you should not be afraid of team response    As far as ROI  it is a snap to integrate  and requires no code change in its basic form   just adding a single annotation to your class  And last  if you change your mind  you can run the unlombok  or let your IDE create these setters  getters  and ctors   which I think no one will ask for once they see how clear your pojo becomes

User · Answer

It sounds like you ve already decided that Project Lombok gives you significant technical advantages for your proposed new project    To be clear from the start  I have no particular views on Project Lombok  one way or the other    Before you use Project Lombok  or any other game-changing technology  in some project  open source or other wise   you need to make sure that the project stake holders agree to this   This includes the developers  and any important users  e g  formal or informal sponsors    You mention these potential issues      Flamewars will erupt in the   Java Freenode channel when I mention it    Easy   Ignore   don t participate in the flamewars  or simply refrain from mentioning Lombok      providing code snippets will confuse possible helpers     If the project strategy is to use Lombok  then the possible helpers will need to get used to it      people will complain about missing JavaDoc     That is their problem   Nobody in their right mind tries to rigidly apply their organization s source code   documentation rules to third-party open source software   The project team should be free to set project source code   documentation standards that are appropriate to the technology being used    FOLLOWUP - The Lombok developers recognize that not generating javadoc comments for synthesized getter and setter methods is an issue   If this is a major problem for your project s   then one alternative is to create and submit a Lombok patch to address this        and future commiters might just remove it all anyway    That s not on   If the agreed project strategy is to use Lombok  then commiters who gratuitously de-Lombok the code should be chastised  and if necessary have their commit rights withdrawn   Of course  this assumes that you ve got buy-in from the stakeholders     including the developers   And it assumes that you are prepared to argue your cause  and appropriately handle the inevitable dissenting voices

User · Answer

I read some opinions about the Lombok and actually I m using it in some projects   Well  in the first contact with Lombok I had a bad impression  After some weeks  I started to like it  But after some months I figure out a lot of tiny problems using it  So  my final impression about Lombok is not so positive   My reasons to think in this way    IDE plugin dependency  The IDE support for Lombok is through plugins  Even working good in most part of the time  you are always a hostage from this plugins to be maintained in the future releases of the IDEs and even the language version  Java 10  will accelerate the development of the language   For example  I tried to update from Intellij IDEA 2017 3 to 2018 1 and I couldn t do that because there was some problem on the actual lombok plugin version and I needed to wait the plugin be updated    This also is a problem if you would like to use a more alternative IDE that don t have any Lombok plugin support   Find usages  problem   Using Lombok you don t see the generated getter  setter  constructor  builder methods and etc  So  if you are planning to find out where these methods are being used in your project by your IDE  you can t do this only looking for the class that owns this hidden methods  So easy that the developers don t care to break the encapsulation  I know that it s not really a problem from Lombok  But I saw a bigger tendency from the developers to not control anymore what methods needs to be visible or not  So  many times they are just copying and pasting  Getter  Setter  Builder  AllArgsConstructor  NoArgsConstructor annotations block without thinking what methods the class really need to be exposed  Builder Obssession     I invented this name  get off  Martin Fowler   Jokes apart  a Builder is so easy to create that even when a class have only two parameters the developers prefer to use  Builder instead of constructor or a static constructor method  Sometimes they even try to create a Builder inside the lombok Builder  creating weird situations like MyClass builder   name  Name   build   create    Barriers when refactoring  If you are using  for example  a  AllArgsConstructor and need to add one more parameter on the constructor  the IDE can t help you to add this extra parameter in all places  mostly  tests  that are instantiating the class  Mixing Lombok with concrete methods  You can t use Lombok in all scenarios to create a getter setter etc  So  you will see these two approaches mixed in your code  You get used to this after some time  but feels like a hack on the language    Like another answer said  if you are angry about the Java verbosity and use Lombok to deal with it  try Kotlin

[java] Is it safe to use Project Lombok?

Examples related to java

Examples related to lombok