geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Calahan <>
Subject Re: JAM: Java API for Metadata
Date Sat, 27 Mar 2004 08:09:31 GMT
At 05:05 AM 3/27/2004 +0000, wrote:
>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 

>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 

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,

>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 
>> 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:
>>Any feedback is more than welcome.

View raw message