Hi, Well, I can think of at least one use-case where a JDK10 version of a module would have different dependencies than JDK9: if the module used an external lib for X in JDK9, and then JDK10 incorporated that functionality X so that import would no longer be required but the module would then import the JDK10 module.
Like what happened for JodaTime and the JDK a while back. I'm not saying it would justify the additional complexity, but it certainly sounds like a plausible use-case. Not one that I'd be in a hurry to support in Ceylon either, mind you ;) Cheers. On 18/01/16 14:37, Paul Sandoz wrote: > Hi Paul, > > A jar file can be considered a unit of release, and a modular-jar is no > different in that respect e.g. either kind might have a maven pom and be > published to maven central. The strong expectation is a unit of release has > one set of dependencies. > > Changing that expectation will i think cause problems for existing tooling > and the JDK compile-time and runtime processing of modules. So i would prefer > to keep it simple and mandate that a multi-release jar file has only one > module-info.class at the root (such files located in a versioned area would > be ignored). > > Paul. > >> On 13 Jan 2016, at 17:55, Paul Benedict <pbened...@apache.org> wrote: >> >> With multi-release JARs, there is a directory structure to partition out >> the class files for the destined versions of the Java runtime. >> >> With modules, the module-info.class sits in the root of the JAR. >> >> How will these two requirements be reconciled? Are there plans such as >> allowing module-info.class in each version folder too? It is quite >> conceivable a module will require dependencies in one Java version; yet not >> for another. >> >> Cheers, >> Paul
