FWD » Core Development » Runtime Infrastructure

FWD builds under Java 21, I've build hotel_gui and made a quick test - it works.

Assuming that bringing support for Java 21 is not dependent on removing support for java 8/11/17 a bit overestimated efforts are below (1d = 8h):

• general port and hotel/hotel_gui apps full testing - 2d
• cleaning 54 compiler warnings - 1d (note there are some additional converted code warnings)
• move JNI and native dependencies into the jar (Linux) - 1d and 1d+ windows testing
• regression testing (including adding support for java 21) - 1d + changes to base images (by Roger ?)
• performance testing - 2d
• customer application testing - depends on scope - 2-3 days
• optional - ffm as an option when jdk21+ is detected to use in Memory Manager - no deep analysis yet, 5d+ - requires some discussions (arena types, memory operations implementation, conditional or mandatory etc)

move JNI and native dependencies into the jar (Linux) - 1d and 1d+ windows testing

Is this related to the FFM rework? Or is it related to #6340? Iw ould defer this unless it is really needed.

optional - ffm as an option when jdk21+ is detected to use in Memory Manager - no deep analysis yet, 5d+ - requires some discussions (arena types, memory operations implementation, conditional or mandatory etc)

In Java 21, FFM is experimental. We can't officially move to it until 2 things occur:

• We support Java 25 which is the first LTS release which will officially support FFM; AND
• We drop support for all Java releases prior to Java 21.

This is why we have #9684 as a separate task. That work will be deferred.

Is there any reason we can't do the performance testing first?

Greg Shah wrote:

move JNI and native dependencies into the jar (Linux) - 1d and 1d+ windows testing

Is this related to the FFM rework? Or is it related to #6340? Iw ould defer this unless it is really needed.

No, its more like choosing a proper way for FWD and testing if any suggested ways would work in 2025. I have some security related concerns (extracting binary library and execute it would trigger modern intrusion detection).

Is there any reason we can't do the performance testing first?

Performance testing can be third after initial testing and regression testing, as I am doing performance testing by execution of selected tests from regression tests suite.

Tomasz Domin wrote:

Greg Shah wrote:

move JNI and native dependencies into the jar (Linux) - 1d and 1d+ windows testing

Is this related to the FFM rework? Or is it related to #6340? Iw ould defer this unless it is really needed.

No, its more like choosing a proper way for FWD and testing if any suggested ways would work in 2025. I have some security related concerns (extracting binary library and execute it would trigger modern intrusion detection).

Let's defer that work to #6340.

Is there any reason we can't do the performance testing first?

Performance testing can be third after initial testing and regression testing, as I am doing performance testing by execution of selected tests from regression tests suite.

Using the regression suite for performance testing was misleading last time. It looked like Java 17 was slower than Java 8 but in other customer application testing it has proven to be noticably faster.

I think we should try some early performance testing using some other customer code.

I've created task branch 9685a which is based on trunk revision 15988 and was already tested with hotel_gui app.

• putting Java 21 first on the PATH like export PATH=/usr/lib/jvm/java-21-openjdk-amd64/bin/:${PATH}
• switching default Java to Java 21 machine wide like sudo update-alternatives --set java /usr/lib/jvm/java-21-openjdk-amd64/bin/java

To verify the setting execute java -version.

Note that using Java 21 requires a separate spawner installation folder e.g. /opt/spawner_jdk21/, as older spawners will no be able to run Java 21 compiled code.
To verify please check with ldd /opt/spawner_jdk21/spawn. There should be line like libjvm.so => /usr/lib/jvm/java-21-openjdk-amd64/lib/server/libjvm.so (0x00007a557b000000) in the command output.

Tomasz Domin wrote:

Roger
In file container_java_21.diff please find changes to container project to support Java 21.
The patch is installing additional JDK version 21 and generates two more containers base_ubuntu_22.04_jdk21 and base_ubuntu_22.04_pg14_jdk21

Generated containers were tested and they work fine.

These are checked into revision 77 (for the most part). Note that I have a new version in-flight which already included JDK21. However, it is a lot more refactoring that will create some thin runtime images, and thicker development images. I incorporated the updated switch-java.sh which handles all the supported JDK's in a more streamlined manner. Also, there is a JDK_DEF_VERSION environment variable which is used to set a default JDK, if no version is specified. This default is JDK8, for now.

Roger Borrello wrote:

Tomasz Domin wrote:

Roger
In file container_java_21.diff please find changes to container project to support Java 21.
The patch is installing additional JDK version 21 and generates two more containers base_ubuntu_22.04_jdk21 and base_ubuntu_22.04_pg14_jdk21

Generated containers were tested and they work fine.

These are checked into revision 77 (for the most part). Note that I have a new version in-flight which already included JDK21. However, it is a lot more refactoring that will create some thin runtime images, and thicker development images. I incorporated the updated switch-java.sh which handles all the supported JDK's in a more streamlined manner. Also, there is a JDK_DEF_VERSION environment variable which is used to set a default JDK, if no version is specified. This default is JDK8, for now.

I noticed the -p option for pushing the images was not updated, so I checked those into revision 78.

There is a problem with building FWD on clean system with Java 21 only - gradle 7.6.4 does not support Java 21 fully (see #10775)
It was not detected as I never did any clean build on clean system - I was just switching JDKs on development machine.

Saying so - supporting JDK 21 requires migrating gradle to version at least 8.5 -

I've spent some time migrating gradle to version supporting Java 21 - I started with version 8.14.3, which is currently the newest in 8.x line.
Unfortunately It seems I've found a bug in gradle 8.14.x - in case project has files processed by AspectJ incremental Java compilation fails when using java plugin (like we do in sheet project). It took me few hours before I got to the cause, I even tried internal gradle debugging. I was so stubborn on this as I wanted to keep gradle version 8.14.x as it also supports Java 24.

Unfortunately I had to rollback to gradle version 8.13, where almost immediately things started to work. I still need to test it with Java 17, as support for Java 8 will be outdated.

If we even move to gradle 8.14.x we need remember to disable incremental compilation for ext/sheet project with:

tasks.withType(JavaCompile).configureEach {
    options.incremental = false
}

Rebased to trunk/16277
Pushed up 9685a to revision 16278.

I have revision 16302 of trunk and am trying to compile with JDK21. When I run ./gradlew all sheet:war I get:

To honour the JVM settings for this build a single-use Daemon process will be forked. See https://docs.gradle.org/7.6.4/userguide/gradle_daemon.html#sec:disabling_the_daemon.
Daemon will be stopped at the end of the build 

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'trunk'.
> Could not open cp_proj generic class cache for build file '/home/rfb/projects/fwd/trunk/build.gradle' (/home/rfb/.gradle/caches/7.6.4/scripts/e60uiinzp7lhrsop3qxgw3j60).
   > BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 65

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 3s

I am using the latest goldencode/basedev_ubuntu_24.04 Docker image, which can be pulled with:

scp <id>@xfer.goldencode.com:/opt/fwd/container/dbash.sh .
./dbash.sh

The tools installed in the image are:

base_tools_def="openssh-server gosu locales jq sed curl sudo wget unzip zip 7zip rsync less ca-certificates gnupg screen dos2unix vim ncurses-term sysstat iptables lsb-release sshfs redir lynx xmlstarlet" 
base_tools=$base_tools_def
dev_tools_def="build-essential gcc brz python3-paramiko apt-utils libc-bin ant dpkg-dev libffi-dev libpam0g-dev iproute2 iputils-ping bind9-dnsutils software-properties-common libncurses5-dev" 
jdk_install="openjdk-17-jdk openjdk-21-jdk" 
jdk_sources="openjdk-17-source openjdk-21-source" 

Do I need to remove the old gradle cache?

Roger Borrello wrote:

I have revision 16302 of trunk and am trying to compile with JDK21. When I run ./gradlew all sheet:war I get:
[...]

I am using the latest goldencode/basedev_ubuntu_24.04 Docker image, which can be pulled with:
[...]

The tools installed in the image are:
[...]

Do I need to remove the old gradle cache?

No - actually that happens when you remove old cache.
Please switch to gradle 8.13 by editing gradle/wrapper/gradle-wrapper.properties and optionally ext/sheet/gradle/wrapper/gradle-wrapper.properties
Or you can use branch 9685a, but its a bit outdated.

Tomasz Domin wrote:

I am attaching a patch switch_to_gradle_8_13.diff to switch to gradle 8.13 for you convenience.
Apply if you get into troubled with building FWD with Java 21

Thank you! It worked great.

Our appcds support from Java 17 is broken in Java 21. See #11100-27 and following for details.

What I need to tell that the latest changes from 9685a has became obsolete because there are other changes like updating gradle to 9.1.0 which are already in trunk.
AspectJ version upgrade to 1.9.24+ is also in 9686a.