What are all the disadvantages over LOMBOK?

[Deepanraj Devaraj]

What are all the disadvantages over LOMBOK?

[Marco Servetto]

The main disadvantage is that you have to know it exists.
It is a third party library, so most programmers have no idea it
exists and works well.
As a second disadvantage, it works on Java, so while it makes Java
much better, it can not, by design, solve most of Java problems.


There may be more problems that others can list :)

On 25 February 2015 at 14:14, Deepanraj Devaraj

<deepanra...@gmail.com> wrote:
> What are all the disadvantages over LOMBOK?
>

> --
> You received this message because you are subscribed to the Google Groups
> "Project Lombok" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to project-lombo...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Peter Grant]

The primary complaint I've heard is, "It doesn't work in my IDE."  A more accurate statement would be, "It doesn't work in my IDE out of the box, and support for experimental features may vary across IDEs."  

For example, this use of an experimental feature compiles fine but generates errors in IDEA: @RequiredArgsConstructor(onConstructor = @_({@Deprecated}))

The people working on the IDE support have done a great job.  It's easy to install and works really well, and if a feature is marked experimental, I shouldn't expect it to be supported fully yet.  To their credit, however, they do such a good job of supporting even the experimental features that I'm surprised if something doesn't work perfectly.

I have also fielded the odd question of how to add a breakpoint to the generated code.  I never discovered if you could, but I noted that Boilerplate Breakpoint would be a passable name for a steampunk band.

[Eric B]

Unfortunately it does not work with aspectJ.

Otherwise it is a great tool.

Eric

[Peter Grant]

I seem to recall having used lombok successfully with aspectj, but I may have avoided this problem entirely by using load-time weaving.  From what I've read, it sounds like the lombok annotation processors don't run (or don't run properly) under ajc, and if that's the case then this is a perfectly valid complaint.  However, people have successfully worked around this problem by performing two-stage compilation with javac or delombok and then ajc.  Of course that's complicated, but the chief complaint seems to be that the workaround breaks IDE integration.

[Eric B]

A lot depends on what you use aspectj to do.   If you are just advising methods etc it won't be a problem.   The issue occurs when you try to declare fields and /or methods in a mixin aspect.  In which case the javac compiler fails b/c the fields don't exist (assuming they are referenced) and the ajc compiler falls b/c none of the Lombok generated code exists.

So you can't run delomok or anything else at that point b/c you have a deadlock / catch 22 situation, where ajc needs the Lombok code to compile and javac needs the aspectj code to compile.

LTW would work since at that point Lombok code is just regularly generated Java.

Thanks
Eric

[Fabrizio Giudici]

On Sun, 01 Mar 2015 02:40:40 +0100, Eric B <eben...@gmail.com> wrote:

> A lot depends on what you use aspectj to do. If you are just advising
> methods etc it won't be a problem. The issue occurs when you try to
> declare fields and /or methods in a mixin aspect. In which case the
> javac
> compiler fails b/c the fields don't exist (assuming they are referenced)
> and the ajc compiler falls b/c none of the Lombok generated code exists.
>
> So you can't run delomok or anything else at that point b/c you have a
> deadlock / catch 22 situation, where ajc needs the Lombok code to compile
> and javac needs the aspectj code to compile.
>
> LTW would work since at that point Lombok code is just regularly
> generated
> Java.

If you aren't doing extensive stuff such as the quoted injection of
fields/methods (that are referred by Lombok in some way), it's also
perfectly possible to have Lombok to co-exist with ajc even with static
weaving. I'm routinely doing that. All you need is to force ajc to
manipulate bytecode (which happens when you de-configure the source
directory, so ajc can't find them and reverts to bytecode). Below an
excerpt of my POM:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<configuration>
<Xlint>ignore</Xlint>
<source>${tft.javac.source}</source>
<complianceLevel>${tft.javac.source}</complianceLevel>
<target>${tft.javac.target}</target>
<!-- Prevent ajc from finding sources -->
<sources />
<testSources />
<!-- This is important because sometimes the
plugin decides that there's nothing to do
because sources are not specified -->
<forceAjcCompile>true</forceAjcCompile>
...
</configuration>
...
</plugin>

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[dayanand]

I love Lombok and it works great.
Other annoying part of Lombok apart from the ones called out here is, if you update the field names, any reference to the setter/getter is not updated. It is not trivial for the IDE to implement it.

[Eric Lefevre-Ardant]

I should point that the IntelliJ plugin for Lombok does support renaming getters and setters automatically. It does not support renaming the withX() methods (@Wither) or the methods in a builder (@Builder), though.

--

[David Belmez]

IntelliJ 2017 refactorize any getter/setter call if you change any field name

[Inessa]

It will be great if @ExtensionMethod annotation functionality would be moved from experimental to production.