PROPOSAL: Method and Field Literals

[brucechapman at paradise.net.nz]

Quoting Stephen Colebourne <scolebourne at joda.org>:

> 
> - One area that needs to be added to the spec is to allow member
> literals in annotations. Currently, annotations are defined to only
> accept a limited subset of types that are known to be safe and
> immutable. There is a use case for frameworks to link to methods and
> fields from annotations (currently it is done using strings). The
> problem is that Field/Method/Constructor are not immutable. However,
> it has been suggested to me previously that a clone can be returned
> each time from the annotation.
> 

If that line of reasoning is followed (and I agree it is worth pursuing) then
the proposal would then be incomplete if you did not extend it to cover type
literals as well, both as type literals per se and allowing them as annotation
element values. Currently class literals cannot represent instantiations of a
generic type. If we allow field and method literals of generic types, but don't
address the lack of a generic type literal, we haven't gone far enough.

Following that line of reasoning, and that the type literal doesn't have a
obvious place to put the # consistently with field and method literals, maybe
the solution is to use # in a bounding form like these
#ArrayList<String>#
#PrintWriter.out#
#ArrayList<String>.add(String)#

but that might not play nicely with recent discussions about the nature of the
LHS when # is used as a dereferencer, and with the FCM/BGGA stuff that it would
be good to be considerate of.

As well as the runtime reflection representation, we should also consider how
these constants (partularly when used as annotation element values) would be
represented in javax.lang.element. (it would appear to fit nicely into
javax.lang.element.AnnotationValue.getValue() which can return a TypeMirror
which can be used to represent all these (types, fields, methods, constructors)

The use of these literals as annotation values may well force a change in the
implementation strategy such that these are encoded in the classfile specially
rather than merely be compiled with a desugaring to call a helper method at
runtime. Annotation values neeed to have all three of a runtime
(java.lang.reflect) representation as well as a compile time (javax.lang.model)
representation, and a classfile representation.

I would LOVE to see type literals added (generally and as annotation element
values) for some of the annotation processing experiments I am doing) but my
fear (hopefully unfounded) is that this is starting to maybe get a little large
for coin.

Bruce