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.) > - Just use them for apt (RetentionPolicy.SOURCE). Ok. RetentionPolicy is defined during the run of APT ?? > What I'm proposing is RetentionPolicy.SOURCE for all annotations and > simply generating .xinfo files, just like the current JavaDoc based > processor does, as an alternative to the current system. I have a better idea. 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. >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). Cheers Niclas -- +------//-------------------+ / http://www.bali.ac / / http://niclas.hedhman.org / +------//-------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
