JDK-8061399 : Support for public abstract enum declaration
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Priority: P5
  • Status: Closed
  • Resolution: Other
  • Submitted: 2007-06-18
  • Updated: 2014-10-17
  • Resolved: 2014-10-17
Related Reports
Relates :  
Relates :  
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
Give the ability to create abstract classes between the final enum declaration containing the static enumerated values, and the abstract superclass for all enum java.lang.Enum.
So an AbstractColumn.java file can contain:
public abstract enum AbstractColumn {
   String columnName;
   int precision;
    AbstractColumn() {
       columnName = name();
       precision = 0;
   }
  AbstractColumn(String c, int p) {
   ....
   }
   public String getColumnName() {return columnName();}
}

And inside an O/R Mapping framework an annotation can be:
public interface @Column {AbstractColumn definition();}

And then the application users have the level of indirection they need to provide logic to the framework using the static annotations. For example:
public enum CustomerColumn extends AbstractColumn {
  firstName, lastName, age;
   public String getColumnName() {
      return StringUtils.capitalizeWithUnderscore(name());
   }
}

@Entity
public class Customer {
  @Column(definition = CustomerColumn.firstName)
  private String firstName;
}

Then all the problems of hardcoded schema names, copy/paste, string based errors (no type safety), and so on disappear.
  From my experience, the limitations of Annotations are really pushing developers away, and this feature can unlock the issue.

JUSTIFICATION :
The request was already reported in Bug ID: 6222244 and Bug ID: 6507006.
For example: http://beust.com/weblog/archives/2004_04.html
There is a big demand to have more flexible annotations, and one big solution is this one: Have the user define its own enum classes that extends a specific abstract enum provided by the framework, and use this specific enum in the framework annotations.
With this, if you want to redirect to XML configuration, nothing stops you...


---------- BEGIN SOURCE ----------
/*
 * @test @(#)AE1.java	1.7 08/06/07
 * @summary support for abstract enum
 * @author freds
 *
 * @compile AE1.java
 */

package abstractEnum.ae1;

public abstract enum AE1 {
    int i;
    AE1() {i=2;}
    AE1(int pi) {i=pi;}
    public int getI() {return i;}
}

/*
 * @test @(#)E1.java	1.7 08/06/07
 * @summary support for abstract enum
 * @author freds
 *
 * @compile AE1.java E1.java
 */
public enum E1 extends AE1 {
    one(1),two;
    E1() {
    }
    E1(int pi) {
        super(pi);
    }
}

/*
 * @test @(#)AnnoAETest.java	1.7 08/06/07
 * @summary support for abstract enum
 * @author freds
 *
 * @compile AnnoAETest.java
 */
public @interface AnnoAETest {
    AE1 ae1();
}

/*
 * @test @(#)AnnoAEUsage.java	1.7 08/06/07
 * @summary support for abstract enum
 * @author freds
 *
 * @compile AnnoAEUsage.java
 */
public class AnnoAEUsage {
    @AnnoAETest(ae1 = E1.one)
    private String fisrt;
}

---------- END SOURCE ----------

Comments
The 'specification' component of the Java Bug System is for reporting technical errors and ambiguities in the text of The Java Language Specification and The JVM Specification. It is not the venue to propose new features in the Java language or JVM. Ongoing feature development is carried out in OpenJDK (http://openjdk.java.net/jeps/); corresponding enhancements to The Java Language Specification and The JVM Specification are managed through the Java Community Process (http://jcp.org/).
17-10-2014

EVALUATION From the JSR201 FAQ: "With the Typesafe Enum pattern described in Effective Java, it is possible to subclass an enumerated type. Why is this not allowed by the language feature? The semantics of inheritance for enum types is too confusing. People expect subclasses to contain the enumeration constants from both the superclass and the subclass, but they contain only the subclass constants. Further, the compiler generates two static methods for each enum class providing operations on the entire class (values() and valueOf(String)). These methods are defined using the list of constants found in the enum declaration, hence subclassing would break them. More seriously, allowing subclassing of enums would render switch statements ambiguous if multiple subclasses of an enum class contained enum constants with the same simple name. All things considered, the complexity inherent in allowing subclassing is too great to justify it." The text above discusses arbitrary subclassing. I see from your site [1] that you do not permit arbitrary subclassing - all you allow is an abstract enum (without constants) subclassed directly by one or more non-abstract enums. That supports your particular use case: 1) An abstract enum contains code only. 2) Constants are only defined in a non-abstract enum 'subclass', and are always referenced as members of that subclass. (More generally, constants are always used in a context where they are members of a particular subclass.) (2) avoids the first problem from the FAQ. (2) also explains why you are are prepared to restrict switches to variables of NON-abstract enum type, and it makes the third problem goes away. The second problem is tricky. Your abstract enums are enums so they must support values(). What do you return? You could return an empty collection, but that is not in keeping with the aim of enums as outlined by Neal Gafter [2]: "First, the whole idea of an enum is that you statically enumerate ALL the members of the type. If you can extend the type and add members (via subclasses) later, then the purpose is defeated. Members of the extended enum are indeed values of the base enum type, as it is a subtype. So the must be listed in the VALUES of the base class. Ignoring the question of how the compiler can possibly arrange that, is this really what anyone would want?" Overall, there may be some merit in your use case. We will not rush into extending the design space of enums, particularly in ways contrary to JSR201's intent, but I will keep this request around to track the KSL work. [1] http://www.jfrog.org/wiki/index.php/Fred:Abstract_Enum_Patch [2] http://forum.java.sun.com/thread.jspa?threadID=427486&messageID=1932298
19-06-2007