ModuleInfo extends AnnotatedElement

[Mandy Chung]

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?
>    * 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