On 27 Mar 2004, at 08:09, Patrick Calahan wrote:
At 05:05 AM 3/27/2004 +0000, [EMAIL PROTECTED] wrote:I'd personally love to see JAM available as a separate package somewhere with support for both a JDK 1.4 and JDK
The good news here is that there is no need for separate 1.4 and 1.5 versions. JAM's internals are factored in such a way that the same binary will run under both 1.4 and 1.5. When you are running under 1.5, JAM becomes 175-aware; when you're running under 1.4, JAM simply doesn't understand 175 annotations.
Cool
(Actually, this last restriction may be removed if I ever get around to finishing my own java source parser - when that's done, you actually will be able to deal with 175 annotations under 1.4 if you have the original source files available. For that matter, it's not too hard to imagine writing something that parses the 175 annotations out of a classfile while running 1.4 - it's just not clear to me that anyone will have a need to do this).
BTW QDox can already parse Java source codes quickly for this kind of job...
http://qdox.codehaus.org/
1.5 version. It sounds great! I'd also love to see some experiment done on a JDK 1.4 runtime metadata support so
that, say, as part of the build process we can turn doclet tags into some generated classes so JAM could introspect the annotations at runtime in a JDK 1.5-style way.
There is support in there now for exactly this kind of thing, and I'm starting to use it in xml-beans. The basic idea is you write your own 'annotation proxy' class which can be populated from javadoc tags. By default, it is populated by lining up tag values with method names on your class, but you can easily customize this mapping by overriding a method or two. The proxy class most likely will look just like a 175 annotation, but that's completely up to you.
This gives you strong typing for javadoc tag info, but it has another benefit in that it can also be populated from 175 annotations. This means your code doesn't have to care whether it is dealing with tags or annotations.
Excellent.
Then the next step would be for us to be able to use AOP-style introductions to generate the annotations using pointcuts (e.g. rules to define where the annotations should go) so we don't have to litter our code with doclet tags that we could infer using some simple rules in our build systems (e.g. design patterns, naming conventions and so forth - allowing the use of doclet tags to overload any such rules).
Ah, that is interesting - I hadn't yet really thought about how aspects might fit in here. I'll definitely give that some more thought, and I'd love to hear more about what you guys are thinking about along these lines.
Basically it just allows us to do this (on 1.4)
parse Java source code -> pointcuts -> binary annotations class files.
on 1.5 this would probably be done with bytecode swizzling like most AOP engines.
As it is, JAM does provide some of its own machinery that might give you what you want. JAM allows you to plug in to it's 'classloading' process such that you can modify the view that is constructed for each java type. To sketch a trivial example: you could easily add a 'foo' annotation to every method which returns a boolean and whose name contains the word 'foo.'
Excellent :)
So I guess we could do all this at runtime. I guess it depends on which end of the pipe you are (a developer of a package or a deployer of the package).
For the annotation-introductions side of things I'd thought that a developer should decide his naming conventions & rules, then use those in the build process so that the jar of the code already has binary annotations inside - so anyone can just use the binary and see the correct annotations. Doing it the other way is interesting too - at runtime modifying annotations - though I'm less interested in that side of things just yet. I'm really keen on the former :)
For a more concrete idea of how this works, take a look at the '...jam.mutable' subpackage; you basically get an opportunity to inspect objects of those types and modify them in any way you see fit.
It may be worth noting that JAM's annotation processing features are really just specific uses of this mechanism. For example, I have a plugin which parses a class' comments as it is loaded and creates appropriate annotations for any javadoc tags found there.
Cool.
James ------- http://radio.weblogs.com/0112098/
