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
|