Jabel + Lombok = safe for production?

[magicprinc]

I am really sorry, but I have to ask :-( I need to port a big Java 17 project to Java 8, so I have found Jabel today. Is it safe to use Jabel plus Lombok in production? The Jabel project is quite mature: no big incidents so far?

Thank You!

[asolntsev]

@magicprinc We have been using Jabel in Selenide project for 1.5 years. Works fine. But

1. Jabel doesn't really work "in production". Jabel is used only during compilation. It's not deployed to production.
2. We didn't try to use Jabel and Lombok together.

[magicprinc]

@asolntsev Thank You very much for sharing your experience! It is very helpful and reassuring to know!

I will try to mix them and report back :-)

[magicprinc]

It works! :-)

• openjdk 17.0.6 2023-01-17 LTS
• lombok 1.18.26
• sonarlint latest.release
• https://errorprone.info latest.release (!)

I had only to fix absent-in-v8 JDK API calls, but no problem with java language features.

Amazing!

Gradle example with this annotation processors Zoo: https://github.com/magicprinc/Apache-Click/blob/trunk/click-freemarker/build.gradle

[asolntsev]

@magicprinc Cool! Thank you for sharing the information (and especially the working example).

One idea to think about: if you already use Java 17 (especially records) then probably you don't really need Lombok? Many of Lombok features are not really needed (getters/setters are rather a sign of bad design), and some other features can be replaced by records.

[magicprinc]

@asolntsev The pleasure is mine :-)

My favorite Lombok features are: 1) @NonNull for parameters a) is part of API e.g. IDEA understands b) generates usual throw-if-null check 2) val ~ final var 3) @Slf4j 4) @Getter @Setter - sometimes you can't avoid them with Spring 5) @ToString - as first draft as minimum 6) @RequiredArgsConstructor 7) @Builder and @SuperBuilder

Records are fine, but I can't replace all covered functionality with them...

[lppedd]

I'm wondering if this project can be adapted to different bytecode levels. Example: many projects are now stuck at Java 11, while the language features are progressing very quickly. I'm not sure if there are real advantages in targeting an higher lever class file version, maybe minor instructions optimization?

[magicprinc]

I think it is quite easy to migrate from 11 to 17. 8→11/17 is a different story.

[lppedd]

@magicprinc not if you're part of a big release train and support for a version extends to multiple years. In my case I'm on Java 11 just because the platform we're targeting was EOL.

[magicprinc]

@lppedd I have found this project only yesterday ;-), but I think you can do it.

If we take this as an example https://github.com/magicprinc/Apache-Click/blob/trunk/click-freemarker/build.gradle

change targetCompatibility = 8 options.release.set(8) // javac --release 7..18+ to targetCompatibility = 11 options.release.set(11)

It is real JDK's javac who does the actual work

[lppedd]

@magicprinc I've investigated a bit and it turns out we use the Eclipse compiler, so not compatible with Jabel, what a pity.

[lppedd]

@magicprinc also turns out ECJ supports different values for source and target already. I've just compiled with a source level of 17 using switch patterns to a target of 11 👀

[magicprinc]

@lppedd Then you can also try https://www.eclipse.org/xtend/ It is miles beyond standard javac.

[lppedd]

@magicprinc I think at that point I would just go with Kotlin, but Xtend is also ok.
I've known the Eclipse compiler for a long time and never knew about this feature. I'm wondering then, why not just use ECJ over javac.

[magicprinc]

@lppedd If you really want to turn to the dark side, you can also try this magic: https://github.com/manifold-systems/manifold https://plugins.jetbrains.com/plugin/10057-manifold

Jabel and Lombok are already awesome enough, but what Project Manifold does, it is almost magic... dark magic :-)