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 <pbened...@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.lev...@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
>>
