Spring's need for optional dependencies
Peter Levart
peter.levart at gmail.com
Fri Dec 18 16:58:06 UTC 2015
On 12/18/2015 05:28 PM, Ali Ebrahimi wrote:
> Hi,
> Can we all agree that native Optional dependency support would be
> clean, best and reasonable solution.
I think we 3 do agree ;-).
Regards, Peter
>
> On Fri, Dec 18, 2015 at 7:47 PM, Peter Levart <peter.levart at gmail.com
> <mailto:peter.levart at gmail.com>> wrote:
>
> 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
>
>
>
>
> --
>
> Best Regards,
> Ali Ebrahimi
More information about the jigsaw-dev
mailing list