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

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.




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

Search: