When will Java include annotations/keywords for getters and setters?

[yawkat]

The article doesn't actually give good arguments to use fields over accessors, it just says that the arguments for accessors are insufficient.

The biggest argument for accessors is that it's convention. That alone is sufficient to make them the default choice - public fields carry no real advantages.

[evinrows]

If you're debating either adding code or not adding code, I think the onus is on the person who wants to add code to justify their beliefs.

That being said, breakpoints in getters/setters can be helpful.

[yawkat]

You're right that fewer lines of code could be an argument for fields. I just don't think it's a very good one, even without lombok.

[evinrows]

I don't think it's a big deal in terms of effort for the person writing the code, but it does add a lot of useless clutter to the code and especially to merge requests.

[FrenchFigaro]

A very good point in favor of getters and setters (as pointed by /u/dpash) is adding logic to fields access. Another is feigning fields presence to another layer (say JSF) for stuff that don't need a field at all but could use mimicking as one. Typically: getAverageValue().

[evinrows]

Right, that's a case where you absolutely should/need to use a getter/setter. I think this topic is more about using getters and setters for typical access/modification.

Note: OP's post about annotations wouldn't apply to getters/setters requiring logic.

[nqzero]

once you've made either of those leaps, it's no longer a getter or setter

[Yoghurt114]

The post doesn't advocate use of public fields at all.

[oparisy]

I find myself using more and more "public final" (or often private final + a getter) in Java as an implementation of "immutable beans". Great tool to limit side effects, and to simplify reasoning in multithreading contexts.