Optional dependencies

[Stephen Colebourne]

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