Spring's need for optional dependencies

Peter Levart peter.levart at gmail.com
Fri Dec 18 16:17:09 UTC 2015

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.levart at gmail.com 
> <mailto:peter.levart at 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.levart at gmail.com <mailto:peter.levart at gmail.com>
>         <mailto:peter.levart at gmail.com
>         <mailto:peter.levart at 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
>                 <stef at epardaud.fr <mailto:stef at epardaud.fr>
>         <mailto:stef at epardaud.fr <mailto:stef at 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

More information about the jigsaw-dev mailing list