Honor the JAVA_HOME environment variable in nbexec script #8725

stoty · 2025-08-11T06:14:29Z

The current code ignores JAVA_HOME.

This patch honors the JAVA_HOME environment variable, then falls back the original java detection code.

The original code does not work jenv style shims.

matthiasblaesing

This breaks the NetBeans IDE launcher. When no JAVA_HOME is set the IDE does not start anymore. I'm on Ubuntu 25.04 and I build this branch. Running the build gives me:

matthias@enterprise:~/src/netbeans$ export LANG=C
matthias@enterprise:~/src/netbeans$ rm -rf x
matthias@enterprise:~/src/netbeans$ nbbuild/netbeans/bin/netbeans --userdir x --cachedir x
/home/matthias/src/netbeans/nbbuild/netbeans/platform/lib/nbexec: line 438: /home/matthias/src/netbeans/bin/java: No such file or directory
matthias@enterprise:~/src/netbeans$

stoty · 2025-08-18T05:02:20Z

What happens in that case without the patch @matthiasblaesing ?

If you check the patch, it falls back to the original code in the else branch when neither env var is specified.

I've just realized that the patch will also consider /bin/java if JAVA_HOME is not set, but your ouput shows a different directory.

neilcsmith-net

I'm in two minds whether this is a good move. NetBeans and the platform have not been JAVA_HOME aware by default in the past, which might make this an unexpected change. On the other hand, it brings it in line with recent changes in the Windows launcher. Of course, that was broken before so not quite the same thing!

We should probably ignore JDK_HOME to keep in line with the new Windows launcher behaviour?

The NBPackage script sets JAVA_HOME for the DEB and RPM packages, although there shouldn't be any effect here if this is ignored with jdkhome set. I think there's a reverse to consider here too - whether JAVA_HOME should then always be set to the jdkhome value for the execution of the IDE / platform application?

neilcsmith-net · 2025-08-18T16:23:52Z

platform/o.n.bootstrap/launcher/unix/nbexec

-                    jdkhome=`dirname $java`"/.."
-                fi
+            *)
+            if [ "x" != "x${JAVA_HOME}" -a -x "${JAVA_HOME}/bin/java" ]; then


Isn't -a effectively deprecated in favour of multiple tests with && ?

It might be enough to check for -n "${JAVA_HOME} ? There's a test with -x below.

-a is used in this same script elsewhere, but I'm not particular about the implementation details.
I'm not confident in shell programming, so I just copy what already see used.

I was wondering how to handle the empty JAVA_HOME.
I thought that "" is probably an error, if someone puts the JDK it in the root directory, they should use "/" instead.

But again, it's fine either way for me.

If you have a strong preference, LMK and I will change it.

Ah, OK, leave -a (if the and is required at all). I'd missed that it was used elsewhere - we should rethink them all at some point.

And empty JAVA_HOME should surely be treated the same as unset. In fact, not sure how easily we could check the difference in all cases. I still think a check for JAVA_HOME being non-zero length without the additional -x check would be enough here anyway. I'm not sure an invalid JAVA_HOME should just be ignored.

Will let others comment on that.

Ah, OK, leave -a (if the and is required at all). I'd missed that it was used elsewhere - we should rethink them all at some point.

And empty JAVA_HOME should surely be treated the same as unset. In fact, not sure how easily we could check the difference in all cases.

The "x" != "x${JAVA_HOME}" idiom is used quite frequently, it is only true if the variable is set and is not zero length.

I still think a check for JAVA_HOME being non-zero length without the additional -x check would be enough here anyway. I'm not sure an invalid JAVA_HOME should just be ignored.

The rest of the java detection code checks to see if a java executable is present, I copied that.

But I see your point, if JAVA_HOME is set incorrectly, it makes sense to just fail instead of ignoring it.
I'm fine with it either way.

Will let others comment on that.

The "x" != "x${JAVA_HOME}" idiom is used quite frequently, it is only true if the variable is set and is not zero length.

Sure, and as I understand it the historic form of -n. Mind you, again checking the rest of this file for consistency, we seem to use the pattern [ ! -z "${JAVA_HOME}" ] elsewhere in it.

The rest of the java detection code checks to see if a java executable is present, I copied that.

Yes, and if you let it fall through it should hit that check and exit.

replaced = with ! -z

Removed the extra executable check.

stoty · 2025-08-18T17:28:22Z

I'm in two minds whether this is a good move. NetBeans and the platform have not been JAVA_HOME aware by default in the past, which might make this an unexpected change. On the other hand, it brings it in line with recent changes in the Windows launcher. Of course, that was broken before so not quite the same thing!

I saw JDK_HOME being used, that was probably the VisualVM Windows launcher code, not the NetBeans one.

We should probably ignore JDK_HOME to keep in line with the new Windows launcher behaviour?

Sure, will remove.

The NBPackage script sets JAVA_HOME for the DEB and RPM packages, although there shouldn't be any effect here if this is ignored with jdkhome set. I think there's a reverse to consider here too - whether JAVA_HOME should then always be set to the jdkhome value for the execution of the IDE / platform application?

I don't think that's really necessary.

The only time JAVA_HOME would come up is when NetBeans is starting a new JDK,

If it is started directly case NB would use one of the configured JDK instances.
In the indirect case (i.e. NB starts a shell script or C code which starts a JDK) it may be sometimes useful, but IMO it's better to be transparent and not try to second guess the user's evironment setup.

neilcsmith-net · 2025-08-19T10:22:58Z

I saw JDK_HOME being used, that was probably the VisualVM Windows launcher code, not the NetBeans one.

Maybe. I don't know why they use a fork of that but not this.

I think there's a reverse to consider here too - whether JAVA_HOME should then always be set to the jdkhome value for the execution of the IDE / platform application?

I don't think that's really necessary.

The only time JAVA_HOME would come up is when NetBeans is starting a new JDK,

Just a related thought to this. It's set conservatively when unset by the user in the DEB and RPM. I find it very useful to ensure that the terminal, etc. in the IDE has JAVA_HOME set to the JDK the IDE is running on.

Thanks for the changes. Let's see if anyone else has any comments, and that @matthiasblaesing issue is resolved.

matthiasblaesing · 2025-08-21T18:55:53Z

platform/o.n.bootstrap/launcher/unix/nbexec

-                    jdkhome=`dirname $java`"/.."
-                fi
+            *)
+            if [ ! -z "x${JAVA_HOME}" ]; then


What is the idea here? This can't work and in fact does not. If JAVA_HOME is not set, this evaluates:

! -z "x${JAVA_HOME}"

! -z "x"

! false

true

And with any other value this is the same as the zero length check will only ever check a longer path.

Let me repeat the test setup:

no JAVA_HOME set

java and javac on the PATH

build from PR and run in base directory: nbbuild/netbeans/bin/netbeans --userdir x --cachedir x (ensure, that directory x does not exist prior)

Sorry, forgot to remove the x

matthiasblaesing

Works for me and looks sane. Thank you.

Please squash the changes into a single commit to prepare for merge.

jtulach · 2025-08-23T12:36:46Z

platform/o.n.bootstrap/launcher/unix/nbexec

-                    jdkhome=`dirname $java`"/.."
-                fi
+            *)
+            if [ ! -z "${JAVA_HOME}" ]; then


this code reads the JAVA_HOME environment variable

the Open file from embedded terminal, easily! #8756 PR does something similar for --userdir, but it also

sets the environment variable

so child processes find the same value even if it was only specified by CLI argument

I don't know enough about how NetBeans handles multiple Java enviroments to comment on whether that's a good idea.

In some IDEs the Java that runs the IDE is independent from the Java(s) used for the projects.

IMO such a change would better be done from the Java side, as this patch only touches the non-Apple Unix path, and the java code would be a common path instead of threeseparate ones (MacOS, generic unix, Windows)

stoty · 2025-08-25T03:59:30Z

Works for me and looks sane. Thank you.

Please squash the changes into a single commit to prepare for merge.

Thank you, done.

matthiasblaesing · 2025-08-25T19:35:33Z

@stoty thank you. I adjusted the head message and title of this PR to reflect the final state and merged.

stoty · 2025-08-26T05:31:37Z

Thank you @matthiasblaesing .

stoty mentioned this pull request Aug 11, 2025

Honor the JAVA_HOME environment variable oracle/visualvm#623

Open

mbien added Platform [ci] enable platform tests (platform/*) os:linux labels Aug 11, 2025

mbien linked an issue Aug 11, 2025 that may be closed by this pull request

Honor the JAVA_HOME and JDK_HOME environment variables in nbexec script #8724

Closed

matthiasblaesing requested changes Aug 16, 2025

View reviewed changes

neilcsmith-net reviewed Aug 18, 2025

View reviewed changes

matthiasblaesing reviewed Aug 21, 2025

View reviewed changes

matthiasblaesing approved these changes Aug 22, 2025

View reviewed changes

neilcsmith-net mentioned this pull request Aug 23, 2025

Open file from embedded terminal, easily! #8756

Open

jtulach reviewed Aug 23, 2025

View reviewed changes

Honor the JAVA_HOME and JDK_HOME environment variables in nbexec script

a3253e1

stoty force-pushed the issue8724 branch from ea5b10f to a3253e1 Compare August 25, 2025 03:58

matthiasblaesing changed the title ~~Honor the JAVA_HOME and JDK_HOME environment variables in nbexec script~~ Honor the JAVA_HOME environment variable in nbexec script Aug 25, 2025

matthiasblaesing added this to the NB28 milestone Aug 25, 2025

matthiasblaesing merged commit 5abc89b into apache:master Aug 25, 2025
32 checks passed

Honor the JAVA_HOME environment variable in nbexec script #8725

Honor the JAVA_HOME environment variable in nbexec script #8725

Uh oh!

Conversation

stoty commented Aug 11, 2025 • edited by matthiasblaesing Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

matthiasblaesing left a comment

Choose a reason for hiding this comment

Uh oh!

stoty commented Aug 18, 2025

Uh oh!

neilcsmith-net left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

neilcsmith-net Aug 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stoty commented Aug 18, 2025

Uh oh!

neilcsmith-net commented Aug 19, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matthiasblaesing left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stoty commented Aug 25, 2025

Uh oh!

Uh oh!

matthiasblaesing commented Aug 25, 2025

Uh oh!

stoty commented Aug 26, 2025

Uh oh!

Uh oh!

stoty commented Aug 11, 2025 •

edited by matthiasblaesing

Loading

neilcsmith-net Aug 19, 2025 •

edited

Loading