[ https://issues.redhat.com/browse/ELY-1979?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on ELY-1979: --------------------------------------- This will get interesting. Our build requires Java 11 as we have some multi module jars which allow us to use some later APIs to move away from some of the "workarounds" we needed when running against Java 8, as defined in jboss-parent we however still target Java 8: {code:xml} <maven.compiler.target>1.8</maven.compiler.target> <maven.compiler.source>1.8</maven.compiler.source> {code} We then redefine the maven-compiler-plugin and set the release version to 8: {code:xml} <release>8</release> {code} This parameter is passed straight to javac, According to the documentation for the release parameter: {quote} Compiles against the public, supported and documented API for a specific VM version. Supported release targets are 6, 7, 8, 9, 10, and 11. {quote} https://docs.oracle.com/en/java/javase/11/tools/javac.html It seems even the latest versions of Java 11 don't agree these new methods are part of the Java 8 API. If I remove the release setting the use of these new methods build cleanly but it does leave the project at risk of using API later than Java 8. I can probably relax this check just for the affected component to get the changes through but we may now need an alternative API check to double check we don't accidentally introduce anything else new - so far this configuration has been quite reliable at providing the protection we need. -- This message was sent by Atlassian Jira (v7.13.8#713008)