[virmundi]

The problem I have with Lombok is that suddenly it’s hard to trace getters and setter from the Pojo. By this I mean asking the question, “where is getId() used” is hard if I want to use the find references feature of the IDE.

[lmilcin]

I also have mixed feelings about Lombok.

For example, if you want to automatically create getters and setters to all private variables, why not make them public in the first place?

I hate when tools mess with IDE. What about guys using Emacs (or any other editor that does not understand Lombok)? I think generating code from IDE is fine as well as having code generated from build system distributed along with code, but having that code generated through magic of annotation processor is not as nice. I also suspect that Lombok messes my IDE on a deeper level but I have not yet a good concrete proof. Recently I am more and more frequently finding situations where Idea messes up understanding correct types of things and it takes for it some time to catch up (and sometimes reloading the file).

On the other hand I love small things like creating builder or logger. Which is to say these can be just as easily generated from a template, no annotation processor needs to be involved.

I think main feature of Java for many years were its IDEs which would allow to run accurate refactorings or always understand who is using particular piece of code, what is exact call hierarchy, etc. I feel loosing that is going to make Java much less useful for me when I try to analyze large project or run huge refactorings.

[goostavos]

>why not make them public in the first place?

If you're in an old school "OOP" style java codebase, where each class is its own little island of encapsulated state and behavior, the coupling of the two means that strictly controlling access via getters is usually required.

Even in more "modern" java, where you do most of your programing against plain data, having Lombok attach getters still gives you some quality of Life benefits because you can use method reference rather than anonymous functions for high-order access (e.g. `things.map(MyClass::getName)` rather than `things.map(myclass -> myclass.name)`)

I'm with you on mixed Lombok feelings, though. It's great right up until its not. It fails or doesn't work in really unexpected or weird ways, and is the source endless pain when you've got other annotation based things (like dagger) which then imposes annotation processing order failures.

[lmilcin]

> If you're in an old school "OOP" style java codebase, where each class is its own little island of encapsulated state and behavior, the coupling of the two means that strictly controlling access via getters is usually required.

That I agree. My comment was meant to be cheeky a little bit as it is actually pretty difficult to find trully OOP application, at least in area of backend apps I am working in.

Obviously, in OOP you are not supposed to expose your internal state but rather accept messages to run behaviour.

If you are working on a truly OOP application then Lombok is useless. Your public class interface is all that matters then and you would spend more time fighting Lombok than just writing it manually.

Lombok is only good at automating boilerplate which, if you have a lot of, is a sign of some other problem.

> It's great right up until its not. It fails or doesn't work in really unexpected or weird ways

That is exactly the point. Magic is fun until you find out that it leaks horribly and causes unintended side effects with all sorts of stuff.

What's the point of replacing simple problem (just really use templating mechanism you have in your IDE) with complex problem (dealing with magic failing on you).

[p2t2p]

> why not make them public in the first place?

Because in future I may want to add some validation there, or processing, like sending events on set of a value, etc.

Properties in C# was a genius move that solves it correctly.

[watwut]

Unless we are talking about API, then you add getter and setter. You might even be able to refactor all callers automatically via IDE. I mean, I dont mind getters and setters in java, it is standard at this point.

But origin of it is in EJB specification, it is not something that would be interently needed elsewhere. It just "feels wrong" to programmers (including me) at this point.

[lmilcin]

That, in my observation, almost never happens.

[p2t2p]

I'm working in a product that is about 10 years old and 4 months ago it went through a quite a big project which purpose was to add extended auditing to be more enterprise friendly. The system was flooded with auditing events on various changes into internal data. The system provides a public API and allows to install plugins. If we had to change our entities that would be a compatibility nightmare for thousands of plugin vendors.

[v-erne]

I'm not sure how this works in other IDEs, but lombock Eclipse plugin kinda solves this problem. You can run CTRL+Shift+G (Find references) on getter/setter that is shown in class outline and it will immediately give You getter/setter uses.

https://stackoverflow.com/questions/42644923/eclipse-with-lo...

[LgWoodenBadger]

Depends on your IDE. IntelliJ IDEA supports this with the Lombok plugin