PROPOSAL: Method and Field Literals (original) (raw)

brucechapman at paradise.net.nz brucechapman at paradise.net.nz
Wed Mar 11 19:32:00 PDT 2009

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# #PrintWriter.out# #ArrayList.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

More information about the coin-dev mailing list