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([EMAIL PROTECTED](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 oneprovider 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. Iam 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
