This is probably package related but since it is only showing up with Fedora 35 (and was OK before the update), I will ask the question.
Maven appears to pick up the wrong version of Java. I’ve set java-17-openjdk as the version to use using alternatives but maven is using java-11?
This did not occur with F34, does anyone know what is going on?
$ java -version
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment 21.9 (build 17.0.1+12)
OpenJDK 64-Bit Server VM 21.9 (build 17.0.1+12, mixed mode, sharing)
$ echo $JAVA_HOME
/usr/lib/jvm/java-17-openjdk-17.0.1.0.12-1.rolling.fc35.x86_64
$ mvn -version
Apache Maven 3.6.3 (Red Hat 3.6.3-12)
Maven home: /usr/share/maven
Java version: 11.0.13, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-11-openjdk-11.0.13.0.8-1.fc35.x86_64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.14.14-300.fc35.x86_64", arch: "amd64", family: "unix"
$
OK, for some reason a configuration file was added to this RPM that set JAVA_HOME in /etc/java/maven.conf
Commenting it out prevented JAVA_HOME from being clobbered.
and it seems like there are packages to tell maven what java version to use. So for example, if you want maven to use OpenJDK 11, you’d install the maven-openjdk11 package. This sets the config file:
which will replace the maven-openjdk11 package with maven-openjdk17 and give you the expected output:
$ mvn -version
Apache Maven 3.6.3 (Red Hat 3.6.3-12)
Maven home: /usr/share/maven
Java version: 17.0.1, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-17-openjdk-17.0.1.0.12-1.rolling.fc35.x86_64
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "5.14.15-300.fc35.x86_64", arch: "amd64", family: "unix"
So, it’s not a bug. It’s just a package based way of allowing users to choose what java version they want maven to use.
What could be done is to add a README or something to tell users about these packages. Maybe it’s in the documentation somewhere, but I haven’t looked.
Having the user forced to keep up to date and install that package for whatever version of java is in use seems a bit short-sighted of the developers. If Maven requires a specific version of java then during the install it seems would be the time to verify that dependency is met. If it merely needs a config to match what is already installed then that config should also be set during the install.
It seems that the developers should ensure that the install matches the system it is on and failure to properly configure it seems at the very least a packaging bug. The user should not be required to chase down the problems caused by mis-configuration.
Maven and most of other Java applications packaged in Fedora are ran with JRE/JDK specified by JAVA_HOME environment variable or configured in config files. Neither PATH nor alternatives are used for controlling Java version used by Maven. This approach is used since Fedora 27 and is documented in F27 release notes.
To change Java version used by Maven in current session you can set JAVA_HOME variable to point to appropriate directory, like /usr/lib/jvm/java-17. This can be done without root access on the system.
In order to permanently change JDK used to run Maven on the whole system you can pick appropriate binding package. Maven in Fedora 35 ships with bindings for OpenJDK 8, 11 and 17. dnf swap maven-jdk-binding maven-openjdk17 command can be used to swap whatever Maven JDK binding package is currently installed to OpenJDK 17 binding.
It is also possible to use Maven Toolchains, which allow Maven to build projects with different JDK than it is used to run Maven.
One would expect this behavior but alas this is not the case.
Unfortunately JAVA_HOME is overwritten by the mvn script to use that defined in /etc/java/maven.conf so its not possible to change the version used by maven by setting the JAVA_HOME environment variable.
. /etc/java/maven.conf
On re-reading the /usr/bin/mvn bash script I see there is an environment variable MAVEN_SKIP_RC which, if set, will cause mvn to ignore maven.conf and thus not override JAVA_HOME.
This is not actually ideal (I think) as maven is then run with (perhaps) and incomparable java version.
My problem is that the java files compiled by maven have Java 17 features that fail when compiled with Java 11. I’m OK with maven running under Java 11 but need the files compiled using the Java to specified by JAVA_HOME.
In /usr/bin/mvn, maven is run with the java specified in JAVACMD.
if [ -z "$JAVA_HOME" ] ; then
JAVACMD=`which java`
else
JAVACMD="$JAVA_HOME/bin/java"
fi
It looks to me that a better solution is to set JAVACMD to specific Java version of the installed maven libraries (e.g. 11) and leave aloneJAVA_HOME so that the user java files are compiled as expected.
If you see behavior different from what I described then please open a bug report at Red Hat Bugzilla and it will be investigated by Maven maintainers.