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:

    <profile>
      <id>jdk-release-flag</id>
      <activation>
        <jdk>[9,)</jdk>
      </activation>
      <properties>
        <maven.compiler.release>8</maven.compiler.release>
      </properties>
    </profile>

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.

Update:

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.

FWIW, another fairly easy fix is removing invokations of the javah command. I added a note here: https://fedoraproject.org/wiki/Changes/Java11#javah:_No_such_file_or_directory

Edit: For example: https://src.fedoraproject.org/rpms/snappy-java/blob/2981aaa5b8a597129ad2f12cdf1f4617303a8425/f/javah-adaptation.patch

Update:

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

Update:

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

Update:

Fixed the following packages:

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

Update:

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

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

Update:

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!