Opportunistic coin improvements for JDK8: Can those be tracked someplace? (Any annotation in annotations)

Joseph Darcy joe.darcy at oracle.com
Fri Oct 28 17:22:37 PDT 2011


The request for this kind of extension to annotations has come up before.

The RuntimeVisibleAnnotations and RuntimeInvisibleAnnotations attributes 
might need to be updated to support this feature since at a top level in 
the class file the annotation information is stored as [member name, 
data] pairs and not [member name, member type, data] triples.

Platform changes needed by this request would include changes to javac 
to write out the revised annotations and revisions to the 
annotation-reading methods in core reflection and javax.lang.model.

Another adjustment to annotations that was been requested is something 
in the space of allowing two annotation types to have a common supertype 
other than java.lang.annotation.Annotation.  For example, allow 
annotation types to implement interfaces or allow one annotation type to 
extend another.

You're free to work on a patch, but I don't think it would be likely to 
get into 8.



On 10/19/2011 7:58 PM, Reinier Zwitserloot wrote:
> A minor update to annotations is on the 'hey, maybe we can get around to it
> for 8' list, to be specific: Allowing the same annotation to show up
> multiple times on the same node.
> If annotations are being looked at anyway, I'd love to be able to add
> "Annotation" and "Annotation[]" to the list of legal return types for an
> annotation method declaration. The valid constants that can be used for
> these are _any_ annotation, i.e.:
> @OnMethod({@SuppressWarnings("all"), @Generated})
> private final int foo; // An annotation processor will generate a new file
> with a method based on this field.
> It seems like a pretty low-impact change, but without a coin process I'm not
> sure I should bother putting in the effort to write it up and make a javac
> patch. If there's more clarity that annotations are going to go through some
> changes anyway, will there still be enough time for me to cook up a patch so
> it can be considered?
>   --Reinier Zwitserloot

More information about the coin-dev mailing list