geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jastrac...@mac.com
Subject Re: JAM: Java API for Metadata
Date Sat, 27 Mar 2004 12:43:13 GMT

On 27 Mar 2004, at 08:09, Patrick Calahan wrote:
> At 05:05 AM 3/27/2004 +0000, jastrachan@mac.com 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/


Mime
View raw message