Real-World Java

[paul nisset]

Hi ,
I've been at the same job for a while. I was wondering if Spring is still the dominant group of frameworks that people are currently using? For example, I've never heard of Prometheus or Project Lombock.
Thanks.

[Jorge Ruiz-Aquino]

I've been in the same project for several years now, using JavaEE5, Java SE 6, old fashion JSP, etc. I'm happy to know I'm not the only one.
It is hard to believe you have not heard of Project Lombok, though.

According to https://www.jrebel.com/blog/spring-boot-alternatives#spring-boot-alternatives-01, Spring's market share is still the top among Java Frameworks. Compared with other languages this number varies significatively.
So, it would be a good idea to have some knowledge about the framework.

My approach is start top-down. I use a rapid dev tool, e.g. JHipster (or Appfuse some years ago), generate a project with a technology stack already set and start learning them while working on a project. I prefer this than bottom-up where I have 0 or little idea how to build-up the project.

[Tim Cooke]

paul and Jorge wrote:Project Lombock.

I came across this tool some years ago and very quickly disliked it vehemently.

Maybe it has changed in recent times, but I doubt it because the things everybody loved so much about it was the same set of things that I wanted a million miles away from any codebase I had to support. In my current job, one of the first things I did with one of our Java codebases was to completely remove the dependency on Lombok. No thank you, no way, no way, no way.

[Roland Mueller]

Tim Cooke wrote:

paul and Jorge wrote:Project Lombock.

I came across this tool some years ago and very quickly disliked it vehemently.

Maybe it has changed in recent times, but I doubt it because the things everybody loved so much about it was the same set of things that I wanted a million miles away from any codebase I had to support. In my current job, one of the first things I did with one of our Java codebases was to completely remove the dependency on Lombok. No thank you, no way, no way, no way.

I 've encountered this dislike of Lombok in several places and by several persons in Coderanch but nevertheless missed until now the reasons what makes Lombok such an evil thing.

My view of Lombok sees at first the reduction of boilerplate code. E.g. having annotations to replace tons of getVal() / setVal(x) declarations.

Believe me my intent is not to start a flame war rather than have a list of pros and cons for / against Lombok.

[Jeanne Boyarsky]

paul nisset wrote:For example, I've never heard of Prometheus or Project Lombock.
Thanks.

But our book .

Yes, Spring is still dominant. It integrates with many other technologies

Re Lombok, the following is the beginning of the Lombok chapter. It's a technology that isn't used everywhere and people have difereence preferences about. But you have to understand something to like or dislike it. So learn about Lombok and then form your own opinion!

Project Lombok is one of life ’ s little conveniences. Lombok uses simple annotations to eliminate a ton of boilerplate code, such as getters and setters, logging, equals , and hashCode , as well as other scaffolding that might otherwise obscure a Java codebase. Lombok does this through the magic of bytecode reweaving , a process that rewrites the .class files by adding the desired code, without modifying your source files.

You might worry that this will complicate debugging and logging since the source code line numbering won ’ t match the modified class. But in fact, Lombok adjusts for that in the executing code, and the major Integrated Development Environments (IDEs) also handle it gracefully. Admittedly, there are times during intricate debugging sessions where stepping into generated code might be difficult, or cryptic logging messages might surface, for example if an exception is thrown from code that isn ’ t in your codebase!

Some of this might sound like Java “records,” introduced in Java 14. For cases where you need immutable data objects, records would usually be the way to go. But Lombok offers much broader capability, and many enterprise development teams are using it. For those that do, it adds great value.

You also might be thinking that you can use code generation to create getters, setters, equals, etc. The problem with code generation is that you have code that needs to be maintained and risks getting out of sync.
Additionally, code coverage tools will show this generated code as having low coverage.

[Tim Cooke]

Apologies Jeanne for hijacking your book promo conversation with my opinions on Lombok, but thank you for providing such a comprehensive response on the topic. I may be tempted to buy a copy of your book just to learn more about a reasoned opinion from a trusted peer.

I believe this:

Jeanne wrote:learn about Lombok and then form your own opinion!

is about the best piece of advice you can take from this discussion.

However, since Roland asked, I'll elaborate on my own reasons why I don't particularly like Lombok.

The primary objection is the disconnect between your source code and your deployable artefact. Fundamentally the code you wrote is not the code you deploy to production. I may be overly pedantic about this point, but I prefer need to maintain a strong link between cause (source code) and effect (running software).

Perhaps IDE support has improved over the years, but my experience was that my IDE often reported things as unused because it didn't understand the "not connected, but will be later" thing. My IDE also complained of compile errors for calls to the "don't exist, but will later" methods. As a development experience I did not enjoy it, and all these things reduced my trust in the IDE suggestions. Can I delete this thing, really? Maybe? I need to figure it out.

Overall, reasoning with the code just got a lot harder. I could no longer trust my IDE refactor suggestions around dead code. I was living full time with compilation errors in my IDE which prevented me from noticing actual compilations errors until much later.

The cost benefit analysis just didn't stack up for me. The benefit of not having to write a few lines of code (that my IDE did for me anyway), did not come close to the cost of the cognitive overhead of having to remember what Lombok was doing for me, and to blindly trust what it was doing without ever seeing what it did.

[Campbell Ritchie]

PN: have a cow for stimulating such an interesting discussion

[Tim Cooke]

Tim Cooke wrote:In my current job, one of the first things I did with one of our Java codebases was to completely remove the dependency on Lombok

I'll add to this that I was, am still am, in the fortunate position of being able to make decisions like this about a product codebase. However, I do recognise that if you work in a team who promote the use of Lombok then regardless of your own opinions on the matter there is value in being skilled in its use.

[paul nisset]

Thanks Jeanne for the explanation. Lombock sounds interesting. Seems really useful or a pain depending on the use case or real world experience. Thanks everyone else for their opinions.