On Fri, Dec 18, 2015 at 7:19 PM, Peter Levart
<peter.lev...@gmail.com <mailto:peter.lev...@gmail.com>> wrote:
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>
<mailto: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>
<mailto: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
--
Best Regards,
Ali Ebrahimi
