Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Perhaps I haven't had enough coffee yet, but could you explain how an immutable data structure is any different than an object whose class definition is all final? If you can't change any property of the object, wouldn't that be the same as what this annotation does?

To be clear, it seems like a nice boiler-plate avoidance technique (which Java could always use more of). But you're implying that there's some other significant underlying problem this solves and I don't see it.



Java doesn't have immutable collections in its standard library. If if a java.util.* collection is declared final, you can still modify its contents.


Actually, it does, but they don't have explicit types. See java.util.Collections.unmodifiableCollection(...), etc.


That still doesn't work all the way down. The objects you get out of the collection remain as mutable as when they were inserted.

Also, unmodifiableCollection doesn't make the collection you pass in immutable; it creates a new object through which you can access it as long as you don't modify it. Anybody holding a reference to the original object can still change the object.

I think you can even somewhat break the collection by changing objects inside it if doing that changes their hashcode (for sets and dictionaries, such a change may have to reinsert the item in the collection to make sure that you can still retrieve it)


Right, but this project doesn't solve that problem, either. It wraps the underlying collection in a builder to make it less easy to access, but it doesn't appear that it places any additional restrictions on the types of members or collection elements (from the generated code on their site anyway).

If you weren't using this library, you could achieve something similar with, e.g.,

  someImmutableSet = Collections.unmodifiableSet(new HashSet<E>(someSet));
I think this library really is about making immutable objects accessible, i.e., taking away the boiler plate. Hand-writing immutable (and potentially mutable) implementations on top of interfaces for a whole set of DTOs is super annoying.


Derp, for whatever reason I was thinking of an object as the data structure in this case. Thanks for clarifying!


if a class definition contains a Map that's declared final, nothing prevents anyone from mutating the map itself, if there's a public getter to it.

In order for a class to be immutable, all its fields need to be be immutable and final. Immutability got to be recursive.

Also, in Java, the class should be final, otherwise nothing prevents anyone from extending it and pass a mutable data structure instead of the immutable one you'd expect

Edit : added the "in java", as we could imagine another language where immutable doesn't require objects to be final.


A final data structure can't be reassigned, but it's contents can still be modified.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: