Optional dependencies

Stephen Colebourne scolebourne at joda.org
Fri Dec 4 16:53:34 UTC 2015

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

Given the above setup, it seems to me that -addReads at compile time
is insufficient to meet the requirement of optional dependencies.

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.


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

More information about the jigsaw-dev mailing list