[JSR308] An implementation of Subtyping for Annotations
chaack at cs.ru.nl
Tue Sep 1 15:02:28 EDT 2009
the zip file only contains the compiler patch, and a jar with the
patched JSR 308 compiler, and a set of examples with commented Java
sources, which were meant to explain our design decisions by example.
We are aware that this does not meet the criteria to go into the OpenJDK
compiler. We have manufactured this patch, as an initial step, in order
to find out how much of a an extension to the JSR 308 compiler (and the
JLS) is needed in order to support recursive annotation types and
subtyping for annotation types. If there is interest, we will gradually
add documentation to make what we have done more accessible, as well as
more tests to make it more trustworthy.
We, of course, read the JSR 308 specification, including the section on
annotation inheritance, prior to doing this. Our general strategy has
been to be very conservative about the extension and impose enough
syntactic restrictions to rule out semantically dubious issues, while
still being permissive enough to support the useful cases (in particular
recursive annotations, which would be very useful in a project that we
work in). For instance, the example that you mentioned in your mail does
not arise with our proposed extension, because we disallow subtypes of
annotation types to "redefine" fields that have already been defined in
their supertypes. In your example, this means that a subtype @Sub1 of
@Super cannot have a "value" field, if @Super already has a "value" field.
We take your point that we need to test the compiled code with
reflection. We have not done this yet, but so far only tested (with a
small test set) that the compiler itself behaves as expected.
Michael Ernst wrote:
>> This is just to inform the list that we have updated our patch to the
>> release of the JSR 308 compiler from 21/8. So the patch is now
>> compatible with the JSR 308 compiler. The updated patch is still
>> available from here:
>> Server: http://www.aicas.de/customers/JCP_JSR308
>> Name: JCP_JSR308
>> Password: 308
> Thanks for this start. I noticed some problems with this.
> The zip file doesn't have any documentation (not even a README file).
> The zip file contains no specification to explain what the code is intended
> to do, nor is there any evidence of a design or design rationale. It would
> be good to start with the one in section D.3.1 of the Type Annotations
> As one example that is already pointed out in that section, the design
> needs to specify how the APIs and interfaces, both for compilation time and
> reflection, are intended to work; an example is getAnnotation(Class).
> Suppose that annotation types Sub1 and Sub2 are direct subtypes of Super,
> whose value field has type int. What is the behavior of
> getAnnotation(Super.class) when called on these locations?
> * a location that is annotated with @Sub1(1)
> * a location that is annotated with @Super(0) and @Sub1(1)
> * a location that is annotated with @Sub1(0) and @Sub2(0)
> * a location that is annotated with @Sub1(1) and @Sub2(2)
> The zip file contains some input files that might be useful for testing,
> but there is no indication of how to run them, nor any build file.
> Furthermore, there are no tests: there are .java files but no indication
> of the expected output.
> Do you have any experience using the implementation?
> I do not want to be discouraging, especially after you have made a start
> (and when so many people on this mailing list have made good contributions
> in other respects). But I'm afraid that right now I don't have time to
> take on the maintenance and documentation of undocumented, unspecified,
> testless code. If you want to continue working in order to produce
> something that will be solid enough to go in the OpenJDT compiler by way of
> the Type Annotations compiler, then that is great and will be very welcome.
> Thanks a lot!
More information about the JSR308