Hi,
The proposal for #ModuleAnnotations says:
/" - Extend `javax.lang.model` and `java.lang.reflect` to provide access//
// to module annotations. Repeating annotations are supported, subject//
// to the usual rules for repeatable annotation types. *(This
proposal*/*/
/**/ will not add similar support to
`java.lang.module.ModuleDescriptor`;/**/
/**/ that would add yet more complexity, and we haven't seen a use
case/**/
/*/* for it.)*"/
A possible use case might be here:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008077.html
...in particular in the following message:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008102.html
...where it says that one option would be to have a "labeling system"
for modules. To find out to what "groups" they belong to.
But there's a more fundamental problem that prevents adding support for
annotations to ModuleDescriptor - a chicken-egg problem. Annotations are
types and they reference types. These types can be declared in the
module that uses them in its module descriptor. Until a
java.lang.reflect.Module is instantiated for a module that might contain
the types that appear in its module descriptor, those annotations can
not be materialized in a form that we are used to - as instances of
annotation interfaces.
Unfortunately, annotations on ModuleDescriptor would be useful precisely
in cases where there's no Module instantiated yet. For example, to
identify a group of module descriptors such as in above-mentioned use-case.
Would it be worth exploring the possibility to present module
annotations on ModuleDescriptor in a more symbolic and reflective way?
Where annotation instances would be represented as generic key/value
records, java.lang.Class instances would be represented just as class
names and enum instances just as some generic untyped equivalent?
Anyway, current implementation of annotations on
java.lang.reflect.Module uses a clever trick - it defines a class
derived from module-info.class in the VM just to be able to use the
existing java.lang.Class infrastructure for annotations (similarly to
how Package does for its annotations) with additional hack where each
such module-info class has to be defined in its own class loader as just
a single name is used for multiple module classes.
Here's an alternative implementation that does not need to define the
class in the VM:
http://cr.openjdk.java.net/~plevart/jdk9-jake/Module.annotations/webrev.02/
It instead modifies AnnotationParser to use a special
AnnotationParser.ConstantPool interface which is implemented by two
classes: a classical reflection ConstantPool backed by VM and a
lightweight Java-only implementation which is used to parse
module-info.class. So while parsing module-info.class, the
RuntimeVisibleAnnotations attribute is extracted and memorized in
ModuleDescriptor. Together with the lightweight ConstantPool
implementation, they are used in Module to parse the annotations when
1st requiested.
It is more involved than current implementation, but it is also lighter
and might be extended to support - let's call them
annotation-descriptors - on ModuleDescriptor.
What do you think?
Regards, Peter
