You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Nicolas Malin <ni...@nereide.fr> on 2025/10/03 12:31:29 UTC
Move trunk to java 21
I will open an issue and try to move forward on it ? :)
At this time only OFBiz test doesn't on 21 works.
Nicolas
Re: Move trunk to java 21
Posted by Jacques Le Roux via dev <de...@ofbiz.apache.org>.
Hi Gaetan,
Actually I did not show the right trunk (HEAD) version which is
https://github.com/apache/ofbiz-framework/blob/trunk/.github/dependabot.yml
But anyway the content is the same since
https://github.com/apache/ofbiz-framework/commit/a93b04bbb2205e4395f134c85e57a44e56b8c861
When I compare your PR with trunk HEAD, I indeed see no change at all in dependabot.yml
https://github.com/apache/ofbiz-framework/compare/trunk...gtchaboussie:ofbiz-framework:OFBIZ-13306
Are you sure that the branch related to your PR is up to date with trunk HEAD?
Because in
https://github.com/gtchaboussie/ofbiz-framework/commit/dee6a10839b0f93534c85eccdbde1c6bb5461d0f
it could be the removing of package-ecosystem: npm in dependabot.yml
The one done by Jacopo 4 years ago?
BTW, maybe I'm missing something :)
TIA
Jacques
Le 24/03/2026 à 08:49, gaetan.chaboussie a écrit :
>
> Hi @jacques,
>
> I don't remember editing any file other than java, xml and gradle.
>
> I'm not familiar enough with github and dependabot, and it seems the commit you mention (dee6a10) comes from trunk that was merged in the
> OFBIZ-13306 branch.
>
> If any action on my part affected it, i'm not sure wich one it was
> Gaetan
>
> On 3/24/26 06:39, Jacques Le Roux via dev wrote:
>> Hi,
>>
>> While working on the "password issue", I found an interesting warning at
>> https://github.com/apache/ofbiz-framework/actions/runs/23431619247
>>
>>
>> *build* <https://github.com/apache/ofbiz-framework/actions/runs/23431619247/job/68159137855#step:13:3>
>> Node.js 20 actions are deprecated. The following actions are running on Node.js 20 and may not work as expected:
>> actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11, actions/setup-java@387ac29b308b003ca37ba93a6cab5eb57c8f5f93. Actions will be forced to
>> run with Node.js 24 by default starting June 2nd, 2026. Please check if updated versions of these actions are available that support Node.js 24. To
>> opt into Node.js 24 now, set the FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true environment variable on the runner or in your workflow file. Once Node.js
>> 24 becomes the default, you can temporarily opt out by setting ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true. For more information see:
>> https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
>> <https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/>
>> Show less
>>
>>
>> Do we have issues with Node 24 ?
>>
>> Also while at it, @Gaetan: is there a reason why npm is removed from .github/dependabot.yml
>> in https://github.com/gtchaboussie/ofbiz-framework/commit/dee6a10839b0f93534c85eccdbde1c6bb5461d0f ?
>> I mean it's still in trunk
>> https://github.com/apache/ofbiz-framework/blob/a2a75e348d8472719b26642e2837b7dab2f20eaf/.github/dependabot.yml#L8
>>
>> TIA
>>
>> Jacques
>>
>> Le 23/03/2026 à 17:13, gaetan.chaboussie a écrit :
>>> 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
>>>
Re: Move trunk to java 21
Posted by Jacques Le Roux via dev <de...@ofbiz.apache.org>.
OK, thanks Jacopo
I was wondering after my last message just sent.
Le 24/03/2026 à 08:57, Jacopo Cappellato a écrit :
> The changes mentioned by Jacques are due to the rebase, they were not
> introduced by Gaetan, and they are not relevant for this thread in which we
> are discussing how to handle the Java upgrade.
>
> Jacopo
>
> On Tue, Mar 24, 2026 at 8:49 AM gaetan.chaboussie <
> gaetan.chaboussie@nereide.fr> wrote:
>
>> Hi @jacques,
>>
>> I don't remember editing any file other than java, xml and gradle.
>>
>> I'm not familiar enough with github and dependabot, and it seems the
>> commit you mention (dee6a10) comes from trunk that was merged in the
>> OFBIZ-13306 branch.
>>
>> If any action on my part affected it, i'm not sure wich one it was
>> Gaetan
>>
>> On 3/24/26 06:39, Jacques Le Roux via dev wrote:
>>> Hi,
>>>
>>> While working on the "password issue", I found an interesting warning at
>>> https://github.com/apache/ofbiz-framework/actions/runs/23431619247
>>>
>>>
>>> *build*
>>> <
>> https://github.com/apache/ofbiz-framework/actions/runs/23431619247/job/68159137855#step:13:3
>>> Node.js 20 actions are deprecated. The following actions are running
>>> on Node.js 20 and may not work as expected:
>>> actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11,
>>> actions/setup-java@387ac29b308b003ca37ba93a6cab5eb57c8f5f93. Actions
>>> will be forced to run with Node.js 24 by default starting June 2nd,
>>> 2026. Please check if updated versions of these actions are available
>>> that support Node.js 24. To opt into Node.js 24 now, set the
>>> FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true environment variable on the
>>> runner or in your workflow file. Once Node.js 24 becomes the default,
>>> you can temporarily opt out by setting
>>> ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true. For more information
>>> see:
>>>
>> https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
>>> <
>> https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/>
>>
>>> Show less
>>>
>>>
>>> Do we have issues with Node 24 ?
>>>
>>> Also while at it, @Gaetan: is there a reason why npm is removed from
>>> .github/dependabot.yml
>>> in
>>>
>> https://github.com/gtchaboussie/ofbiz-framework/commit/dee6a10839b0f93534c85eccdbde1c6bb5461d0f
>>> ?
>>> I mean it's still in trunk
>>>
>> https://github.com/apache/ofbiz-framework/blob/a2a75e348d8472719b26642e2837b7dab2f20eaf/.github/dependabot.yml#L8
>>>
>>> TIA
>>>
>>> Jacques
>>>
>>> Le 23/03/2026 à 17:13, gaetan.chaboussie a écrit :
>>>> 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
Re: Move trunk to java 21
Posted by Jacopo Cappellato <ja...@gmail.com>.
The changes mentioned by Jacques are due to the rebase, they were not
introduced by Gaetan, and they are not relevant for this thread in which we
are discussing how to handle the Java upgrade.
Jacopo
On Tue, Mar 24, 2026 at 8:49 AM gaetan.chaboussie <
gaetan.chaboussie@nereide.fr> wrote:
> Hi @jacques,
>
> I don't remember editing any file other than java, xml and gradle.
>
> I'm not familiar enough with github and dependabot, and it seems the
> commit you mention (dee6a10) comes from trunk that was merged in the
> OFBIZ-13306 branch.
>
> If any action on my part affected it, i'm not sure wich one it was
> Gaetan
>
> On 3/24/26 06:39, Jacques Le Roux via dev wrote:
> > Hi,
> >
> > While working on the "password issue", I found an interesting warning at
> > https://github.com/apache/ofbiz-framework/actions/runs/23431619247
> >
> >
> > *build*
> > <
> https://github.com/apache/ofbiz-framework/actions/runs/23431619247/job/68159137855#step:13:3
> >
> > Node.js 20 actions are deprecated. The following actions are running
> > on Node.js 20 and may not work as expected:
> > actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11,
> > actions/setup-java@387ac29b308b003ca37ba93a6cab5eb57c8f5f93. Actions
> > will be forced to run with Node.js 24 by default starting June 2nd,
> > 2026. Please check if updated versions of these actions are available
> > that support Node.js 24. To opt into Node.js 24 now, set the
> > FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true environment variable on the
> > runner or in your workflow file. Once Node.js 24 becomes the default,
> > you can temporarily opt out by setting
> > ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true. For more information
> > see:
> >
> https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
> > <
> https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/>
>
> >
> > Show less
> >
> >
> > Do we have issues with Node 24 ?
> >
> > Also while at it, @Gaetan: is there a reason why npm is removed from
> > .github/dependabot.yml
> > in
> >
> https://github.com/gtchaboussie/ofbiz-framework/commit/dee6a10839b0f93534c85eccdbde1c6bb5461d0f
> > ?
> > I mean it's still in trunk
> >
> https://github.com/apache/ofbiz-framework/blob/a2a75e348d8472719b26642e2837b7dab2f20eaf/.github/dependabot.yml#L8
> >
> >
> > TIA
> >
> > Jacques
> >
> > Le 23/03/2026 à 17:13, gaetan.chaboussie a écrit :
> >> 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
> >>
Re: Move trunk to java 21
Posted by "gaetan.chaboussie" <ga...@nereide.fr>.
Hi @jacques,
I don't remember editing any file other than java, xml and gradle.
I'm not familiar enough with github and dependabot, and it seems the
commit you mention (dee6a10) comes from trunk that was merged in the
OFBIZ-13306 branch.
If any action on my part affected it, i'm not sure wich one it was
Gaetan
On 3/24/26 06:39, Jacques Le Roux via dev wrote:
> Hi,
>
> While working on the "password issue", I found an interesting warning at
> https://github.com/apache/ofbiz-framework/actions/runs/23431619247
>
>
> *build*
> <https://github.com/apache/ofbiz-framework/actions/runs/23431619247/job/68159137855#step:13:3>
> Node.js 20 actions are deprecated. The following actions are running
> on Node.js 20 and may not work as expected:
> actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11,
> actions/setup-java@387ac29b308b003ca37ba93a6cab5eb57c8f5f93. Actions
> will be forced to run with Node.js 24 by default starting June 2nd,
> 2026. Please check if updated versions of these actions are available
> that support Node.js 24. To opt into Node.js 24 now, set the
> FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true environment variable on the
> runner or in your workflow file. Once Node.js 24 becomes the default,
> you can temporarily opt out by setting
> ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true. For more information
> see:
> https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
> <https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/>
>
> Show less
>
>
> Do we have issues with Node 24 ?
>
> Also while at it, @Gaetan: is there a reason why npm is removed from
> .github/dependabot.yml
> in
> https://github.com/gtchaboussie/ofbiz-framework/commit/dee6a10839b0f93534c85eccdbde1c6bb5461d0f
> ?
> I mean it's still in trunk
> https://github.com/apache/ofbiz-framework/blob/a2a75e348d8472719b26642e2837b7dab2f20eaf/.github/dependabot.yml#L8
>
>
> TIA
>
> Jacques
>
> Le 23/03/2026 à 17:13, gaetan.chaboussie a écrit :
>> 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
>>
Re: Move trunk to java 21
Posted by Jacques Le Roux via dev <de...@ofbiz.apache.org>.
Hi,
While working on the "password issue", I found an interesting warning at
https://github.com/apache/ofbiz-framework/actions/runs/23431619247
*build* <https://github.com/apache/ofbiz-framework/actions/runs/23431619247/job/68159137855#step:13:3>
Node.js 20 actions are deprecated. The following actions are running on Node.js 20 and may not work as expected:
actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11, actions/setup-java@387ac29b308b003ca37ba93a6cab5eb57c8f5f93. Actions will be forced to run
with Node.js 24 by default starting June 2nd, 2026. Please check if updated versions of these actions are available that support Node.js 24. To opt
into Node.js 24 now, set the FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true environment variable on the runner or in your workflow file. Once Node.js 24
becomes the default, you can temporarily opt out by setting ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true. For more information see:
https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
<https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/>
Show less
Do we have issues with Node 24 ?
Also while at it, @Gaetan: is there a reason why npm is removed from .github/dependabot.yml
in https://github.com/gtchaboussie/ofbiz-framework/commit/dee6a10839b0f93534c85eccdbde1c6bb5461d0f ?
I mean it's still in trunk
https://github.com/apache/ofbiz-framework/blob/a2a75e348d8472719b26642e2837b7dab2f20eaf/.github/dependabot.yml#L8
TIA
Jacques
Le 23/03/2026 à 17:13, gaetan.chaboussie a écrit :
> 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
>
Re: Move trunk to java 21
Posted by "gaetan.chaboussie" <ga...@nereide.fr>.
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
Re: Move trunk to java 21
Posted by "gaetan.chaboussie" <ga...@nereide.fr>.
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
Re: Move trunk to java 21
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Re: Move trunk to java 21
Posted by Michael Brohl <mi...@ecomify.de>.
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
Re: Move trunk to java 21
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Re: Move trunk to java 21
Posted by Nicolas Malin <ni...@nereide.fr>.
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
Re: Move trunk to java 21
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Re: Move trunk to java 21
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Re: Move trunk to java 21
Posted by "gaetan.chaboussie" <ga...@nereide.fr>.
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
Re: Move trunk to java 21
Posted by "gaetan.chaboussie" <ga...@nereide.fr>.
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
Re: Move trunk to java 21
Posted by Jacques Le Roux <ja...@les7arts.com>.
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