Spring's need for optional dependencies

[Paul Benedict]

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.

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.

Cheers,
Paul

On Thu, Dec 17, 2015 at 10:58 AM, Peter Levart <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> 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
>
>