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

Stuart Marks stuart.marks at oracle.com
Tue Dec 8 00:19:54 UTC 2015


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....

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?

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
>



More information about the core-libs-dev mailing list