#1 OpenJDK 11 EasyFix
Closed 2 years ago by decathorpe. Opened 2 years ago by decathorpe.

Below is an initial list of "easyfix" issues that should resolve build failures with Java 11, unless they only mask other issues further down the line.

Builds can be seen in this COPR:

In addition to the proposed changes to java-1.8.0-openjdk, java-11-openjdk, and javapackages-tools, I switched the default method for generating JavaDocs to xmvn-javadoc, which is much much less errory with OpenJDK 11.

These changes should be safe to include in rawhide even before openjdk 11 is made the default. If you do, please edit this ticket and add change [ ] to [x] below.

The COPR is also wired up to automatically build the latest state of packages in dist-git, so if you do make the changes, you should be able to see packages switch from red to green in the COPR, too.

- [ ] gnulib:                     ant -source 1.8 -target 1.8 (uses 1.3 upstream :(((( )
- [ ] jaxodraw:                   ant -source 1.8 -target 1.8
- [ ] junit:                      %mvn_build -- -Dmaven.compiler.source=1.8 -Dmaven.compiler.target=1.8
- [ ] metadata-extractor2:        move away from native2ascii
- [ ] openstack-java-sdk:         add back javadoc subpackage
- [ ] rxtx:                       autotools -source 1.8 -target 1.8
- [ ] sblim-cim-client:           ant -source 1.8 -target 1.8
- [ ] sblim-cim-client2:          ant -source 1.8 -target 1.8
- [ ] scala:                      ant -source 1.8 -target 1.8
- [ ] skinlf:                     ant -source 1.8 -target 1.8

Ideally, we should use -Dmaven.compiler.release=8. However, the compiler compliance checks in newer JDKs is sometimes stricter than the older JDK was for that version. On the other hand, using the release option does fix other issues.

Does -Dmaven.compiler.release=8 result in 1.8 being used for source and target?

Does -Dmaven.compiler.release=8 result in 1.8 being used for source and target?

In theory, it replaces those, as well as sets the bootstrap class path, to ensure it can't bind to any non-visible APIs that wouldn't be available if run in the target Java version.

However, there are a few caveats:

  1. The flag requires a newer version of maven-compiler-plugin (I'm not sure what version is in Fedora) so that it recognizes the property and sets the appropriate javac -release arg,
  2. It is still useful to set maven.compiler.source and maven.compiler.target properties, because these may be used in project pom.xml files and by plugins other than maven-compiler-plugin,
  3. The release flag can be more strict than actually building on that version of Java. In particular, certain internal APIs which were documented as non-public, but were still technically available, may not compile if the release flag is set, even if it compiles fine on the JDK that it is targeting. However, if the release flag is not set, this can also cause problems. For example, I'm aware of at least one case where code using some ByteBuffer methods will not work on the target JDK unless the release flag is set to ensure strict compiler compliance. This is because new methods were added to ByteBuffer that shadow the old methods, and the compiled byte code will reference a non-existent method in the target JDK if compiled with a newer JDK without the release flag.

In general, I'd recommend adding -Dmaven.compiler.release=8 in addition to the same flags for source and target, if the pom.xml itself doesn't already set the property for the release flag. This will ensure strict compiler compliance with the target JDK version. If anything breaks, they should be addressed on a case-by-case basis.

There's a problem with using -Dmaven.compiler.release=8. We have the latest version of maven-compiler-plugin in fedora, but it looks like it only supports the --release flag when running on Java 9 or later, so adding this flag to packages now will break them.

Using -Dmaven.compiler.source=1.8 and -Dmaven.compiler.target=1.8 works with both java-1.8.0-openjdk and java-11-openjdk as default, which is why I suggested it as the "easyfix" action.

@decathorpe Yes... the release flag only works on 9 and later. That is why I have contributed the following patch to several Maven-based projects upstream:


This isn't generally necessary on Fedora builds, because we already know what JDK will be used in the buildroot, don't we? Even if we don't, something similar could be done with an RPM conditional.

As I previously suggested, it's not necessarily an easy fix. Building on a newer JDK with only -source 1.8 and -target 1.8 can still result in broken builds. Even if the code compiles fine, it may result in compatibility breakages when somebody tries to run the code on the older JRE. That is why it's probably worth pursuing the use of the -release flag if possible.

No, we don't necessarily know which openjdk version a package will be built right now. For example, we have a COPR for test rebuilds against OpenJDK 11 (which is how I compiled the list of EasyFixes), and the mass rebuild for OpenJDK 11 will happen in a side tag soon ...

I also don't think that adding conditionals into 200 .spec files is a scalable solution to this problem. Doing a simple one-line change that works before and after the switch to OpenJDK 11 seems like the better solution to me, and it's also what the "Java 11 by default" Change owners recommend.

I agree adding conditionals isn't scalable. Under that constraint, I agree that it is best to avoid using the -release flag (via -Dmaven.compiler.release=N or otherwise). We should just be aware that if the library is built using the a newer JDK without this flag, there is some small risk of compiled code being broken in subtle ways. It's just something to be aware of, in case it needs to be fixed on a case-by-case basis later, if a bug is reported.

@ctubbsii Yup, I'll keep that in mind. If we get bug reports for such cases, we know what to do, and at that point, Java 11 is the default, so we can safely add the -release flag then.


The follwing packages are now building successfully with both java-1.8.0-openjdk and java-11-openjdk:

  • ant-contrib
  • antlr3
  • antlr32
  • antlrworks
  • apache-commons-jxpath
  • cal10n
  • decentxml

I've removed them from the list in the ticket body.


The following packages have been fixed, and I've removed them from the original list:

  • apache-commons-logging
  • atinject
  • bouncycastle
  • hamcrest
  • jakarta-annotations
  • jnr-netdb
  • jnr-x86asm
  • nekohtml
  • sat4j
  • ws-commons-util
  • xalan-j2
  • xml-commons-apis
  • xmlrpc
  • xz-java


The following packages are now fixed and removed from the original list.

  • apache-commons-cli
  • felix-osgi-obr-resolver (retired)
  • geronimo-annotation (retired)
  • geronimo-interceptor
  • geronimo-jaxrpc
  • geronimo-jcdi-1.1-api
  • geronimo-jms
  • geronimo-jpa
  • geronimo-osgi-support
  • geronimo-validation
  • glassfish-jaxb-api
  • jansi-native
  • jcip-annotations
  • jdom
  • jFormatString
  • jline
  • json_simple
  • jsr-305
  • jzlib
  • maven-release (retired)
  • plexus-cipher
  • replacer
  • slf4j
  • stringtemplate
  • tzdata


Fixed the following packages:

  • apache-ivy
  • joda-time
  • maven2
  • maven-artifact-resolver


The following packages have been fixed and removed from the original list:

  • ant-antunit
  • apache-commons-exec
  • jaxen
  • univocity-output-tester
  • xpp3


The following packages have been fixed and removed from the original list:

  • apache-commons-math
  • apache-commons-modeler
  • apache-log4j-extras
  • apache-rat
  • buildnumber-maven-plugin
  • hibernate-jpa-2.0-api
  • jacoco
  • jacop
  • java-dirq
  • jcodings
  • jglobus
  • sunflow
  • voms-api-java

I fixed another batch of packages:

  • jdependency
  • maven-license-plugin
  • msv
  • nailgun
  • paranamer
  • plexus-i18n
  • portlet-2.0-api
  • relaxngDatatype
  • scannotation
  • tomcat-taglibs-standard
  • xmltool
  • xsom

Another batch of packages I fixed today:

  • brazil
  • bytelist
  • flexdock
  • imagej
  • jdom2
  • jsap
  • jtidy
  • jvyamlb

Fixed kxml and lpg and now I am out of F-s to give.

Can remove libdb from the list -- the maintainer dropped the Java subpackage: https://src.fedoraproject.org/rpms/libdb/c/17b322e82a45ad268ecae7ed49d437460b182677

Alright, I fixed vecmath and t-digest, and I think those two were the last really "easy" changes.

Closing this ticket. Java 11 is now the default in rawhide and the remaining build failures can be tackled on an individual basis.

Thanks for all your help!

Metadata Update from @decathorpe:
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.