Hi Paul,
I think we are not in disagreement. We are just talking of slightly
different things. So let me answer your concerns...
On 12/17/2015 06:14 PM, Paul Benedict wrote:
Peter, thanks for your comments. I differ in that I don't see any
problems with optional dependencies. Right now, like in Spring,
optional features are enabled with a Class.forName() runtime check; if
ClassNotFoundException is captured, the feature is unavailable. I
expect that coding pattern to continue with optional dependencies.
Libraries know how to check if a class is available and fallback to
another plan when it's not.
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.
What's different with jigsaw is how you include an optional module in
the runtime configuration.
Now you do this:
java -classpath ....:/path/to/my-optional-module.jar:...
With jigsaw you do this:
java -mp /repository/of/modules -addmods ...:my-optional-module:...
What's nice is that you don't have to remember to put the module into
the 'repository-of-modules'. You just have to remember to '-addmods
my-optional-module' and jigsaw will tell you if it can't find it. So you
have explicit control from command line.
Regarding your concern on the command line, I am not sure if people
will be using the command line often. I expect tools to eventually
read the Module Descriptors and assemble the correct list of modules.
I believe Maven is currently investigating something similar right
now. Currently, Jigsaw only reads a module directory, but eventually
individual jars will be able to be listed. Just let tools solve this
problem.
I think this feature is only meant to simplify establishing a set of
searchable modules when each of them is found in a directory with some
other files that would otherwise be in the way if the directory as a
whole was included in the modulepath (think of automatic modules). And
that's only needed when compiling or running directly from the layout of
Maven local repository. Application assembly usually puts all modules
into a single archive. I believe this could be a .jimage file in the future.
When you put something in -modulepath, it does not automatically become
part of your runtime configuration and I think it should not. The
concept of listing the root module(s) explicitly and letting the system
figure out the transitive closure which then becomes a set of modules
included in the runtime configuration is a powerful concept. And I think
optional modules should not automatically be included in the runtime
configuration.
All that Juergen has to tell jigsaw Spring users is to "require" the
modules that are Spring optional dependencies in their own root
application module and jigsaw will make sure they are included at
runtime. Or users can choose to delay that decision to launch runtime by
not "require"-ing the modules and using -addmods option instead.
Regards, Peter
Cheers,
Paul
On Thu, Dec 17, 2015 at 10:58 AM, Peter Levart <peter.lev...@gmail.com
<mailto:peter.lev...@gmail.com>> wrote:
Hi,
On 12/17/2015 12:03 PM, Stephen Colebourne wrote:
And here are the threads for Joda projects, which also need
optional
dependencies:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005462.html
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005638.html
Note, I do not consider command line flags to be acceptable as
a solution.
Stephen
On 17 December 2015 at 09:41, Stephane Epardaud
<s...@epardaud.fr <mailto:s...@epardaud.fr>> wrote:
As I already mentioned, we also have the need for this in
Ceylon, for
the same reasons. Dependencies are required at
compile-time but optional
at run-time, based on detection: if it's there fine, if
not then no problem.
The only problem I see with optional dependencies at runtime is as
follows...
If "requires optional X" semantic was to include the module X in
configuration if it could be found with module finder (on
-modulepath), otherwise not, then the established configuration
would not only be dependent on command-line arguments, but also on
the content of module directories. If there was a common directory
used as a repository for various modules, you would not be able to
opt-out of using a particular module if it was declared as
optional dependency and included in the modulepath.
So instead of assembling command-line arguments (-addmods ...),
you would be forced to assemble private module directories for
each particular configuration.
Contrasting this with what we have now, the classpath: you have to
declare that you use a particular optional dependency on command
line, by mentioning it on the -classpath. And when you do that
(assemble a -classpath command line argument), the configuration
does not even check that it really is there. If the .jar file
isn't there, it is simply ignored.
So I think the safe "requires optional X" semantic would have to
be such that it acts as two descriptors:
requires X - at compile time
nothing - at runtime (no attempt to find the module and add it to
configuration)
You would still have to put -addmods X to command line, but then
you would have a total control over configuration from
command-line only.
Optional dependencies basically then just reduce to a means to
have two different descriptors: one for compile-time and one for
run-time, where run-time has a sub-set of requires from
compile-time descriptor. It can be done now (with separate
compilation), but it would be convenient to have a single
descriptor with two scopes of requires.
Regards, Peter
