Optional Module Dependency

[Alan Bateman]

Mandy Chung wrote:
> :
>
>>
>> The Module.isModulePresent(String mn) method might be renamed to 
>> isModuleAvailable
>> since it includes the check for availability from the calling module.
>>
>
> I see both the term "present" and "available" don't precisely indicate 
> it's
> relative to the calling module.  In that case, isModulePresent seems 
> preferable.
I agree, and it's somewhat consistent with existing methods such as 
isAnnotationPresent and exceptions such as TypeNotPresentException.

> :
>
>> As an example, in
>> the webrev of java.util.Properties, the code that has the dependency is
>> not in the same class as the test for the module.  There may be a 
>> mismatch
>> between the module name and the understanding of its contents.
>
> The platform classes / modules are a special case.  We would 
> investigate this
> when we support aliases.  The platform modules are strongly connected 
> (i.e.
> requires local) and currently loaded by the BootLoader for 2 reasons;
> 1. compatibility - all system classes are loaded by the null bootstrap 
> class loader
> 2. split package requirement
>
> java.util.Properties is in the jdk.boot module and in the context with 
> jdk.boot+sun.jaxp
> (+ other platform modules).  jdk.boot module shouldn't depend on any
> modules and it couldn't find jdk.jaxp.   I think we should treat the 
> jdk.boot module
> a special case that it should also find the contexts from jdk.base.
>
> Is there other use case you think of?
To Roger's point, I think anyone creating an optional dependency will 
need to take care. I agree the examples for the platform look confusing 
and we should probably addressed by providing  documentation or examples 
to show how one might do this in an application or library.


>>
>> When refering to types that are not (going to be) present, care must 
>> be taken
>> to ensure the classfile can be verified without needing to evalate 
>> the missing
>> types.  This can be a bit subtle. In my experience, the coding patterns
>> that are easy to understand limit where references to optional types 
>> may be
>> used. 
>
> Good point.  I'm checking with Alex Buckley further on the 
> verification side.
> We probably have to come up an idiom that prevents a class referencing
> the optional types being verified unless the optional module is present.
If there is a static reference to a type then I would assume it is no 
longer an optional dependency (or maybe I'm not understanding the 
approach, and static references are actually allowed?).

-Alan.