Ah, yup, not supported by the syntax. But... isn't this possible? I suppose this turns into a request for enhancement now. Couldn't this be made to work? All you would need is the syntax support for the parametrized constructor call. I don't see any fundamental rules this would break.

I'm not saying the requested feature is useful (I'd have to think about that a bit more), but I don't see why it would be impossible? Basically you'd define a per-value concrete type for the type argument defined on the enum class definition.

I don't see why it would be impossible to tweak the JLS to allow this.
You claim that it's impossible

I most certainly claimed no such thing.

Correct.

You claimed that it's impossible to instantiate the enum when the question was already at the point of tweaking the Java language.

So why not provide a type parameter to an enum and specify a concrete type for different values?

I don't know: why not? Why are you asking me? The decision has nothing to do with me.

I was asking the question because I interpreted your "there's no point" (wrongly?) as "there's no point in modifying the Java language to allow this".

I'm just asking for a concrete motivation. I haven't been given one yet.

The example posted looks like a pretty concrete motivation to me. With the example enum I can easily create a ContainerType object (of any type if I don't care), but I can also create specific FooContainer by using CommonContainers.BOX.createConteiner(). That way I can use the enum and still be typesafe with APIs that expect a FooContainer.

ejp wrote:
I'm just asking for a concrete motivation. I haven't been given one yet.

The example posted looks like a pretty concrete motivation to me. With the example enum I can easily create a ContainerType object (of any type if I don't care), but I can also create specific FooContainer by using CommonContainers.BOX.createConteiner(). That way I can use the enum and still be typesafe with APIs that expect a FooContainer.

Exactly. I'm aware that this may be taking enums somewhere they aren't supposed to go, or may be taking generics just way too far, which is why I posited the question on the forums. I'm just trying to enforce type safety at compile time with this specific case. There may be some other, suitable, way to do this, but enums just seemed to be so well suited to this.

Basically, my motivation for this is to provide an enum that acts as a "template" (for lack of a better word) of sorts. I have a class, and there are certain combinations of field states that I KNOW that users of this class will commonly be referring to. The constants provide an easy way to instantiate the class and place it in the proper state for immediate use, as well as provide a common identifier for that specific descriptor.

Now, I know this could be done without the enum facility, (I've already decided I want the type safety more than I want the enum features) but its just handy being able to switch on the constants, use them in EnumSets and Maps, and use the other facilities provided by the Enum class.

MutantPlatypus wrote:
Basically, my motivation for this is to provide an enum that acts as a "template" (for lack of a better word) of sorts. I have a class, and there are certain combinations of field states that I KNOW that users of this class will commonly be referring to. The constants provide an easy way to instantiate the class and place it in the proper state for immediate use, as well as provide a common identifier for that specific descriptor.

Now, I know this could be done without the enum facility, (I've already decided I want the type safety more than I want the enum features) but its just handy being able to switch on the constants, use them in EnumSets and Maps, and use the other facilities provided by the Enum class.

So this is basically the factory method pattern? It's quite common for a factory method to be static, so it isn't much of a leap to make the enum element itself be a factory.

I did. It is. You can't do new MyEnum<Integer>, or even new MyEnum(). That's not just a 'claim', it's a fact.

Of course you are right.

It's just that in my mind objects don't exist without instantiation and the enum values are objects (and they do get to execute the constructor), so I'd say (in my in-precise language) that there is some instantiation involved in declaring enum values. But that's beside the point.

But I was missing the point. The usage the OP is proposing is something else, a class that has differently parameterized instances of itself declared as members. Rather like: