Enhanced Enums -- use cases

[Stephen Colebourne]

I have examined the uses of Enum in our codebase as best I can. I
remain skeptical that this feature adds enough value, although the
ability to use different generic types on each instance would no doubt
be useful on occasion.

In every case I examined (about 150 enum types), the enum methods
needed to be on the enum itself. There were no cases I could find
where a method made sense to be pushed down to the constant, nor where
a field on the constant made sense. This is not surprising as the enum
is the type, and as such should have the behaviour.

There were a couple of occasions where I thought it might apply.
However, on further examination I convinced myself that a standard
method on the enum with different implementations for each enum
constant was a better solution (thus no need for this feature).

The fundamental reason for this is two-fold. Firsty, enums are mostly
used to restrict a set of standard codes, typically to meet a business
requirement, thus they have no behaviour. Secondly, most enums that do
have behaviour  I can see reduces to:

SomeEnumType t = obtainEnumFromString();
// t passed around through lots of other code
t.doSomething();

ie. the method must be called on the enum type. There is rarely the
opportunity to use a sharper type, because the constant itself is
rarely used directly in the code. (The main places where the constants
are used is in tests)


What is annoying about the current implementations is the ceremony of
setting up per instance data.

  public enum Status {
    BAD_USAGE(64),
    BAD_OR_MISSING_DATA(65),
    GENERAL_ERROR(70),
    VALIDATION_FAIL(75);
    private final int exitCode;
    Status(int exitCode) {
      this.exitCode = exitCode;
    }
    public int getExitCode() {
      return exitCode;
    }
  }

It seems that the constructor and/or private field and/or method are
information that could be inferred to some degree.

Stephen


On 11 April 2017 at 20:11, Brian Goetz <brian.goetz at oracle.com> wrote:
> As you may have noticed, we pushed an implementation of Enhanced Enums some
> time ago.  We're hoping to get user feedback on the feature as it is now
> implemented.
>
> To get things started, here are some typical use cases where generic enums
> might be useful.  Please contribute others, as well as places in the JDK
> where code could be refactored using this feature.
>
> An obvious example is com.sun.tools.javac.code.Dynamic
> (http://hg.openjdk.java.net/valhalla/valhalla/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Dynamic.java#l51),
> where we have an enum that represents the kinds of types representable in
> the constant pool.
>
> In that case, these factory methods:
>
> http://hg.openjdk.java.net/valhalla/valhalla/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Dynamic.java#l137
>
> should be collapsible to a single generic method:
>
>     <D> static BootstrapArgument<D> constant(Kind<D> kind, D data).
>
>
> Another example is command line parsing; for command line arguments, we can
> represent them as enums whose type represents the type of an (optional)
> parameter:
>
>     enum Args {
>         QUIET<??>("quiet", "q"),
>         FILE<String>("file", "f"),
>         COUNT<Integer>("count", "c"), ....
>     }
>
> (though its not obvious what the type arg of QUIET should be.)
>
>
> If anyone wants to experiment and offer their experience in applying (or
> misapplying) this feature, either to the JDK or their own codebase, that
> would be appreciated....
>
>