Re: Generating Avalon meta information using apt

On Fri, 17 Sep 2004 02:33:02 +0800, Niclas Hedhman <[email protected]>  
wrote:

> On Friday 17 September 2004 01:40, Raffael Herzog wrote:
>
>> Annotations can be used in several ways:
>> - Read them using Reflection at runtime (RetentionPolicy.RUNTIME).
>
> Ok.
>
>> - Keep them in the class files for later instrumentation, but don't keep
>> them accessible at runtime (RetentionPolicy.CLASS). Instrumentation can  
>> be
>> done with a post-processor or using the java.lang.instrument package at
>> load time.
>
> Not sure what this means in reality. I assume it is something 'similar'  
> to
> Dynamic Proxy, into the annotations of a particular class that the  
> instrument
> wraps. (Guessing wildly, based on how I would have done it.)

No, it allows you to manipulate the class file (as byte array) before it  
is defined by the class loader.

The interface (ClassFileTransformer) is rather simple:

byte[] transform(ClassLoader loader,
                  String className,
                  Class<?> classBeingRedefined,
                  ProtectionDomain protectionDomain,
                  byte[] classfileBuffer)


>> - Just use them for apt (RetentionPolicy.SOURCE).
>
> Ok.
>
> RetentionPolicy is defined during the run of APT ??

No, this has nothing to do with APT. RetentionPolicy is an enum and is  
specified using the @Retention meta annotation.

Some examples for annotation types:

@Target({ElementType.CONSTRUCTOR, ElementType.METHOD})
@Retention(RetentionPolicy.SOURCE)
public @interface Context {
     Class<? extends org.apache...Context> type()
         default org.apache...Context.class;
     Entry[] entries() default {};
}

@Target({})
@Retention(RetentionPolicy.SOURCE)
public @interface Entry {
     String name();
     Class type() default String.class;
     boolean optional() default false;
}

These are some kind of Java classes that implement the interface  
java.lang.annotation.Annotation, that's it.

Usage:

@Component(...)
public class MyComponent {
   @Context(entries={@Entry(name="urn:avalon:name"),
                     @Entry(name="urn:avalon:home", type=File.class)})
   public void contextualize(Context ctx) throws ContextException {
     ...
   }
}

Javac includes this data in the class file. *If* you run apt and have some  
AnnotationProcessorFactories that announce themselves through SPI, these  
AnnotationProcessorFactories will be used to generate code. apt is *only*  
needed if you want to do something with the annotations at compile time.


> We have already planned to do a fairly large refactoring of the current  
> Meta
> package.
>> From a 'runtime' perspective, it will be possible to specify more than  
>> one
> provider of Meta extraction, and where Java2v5 could be one (and in the
> future the preferred one). Details on this has not been worked out yet,  
> but I
> assume this is a pretty good use-case to figure it out.

Well, I don't think it's a very good idea to actually use annotations at  
runtime. It would be just another way of specifying the same while not  
eliminating the need for some additional meta information in a file. You  
certainly don't want to load every single class in the classpath just to  
be able to look at its annotations and collect its metadata. Scanning the  
JAR files for .xinfo entries is just fine.


>> From a 'build' perspective, i.e. Avalon build, it becomes much more  
>> complex. I
> am not sure how we are going to manage to build some parts with a JDK1.3
> compiler and some with a JDK 1.5. Perhaps we can get away with a JDK1.5
> compiler (with 1.4 compliance checking where relevant) for the Metro  
> project,
> and leave Avalon with its JDK1.3 requirement (mainly stipulated by  
> Cocoon).

Building isn't really a problem if you keep annotations out of the runtime  
system -- everyone uses the compiler that fits. Of course, it might be  
necessary to provide more/different metadata, but that's what the version  
numbers of the DTDs are for, isn't it? ;)


cu,
    Raffi

-- 
raffael herzog
software engineer

codeshack ag
smart software solutions

hardstrasse 219, postfach
8037 zurich - switzerland

tel: +41 43 444 65 65
fax: +41 43 444 65 66

[email protected]
www.codeshack.ch