> so it is kind of only of academic value if a field in a POD, POJO, POCO or whatever it is called in the specific language actually may change.

I'm not sure if you've debugged much, or inherited any large legacy projects, but knowing it is immutable vs "typically it isn't" is a pretty big distinction in that moment.

Good code don't have this issue.

Good code doesn’t have concepts like “typically doesn’t mutate”. It’s either mutable or immutable.

The standard way to do it is to mutate clones as always in Java. Typically by use of libraries that provide this. You really need very bad code to have to think about if objects are mutable.

Apparently you don’t know most immutable structures are optimized for modified cloning in ways mutables aren’t.

This is Java.

And?

good code shouldn't need to be debugged either ;)

"Typically" this means you can never be sure, which is a problem.

Sure of what? If your code is not garbage it takes two seconds to see where things change. It should be very places in the code.

It takes two seconds in a hello world demo. It takes probably more in a millions of lines project.

Fields of an object should typically not change. But yes, I had to make a field of a class immutable some time ago. There was a bug and I could not read the code to figure out were the object was changed. Still, caused by bad code. Same object sent around pretty much everywhere.

So even you, the master of great code, wrote bad code. I guess immutability is worth something then.

I did not write the original solution...

Precisely: you did not write the original solution, which is where immutability shines. It's a code comprehension tool; it gives you guarantees about code you didn't write. That's a huge boon!

There are no guarantees that it is the same object you get so it is pointless.

No one uses immutables to make sure they “get the same object”. What does that even mean?

So you reckon we only need immutability if two or more people have to work on code. Ok.

You are just too stupid. I hope you are not immutable.

There are many good things enabled by immutability, like safer/easier multithreading, value-like semantics for objects. It is definitely not only of academic value.

Typically you use values and not objects for these kind of things so not that much gained.

Values require copying, so depending on the problem it can be worse from a perspective point of view.

Keyword being “may”.

Guarantees are nice. Especially if objects are going to be passed around every which way from Sunday. It allows you to better reason about what could happen, and where.

Java has taken a while to get there, but I’m glad that they have finally.

Well, if you pass around objects and change their state records will not help. People who does this are already using immutable frameworks in Java to clone and change some field and then pass it along.

Sure, things have been bolted on top of Java to allow this to happen. People have made use of them.

Java now has built in support for these things, so no longer will developers rely on third-party solutions.

This is great for the Java world, and for any languages that are being built on top of the JVM by extension.

I would politely disagree with your characterisation of it being just academic, as an engineer I find it incredibly exciting. Admittedly, my bar is pretty low for excitement these days.

I have done Java for 25 years and never felt any need for records. There are so many issues...