2 questions about enums and the closed/withdrawn JEP 301

[Maurizio Cimadamore]

On 29/03/2023 14:14, Archie Cobbs wrote:

> Regarding that problem, would it work to just add "workaround" methods 
> like this?
>
>         public static <T extends Enum<T>> EnumSet<T> 
> noneOfGeneric(Class<? extends T> klass)
>
> Even though klass has type Class<? extends T>, at compile time, you're 
> not going to be able to specify any Class constant other than the top 
> enum class, so no problem there, and at runtime, this method could do 
> introspection to find the top enum class (if necessary; unlikely) and 
> then use that.

I don't think that would help much. To show why, let’s step back a bit, 
and let's ignore enums completely.

Consider the following recursive generic type declaration:

|class Foo<X extends Foo<X>> { ... } |

Now let’s define a container type for our Foos:

|class Box<X extends Foo<X>> { X get(); void set(X x) { ... } } |

Given these declaration, the following types are *not* well-formed types:

|Box<Foo> Box<Foo<?>> |

The following is legal:

|Box<? extends Foo> |

But that is also a type that has significantly different characteristics 
from the ones above - e.g. you can’t call |Box::set| on it. So, even 
before getting to generic methods accepting Foos, we have a much more 
fundamental problem: we can't even express the type of a variable of 
type |Box<Foo>| in the type-system (!!).

What we realized was that JEP 301 rubs exactly againt this problem (just 
s/Foo/Enum and s/Box/EnumSet) - which means code using non-generic enums 
doesn’t have a clear migration path towards generified enums.

Maurizio

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230329/332d300b/attachment.htm>