ModuleInfo extends AnnotatedElement

[Roger Riggs]

Hi,

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
      iterate over
      the available annotations without having to make a call to probe
      for each one.
    * Style: Should there be more symmetry between Module and ModuleInfo
      APIs?
      ModuleInfo returns Set<x>, while Module returns Annotation[] arrays.
      Use of arrays generally requires that they be copied; creating
      garbage.
    * 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()
      modifiable by
      the caller?  It would be good to be clear about whether they are
      copies
      of the internal structures or are read-only to prevent corruption.
      Read-only would
      be better and create less garbage.
    * In the case of annotations whose values are classes (see the
      getAnnotation method),
      and the UnsupportedElementTypeException is thrown, under what
      circumstances
      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
      specified
      to be thrown when the class is not accessible.  Should it be used
      in ModuleInfo.getAnnotation
      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.

Roger



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:
> http://cr.openjdk.java.net/~mchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html 
>
>
>>
>> Dealing with annotation types whose methods are declared to return 
>> Class objects is problematic in this mixed environment and should be 
>> avoided.
>
> 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.
>
> Thanks
> Mandy
>
> joe.darcy at oracle.com wrote:
>> Hello.
>>
>> 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 
>>> AnnotatedElement:
>>>
>>> http://cr.openjdk.java.net/~mchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html 
>>>
>>>
>>> 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 
>>> exception.
>>>
>>> Any comment, opinion?
>>>
>>> Joe, your feedback would be helpful.