Spring's need for optional dependencies

[Peter Levart]

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>> 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>> 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
>
>