ModuleInfo extends AnnotatedElement
Roger.Riggs at oracle.com
Wed Apr 28 11:50:58 PDT 2010
Some comments on the module APIs:
* On ModuleInfo, I would like to see an enumeration of the Annotations;
like getAnnotations() on Module. This will allow the caller to
the available annotations without having to make a call to probe
for each one.
* Style: Should there be more symmetry between Module and ModuleInfo
ModuleInfo returns Set<x>, while Module returns Annotation arrays.
Use of arrays generally requires that they be copied; creating
* In the ModuleInfo.permits() method it returns a Set<String>;
in contrast the provides() method returns a Set<ModuleId>.
Is there a reason that String is used instead of a ModuleId?
* Are the sets returned from permits(), requires(), provides()
the caller? It would be good to be clear about whether they are
of the internal structures or are read-only to prevent corruption.
be better and create less garbage.
* In the case of annotations whose values are classes (see the
and the UnsupportedElementTypeException is thrown, under what
will the getClassNames() method return more than one Class name?
A List<String> seems a bit heavyweight for this purpose.
* In the AnnotatedElement interface the TypeNotPresentException is
to be thrown when the class is not accessible. Should it be used
instead of the new UnsupportedElementTypeException? BTW, this
name is not quite correct since
the type is just not found in the caller's type system.
Mandy Chung wrote:
> Hi Joe,
> Thanks for the feedback. I revised the ModuleInfo interface not to
> extend the AnnotatedElement interface but instead just adds the
> isAnnotationPresent and getAnnotation method:
>> Dealing with annotation types whose methods are declared to return
>> Class objects is problematic in this mixed environment and should be
> Agree. I follow the way that the
> javax.lang.model.Element.getAnnotation method specifies so that an
> exception will be will be thrown when it attempts to read a Class
> object by invoking the relevant method on the returned annotation. I
> added a new exception java.lang.module.UnsupportedElementTypeException
> for such purpose.
> joe.darcy at oracle.com wrote:
>> On 4/20/2010 2:33 PM, Mandy Chung wrote:
>>> The current API only supports to read annotations of a module when
>>> the module has been installed by using the java.lang.reflect.Module
>>> API (that extends AnnotatedElement). There are cases that one
>>> would want to read the annotations from module-info while the module
>>> is being installed. For example, a module can include some
>>> annotation to specify the installation requirement that can be used
>>> to determine if the module installation should continue based on the
>>> system configuration. It is an opportunity to eliminate transfers
>>> of the entire module and its dependencies if not needed.
>>> We need to provide an API to read the annotations from module-info
>>> but the module may not be installed or downloaded at all.
>>> One proposal is to extend java.lang.module.ModuleInfo to extend
>>> It will not load any classes referenced by annotations for this
>>> ModuleInfo until the getAnnotation or other method specified in the
>>> AnnotatedElement interface is called (since those classes might not
>>> exist or be found by the class loader). In other word, this change
>>> will not affect the current module loading/resolution. It will use
>>> the current module class loader to find classes to construct the
>>> Annotation objects. If the type of an annotation's element cannot
>>> be found, it will result in a TypeNotPresentException in the
>>> current proposed specification. TypeNotPresentException is an
>>> unchecked exception and perhaps it'd be better to throw a checked
>>> Any comment, opinion?
>>> Joe, your feedback would be helpful.
More information about the jigsaw-dev