Timeline for Why doesn't Java 8 include immutable collections?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 13, 2015 at 6:32 | comment | added | supercat |
@jhominal: IMHO, the proper pattern in many cases should be to have pairs of related mutable and immutable classes, analogous to String and StringBuilder. A BigIntAccumulator class could support a mutating Add method which was substantially faster than a non-mutating Plus method which had to construct a new instance. If the accumulator type allocated some extra storage for temporary calculations it could also support other mutating operations like MultiplyBy.
|
|
| Dec 23, 2013 at 15:49 | comment | added | jhominal |
@JamesAnderson: About BigDecimal: do you recognize that, if the BigDecimal was not immutable, then nobody could use it to materialize values, in the way one can use int, double, and any other number type? Because if I get the value of a property getLength() in a BigDecimal, I would not like being told "Warning, the value that you get can be changed at any time." - that could force me to do additional defensive copies. (Sometimes I would like to know the new length after it changes! But it cannot be the job of BigDecimal, which is supposed to represent purely a number value.)
|
|
| Dec 23, 2013 at 15:44 | comment | added | jhominal | @JamesAnderson: In short, your reasons 2 and 3, are more reasons to avoid using immutability - they are not reasons for Java designers to avoid implementing it. (A good reason would be that, e.g., designing performant immutable collections requires non-trivial work) | |
| Dec 23, 2013 at 15:42 | comment | added | jhominal | @JamesAnderson: My problems with your answer: "Performance" - you could say that real life immutable collections always implement some form of sharing and reuse to avoid exactly the issue you describe. "Concurrency" - the argument boils down to "If you want mutability, then an immutable object does not work." I mean that if there is a notion of "latest version of the same thing", then something needs to mutate, either the thing itself, or something that owns the thing. And in "Storage", you seem to say that mutability is sometimes not desired. | |
| Dec 20, 2013 at 3:33 | comment | added | James Anderson | A little bit miffed about the down votes here. The OP asked why they did not implement immutable collections, and, I provided a considered answer to the question. Presumably the only acceptable answer among the fashion conscious is "because they made a mistake". I actually have some experience with this having to refactor large chunks of code using the otherwise excellent BigDecimal class purely because of poor perfomance due to immutability 512 times that of using a double plus some messing around to fix the decimals. | |
| Dec 20, 2013 at 3:27 | comment | added | James Anderson | If several threads need to access the latest version then a classic immutable object does not work. Instead you have the performance overhead and complication of a "pretend" immutable object. | |
| Dec 20, 2013 at 1:41 | comment | added | Tom Hawtin - tackline | Using concurrency as an argument against immutability is unusual. Duplicates as well. | |
| Dec 19, 2013 at 2:33 | comment | added | GlenPeterson | Couple problems. The collections in Clojure and Scala are both immutable, but support light-weight copies. Adding element 1001 means copying less than 33 elements, plus making a few new pointers. If you share a mutable collection across threads, you have all kinds of synchronization issues when you change it. Operations like "remove()" are nightmarish. Also, immutable collections can be built mutably, then copied once into an immutable version safe to share across threads. | |
| Dec 19, 2013 at 1:32 | comment | added | Jon Purdy | Immutable collections only require copying if you can’t share because of pervasive mutability like Java has. Concurrency is generally easier with immutable collections because they don’t require locking; and for visibility you can always have a mutable reference to an immutable collection (common in OCaml). With sharing, updates can be essentially free. You may do logarithmically more allocations than with a mutable structure, but on update, many expired subobjects can be freed immediately or reused, so you don’t necessarily have higher memory overhead. | |
| Dec 19, 2013 at 1:20 | history | edited | James Anderson | CC BY-SA 3.0 |
added 461 characters in body
|
| Dec 19, 2013 at 1:15 | history | answered | James Anderson | CC BY-SA 3.0 |