Intersection of Modules and Multi-Release JARs

[Stephane Epardaud]

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 <pbenedict at 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