Any code compiled with ant on Java 11 will produce classfiles that are incompatible with Java 8 (classfile version 52 vs 55). This will cause problems for any packages that cannot move to Java 11 yet.
WIP list of packages that have .class files with version 55:
- BareBonesBrowserLaunch - Mars - Singular-surfex (fixed) - antlr-tool (fixed) - antlr3-tool - bigloo (fixed) - brlapi-java - capstone-java - collectd-* - cryptlib-java(-docs??) - cvc4-java - ditaa - dl_poly-gui - erlang-jinterface - fastbit-java - fernflower - filedrop - findbugs-bcel - flute - freerouting - frysk - genders-java - glite-jobid-api-java - gnu-getopt - graphviz-java - healpix-java - hyperstraier-java - idm-console-framework - isorelax - jakarta-oro - java-atk-wrapper - java-hdf - java-hdf5 - java-z3 - javacc (fixed) - jcuber - jdepend - jericho-html - jgrapht - jgraphx - jna (v53 in jna.jar/com/sun/jna/AltCallingConvention.class) - jorbis - jorbis-player - jpcap - jssc - laf-plugin - libgda-java - libidn-java - libkml-java - libphidget-java - libreoffice-writer2latex - libreoffice-writer2html - libsphinxclient - libvirt-java - libwebp-java - mapserver-java - mecab-java - miglayout - opencv-java - openmpi-java - openni-java - osmpbf-java - papaki - pentaho-reporting-flow-engine - plplot-java - portmidi-tools - ppl-java - procyon-* - python3-jep - qdbm-java - regexp - rhino* - rsyntaxtextarea - rundoc - sac - saxpath - sdljava breaks bolzplatz2006 - shaman - simple-jndi - snip - sphinx-java - subversion-javahl - systemtap-runtime-java - taggle* - test-interface - tomcat-webapps - tomjatjss - uddi4j - vecmath1.2 (fixed) - will-crash - writer2latex - wsil4j - xjparse
I'm now running a full analysis of all class files included in packages built in https://copr.fedorainfracloud.org/coprs/g/java-maint-sig/java-11-default/ ...
It's gonna take some time, but I'll post the list of packages that have class files with version > 52 here when it's done.
Turns out, my script is a bit inefficient - it has been running continuously for 7 hours and it has processed packages A-Za-i. I'll optimize the script and run it again tomorrow. :zzz:
Optimized script, first results:
BareBonesBrowserLaunch-3.1-20.fc33.noarch.rpm Class version too high: 55
Mars-4.5-12.fc33.noarch.rpm Class version too high: 55
Singular-surfex-4.1.1p3-15.fc33.x86_64.rpm Class version too high: 55
antlr-tool-2.7.7-61.fc33.noarch.rpm Class version too high: 55
antlr3-tool-3.5.2-29.fc33.noarch.rpm Class version too high: 55
Will post updates below as running the checks progresses.
I have another few:
bigloo-4.3h-3.fc33.x86_64.rpm Class version too high: 55 bigloo-4.3h-3.fc33.x86_64.rpm usr/share/java/jigloo.class
brlapi-java-0.8.0-8.fc33.x86_64.rpm Class version too high: 55
byteman-4.0.11-2.fc33.noarch.rpm Class version too high: 53
capstone-java-4.0.2-1.fc33.noarch.rpm Class version too high: 55
Another few:
collectd-generic-jmx-5.11.0-6.fc33.x86_64.rpm Class version too high: 55
collectd-java-5.11.0-6.fc33.x86_64.rpm Class version too high: 55
cryptlib-java-3.4.5-12.fc33.x86_64.rpm Class version too high: 55
cryptlib-javadoc-3.4.5-12.fc33.noarch.rpm Class version too high: 55 cryptlib-javadoc-3.4.5-12.fc33.noarch.rpm usr/share/javadoc/cryptlib/cryptlib/CRYPT_OBJECT_INFO.class
(WHY is there a .class file in the -javadoc subpackage :interrobang: )
cvc4-java-1.7-13.fc33.x86_64.rpm Class version too high: 55
ditaa-0.10-11.fc33.noarch.rpm Class version too high: 55
dl_poly-gui-1.10-8.fc33.noarch.rpm Class version too high: 55
ecj-4.16-3.fc33.noarch.rpm Class version too high: 55 ecj-4.16-3.fc33.noarch.rpm usr/share/java/ecj/java14api.jar.extracted/javax/annotation/processing/AbstractProcessor.class
ECJ is a false positive that you can ignore -- it is itself a Java compiler and contains some amount of magic.
Next batch:
erlang-jinterface-23.0.2-2.fc33.x86_64.rpm Class version too high: 55
fastbit-java-2.0.3-17.fc33.x86_64.rpm Class version too high: 55
fernflower-183.5153.8-7.fc33.noarch.rpm Class version too high: 55
filedrop-1.1-12.fc33.noarch.rpm Class version too high: 55
findbugs-bcel-6.0-0.19.20140707svn1547656.fc33.noarch.rpm Class version too high: 55
flute-1.3.0-23.OOo31.fc33.noarch.rpm Class version too high: 55
freerouting-1.3.1-5.fc33.noarch.rpm Class version too high: 55
frysk-0.4-73.fc33.x86_64.rpm Class version too high: 55
genders-java-1.27.2-4.fc33.x86_64.rpm Class version too high: 55
glite-jobid-api-java-1.3.9-13.fc33.noarch.rpm Class version too high: 55
gnu-getopt-1.0.14-18.fc33.noarch.rpm Class version too high: 55
graphviz-java-2.44.0-10.fc33.x86_64.rpm Class version too high: 55
healpix-java-3.50-5.fc33.noarch.rpm Class version too high: 55
hyperestraier-java-1.4.13-40.fc33.x86_64.rpm Class version too high: 55
idm-console-framework-1.2.0-5.fc33.noarch.rpm Class version too high: 55
isorelax-0-0.28.release20050331.fc33.noarch.rpm Class version too high: 55
jakarta-oro-2.0.8-29.fc33.noarch.rpm Class version too high: 55
I'll run the rest of the checks tomorrow.
Metadata Update from @decathorpe: - Issue marked as blocking: #10
You can ignore byteman. It's an instrumentation library which needs JDK 9+ to build, but runs fine with JDK 8. The JDK 9 bytecodes are most likely never executed in the JDK 8 case as it's using a multi-release-jar packaging paradigm.
@jerboaa yeah it looked that way from the name of the class file. thanks for confirming! The analysis script is still running (and at this speed, it'll run until the day after tomorrow ...)
Analysis script finished, final list is in the ticket body.
I also rewrote the script in Rust so next time we need something like it, it'll run, like, 1000x faster :cry:
I fixed bigloo.
I also fixed Singular-surfex.
@jjames: Thanks for looking at those, though there's no need to fix them unless packages that are stuck at Java 8 use them (though setting 1.8 level bytecode doesn't hurt either).
In the cases of bigloo and Singular, the Java code is quite old, predating Java generics (1.5). There were other problems with both, so setting them to 1.8 bytecode was a minor part of what I did. I'll talk to the respective upstreams about the improvements I made to the code.
@jjames Oh, nice. Then ignore what I said :)
@jjames: Thanks for looking at those, though there's no need to fix them unless packages that are stuck at Java 8 use them
I wonder if it's easy to remove "leaf" packages from this list. I imagine nothing else depends on the Java in libreoffice, for example.
Oops! I changed this to use -source 1.8 in 97a4caa, but didn't add -target 1.8 (despite mentioning that in the commit message).
-source 1.8
-target 1.8
This is now fixed by 2f54dbf.
rawhide build completed successfully: https://koji.fedoraproject.org/koji/buildinfo?buildID=1577997
I think we fixed all actual issues that were caused by packages that produced bytecode incompatible with Java 8. For other packages, it's not a problem to target newer bytecode.
Metadata Update from @decathorpe: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.