Hi all,
So there has been a discussion on the merge request [1], thanks to all.
I can try to summerize the main points here:
The current Github CI builds OFBiz with java 17[2]. I'm not familiar
enough with the technology to
- How do we proceed with the Java version migration ?
- One option could be to ensure that OFBiz compiles woth Java 21, but
keep source and target in gradle set to Java 17
- This would induce setting up github CI to java 21 to ensure
that the code produced is 21 compliant.
- An other way would be to also migrate the source and target version
in gradle to java 21.
- This would me more coherent but would make the next
migrations / updates heavier.
- This would also mean that we would have to maintain two CI
for a time (17 and 21) for a time.
Are there any thoughts or opinions on how to handle the migration (of
framework and CI/CD), both in terms of actions and / or planning ?
TIA, Gaetan.
[1] https://github.com/apache/ofbiz-framework/pull/917
[2]
https://github.com/apache/ofbiz-framework/blob/a2a75e348d8472719b26642e2837b7dab2f20eaf/.github/workflows/gradle.yaml#L43
On 3/20/26 09:19, gaetan.chaboussie wrote:
Hi all,
Coming back after some time on this discussion [1] .
I rebased the 21 migration branch, and all seems to be working with
source and target set as Java 21.
It took a while, but considering that there is talk about splitting
the framework, i thought the java version update was a priority.
Merge is ready [2], are there any remarks ?
Gaetan
[1] https://issues.apache.org/jira/browse/OFBIZ-13306
[2] https://github.com/apache/ofbiz-framework/pull/917
On 11/12/25 09:37, Jacques Le Roux wrote:
Hi,
That sounds raisonnable to me, though I'm not sure about the release
branches creation dates.
Do we really need, and especially can afford, a release branch per
year ? The most recent past clearly shows it's not the case...
There is another argument about having the same Java version for the
release branche(s) and the trunk.
It's really less work for committers ! Of course only when possible,
that can't be a constraint.
But I really like it when merging bugs in release branches ! Don't you ?
Jacques
Le 11/11/2025 à 11:03, Michael Brohl a écrit :
Hi all,
we should ask ourselves "what is the real benefit for the project
and it's users to upgrade to a higher Java version and when should
we do it?".
As said before, the projects and users / companies I know are on a
more conservative update way and JDK 17 LTS is supported until at
least October 2027. So if we do one new release branch ever year and
there are no serious reasons to upgrade, I would suggest the
following roadmap:
release 25.x with JDK 17 (creating the branch this year), after that
moving trunk to 21 completely
release 26.x with JDK 21 (creating the branch in 4th quarter of 2026)
We should support 25.x until at least October 2027 then, having a
support overlap for 25.x and 26.x of about a year.
That will give us enough time to stabilize a 26.x release branch
with JDK 21 and users enough time to prepare for the 26.x upgrade
(assuming that the first release will be in mid 2027).
Best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 11.11.25 um 09:44 schrieb Jacques Le Roux:
Hi,
As I said already, I'm mostly concerned with possible real issues
with "this-escape", even with JDK 17 that needs backporting, and
maybe a lot of work before.
When looking at
https://en.wikipedia.org/wiki/Java_version_history#toc-Java_17_updates
there is indeed some free time for JDK 17.
But there is a problem using it as target, ie in main build.gradle,
like
java {
sourceCompatibility(JavaVersion.VERSION_21)
targetCompatibility(JavaVersion.VERSION_17)
}
because of
https://docs.oracle.com/en/java/javase/21/docs/specs/man/javac.html#option-target
<<Note: The target release must be equal to or higher than the
source release>>
Sincerely I still see no problem using 21 for trunk we could even
release using 17 for source and target.
Jacques
Le 10/11/2025 à 14:54, Nicolas Malin a écrit :
From my side, I think it's a good to clean OFBiz java code to
support Java 21 with all new alert raise and let it on java 17 for
the target src.
We know that it's minimal on java 17 and completely compliant on
java 21. Each administrator can select the correct jre for is
infrastructure.
In my mind when I started this subject it's more "are we java21
compliant" to prepare the future :)
Nicolas
On 10/11/2025 10:34, Jacques Le Roux wrote:
Hi,
There is something I did not speak about, the new "this-escape"
warning.
Here is a good and simple explanation about it:
https://stackoverflow.com/questions/77191858/what-is-a-this-escape-warning-and-how-do-i-deal-with-it#77191859
OFBiz contains 97 such possible issues. To hide them, for the
moment in build. gradle I put in “options.compilerArgs <<
'-Xlint:-this-escape'” into _« tasks_._withType_(_JavaCompile »_
As this can allow the compiler to do anything it wants: <<In the
C programming community, undefined behavior may be humorously
referred to as "nasal demons", after a comp.std.c post that
explained undefined behavior as allowing the compiler to do
anything it chooses, even "to make demons fly out of your nose">>
https://en.wikipedia.org/wiki/Undefined_behavior
We need to verify when it's really an issue and then fix it.
Most of the work remains and even the fix should be backported to
the release branch. That's also why we should not wait.
HTH
Jacques
Le 09/11/2025 à 12:10, Jacques Le Roux a écrit :
Hi,
About CI, it's possible to build trunk on GH actions by changing
gradle.yaml from JDK 17 to 21.
Then also BB should be changed the same.
After a 1st glane I'm still unsure about demos that now use Docker.
I see no Java version reference in docker-image.yaml. IIRR it
uses the jar build by gradle.yaml.
The VM still uses JDK 11 by default. Only JDK 17 is also installed
Looking for "17" in source we get 22 774 occurrences.
A lot are unrelated, but still 1110 for " 17" (" 17 " only 1
unrelated).
Apart changes in
https://github.com/apache/ofbiz-framework/pull/917/files for "
17" in source we have also:
devcontainer.json related to
https://issues.apache.org/jira/browse/OFBIZ-13151
INSTALL
README.adoc
dependencies.gradle
I did not look into the 1110 others that are into applications,
framework, themes and plugins (with also patches I have locally)
code.
Conclusion, it seems easy to decide to go with JDK 21 for trunk.
Jacques
Le 07/11/2025 à 15:58, gaetan.chaboussie a écrit :
Hello all. As pointed out by Eugen [1], a question rises from
the subjet of Java21 update:
Of 'source' and 'target' java versions, wich one(s) should be
updated ?
I for myself don't have a strong opinion on the matter.
Regards
Gaetan.
[1]
https://github.com/apache/ofbiz-framework/pull/917#issuecomment-3493565728
On 10/27/25 11:21, gaetan.chaboussie wrote:
Done nicolas :
https://issues.apache.org/jira/browse/OFBIZ-13306
Gaetan
On 10/3/25 15:31, Jacques Le Roux wrote:
Hi Nicolas,
That's a good idea. Another would be to upgrade Gradle,
because for instance of bottom of
https://issues.apache.org/jira/browse/OFBIZ-13296
Jacques
Le 03/10/2025 à 14:31, Nicolas Malin a écrit :
I will open an issue and try to move forward on it ? :)
At this time only OFBiz test doesn't on 21 works.
Nicolas
