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 <scolebou...@joda.org> wrote:
On 1 December 2015 at 15:39, Alan Bateman <alan.bate...@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
