ModuleInfo extends AnnotatedElement
Mandy Chung
mandy.chung at oracle.com
Wed Apr 28 12:22:33 PDT 2010
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
More information about the jigsaw-dev
mailing list