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.lev...@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.lev...@gmail.com >> <mailto:peter.lev...@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 >> <s...@epardaud.fr <mailto:s...@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