Bug ID: JDK-8313983 jmod create --target-platform should replace existing ModuleTarget attribute

Versions (Unresolved/Resolved/Fixed)

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 21	JDK 22
21.0.5Fixed	22 b14Fixed

Attempts to unpack and pack the java.compiler.jmod produces the next exception:
===========================================
Error: More than one ModuleTarget attribute
java.lang.module.InvalidModuleDescriptorException: More than one ModuleTarget attribute
        at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1216)
        at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:243)
        at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129)
        at jdk.jlink/jdk.tools.jmod.JmodTask.describe(JmodTask.java:318)
        at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:207)
        at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:35)
===========================================

The bug can be reproduced if jmod tool from JDK21 is used for jmods files from jdk20 or jdk21. The tool from JDK20 works fine with jmods files from jdk20.

Steps to reproduce:

JAVA_HOME=/jdk21/build/windows-x86_64-server-release/images/jdk/

JMOD_BINARY=${JAVA_HOME}/bin/jmod.exe
JMOD_DIR=${JAVA_HOME}/jmods
TEST_JMOD=java.compiler.jmod
mkdir extract
mkdir pack
${JMOD_BINARY} extract ${JMOD_DIR}/${TEST_JMOD} --dir extract/${TEST_JMOD}
cd extract/${TEST_JMOD}
${JMOD_BINARY} create --target-platform -amd64 --module-version 21 --class-path classes --legal-notices legal ../../pack/java.compiler.jmod
cd ../../
${JMOD_BINARY} describe pack/java.compiler.jmod

The last command produced this error.

Tested on windows and linux.

The same exception can occur if the java.base jmod file should be repacked using hash+module-path of repacked java.compiler.jmod.

Fix request (21u) Clean backport. The fix for a regression introduced in jdk21. No new issues were found by the tier1/tier2/tier3/tier4 tests. The fix is verified by the steps from the description. Review 21u-dev: https://git.openjdk.org/jdk21u-dev/pull/666
05-06-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/666 Date: 2024-06-04 23:39:14 +0000
05-06-2024
Changeset: c2e01eba Author: Adam Sotona <asotona@openjdk.org> Date: 2023-09-01 08:33:33 +0000 URL: https://git.openjdk.org/jdk/commit/c2e01eba5a537acd573b7d2e6d41811c415c3f68
01-09-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/15514 Date: 2023-08-31 12:13:40 +0000
31-08-2023
ModuleTargetAttribute and ModuleResolutionAttribute are both flagged as 'allow multiple' in the Classfile API, probably because of lack of reference to a specification and assumption there might be more targets. I'll fix it.
31-08-2023
I've changed the title on this issue so that it's a bit clearer what this is about. When jmod create --target-platform is used then it should replace the ModuletTarget class file attribute if it exists, it shouldn't add a second attribute. It maybe that changing the module-info extender from using ASM to the new ClassFile API has introduced this issue. The scenario is unusual, surprised it was noticed.
10-08-2023
It works on JDK 20 but fails on JDK 21.
09-08-2023