[enhanced-enums]: Use case and rehabilitation?

[Maurizio Cimadamore]

Hi Bernard,
thanks for your email(s) - I can definitively buy that there are ways to 
make the javac code work with some of the clever tricks you figured out. 
However, I think we should also be careful not to mistake 'rewriting 
javac' as the end goal here. The goal is to smoothly extend the scope of 
the enum feature so that it would interop with generics too, in a way 
that makes it intuitive for people to use. Regardless of the tricks we 
can play, I see two fundamental (and partly related) issues with the 
current status of enhanced enums: (1) generifying an enum is not a 
source compatible migration; (2) one cold claim that EnumSet is a core 
part of the enum 'vocabulary' of any Java developer - so having a 
solution that forces you to use something else (such as TreeSet) would 
be sad.

So, while I don't object with the contents of your emails (and thanks 
for doing the exercise!) - I guess my question is: let's suppose some 
library developer has generified his enums. Do we expect all clients to 
go through the exercise you just went through? The bad things about the 
approach you sketched (and something I noted myself too), is that the 
approach is hardly mechanical - you need to do different things in 
different situations, depending on the context. This is where, I think, 
things get hard for the average developers who 'just wants to get things 
done'.

That said, maybe there's something in here - and if we can make the 
migration process smooth enough, maybe that's ok.

Thanks
Maurizio


On 13/09/17 21:46, B. Blaser wrote:
> Hi,
>
> I'd like to examine a bit more the use case along with the blocking
> reason expressed in [1].
>
> As explained, the main problem in using enhanced enums within javac
> options appears when invoking some methods like
> "EnumSet.noneOf(Option.class)". "Option" being raw, all type
> parameters are erased and the resulting type is only "EnumSet" which
> is causing problems in some situations.
>
> Another problem is in representing an heterogeneous set of options
> using "EnumSet<Option<?>>" which is currently impossible, as explained
> in [1].
>
> But fortunately, those problems are not blocking when refactoring
> javac options with enhanced enums.
>
> Here are the main keys:
>
> * "enum Option<X> {}" instead of "enum Option {}"
> * "EnumSet<Option<?>>" which doesn't work becomes "Set<Option<?>>"
> * "EnumSet.noneOf(Option.class)" which is raw becomes "new TreeSet<Option<?>>()"
> * "EnumSet.allOf(Option.class)" which is also raw becomes "new
> TreeSet<Option<?>>(Arrays.asList(Option.values()))"
>
> Then, we can start defining some options:
>
> * "D<String>("-d", ...)"
> * "PROC<ProcOption>("-proc:", ...)" with "enum ProcOption { none, only; }"
> * "G_CUSTOM<EnumSet<DebugOption>>("-g:", ...)" with "enum DebugOption
> { lines, vars, source; }"
>     notice that "EnumSet<DebugOption>" is well-formed here and there's
> no problem in using it
> * "RELEASE<Integer>("--release", ...) {
>         @Override // Overrides "public <X> X parse(String arg)"
> declared in "Option<X>"
>         public Integer parse(String arg) {
>             return new Integer(arg); // Simplified parsing
>         }
>     }"
>
> After parsing, we can provide them through "Options" and "OptionHelper":
>
> * "public <Z> void put(Option<Z> option, Z value)"
> * "public <Z> boolean isSet(Option<Z> option, Z value)"
> * "public <Z extends Enum<Z>> boolean isSet(Option<EnumSet<Z>> option, Z value)"
> * "public <Z> Z get(Option<Z> option)"
>
> And finally, we can use them conveniently:
>
> * "helper.put(lookup(primaryName), parse(arg))" in "Option"
> * "options.isSet(Option.PROC, Option.ProcOption.only)" in
> "JavacProcessingEnvironment"
> * "options.isSet(G_CUSTOM, DebugOption.vars)" in "Gen"
> * "Integer platform = options.get(Option.RELEASE)" in "Arguments"
>
>
> I've tried successfully this refactoring on the latest JDK 10 using
> the latest enhanced enums JDK.
>
> Do you think this would be interesting to rehabilitate enhanced enums
> and continue exploring them?
>
> Thanks,
> Bernard
>
> [1] http://mail.openjdk.java.net/pipermail/amber-spec-experts/2017-May/000041.html