Well the implementors of annotations in the JDK decided on this
classic
restriction :-
"only primitive, String, Class, annotation, enum are permitted as
the types of
the element in an annotation" meaning that you can't have an
element with an
interface type.
and we also can't "extend" an enum.
Ugh. Just confirmed this. Bummer.
In light of that restriction, my vote goes for the addition of an
IdGeneratorStrategy.CUSTOM label to be used in conjunction with a
customValueStrategy string element as mentioned below.
- Chris
P.S.: Is anybody talking about improving annotation semantics,
perhaps in the Java 7 timeline? There are multiple new JSR's
regarding annotations: 250, 305, 308, but no apparent effort to
rectify these issues we've been running into. I'd be interested to
hear if anyone's heard about any such effort.
On Aug 9, 2007, at 10:56 PM, Andy Jefferson wrote:
As a perhaps lighter-weight variant on Andy's option (2) below, could
we simply provide an alternative, string-based parameter to the
annotation, such as 'customValueStrategy'?
@Target({ElementType.FIELD, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface Persistent
{
// ...
IdGeneratorStrategy valueStrategy() default
IdGeneratorStrategy.UNKNOWN;
String customValueStrategy() default "";
}
If going for this case a "CUSTOM" value should be added to the enum
(rather
than using UNKNOWN - which is for where you don't want one, maybe
it should
be NONE instead of UNKNOWN), and when it is CUSTOM the user supplies
the "customValueStrategy". Similarly in @DatastoreIdentity
"strategy".
Another option could be to have IdGeneratorStrategy become a marker
interface and then have the enum be defined as something like:
public interface IdGeneratorStrategy {}
public enum StandardIdGeneratorStrategy implements
IdGeneratorStrategy
{
UNKNOWN,
NATIVE,
// ...
};
This would allow implementations to supply custom id generators in a
typesafe way:
package org.jpox.annotations;
public enum JPOXIdGeneratorStrategy implements
IdGeneratorStrategy
{
AUID,
// ...
};
I like this latter approach, because it demonstrates very clearly
that my usage is vendor-specific and non-portable.
--
Andy (Java Persistent Objects - http://www.jpox.org)
