Bug 900767 – dev-java/javatoolkit does not support multi-release JAR files (in /usr/libexec/javatoolkit/class-version-verify.py)

• Status: CONFIRMED
• Product: Gentoo Linux

[Description Volkmar W. Pogatzki 2023-03-11 06:03:35 UTC]

GENTOO_VM=openjdk-17  CLASSPATH="" JAVA_HOME="/usr/lib64/openjdk-17"
JAVACFLAGS="-source 1.8 -target 1.8" COMPILER=""


$ emerge -pqv '=dev-java/maven-bin-3.9.0::gentoo'
[ebuild  NS   ] dev-java/maven-bin-3.9.0 [3.8.7]


CVV: 1.8
Checked: 109 Good: 107 Bad: 2 Skipped: 0
 * Incorrect bytecode version found
 * in file: /var/tmp/portage/dev-java/maven-bin-3.9.0/image//usr/share/maven-bin-3.9/lib/plexus-utils-3.4.2.jar
 * See /var/tmp/portage/dev-java/maven-bin-3.9.0/temp/class-version-verify.log for more details.
 * ERROR: dev-java/maven-bin-3.9.0::gentoo failed (install phase):
 *   Incorrect bytecode found

[Comment 1 Volkmar W. Pogatzki 2023-03-11 06:04:09 UTC]

Created attachment 857251 [details]
emerge --info

[Comment 2 Miroslav Šulc 2023-03-11 06:22:27 UTC]

i guess this is not an issue of the package but instead the tool that checks the bytecode versions of the files. the mentioned jar contains multiple versions of some files and the tool does not support it. it would have to be updated to handle the versioned dirs inside the jar appropriately.

[Comment 3 Volkmar W. Pogatzki 2023-03-11 07:21:29 UTC]

Confirmed.
Temporarilly commenting out JAVA_PKG_STRICT in /etc/portage/make.conf solves it for me.

/etc/portage/make.conf
# JAVA_PKG_STRICT=true

[Comment 4 Miroslav Šulc 2023-03-11 08:27:45 UTC]

yes, it's called from that function in that eclass but the fix/enhancement has to be done in javatoolkit in /usr/libexec/javatoolkit/class-version-verify.py which performs the check. a python fluent speaker could:
- exclude content of META-INF/versions/ from the regular check
- add extra bytecode check only for files in META-INF/versions/\d+ (if those dirs exist) that the bytecode of the files matches the version specified by \d+.

[Comment 5 Miroslav Šulc 2023-03-11 08:32:21 UTC]

in fact the exact file is cvv.py which contains the logic.

[Comment 6 Volkmar W. Pogatzki 2024-08-01 05:45:15 UTC]

(In reply to Miroslav Šulc from comment #4)
> yes, it's called from that function in that eclass but the fix/enhancement
> has to be done in javatoolkit in
> /usr/libexec/javatoolkit/class-version-verify.py which performs the check. a
> python fluent speaker could:
> - exclude content of META-INF/versions/ from the regular check
> - add extra bytecode check only for files in META-INF/versions/\d+ (if those
> dirs exist) that the bytecode of the files matches the version specified by
> \d+.

If this could be re-written in Java and be integrated in java-dep-check would it be possible to last-rite javatoolkit?  xml-rewrite used by java-ant-2 has now only a few consumers left which could be converted to go without java-ant-2.

[Comment 7 Volkmar W. Pogatzki 2024-08-01 15:30:46 UTC]

Could maybe some part of dev-java/jclasslib be used for this purpose?