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
