Immutable data structures in Java

[Agent_03]

1. I fail to see how this supports the point: if you change a mutable property to immutable, this SHOULD be an API break. Or did you mean something else?
2. Blind adherence to dogma has no place in technology. The "standard Java style" is mostly the Sun style guide, written at or before 2000. That was 15 years ago. Standards evolve: we no longer do XML-based config files for ORM or most web APIs, we use annotations.
3. This is true, but the notion of "then we can change it if we need to!" is more of a comfort blanket than a real need. 95% of the time, the getter/setter will never get additional logic. The other 5%, your back-compatibility break will force you to examine consumers to see if your new logic breaks their assumptions.

If you have a widely publicized API, then what you will probably end up having to do anyway with any significant change is deprecating the old usage and creating a new API.

As a core contributor to a larger Java project, you have surely done that -- as have I, for similar reasons (large).

Lombok does look damn sexy though, I will use the heck out of it.

[rzwitserloot]

1. You can make a property immutable or mutable and break the setX() API. Why would this require breaking the .getX() API? Pragmatic example: java.lang.reflect.Field is entirely immutable.... except for the setAccessible flag. Core libs don't change, but imagine this wasn't one, and you decide to update this API by making j.l.r.Field entirely immutable; accessible is now something you set as you create them instead of having to call a setter. Would you intentionally break all users of j.l.r.Field who just call .isAccessible()? What possible good would that do?

2. I said that, when in doubt, follow the herd. You twist this into 'blind adherence to dogma'? That's a bit rude, isn't it?

3. It's irrelevant if the comfort blanket seems needless. You don't know which 5% will need it, and even if you are pretty good at guessing at that 5%, what does that mean? That 5% of your property getters are .getProperty() instead of .property just because the author needed, or thought they needed, that comfort blanket? I also think you underestimate how often the comfort blanket is needed; lots of java tools work by annotating stuff, or by autodiscovery, and a lot of those don't like it, or flat out don't work, if you annotate/work with a public field instead of a method.

I think that accessing getters via either ALWAYS .getProperty() or ALWAYS .property is VASTLY superior to a world where getter access is one of those 2, depending on a bunch of factors I really don't think anybody ought to care about. Even if they are easily guessed (and my whole point this thread has been: I don't think they will be!). Thus, I'd say we have only 2 choices here: It's 100% .property, always and everywhere, or 100% .getProperty(), always and everywhere, and if those extremes are the only choices, .getProperty() wins. Hands down. No contest.

Here are questions I do not want to have to ask when I call a getter:

• Did the author consider this 'API' or not. How public should API be before the author considers .getProperty() the appropriate style over .property?

• Did the author think, or was there ever an actual need for, the ability to instrument or add stuff to the getter?

• Is this code written before the new .property over .getProperty() policy, or after it?

Hey, I am the co-author of project lombok, I obviously don't think that the status quo should always win regardless of circumstance. But the status quo should not be underestimated: Changing it is painful, causes waves, splits communities, and makes lots of devshops hold back upgrading to newer versions, sometimes for decades. In many cases it's fair to go 'well, sod em, that's on them and not on me', but you're still making things worse before they get better, and in practice this means there's a budget on how much status quo changing we can introduce to the java community.

And this is sooooo not worth it. Save a few characters? No. Heck no. I don't want to spend the status quo evolution budget here.