Hey Patrick
Hi James. Thanks for the feedback.
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.
(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).
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.
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.
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.'
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.
Thanks again, -p
Once we get there I'd be a very happy chap :)
On 27 Mar 2004, at 03:23, Patrick Calahan wrote:Hello everyone. I am a committer on Xml-Beans, another project currently in the Apache Incubator. As part of my work there, I have developed an API for representing Java types and their associated metadata which I believe would be of general use to the community.
The API is called 'JAM' - the Java API for Metadata. On the surface, it looks quite a bit like Reflection or the Doclet API, but it affords a greater level of flexibility and convenience, and in particular provides solutions for a number of thorny problems posed by JSR175.
I have had a few discussions with some folks on [email protected] about possibly spinning JAM up as an independent project from xbeans. It was suggested that it would be useful to test the waters in some other projects such as Geronimo to see if JAM would indeed be generally useful. So, here I am testing. :)
Anyway, if you want more gory details, I have temporarily posted some white papers and the API docs here:
http://www.pcal.net/jam
Any feedback is more than welcome.
Thanks,
-Patrick
James ------- http://radio.weblogs.com/0112098/
