RFR(m): updated: JEP 269 initial API and skeleton implementation (JDK-8139232)

[Maurizio Cimadamore]

On 08/12/15 00:19, Stuart Marks wrote:
> Hi Maurizio,
>
> Well, maybe we should add five more overloads to EnumSet.of()? (Only 
> slightly joking here.)
>
> Setting aside the number of overloads, it would add N more overloads 
> to Set.of(). I guess the erasure of <Z extends Enum<Z>> would be Enum, 
> so there wouldn't be any overload ambiguity....
right - no ambiguity
>
> To me the question here is whether this adds sufficient value. The 
> advantage is that one could write
>
>     Set.of(MyEnum.ONE, MyEnum.TWO, MyEnum.THREE)
>
> instead of
>
>     EnumSet.of(MyEnum.ONE, MyEnum.TWO, MyEnum.THREE)
>
> and get an optimized EnumSet instead of a Set that contains object 
> references. Is it worth it?
I'm not too worried about the fact that typing 'EnumSet' is more verbose 
than just 'Set', obviously; but it would seem reasonable to try (within 
reasonable bounds) to provide uniform way to create collections and a 
smooth user experience.

I think with the current status quo, we have that:

Set.of(A, B, C) != EnumSet.of(A, B, C)

and that's surprising, IMHO. At the same time I notice that, even with 
the overload I suggest, they would still be different beasts, as one 
would be mutable, while the other would not.

That said, I think we should aim for an API where such bad surprises are 
avoided (why is my enumset so slow? Ah - it's not an enumset because I 
used the wrong XYZ.of method); unfortunately I don't have a good 
suggestion on how to get there :-( (which might mean that what you did 
is correct :-) )

Maurizio
>
> Presumably this would result in an instance of an immutable EnumSet. 
> Does this case come up that often?
>
> s'marks
>
>
> On 12/4/15 2:22 PM, Maurizio Cimadamore wrote:
>> Hi Stuart
>> small question: I find it a bit odd that EnumSet has max 5 
>> parameters, while Set
>> has more than that.
>>
>> Also, would it be possible, maybe to add overloads to Set that 
>> specifically
>> works on Enum constants?
>>
>> <Z extends Enum<Z>> of(Z z1, Z z2) { ... }
>>
>> This would give you a way to call Set.of and get different answers 
>> based on the
>> static type of the arguments passed in - and we could deprecate the 
>> of method in
>> EnumSet?
>>
>> Too subtle/magic?
>>
>> Maurizio
>>
>> On 02/12/15 02:35, Stuart Marks wrote:
>>> Hi all,
>>>
>>> Thanks for the previous round of review comments. Here's an updated 
>>> API and
>>> implementation for review.
>>>
>>> I've run specdiff with the --hu ("hide unchanged") option, so only 
>>> the bits of
>>> the specification that have changed are shown. As before, though, 
>>> please
>>> ignore the spurious change to EnumSet caused by a javadoc bug.
>>>
>>> API changes:
>>>  - add clarifying notes on immutability
>>>  - remove wording that implied creation of new objects
>>>  - add "value-based" disclaimers
>>>  - add ordering specification for List and non-ordering disclaimers
>>>    for Set and Map
>>>  - clarify that Map.ofEntries() doesn't store the Map.Entry objects, 
>>> instead
>>>    it extracts keys and values
>>>  - Map.Entry instances returned from Map.entry() are *not* serializable
>>>
>>> Other:
>>>  - markup cleanups
>>>  - small implementation cleanups
>>>
>>> JEP:
>>>
>>>     http://openjdk.java.net/jeps/269
>>>
>>> API spec (basically List, Map, and Set):
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/
>>>
>>> Specdiff:
>>>
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html 
>>>
>>>
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/
>>>
>>> Thanks,
>>>
>>> s'marks
>>