Expose elementType of EnumSet and EnumMap

Joe Darcy joe.darcy at oracle.com
Sat Sep 21 20:30:06 UTC 2013

On 9/21/2013 11:43 AM, Marcin Wiśnicki wrote:
> First of all EnumSet/EnumMap are not general purpose collections, they
> are already implementation specific.
> Also, since you can't subclass enum, class of contained values will be
> the same as declaring class.

No, not necessarily.

Specialized enum constants can be implemented by having anonymous 
subclasses of the enum type.

The following two enums declarations are semantically equivalent:

// 1st
public enum MetaSyntVar {
     private int answer;
         MetaSyntVar(int answer) {
         this.answer = answer;
     public int answer() {
     return answer;}

// 2nd
public enum MetaSyntVar {
     FOO {
         public int answer() {
             return 21;}},
     BAR {
         public int answer() {
             return 42;}};
     public abstract int answer();

The former compiles down to one class file; the latter compiles down to 


> >From EnumSet documentation: "All of the elements in an enum set must
> come from a single enum type".
> I don't see how exposing getElementType() can hinder reification. I'm
> going to say that it doesn't. Please provide counterexample if you
> think I'm mistaken.
> Here are your use cases:
> 1. Remove ugly hacks from serialization libraries that were known to
> cause problems with different JVM implementations in the past (for
> example see this code from jackson: http://goo.gl/yudBps)
> 2. A Visual editor of some sort may display EnumSet as a list of
> checkboxes if it knows what type of enum values can be contained
> within this set.
> On Sat, Sep 21, 2013 at 8:15 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> On 09/21/2013 05:27 PM, Marcin Wiśnicki wrote:
>>> Third party serialization libraries and other tools need to know the
>>> type of EnumSet elementType. Currently this field is package-private
>>> and said libraries have to resort to non-portable reflection hacks.
>>> Please add EnumSet#getElementType() and EnumMap#getKeyType() methods.
>>> I've submitted this request to bugs.sun.com last month, where it
>>> received Bug Id: 9006352. There was no further communication and that
>>> bug is still not visible which doesn't surprise me as I've never had
>>> any luck with bugs.sun.com even when submitting actual bug :(
>>> PS. Please keep me CC'ed.
>> Hi Marcin,
>> I've read the bug file but failed to find a description of a compelling use
>> case for these methods.
>> Adding these two methods goes against an important rule:
>> try to avoid for sub-types of Collection, methods that are implementation
>> specific, the history has proven multiple times that implementations of
>> collections change a lot. This is a general rule, that we may want to ignore
>> but it has to worth it.
>> Also, I think it worth to understand what's elementType represent.
>> elementType is not the class of the values contained in the set but the
>> declaring class (Enum.getDeclaringClass) of the enum values. So despite
>> being a Class, elementType is a type information that only exists has a
>> field because generics are not reified. This has two consequences, the first
>> one is that if you want to create an EnumSet, you need a way to have an
>> elementType and the second one is that it may make the work of the people
>> that want to reify generics in a future version of Java harder.
>> and don't think I'm the dragon that keep the treasure, this is just my
>> humble opinion and I try to do my best to explain why adding these methods
>> is not obvious.
>> regards,
>> Rémi

More information about the core-libs-dev mailing list