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.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> 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 > >
