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
