Optional Module Dependency

[Mandy Chung]

  I have implemented the new @RequireAnnotation annotation and a new API 
(Module.isModulePresent method) to test whether a module has been 
resolved and linked.

This note summarizes for the optional module dependency work:
      http://openjdk.java.net/projects/jigsaw/doc/topics/optional.html

Webrev:
      
http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/require-module-annotation/

A few questions to discuss:
1. There are some APIs that require another module depending on the 
input parameters passed in.  Bidi, JNDI, JMX are some examples.  The 
optional module is guaranteed to be present when the given input 
parameter depends on it.

I wonder what the best practice or recommendation of using 
@RequireAnnotation. For APIs that throws ModuleNotPresentException, they 
clearly need to be annotated so that javadoc and other tools can process 
them when appropriate.

I think it's generally a good idea to annotate the source of an optional 
dependency so that a tool can check if the optional dependency is 
declared in the module-info.java (if there is no static reference to 
types from the optional module; otherwise, the compiler can detect 
that).   If a module P didn't declare the optional dependency on M and M 
is present, P will be compiled successfully.  At runtime, 
isModulePresent method will return false even if M is present but it is 
not visible to P.  P's module class loader will fail to find a class in 
module M.  This is the case the new test "optional-method.sh" shows.

I currently put this annotation in these APIs (e.g. 
sun.text.bidi.BidiBase, com.sun.jmx.mbeanserver.Introspector, etc). Alan 
mentioned in an offline discussion I had with him if it's more 
appropriate to have a different annotation for this type of dependency. 
   Any other thought?

2. Class.forName is the existing (legacy) approach to determine if a 
class is present.  In a modular world, a modular application can use 
isModulePresent method instead.  This leads to another question that  
module P should statically reference types from an optional module M; 
replace the use of Class.forName if it was to eliminate static 
dependency (this is the approach JDK uses).

Mandy