[JSR308] Annotation dump utility
pugh at cs.umd.edu
Fri Feb 9 13:34:19 EST 2007
At the risk of causing massive overload and confusion by posting to
both JSR-305 and JSR308, I'm going to post a follow up on this to
both mailing lists. Unless you are subscribed to both groups, any
responses are likely to get rejected by the mailing list you are not
a member of.
On Feb 9, 2007, at 12:15 PM, Eugene Kuleshov wrote:
> Trevor Harmon wrote:
>> In the process of modifying javac to support loop annotations (see
>> my other email to the jsr308-statements list), I needed a tool
>> that would reveal annotation data embedded in a class file. I
>> couldn't find one anywhere, so I had to write one myself. I'm
>> guessing someone on this list needs (or will need) such a utility,
>> so I've made it available for download here:
>> The utility takes a class file as input and prints any annotations
>> it finds. It formats this output to the same struct-like
>> representation that the VM spec uses, making the output easy to
>> read. It can be extended without much effort to dump custom
>> annotation formats.
> BTW, TraceClassVisitor from the util package of the in ASM
> framework  prints standard annotations in format used in the
> Java language. It should be also easy to extend it to print
> nonstandard annotations from new attributes.
>  http://asm.objectweb.org/
I just wanted to say that JSR-305 will have some very important use
cases for such a tool.
As part of JSR-305, I presume we will be coming up with sample
annotations of the JDK libraries.
This will mark things such as which method parameters can't be null,
which method return values
shouldn't be ignored, which methods should be invoked in the Swing
thread and which shouldn't be,
And even if we add these to our own version of the JDK, we obviously
aren't going to be shipping
the code compiled from that; we are going to want to let Sun, IBM,
BEA, etc ship their own version
So I believe we need tools that can move annotation information between:
* Java source files
* Java class files
* some simple standard representation, probably XML
Thus, we could:
* start with an project with JSR-305 annotations.
* extract the annotations to XML form.
* Get a jar file for the currently distributed version of the project
* apply the annotations from the XML to the jar file
* Have a defect detection tool read the annotations from the modified
We could simplify this slightly be just having 4 options for the tool:
* Extract annotations from source to XML
* Update source with annotations from XML
* Extract annotations from jar file to XML
* Update jar file with annotations from XML
I figure one of the main uses of this, for JSR-305, will be to allow
to use third-party provided annotations of standard libraries.
analysis tools get the information from updated jar files or from XML
might depend on the tool.
More information about the JSR308