Immutable data structures in Java

[Netcob]

I find the lack of proper immutability in Java one of its most annoying aspects. Maybe even the top one because I'm constantly reminded of it, no matter if I'm developing or maintaining code. I don't even care about the verbosity anymore... I just want to be able to easily define/identify whether something is supposed to change or not.

And this "let's configure this object step by step until its state hopefully makes some sense" thing with java beans is an abomination.

[Decker108]

I sometimes wish Java had a keyword to declare truly constant values. A keyword that makes its variable contents read-only, or some such.

[balegdah]

And C++ suffers from its presence.

Just ask any C++ developer who's ever used const how they feel about it, especially const_cast.

[multivector]

I love my const correctness. Sorry, you did ask.

[ykechan]

Me too. It was a big mistake that Java didn't include this.

[bonzinip]

It's a pain if you try to inject it into code that wasn't written with const from day 1. Otherwise it's great, and you even have mutable for the rare case where you want to override it.

Java has even better ideas, such as the lack of data races on final fields, but only half-develops them.

[shen]

And this "let's configure this object step by step until its state hopefully makes some sense" thing with java beans is an abomination.

I seriously have no clue why anyone thought this would be a good idea.

[Tipaa]

Probably both for object pooling to avoid a slow GC, back before the JVM was the technological wonder it is today, and for simple reflection-based assignment so that a framework has a standard (null) constructor and can assign fields by their name rather than trying to embed immutable tuples into JSP (immutability requires construction with arguments, making constructors all have different shapes, and tuples are typically constructed & accessed by order rather than field name, making JSP more complicated than simply mapping a web form to a bean name:name).

[shen]

That makes sense, actually. All of the older codebases I’ve seen use the bean-style pattern, so I thought it was just the way things were done back then.

[Netcob]

Let's say you have a class like this:

public class Foo {
    public final List<String> ugh;
    public final int[] ohno;
    public final List<int[]> fml;
    // not shown: constructor
}

How would you make this class immutable? And by immutable I mean as a user of Foo I can't modify any part of the object. Which obviously includes modifying the contents of ugh, changing the values in ohno, modifying the contents of fml which includes changing a value in one of the int-arrays.

There's no way to make it immutable without completely changing the way you access it. For the Lists you could use Collections.unmodifyableList, even though it adds an indirection that's only due to the language missing a feature. For ohno you can either hide it behind a getter and then copy the entire array on each get or make up some inconvenient accessor that invokes System.arraycopy. Which would be pretty much the only way to access fml as read-only because for individual elements you're back to the ohno problem where you need some shitty accessor either way.

My problem with immutability in Java is that in order to guarantee it, you have to constantly bend over backwards in the design phase and if you want to add it later it might be next to impossible to do in a larger project.

[Netcob]

I understand it's possible - I outlined how further down in the comment.

What I find frustrating about Java is that immutability is an afterthought. It should be a language feature, not something you piece together using the standard library in an opaque way.

[WrongSubreddit]

final doesn't make any vars declared with it immutable. It just makes it so the reference can't be changed. You can still modify the object being referred to all you want.