JDK-8146486 : Modular JARs as multi-release JARs
  • Type: Task
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-01-05
  • Updated: 2017-03-21
  • Resolved: 2017-03-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Fixed
Related Reports
Blocks :  
JDK-8047305 - JEP 238: Multi-Release JAR Files
Relates :  
JDK-8157598 - ModuleReader find returns incorrect URI when modular JAR is a multi-release JAR
Sub Tasks
JDK-8156497 :  
Add jar tool support for Multi-Release Modular JARs - Resolved
JDK-8156499 :  
Update jlink to support creating images with modules that are packaged as multi-release JARs - Resolved
JDK-8156568 :  
Update javac to support compiling against a modular JAR that is a multi-release JAR - Closed
JDK-8157658 :  
Examine test coverage for Multi-Release Modular JARs - Resolved
JDK-8164805 :  
Fail to create a MR modular JAR with a versioned entry of a concealed package - Resolved
JDK-8165640 :  
Enhance jar tool to allow module-info in versioned directories but not in base in modular multi-release jar files - Resolved
JDK-8165644 :  
jar tool can not build a modular multi-release jar with new public classes in concealed packages - Closed
Description
This issue is created to track any investigation or work required to have modular JARs be multi-release JARs.

Will multi-release JARs allow a module-info.class to be placed in META-INF/versions?

Will the scanning of JAR files to get the set of packages ignore META-INF/versions? That is, can new packages be added in the versions tree.
Comments
I believe the only work remaining here is to examine the tests to see if further tests are needed to cover all the possible scenarios.
13-02-2017
One thing to note is that the runtime support has regressed a bit since the changes JDK-8157524 went into JDK 9, specifically .class files in packages that are in the versioned section but not in the base section are ignored. We will fix up these issues once the changes for JarFile::versionedStream (JDK-8163798) is in JDK 9.
27-08-2016
The proposal is to allow module-info.class in the versioned section of the JAR file. The module name and exported API should be the same, dependences might vary by JDK major version. The tooling, and maybe API (TBD), will help to enforce this. The proposal is also that the set of concealed packages does not vary by JDK major version, meaning you can't add packages in the versioned section. As things currently stand in JDK 9, then javac reads the module-info.class in the top-level directory of a multi-release JAR whereas runtime will read the module-info.class from the versioned section. Also at runtime, class loading and the ModuleReader implementation for modular JARs already handles multi-release JARs. When patching (-Xpatch) then the patches packaged as JAR files cannot be versioned (patching is a low level mechanism, would need support in HotSpot/boot class loader to change this). The `jar` tool does not yet support modular JARs that have a module-info.class in the versioned section. It trips up in several ways. The `jar` tool will need to be updated to add/replace the ConcealedPackages attribute in both the top-level and versioned module-info.class files. The `jlink` tool does not yet support modular JARs either. It will need to determine the target JDK version (probably by first resolving java.base) and configure the ModuleFinder appropriately. It will also need changes so that only the appropriate resources/classes from the packaged module are copied into the runtime image.
08-05-2016
> Will multi-release JARs allow a module-info.class to be placed in META-INF/versions? There is nothing that would prevent it, but it shouldn't be necessary. The public API exported by the root (i.e. non-versioned classes) is, by definition, the identical API exported by any versioned directory. In other words, only one API is exported by a multi-release jar file. See paragraph 6 under "Description" in JEP-238. > Will the scanning of JAR files to get the set of packages ignore META-INF/versions? That is, can new packages be > added in the versions tree. Yes they can, but they should not be, since it violates the "spirit" of multi-release jars. As stated above, only one API should be exported. Tools (e.g. jar tool) should enforce that constraint. Human built jar files should abide by that constraint.
14-01-2016