Spring's need for optional dependencies

[Neil Bartlett]

I do not see any statement in the Module System Requirements document (http://openjdk.java.net/projects/jigsaw/spec/reqs/) such that Java 9 is required to be backwards compatible, except where code runs in “classpath mode” (aka the unnamed module).

Therefore it is an acceptable solution — at least if you accept the Requirements! — to need explicit API calls such as addReads() in frameworks when running in module mode.

Regards,
Neil

> On 18 Dec 2015, at 16:14, Paul Benedict <pbenedict at apache.org> wrote:
> 
> Adding read edges at runtime is not a backward compatible solution. Jigsaw
> should automatically allow you to read anything your Module Descriptor
> gives you access to -- required or optional.
> 
> Cheers,
> Paul
> 
> On Fri, Dec 18, 2015 at 10:02 AM, Peter Levart <peter.levart at gmail.com>
> wrote:
> 
>> 
>> 
>> On 12/18/2015 04:49 PM, Peter Levart wrote:
>> 
>>> You can check whether the optional module is included in a runtime
>>> configuration or not with a simple Class.forName() check even if you don't
>>> depend on the module (i.e. don't list it in "requires" descriptor at
>>> runtime). The visibility of classes is not restricted. It only depends on
>>> ClassLoader hierarchy. When you successfully resolve some optional class at
>>> runtime (with Class.forName), you then have to add a read edge to it's
>>> module:
>>> 
>>>    Class<?> optionalClass = Class.forName("...");
>>>    MySelfClass.getModule().addRead(optionalClass.getModule());
>>> 
>>> ...before invoking any code that uses this module.
>>> 
>> 
>> Just had an idea!
>> 
>> Optional dependency at runtime could add a read edge to the module if that
>> module was included in the configuration, but would otherwise not cause
>> that module to be included in the configuration by itself. How does that
>> sound? Spring would work as before - no .addRead() calls needed. Just
>> Class.forName("OptionalClass").
>> 
>> Regards, Peter
>>