RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map
stuart.marks at oracle.com
Fri Sep 22 20:37:39 UTC 2017
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
(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.
> 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:
>>> I read through the updated/new definitions and they read well.
>>> 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.
More information about the core-libs-dev