On Friday 17 September 2004 18:48, Raffael Herzog wrote: > On Fri, 17 Sep 2004 02:33:02 +0800, Niclas Hedhman <[EMAIL PROTECTED]>
> 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) And how big security hole is this, I wonder?? > 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. Hmmm.... > >> From a 'build' perspective, i.e. Avalon build, it becomes much more > >> complex. I > 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? ;) Maybe not a problem for our users, but for Avalon itself. If we put the @Dependency and other annotations in the Avalon source, we need to deal with it, since the distro has a requirement of being built with the JDK1.3. So it IS an issue. I think this whole thing need some time to 'cook'. The immediate problem is to get the Avalon source to build using JDK1.5, without using 1.5 features. Cheers Niclas -- +------//-------------------+ / http://www.bali.ac / / http://niclas.hedhman.org / +------//-------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
