Lombok offers more than data classes, so Java records obviously cannot replace it completely. However, @RequiredArgsConstructor makes the code harder to understand. I prefer a visible constructor that shows which parameters a class needs. With modern tools like IntelliJ IDEA, generating (and updating) a constructor is easy, and the visual noise can be reduced by folding the constructor when it is of no interest.
Annotations like @RequiredArgsConstructor also encourage poor style, because there is no room for validation inside the constructor. At most, @NonNull adds null checks, and that is all. Lombok still offers many annotations that promote bad practice or have been superseded by the language itself, e.g. @Setter (mutability without protecting invariants), @Value (records) or @Cleanup (try-with-resources).
@Slf4j can easily be replaced by a single line of code (with the Log4j 2 API, even without specifying the class name).
Lombok's builders are actually useful, since Java has no named parameters with default values (as Kotlin does).
Regarding the "Dark Magic" section: just because other frameworks like Hibernate apply their own flavour of dark magic doesn't make it any better. Such magic should be kept out of the functional core of application code. The more magic is applied, the more problems can occur (e.g., the correct order in which tools apply their magic). This is essentially accidental complexity introduced to improve developer experience, but in the age of AI this may be the wrong optimization.
If you write modern Java, Lombok really doesn't add much.
But you could save some token with Kotlin, too. The language is a bit less "magic" and compiles faster. So, Kotlin might be a sweetspot for AI code generation. Go is probably another good candidate.
I liked Scala a lot, but it also caused some real world problems like different, partly incomprehensible coding syles or compatibility issues. Although the concise syntax could help to save some token, I guess that Scala is not the best language for AI. Other languages like Java or Go are more explicit and clear to the reader - and the AI. The elegance and conciseness simply doesn't matter so much anymore.
I could imagine some AI powered personal portal. This would basically answer the question "What is important and interesting today?". But that would have nothing in common with the old portals like Lycos.
I've experience severe problems with Scala in teams with different skill levels or programming styles. Sometimes Scala code was very cryptic. As much as I like the elegance of the language as such, I've given up on it completely because it is not a good fit for industrial software development in my opinion.
An interesting example to look at is Java vs. Kotlin. While Kotlin is a bit easier and definetly more fun, it didn't manage to gain a big market share in the Java space so far. I guess that this is the case, because Java is good enough and seems to be the safer bet (at least for managers).
I know and like Java for almost 30 years now. It is amazing how carefully the language is beeing refined. For the cultural aspect, yes, that is sadly true, but I have the feeling that the culture changes. More and more developers realize that there is a better way now (e. g. records instead of dumb classes full of getters and setters). Maybe the main problem is bloated frameworks and their stickyness. The Helidon framework, for example, is a breath of fresh air compared to Spring. Go developers complaining about huge Java frameworks and boilplate could be happy with it.
IMHO, the main reason why Spring is huge is because it has grown organically to encompass many of the business cases/issues that one may encounter in both depth and breadth. So the http framework supports almost everything you may ever need and there is integration with every database, middleware, infra like kubernetes. (One can debate about the quality of all the lesser used modules but the main modules are pretty okay.)
On the other hand I have used Quarkus which was great until it wasn’t because a certain http feature wasn’t supported or we needed integration with an unsupported database. In enterprise that is enough reason to just choose for the batteries included option and lift along on improvements of the main framework.
Just adding the bare bones integration wasn’t that hard. The trick comes from ensuring all the observability is wired correctly, that it fits in the framework usage, works good with graalvm, and other “non-functionals”.
At this point the work is typically more than you want a single team to maintain. Unfortunately, in many large enterprises it is just easier and more efficient to grab a bigger framework than trying to organise sharing the custom integration in the organisation.
i am building my own framework on top of it[1].
the biggest thing for me was it was rewritten on virtual threads from grounds up. no vertx. no netty, lesser indirections.
reply