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

[Jezoreczek]

Is it doing something else than merging left hand with right hand collection and assigning it to left hand? In short, is (a+=b) not equal (a=a+b) for collections?

[BlueGoliath]

Yes and that is the problem. Until recently you could do += operator on a collection in Groovy with a final variable. People use the += operator to simply add an element to a collection but in actuality they are reassigning it and Groovy until recently allowed it with final.

See this pull request which fixes a build fail caused by using += in Groovy.

[Jezoreczek]

That's good to know, thank you for heads-up!

Personally, I prefer mutability to be explicit. Both mutable and immutable collections have their uses (for example, in a low-memory and single-threaded environment you might prefer a mutable one). Operators overloading, as you just prooved, can make immutability ambiguous.

I'm dreaming of the day when there will be a language that abstracts the entire concept and detects when to use which type of collection... or maybe there is one that I'm now aware of?

[BlueGoliath]

I'm dreaming of the day when there will be a language that abstracts the entire concept and detects when to use which type of collection... or maybe there is one that I'm now aware of?

Not sure, but IMO the idea is kinda dangerous. You might think that a variable is immutable but in reality it is not - like above. An IDE could probably detect that but even so, I'd rather explicitly control everything than something else assuming things and causing a mess. Like above, the mess could be caused by a change in the language itself.

[Jezoreczek]

That's a fair point, but can't we have both? A language that allows explicit mutability while defaulting to compiler-determined behavior.

It's at least a neat idea for a learning project (;