Gradle projects dictate NetBeans' JDK runtime

[errael]

Apache NetBeans version

Apache NetBeans 16 release candidate

What happened

This is a well known issue. Some recent discussion has shed some light, and mentioned some possibilities. In particular, @sdedic mentions a possible way forward with #4923 (comment) and at the end of #4923 (comment).

@neilcsmith-net says "I also wonder how Gradle 8 will play into all this." in #4923 (comment)

The problem as I'm running into it now, for example, there are two projects I work with that pose a versioning problem, one is stuck on Gradle 6.8.3, the other Gradle 5.3.1. That 2nd pins NetBeans to JDK-11. So it's impossible to run NetBeans and take advantage of JDK features/enhancements (like for high DPI displays). On the next NetBeans LTS bump...

How to reproduce

No response

Did this work correctly in an earlier version?

No / Don't know

Operating System

Linux harmony 6.0.2-76060002-generic #202210150739166628906722.04~fe0ce53 SMP PREEMPT_DYNAMIC Thu O x86_64 x86_64 x86_64 GNU/Linux

JDK

openjdk 11.0.2 2019-01-15 OpenJDK Runtime Environment 18.9 (build 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

Apache NetBeans packaging

Own source build

Anything else

No response

Are you willing to submit a pull request?

No

Code of Conduct

Yes

[lkishalmi]

Well, this is not a bug, but a limitation of the Gradle Tooling API provided by Gradle.

I think the point of view really is why are you stuck with those old Gradle versions, what prevents you to upgrade your build system? That should be a regular task every now and then.

[errael]

I think the point of view really is why are you stuck with those old Gradle versions, what prevents you to upgrade your build system? That should be a regular task every now and then.

I don't disagree. I took the "upgrade your build system" to extremes moving from ant to gradle 7.5.x earlier this year for my main project; then had to back up to 6.8.x. I personally would rather be at the bleeding edge. Sadly, it's not always that simple.

I do not own the Gradle 5.3.1 project; I work with it, occasionally make PR's. It's a quiet project and the owners don't like change. The Gradle 6.8.x requirement is due to gradle/gradle#15942; Gradle 7 removed some JavaToolChainInternal API (Gradle changing internal API stuff causing problems, sound familiar?) so I'm stuck until Gradle cleans up their compiler/toolchain API.

[errael]

Well, this is not a bug

I disagree, Gradle can't be blamed for design decisions made by the NetBeans team. It was probably the right thing to do at the time (NetBeans does tend to do a right thing).

I'm speaking without a good understanding of all the underlying issues, what's possible and with how much effort. It may be that this bug is too much work to fix, and so it won't be fixed; but that doesn't mean it's not a bug.

[lkishalmi]

Thanks Ernie, for being contempt, bugging this much!

It seems I've lived with the misconception, that JavaHome can't be set on build action to retireve the project info for years. I just got angry enough to link that proof here, so it is a limitation in Gradle, when it popped into my eye, that indeed the Java home can be set on BuildActionExecuter. That would resolve this issue.

I have that tested with a raw patch and seems to be working. It wouldn't be a hard change, however a fully working patch is beyond the NB16, but can be expected for early NB17 releases.

[sdedic]

yes, see note #4923 (comment) (at the end).

BTW the same problem probably applies to Maven (it's run using project's target JDK now). I am sure there are scenarios (e.g. plugin compatibility) when the user needs to run it on a specific Java != NetBeans != target. I don't know whether this is worth a shared / common setting in generic project (java) infra.

[errael]

I have that tested with a raw patch and seems to be working. It wouldn't be a hard change, however a fully working patch is beyond the NB16, but can be expected for early NB17 releases.

That's great news. I never expected NB16; when asked for NetBeans version, NB16-RC was the closest

for being contempt, bugging this much!

(I'm glad I toned it down)
I admit that when @sdedic said

volunteers to approach Gradle people with a kindly formulated sugggestion?

My first thought was that I probably wasn't the best choice.

[neilcsmith-net]

BTW the same problem probably applies to Maven (it's run using project's target JDK now). I am sure there are scenarios (e.g. plugin compatibility) when the user needs to run it on a specific Java != NetBeans != target. I don't know whether this is worth a shared / common setting in generic project (java) infra.

I'm sceptical of how this might be done. Can be achieved in build scripts already? Would need to be done in such a way that running the build on CLI behaves the same. Maybe being able to pass registered platforms as paths in environment variables and/or system properties? Maybe also (in Maven) disabling compile-on-save by default?

EDIT: of course, NetBeans needs to know the build target for editing, and the Java home to pass to the build tool, which could be different.

[mbien]

is the error message sufficient to inform the user what the problem is? Or is it some ASM or linkage error?

[lkishalmi]

We can run the Gradle Wrapper with whatever JDK we wish (AFAIK: Java 8-17 at the moment, with Gradle 7.4). Just need to pass an appropriate jvm to the following java task:

netbeans/extide/gradle/build.xml

Line 61 in c69515d

<java fork="true" dir="${tooling}" classpath="${tooling}/gradle/wrapper/gradle-wrapper.jar" classname="org.gradle.wrapper.GradleWrapperMain" failonerror="true">

[lkishalmi]

Will be fixed as of #4985

[errael]

Will be fixed as of #4985

Cool. (I guess the "needs:triage" label can be removed from this issue)