Spring's need for optional dependencies

[Ali Ebrahimi]

Hi,
In general, your workaround has some disadvantages:
1) Existing code does not work as is: (your need read edges)
2) command line options only apply to boot layer not to dynamic
configurations created by future containers

On Fri, Dec 18, 2015 at 7:19 PM, Peter Levart <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>> 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
>>
>>
>>
>


-- 

Best Regards,
Ali Ebrahimi