[vbezhenar]

I somewhat agree with you and reluctant to use Lombok. But it's easy to say "use better language". Kotlin is too different. Java is actually pretty good right now and the only thing I really need is property declaration.

Actually I was thinking about different approach last year, didn't get to implement it. Something like declare abstract class with getX() setX() methods and let library to implement missing methods. Now it's one line per method, no trivial code and able to generate other nice things, e.g. I really want to have fast initializeable properties (like getX throws exceptions until I call setX).

[brabel]

> (like getX throws exceptions until I call setX).

Oh, the wonders of using widespread mutable state! Did you remember to call this other method here before trying to call me??? No?!?! Oh, here's a nasty Exception for you then.

[vbezhenar]

It has nothing with mutable state, actually. I can use this approach with immutable state as well. It's just another value "uninitialized" for property. Like `null` but throws faster (and potentially separate from null, because null could be a valid value).

I'm using it for SQL queries. My query returns subset of some column set. It's not practical to define a separate class for every query. So all queries for the given table returns the same class representing all columns in a given table. But if one method returns subset of those columns, other columns contain uninitialized value and should not be read. Any attempt to use uninitialized value is a bug and must be caught as soon as possible.

[culturedsystems]

"It's not practical to define a separate class for every query."

I'm not sure it's really impractical, at least in my experience. You may not need a separate type for every query, as long as you are willing to have some queries select a few more columns than you actually need right now; and you don't need separate classes, just separate interfaces, which makes the amount of extra code you need smaller.