ModuleInfo extends AnnotatedElement

[Roger Riggs]

Hi Mandy,


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?
The difference is in the coding style, the current API suggests/requires:

        // This pattern always causes 5 calls and perhaps 5 linear searches for the annotation
	ModuleInfo m = xxx;

        Annotation1 a1 = m.getAnnotation(Annotation1.class);
	if (a1 != null) {...}
        Annotation2 a2 = m.getAnnotation(Annotation2.class);
	if (a1 != null) {...}
        Annotation1 a3 = m.getAnnotation(Annotation3.class);
	if (a1 != null) {...}
        Annotation1 a4 = m.getAnnotation(Annotation4.class);
	if (a1 != null) {...}
        Annotation1 a5 = m.getAnnotation(Annotation5.class);
	if (a1 != null) {...}

vs.
	// This pattern touches each annotation that is present only once.
	ModuleInfo m = xxx;
	for (Annotation a : m.getAnnotations) {
	    if (a instanceof Annotation1) {
        	Annotation1 a1 = (Annotation1)a;
	    }
	    if (a instanceof Annotation2) {
        	Annotation2 a2 = (Annotation2)a;
	    }
	    if (a instanceof Annotation3) {
        	Annotation3 a3 = (Annotation3)a;
	    }
	    if (a instanceof Annotation4) {
        	Annotation4 a4 = (Annotation4)a;
	    }
	    if (a instanceof Annotation5) {
        	Annotation5 a5 = (Annotation1)a;
	    }
	}



Furthermore, if you want to write a tool the prints out the annotations 
that are present
it can be done conveniently.

Pretty much every other API that maintains a set of something provides 
an iterator;
ModuleInfo should too.

>>    * 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?
??
>
>>
>>    * 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[]
Ok, so it will just list the classes that are not available.
>
>> A List<String> seems a bit heavyweight for this purpose.
>
> Why would you think it's heavyweight?  What performance concern do you 
> have?
Sorry, I've been working on targets where space and time always matter.
If you don't create garbage, you don't have to clean it up.
>
>>    * 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.
ClassNotFoundException; NoClassDefFoundException...

TypeNotPresentException

These are all failures because Class.forName fails because it cannot 
find the class.

>
> 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. 
I understand there is no attempt to locate or define the class *in* the 
module being inspected
because the module is not fully defined and no classloader can be 
created for it.

But the class name(s) found in the annotations *are* being resolved using
the caller's classloader (Class.forName() or equivalent).  If the 
annotation class is not found
then that is the failure that is being reported, and that is very 
similar to ClassNotFoundException
or TypeNotPresentException.


Roger