On 9/22/17 5:36 AM, Roger Riggs wrote:
Hi Stuart,
I'm cautious about doing work piecemeal toward immutable collections.
The current unmodifiable approach only gives partial protection to the caller
and none to the callee. The assertions it makes are too weak to be useful.
I'm not entirely sure what you're driving at here. Looking at this again, I can
see at least one place that should be strengthened. In List.copyOf, something
like this should be added:
Any modifications to the given Collection are not reflected in the
returned List.
(And similar for Set.copyOf and Map.copyOf.)
Are there other assertions that should be added or strengthened?
I think more value can be achieved by creating concrete final immutable
collections
that applications can use to be certain that the semantics of the collection
are immutable. They can implement the current interfaces but would be compile
time
knowable of the complete semantics of mutability. Then a good bridge between
the current streams (and collections) would be methods that return the concrete
final collections.
It would add some value to have concrete, "immutable" collection classes
exposed. Presumably though these would implement the List/Set/Map interfaces. As
instances get passed around, the "immutable" part would get "cast" away,
limiting the value added.
There is a large design space here (see Guava and Eclipse Collections, among
others that have this concept of "immutability). They're certainly interesting,
but I haven't yet seen an approach that is clearly better than the current
approach of keeping the implementation classes completely hidden.
BTW, I don't think many people are confused by 'immutable' collections appearing
to be mutated because one of the objects in the collection is mutable.
I'm sure *you* aren't confused by the issues. But I spend a lot of effort
explaining these issues to the general public, so I think the change is worthwhile.
s'marks
Thanks, Roger
On 9/21/2017 2:55 PM, Stuart Marks wrote:
On 9/21/17 5:42 AM, Alan Bateman wrote:
On 21/09/2017 01:02, Stuart Marks wrote:
http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.0/
I read through the updated/new definitions and they read well.
Great.
For the copyOf methods then I can't immediately tell from the javadoc if the
given collection can contain null elements. Taking List.copyOf as an example
where coll may be null or it may contain null elements. The javadoc does link to
"Unmodifiable lists" where it specifies the characteristics of the lists
returned by the static factory methods - these include disallowing null
elements. So I think this needs to be clarified.
Agreed, I'll work on some clarifications here, and also disallow null for the
argument itself.
Minimal implementation is okay to get started but what is the reason not to
include some basic tests?
Sorry, I should have been more clear about this. The changeset is clearly not
ready to go in as it stands. I wanted to get an initial review of the
specifications going, then file a CSR request, etc. while continuing to work
on tests and better implementations. I'll post a subsequent review when
they're ready.
Thanks.
s'marks
