OFBIZ-13306: JAVA 21 migration

[gtchaboussie]

Changed: Migration to Java 21
(OFBIZ-13306)

Migration to Java 21

Thanks: Jacques for the warnings work and Nicolas.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[JacquesLeRoux]

I did not look at it yet, we got this:

Execution failed for task ':compileJava'.

error: invalid source release: 21

[ieugen]

@gtchaboussie : thanks for the contribution.

I think you are also trying to increase the java source level - which might not be in scope right now.

The important part is that OFBiz can be built using JDK-21.
I don't believe it means we need to increase source level to 21 so only JDK-21+ can build OFBiz.
I think the source level/version can stay on 17 and have OFBiz build with JDK17 and JDK21

The build fails right now because the CI server uses only JDK-17.
It would be great to have OFBiz tested with multiple JDK versions at once (JDK build matrix) - but some other time.

Regarding source level increase, looking at https://docs.oracle.com/en/java/javase/21/language/java-language-changes-summary.html , the only language changes that are new from 17->21 are:

Record Patterns (JEP 440)

Pattern Matching for switch Expressions and Statements (JEP 441)

Not sure if those are enough to warrant a source level increase.
Should ask on ML.

[JacquesLeRoux]

Hi @gtchaboussie,

The Java build did not work. That's normal as "java-version: 17" is specified in gradle.yaml as mentioned @ieugen above. I did not dig further.

[gtchaboussie]

hi @JacquesLeRoux .
I tried to update it in my last commit but it seems i'm not allowed. I'm not sure I understand

[jacopoc]

Hi @gtchaboussie
I am not sure I understand the issue you are facing:

I tried to update it in my last commit but it seems i'm not allowed.

The OFBIZ-13306 branch is in your fork, so you should be allowed to push new commit into it.

[gtchaboussie]

Yeah sorry, i misread the error message friday.
THere is a conflict in the github file, but i'm not familiar with the github actions files.
The conflict seems to be about a hash, but my only change was about the java version.
Is github trying to update a dependency ?

[JacquesLeRoux]

Hi Gaetan,

I guess you can't push because of these premature commits I did
846e987
01a5ad3

I thought it was necessary to use Java 21. I will now revert them and see what happens here.

As you may now (it's on dev ML), currently there are some issues with GHA (GH actions). That does not help when you mix different issues in an amalgam :(

[JacquesLeRoux]

It was that, please try

[gtchaboussie]

Thanks jacques.
Now i'm getting this error when trying to rerun the failed build, it seems i'm not allowed to run the build.
I can make a fake commit to trigger it though..
https://github.com/apache/ofbiz-framework/actions/runs/23334471276?pr=917

The action step-security/harden-runner@63c24ba6bd7ba022e95695ff85de572c04a18142 is not allowed in apache/ofbiz-framework because all actions must be from a repository owned by your enterprise, created by GitHub, or match one of the patterns: 1Password/load-secrets-action@13f58eec611f8e5db52ec16247f58c508398f3e6, 1Password/load-secrets-action@8d0d610af187e78a2772c2d18d627f4c52d3fbfb, 1Password/load-secrets-action@dafbe7cb03502b260e2b2893c753c352eee545bf, AdoptOpenJDK/install-jdk@*, BobAnkh/auto-generate-changelog@*, DavidAnson/markdownlint-cli2-action@07035fd053f7be764496c0f8d8f9f41f98305101, DavidAnson/markdownlint-cli2-action@30a0e04f1870d58f8d717450cc6134995f993c63, EnricoMi/publish-unit-test-result-action@*, JamesIves/github-pages-deploy-action@4a3abc783e1a24aeb44c16e869ad83caf6b4cc23, JamesIves/github-pages-deploy-action@d92aa235d04922e8f08b40ce78cc5442fcfbfa2f, Jimver/cuda-toolkit@6008063726ffe3309d1b22e413d9e88fed91a2f2, Jimver/cuda-toolkit@b6fc3a9f3f15256d9d94ffe1254f9c5a2565...

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gtchaboussie]

The file used by the workflow still uses java 17: https://github.com/apache/ofbiz-framework/actions/runs/23431619247/workflow?pr=917

I don't know if there is a way to make it use the github file version from PR.

[JacquesLeRoux]

There was another issue in the PR branch, harden runner was present. So now indeed gradle.yaml is the same than in trunk.
I must say that I don't quite understand why the gradle build say

error: invalid source release: 21

Maybe we need to use something like

java {
    sourceCompatibility = '17'
}

in gradle.build?

[JacquesLeRoux]

This could help: https://www.baeldung.com/gradle-sourcecompatiblity-vs-targetcompatibility
Looking at 2 other issues I need to fix :)

[jacopoc]

The CI/CD build fails because it uses JDK 17:

    - name: Set up JDK 17
      uses: actions/setup-java@387ac29b308b003ca37ba93a6cab5eb57c8f5f93 # v4.0.0
      with:
        java-version: 17
        distribution: temurin
        cache: 'gradle'

(see https://github.com/apache/ofbiz-framework/blob/trunk/.github/workflows/gradle.yaml )
while the PR is on 21.

[JacquesLeRoux]

So what

error: invalid source release: 21
does mean?

I guess it's now time to try putting back what you @gtchaboussie initially put in gradle.yaml (ie using JDK 21)
But then why did it fails previously? At this time harden runner was not in gradle.yaml, right?

[jacopoc]

@JacquesLeRoux It means that the sources (at java 21) are not compatible with the runtime used by the workflow (java 17).

[JacquesLeRoux]

Thanks @jacopoc,

So it seems that the ball is in @gtchaboussie camp.

I don't remember how we previously jumped from JDK 11 to 17, but Gaetan I guess what I did in build.gradle
with
846e987
and
01a5ad3
You should do it in your branch and PR
Right @jacopoc ?

[JacquesLeRoux]

Maybe only trying with 846e987 as a 1st step (it's not clear to me if 01a5ad3 is needed)

[jacopoc]

@JacquesLeRoux @gtchaboussie Before merging this, given that it’s an important step, I think we should ensure all concerns are addressed and approach it in a clean, deliberate way (rather than through incremental attempts).

In particular, I think @ieugen’s earlier comment should be addressed.

To summarize and expand on that point: ideally, we should define a clear compatibility strategy. One possible approach is to keep sourceCompatibility/targetCompatibility set to 17 for now, so that we continue producing Java 17–compatible bytecode, while running CI/CD on Java 21 to ensure the project works correctly on the newer runtime.

However, if we want to truly guarantee compatibility with both versions, it might be worth considering running CI on both Java 17 and Java 21 (e.g., via a matrix build), rather than only on Java 21.

More importantly, we should clarify whether this is meant to be a temporary transition phase or a longer-term strategy. In particular, if trunk starts adopting Java 21-specific features, backporting fixes to the release24.09 branch (which is still on Java 17) may become difficult or impossible. This is especially relevant given that our contribution workflow requires fixes to be committed to trunk first and then backported.

Additionally, if we proceed with this PR, I think we should ensure that plugin upgrades are handled at the same time (I’m aware there is a separate PR for that), since Java version upgrades and plugin compatibility are often tightly coupled.

Finally, we should also consider how to handle CI/CD, given that we currently have a single workflow shared between trunk and the release branch, but potentially different Java requirements.

[JacquesLeRoux]

@jacopoc, should we not discuss on dev ML about that?

[jacopoc]

@jacopoc, should we not discuss on dev ML about that?

@JacquesLeRoux yes, see the thread: "Move trunk to java 21"

[JacquesLeRoux]

OK, I see Gaetan's message now