Stats
rzwitserloot/lombok is an open source project licensed under GNU General Public License v3.0 or later which is an OSI approved license.
Lombok Alternatives
-
awesome-annotation-processing
A curated list of resources related to the Java annotation processing API (JSR 269)
-
-
Scout APM
Scout APM - Leading-edge performance monitoring starting at $39/month. Scout APM uses tracing logic that ties bottlenecks to source code so you know the exact line of code causing performance issues and can get back to building a great product faster.
-
-
-
-
-
OpenJ9
Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
-
Thymeleaf
Thymeleaf is a modern server-side Java template engine for both web and standalone environments.
-
manifold
Manifold is a Java compiler plugin, its features include Metaprogramming, Properties, Extension Methods, Operator Overloading, Templates, a Preprocessor, and more.
-
-
equalsverifier
EqualsVerifier can be used in Java unit tests to verify whether the contract for the equals and hashCode methods is met.
-
-
-
-
-
-
DocxJavaMapper-example
An example project from my tutorial about how to map a Docx file to a Java object.
Posts
-
Is using Project Lombok actually an good idea?
For me the most important thing to consider is that Lombok is basically a compiler hack that relies on non-public APIs to work. These API are still there up to Java 16 but it is pretty clear that the path forward is to lock down access to non-public APIs in future Java versions. It's a cat and mouse game to keep it working. There is an extensive thread about that on Lombok's github page. At some point, Lombok will stop working as it is. There are several possible outcomes, you may decide to not upgrade your Java version to keep Lombok compatibility, Lombok may become an external code generation tool instead of an annotation processor, or you may decide to remove Lombok usage. For that they provide a "delombok" tool, but don't expect it to be a single magic command, you'll end up with messy auto-generated code peppered around your codebase, and you may have a lot of work to do to bring your codebase back to good style standards.
-
Reliable WebSockets-based pub/sub with Spring Boot
Firstly, let's set up a basic Spring Boot application. We can use the Spring Initializr with Spring Data JPA, H2 Database, Lombok added. H2 Database will provide us with a simple database, and Spring Data JPA will allow us to easily interact with it using Hibernate. Lombok will make it easier to write concise and readable classes.
-
A categorized list of all Java and JVM features since JDK 8 to 16
I would wholeheartedly recommend against using Lombok in any but the most basic situations. The list of things that are wrong with using Lombok range from unforeseen consequences in many situations to serious future proofing issues with JDKs in the near future beginning with JDK16.
-
We got the [Java] generics we have
Kind of off topic, but is something using either Lombok[0] or Manifold[1] to have better ergonomics in Java? It sounds like a brilliant idea to me, but I don't use Java on a daily basis.
-
Lombok and Guava breaking in Java 16
See: https://github.com/rzwitserloot/lombok/issues/2681
-
Playing the generator game
Well as it turns out, lombok doesn't respects all annotations, since it gets too complicated to implement that behaviour. You can go through the github issues for details 1 2
-
Future Of Lombok
Following the general release of JDK 16: https://jdk.java.net/16/ and specially https://openjdk.java.net/jeps/396 Lombok has severe build issues due to its reliance on the JDK internals which 16 has closed off, discussion here: https://github.com/rzwitserloot/lombok/issues/2681
-
Spring Boot and Java 16 Records
You are probably already using Lombok annotations such as @Value, which is closest if not the same to the Java records. Then you can get rid of one dependency and those Christmas trees of annotations. I might have oversimplified things, and it may make sense to replace Lombok for some cases. But you might be using Lombok for other features and not just one annotation that it provides. And believe me, while Java Records are a welcome feature for Java lovers, but it's not going to replace Lombok, at least for now. You do not believe me? Check out this answer from Brain Goetz on StackOverflow.
-
Is Lombok in danger of becoming incompatible with future JDK's?
From the outside looking in this comment (github) looks like you know what you are going to do goes against the intent of the changes made be OpenJDK and you don't want to give them the opportunity to correct their oversight before JDK16 ships.
I am not too sure, if you read the last comment in the thread https://github.com/rzwitserloot/lombok/issues/2681#issuecomment-791452056
It's not exactly front and center either, while it is the reason I've heard not to use Lombok. Where on lombok.org does it say this? I managed to find it in the 'controversy' section of the article linked on the front page.
Ok, the "fix" is out:
You can take a look here: https://github.com/rzwitserloot/lombok/commit/9806e5cca4b449159ad0509dafde81951b8a8523
[FEATURE] Make Lombok compatible with JDK 16 · Issue #2681 · rzwitserloot/lombok · GitHub
- Algumas das atualizações do Java 8 ao 15