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 theand is required at all). I'd missed that it was used elsewhere - we should rethink them all at some point.

And emptyJAVA_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 forJAVA_HOME being non-zero length without the additional-x check would be enough here anyway. I'm not sure an invalidJAVA_HOME should just be ignored.

Will let others comment on that.

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

And emptyJAVA_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 forJAVA_HOME being non-zero length without the additional-x check would be enough here anyway. I'm not sure an invalidJAVA_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.

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:

• noJAVA_HOME set
• java and javac on thePATH
• 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

• this code reads theJAVA_HOME environment variable
• theMake sure netbeans in embedded terminal means itself #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)