| > 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). |