Description Henrik Lindberg 2010-10-12 11:23:18 EDT

Using the EMF API to get information about EObject instances is a very useful mechanism (get EClass, get EPackage etc.), but there is unfortunately no easy way to do the same given a java Class<? extends EObject>.

I found a way to implement support for this with both minimal effort and footprint. Since Java 1.5 it is possible to annotate java.lang.Package instances, and such an annotation can hold the EPackage URI.

The implementation consists of a single annotation - here called EMFPackage.java :

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.PACKAGE)
public @interface EMFPackage {
 /** The EPackage URI */
 String value() default "";
}
<EOF>

Given that a Package has this annotation it is possible to do the following:

Class<?> x = ...
EMFPackage ep = (EMFPackage)x.getPackage().getAnnotation(EMFPackage.class);
String epackageURI = ep == null ? null : ep.getValue();
// w00t !!

In order to make this work - the code generator should output a file called 'package-info.java' ([sic] this does not conform to the java class file name rule as defined in the Java 1.5 spec).

Each generated package where E-ness is exposed should have this file with content in the following form:
/**  @generated */
@EMFPackage(<PACKAGE URI STRING>)
package <PACKAGE NAME>;
import org.eclipse.emf.EMFPackage; // or wherever it should go...
<EOF>

The runtime footprint is one annotation object per package + the URI String.

The 'package-info.java' should be placed in both interface and implementation packages to avoid having to search for the annotation (given an Impl class and 'package-info.java' was not in this package), all interfaces needs to be examined (possibly finding contributions from multiple EPackages???).

Naturally when the E-ness of the generated code is hidden it may also makes sense to exclude the @EMFPackage annotation. The 'package-info.java' is still very useful as it provides a place to keep the javadoc for the package.

Although there is no guarantee (defined in the spec) that the annotations and retention policies are honoured, such support is expected by a quality mainstream JRE IMO.

I would really like to see support for this in EMF, and hope others also see the benefits. In my particular use case I am interested in finding metadata in a runtime scenario where there is no JDT, and no source available and I want to offer users more info (+ more features) than what I can offer using just java.lang.reflection.

My first implementation used the Namespace URI - don't know if it or the EPackage URI is the most flexible and valuable to get.

Comments?