Optional dependencies

[Peter Levart]

On 12/04/2015 05:53 PM, Stephen Colebourne wrote:
> I've been pondering whether -addReads is sufficient for this use case.
>
> While type 1 of my classification below (annotations) would work using
> compile-time -addReads, I don't think types 2 and 3 would. (Type 2 is
> reflection based, type 3 is usage based)
>
> Here is the setup:
>
> module user {
>    requires org.joda.beans
>    requires com.google.guava
> }
> module org.joda.beans {
>    // optionally requires com.google.guava
> }
>
> Proposed solution:
> compile module with -addReads=com.google.guavea
>
> The proposed solution would allow the Joda-Beans module to be
> successfully compiled. But it seems that it would not be able to see
> the Guava code at runtime (as the module does not have the
> dependency). Note that there is source code in Joda-Beans that
> actively calls Guava clases in addition to checking they exist by
> reflection.
>
> Given the above setup, it seems to me that -addReads at compile time
> is insufficient to meet the requirement of optional dependencies.

You would have to invoke jodaBeansModule.addRead(guavaModule); from your 
org.joda.beans code before 1st use of any guava type. In Addition, you 
would have to ensure guava is part of runtime configuration - either 
implicitly by some module in your configuration requiring guava or 
explicitly by adding "-addmodule guava" to the java launcher command line.

Regards, Peter

> IMO, adding syntax to the module-info for optional dependencies would
> allow the connection between the modules to be recorded properly. With
> that information, the module system could grant the implied
> readability link from Joda-Beans to Guava provided that some other
> module has Guava as a dependency.
>
> Stephen
>
>
>
> On 1 December 2015 at 15:49, Stephen Colebourne <scolebourne at joda.org> wrote:
>> On 1 December 2015 at 15:39, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> This should be doable but maybe not obvious. Can you say a bit more about
>>> the Joda-Time optional dependency on Joda-Convert first? In particular, are
>>> there static references to types in Joda-Convert and maybe a reflection
>>> guard to check the presence of one of its types?
>>>
>>> It might be that you have to compile module joda.time with
>>> -XaddReads:joda.time=joda.convert. At run-time then you can use Module
>>> addReads to read module joda.convert when it's in the module graph.
>> So, there are three variants of dependency in that list.
>>
>> 1) Joda-Time depends on Joda-Convert solely for annotations. Thus, the
>> annotations need to be available to compile against. The annotations
>> have runtime scope, so must remain in the bytecode. However, only
>> those users that want to use Joda-Convert in anger will ever care
>> about them. For everyone else, the fact that there is no class file
>> for the annotation at runtime is not a problem.
>>
>> 2) The Joda-Convert dependency on Guava is reflection based. If it
>> finds the class on the classpath it will enable the conversion logic.
>> If it doesn't it won't.
>>
>> 3) The ElSql dependency on Spring is not reflection based. If the user
>> uses the class ElSqlBundle, they have to have Spring available. If
>> they do not use that class, they do not have to have Spring available.
>>
>> The Joda-Beans dependencies are a mixture of the second and third type..
>>
>>
>> I can see how the compile time flag could work, which is good.
>> However, I think that it should be part of the module-info file, since
>> the project cannot be compiled without it.
>>
>> module org.joda.time {
>>    exports ...
>>    at-compile-time {
>>      requires module org.joda.convert;
>>    }
>> }
>>
>> Stephen