Skip to main content

Is abstract enum good for Java 7?

12 replies [Last post]
Joined: 2006-10-20

Trying to solve issue around JPA and property binding, I found that declaring enum that will be able to extends an "abstract enum" will provide a nice solution for some of Java 7 proposals and issues. I compiled my reasoning here:
I really like to know if it's worth exploring deeper, and trying to apply this idea in the Open JDK project.
Waiting for your comments,

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-10-20

Thanks a lot, I think I will start a patch soon.
It looks like there was a trauma around JSR 201 and enum (see )
where there is:
"JSR201 deliberately restricted Enums in terms of subclassing etc. I doubt if we will re-open this can of worms again."
But it was 2 years ago, so...

Anyway, about generics in Enum you are right and I want to see if with "Reify generics" there is a nice solution to this. By the way, in my proposition for "abstract enum PropertyDefinition" I will need generics for the get and set like you said. But since the parameter is per enum instance I need "reify generics", so... I will wait!

Joined: 2004-05-23

> Thanks a lot, I think I will start a patch soon.
> [...]
> Anyway, about generics in Enum you are right and I
> want to see if with "Reify generics" there is a nice
> solution to this. By the way, in my proposition for
> "abstract enum PropertyDefinition" I will need
> generics for the get and set like you said. But since
> the parameter is per enum instance I need "reify
> generics", so... I will wait!

How come you need reified generics? My knowledge here breaks off, but it seems that the constant declarations are shorthand for a regular constructor, and so the argument type is inferable just like it is in all other locations. You can either infer it from the constructor arguments, or you can use one of two ways of declaring the constant: [this is where my knowledge falls off:] use the "regular" constructor form, CONSTANT(), or use an implicit type argument somehow, CONSTANT() (and actually, "CONSTANT()" might be an implicit argument itself; but I just don't know for sure here exactly).

And if nether of those fits with the current correct syntax: Enums are handled specially, so maybe a special case for declaring constants can be handled.

Are you sure you need reified generics for this part?

And after reading some of those other comments, the point that you can use static methods to create unique implementations for things you might want to make subclasses for seemed valid to me. It's not as elegant, but you can do it by looking up your constant by name and looking up the correct implementation for that constant.

My feeling on this was that enums with a very large number of elements that all may have unique behaviors might be a bad implementation. Such a thing might be better refactored. So maybe giving all enums the ability to grow indefinitely, and orthogonally is not the best.

I definitely do wish generic constants were possible because I think it can be done both succinctly and it's appropriate too.

If you have a short enum type where each element has unique behavior it might be very appropriate. But actually, we have the ability to write many other runaway types currently, so maybe worrying about long enums with constants that vary as widely as any subclass may is not an important thing to worry about. And in fact, even a long enum like that can't be categorically ruled out of applicability completely.

So after all that I think this is a good idea.

Any new comments on the non-reified generics?

Steev Coco.

Joined: 2006-10-20

You are right, reified generics will not help directly. I was thinking about it because today each "PropertyDefinition" instance is creating a typed wrapper PropertyWrapper(), and I'm loosing this info due to the erasure.
But now with "abstract enum" I don't even have a special constructor per property, so your suggestion of generics in enum is the only one that will work.
enum property { firstName(), ... }

If it's generated by javac OK, if not that will look strange.
By the way this is related to the issue with method references MyModel#setTime(Timestamp) were the repetition of parameter types is mandatory for the language but not for an IDE.

Joined: 2006-10-20

So, I finally managed to get a patch for abstract enum working good enough to be used. You can download the patch for the KSL trunk rev 16 at:
And I detailed the adventure into the KSL here:

So now I can compile and run:
public abstract enum AbstractColumn {
String columnName;
int precision;
AbstractColumn() {
columnName = name();
precision = 0;
AbstractColumn(String c, int p) {
public String getColumnName() {return columnName();}


public enum CustomerColumn extends AbstractColumn {
firstName, lastName, age;
public String getColumnName() {
return StringUtils.capitalizeWithUnderscore(name());

Working on using the abstract enum inside annotations attributes...

All my blogs:

Joined: 2006-10-20

I wrote the patches for build b14, allowing Abtract Enum with possible usage in Annotations.
They are availiable here:
The last current limitation is the need to have "public abstract enum AbstractE2> extends Enum", because I need to make the generics declarations ">" generated by synthetic sugar.
When solving the above I will see how to allowing generics declaration in Enum (liked steevcoco proposed).

The RFE entry is here:

Hope someone will find interest like I do, in this...

Message was edited by: freddy33

Joined: 2003-08-24

I think if one of you posts a simple example of abstract enums it would go a long way toward explaining your views to others. Right now it isn't clear (to me at least) why you need abstract enums and what value they add above the existing enum mechanism. The state machine example is too complicated and I didn't find a better example using Google.


Joined: 2006-10-20

I tried to push "abstract enum" futher to state machine writing, and I like it a lot.
Here you see the conversion of state machine by annotations with "abstract enum" looks almost perfect.

Joined: 2006-02-02

I would like to be able to implement interfaces with an enum. This also can't be done because of the "can't extend a class that refers to itself in it's generics" rule. I like the syntax for annotations. The less quoted strings hard coded the better as far as I'm concerned.

Joined: 2006-10-20

Thanks, I really feel that I'm doing something wrong when passing a strings that represent my code.
For the interfaces with enum, you have actually a very powerful enum since you can even inline the implementation on the enum. I used it also and it looks like:

public interface Projection {
Point project(Point p);
String name();

public enum ProjectionType implements Projection {
J2000{public Point project(Point p) { return caculateJ2000(p); },
EarthEqu{public Point project(Point p) { return caculateEarthEqu(p); },
Local{public Point project(Point p) { return caculateLocal(p); },

But, it's still does not solve the boiler plate code between enum of the same type, and the inability in Annotation to have attribute of some "generic enum".

Joined: 2004-05-23

Absolutely yes! You can mark your forum posting "answered" if you ask me!

I also have seen the need for this. It's silly that you can't make generic enum types. We should also gain the ability to declare enum constants that have individual unique type arguments. Like

enum MyProperty {


private final V def;

private MyProperty(final V def) {
this.def = def;

public V get() {
return getFromSomewhere(def);

public void set(final V value) {


I think it would be great.


Joined: 2006-05-02

Could someone that understands all the binding proposals comment about its application?

Joined: 2006-10-20

I found an early discussion about this with Java 5:
and I really think it is a good time for it in Java 7.
This is the main reason people are not using enough enum and enum in Annotations.