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