ModuleInfo extends AnnotatedElement

[Jonathan Gibbons]

Roger,

One more answer ...

Mandy Chung wrote:
> Hi Roger,
>
> Thanks for the comments:
>
> Roger Riggs wrote:
>> 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.
>
> The caller knows which annotations to look for.  You should use the 
> isAnnotationPresent() method to check.  What's the use case to 
> enumerate all Annotations?  What happens if a type doesn't exist?  The 
> caller will need to catch the exception if an annotation type is not 
> found.  In that case, what would the caller do?
>
>>    * 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.
>
> Joe can help explain the reason why AnnotatedElement.getAnnotations() 
> returns Annotation[].
>
>>    * 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?

permits take a module name with no version info. Therefore a String is 
the obvious representation.



>>    * Are the sets returned from permits(), requires(), provides()
>>      modifiable by
>>      the caller?  
> unmodifiable.  Will make it clear in the spec.
>> 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? 
>>      
>
> Class[]
>
>> A List<String> seems a bit heavyweight for this purpose.
>
> Why would you think it's heavyweight?  What performance concern do you 
> have?
>
>>    * 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.
>
> Suggestion on a better name is welcome.
>
> As specified in the UnsupportedElementTypeException spec:
> UnsupportedElementTypeException is thrown when an application attempts 
> to read a |Class| object or a Class[]-valued element by invoking the 
> relevant method on an annotation returned by the 
> |ModuleInfo.getAnnotation(java.lang.Class| 
> <http://cr.openjdk.java.net/%7Emchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html#getAnnotation%28java.lang.Class%29>) 
> method.
> The class could be found but access to elements of type Class object 
> and Class[] is just not supported since the information necessary to 
> locate and load a class is not available when the module is not 
> installed. TypeNotPresentException is not appropriate for this case. 
> Thanks
> Mandy