Support for JDK 1.5 enum parameter types?

[adepue]

I'm wondering if Spring currently provides any kind of support for JDK 1.5 (J2SE 5?) enum parameter types? Take this example enum:

public enum Type { OLD_AND_BUSTED, OLD_AND_WORKING, NEW_HOTNESS };

Now say I have a setter method like so:

public void setType(Type type) { ... }

I would like to do the following in my Spring XML config:

<property name="type"><value>NEW_HOTNESS</value></property>

or at least:

<property name="type"><value>Type.NEW_HOTNESS</value></property>

I would even be satisfied with:

<property name="type"><value>com.mypackage.Type.NEW_HOTNESS</value></property>

Although that is awfully verbose. Since the enum type can be inferred from the parameter type on the set method, it seems the first option should be doable?

- Andy

[Colin Sampaleanu]

Right now Spring itself has no JDK 1.5 specific features. In the parallel 'samples' cvs module, specifically the 'tiger' project, there is some code for handling annotations, but that's about it.

[adepue]

Is Spring planning on providing 1.5 features? How would this be handled, since 1.5 compiles tend to not be backward compatible with older JVMs (which is a rant for another forum)? I would be happy with a separate compile (.jar) for 1.5, though it would be cool if 1.5 features were detected and enabled at runtime via a 1.4 compatible binary... not sure how you would pull this off (maybe using reflection? I know Class provides additional methods - not sure if you can reflect Class itself). I'm not familiar enough with 1.5 yet to know why it isn't backward compatible or if there are easy ways of providing backward compatibility while still having 1.5 features available when running on 1.5? I know during previous upgrade cycles I could sometimes catch JVM exceptions in code blocks using new features and then use an alternate code path - though this is kind of hacky.

- Andy

[Colin Sampaleanu]

We can use a few features via reflection if there is a strong advantage. This is pretty much work though. Where it makes sense as a separate package, the code can be handled as a separate module, like the Annotations code. It's going to be a long while though before we start requiring 1.5 to compile even, never mind to run, for the main codebase.

[adepue]

Actually, for my needs, I think this could be accomplished without explicit JDK 1.5 support if Spring provided a simple way to lookup any constant style value (public static final T X = Y). How about this algorithm:

For a particular property (P), if there is no default conversion or property editor for P's type (T) then attempt to take the String value in the XML and lookup a public static final field of type T  against T's class as the new property value (V).  If found, then set P to V.

Say I have this setter:

public void setType(AccountType type) { ... }

and this XML:

<property name="type"><value>ASSET</value></property>

There is no defaul or automatic conversion available (type isn't a primitive or anything), so Spring would look for a property editor. In our example, there would be no property editor, so Spring would now look for a public static final field named ASSET in the AccountType class (that would itself be an instance of AccountType). If found, Spring would pass in this public static final AccountType instance to setType(...). Maybe another step in the algorithm would be to look for a public static valueOf method that takes a String argument and returns the class type?
Also, I believe it would be useful to do field lookups for constants in general. Say I have an old-style int constant:

public void setType(int accountType) { ... }

Maybe I could do something like:

<property name="type"><value-of>com.mypackage.Constants.ASSET_TYPE</value-of></property>

Thoughts?

- Andy

[Colin Sampaleanu]

I think this could possibly work, although I'm trying to think of any possible side effects. However, the real solution is for us to actually put in expression support, which has been planned for quite a while...

In the meantime, it's verbose, but you could use FieldRetrievingFactoryBean, I think...

[adepue]

Whew, now that would be the bomb. With all the EL libraries out there (JEXL, Commons EL, even Groovy) this should be easy, right? :-)

- Andy