Hi Ali,
On 12/18/2015 05:05 PM, Ali Ebrahimi wrote:
Hi,
In general, your workaround has some disadvantages:
1) Existing code does not work as is: (your need read edges)
See my message written concurrently with your's ;-) Optional dependency
could add a read edge for you if the target module was pulled in by some
other means, but would not cause it to be pulled in.
2) command line options only apply to boot layer not to dynamic
configurations created by future containers
Who knows what future containers will do. They are free to add all
modules deployed in a deployment unit as root modules to the layer
configuration. Root modules could be listed in a deployment descriptor
of the deployment unit. Jigsaw is providing the API for them to do what
they want.
Regards, Peter
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