Describe the bug

On non-Windows systems, if JAVA_HOME is not set, the server script attempts to set JAVA_HOME based on the location of the java executable found in the system PATH. However, there are scenarios where this approach fails:

1. Non-Symbolic Links in PATH

   On macOS, for instance, /usr/bin/java is commonly a direct executable and not a symbolic link, meaning it is not located under a valid JAVA_HOME directory. In such cases, the server script incorrectly sets JAVA_HOME.

2. Symbolic Links in PATH

   Conversely, when the java executable is a symbolic link (e.g., /usr/local/bin/java on macOS), the script correctly resolves the link and sets JAVA_HOME to the appropriate directory. However, the validity of the discovered JAVA_HOME should still be validated, possibly by checking for "include" and "lib" directories.

3. Custom Scripts in PATH

   There are also cases where the java in the PATH is a custom script rather than the actual Java executable. For example, in this stackoverflow question, a user created a script named java to dynamically select the Java version for their application. Here, the server script again sets JAVA_HOME incorrectly.

Impact
When JAVA_HOME is set incorrectly, it can lead to issues that are difficult to debug, as the resulting errors may not clearly indicate that JAVA_HOME is the root cause.

Note that the Windows implementation, server.bat, does not attempt to set JAVA_HOME if it is not already set. Maybe it should behave the same way.

Steps to Reproduce
Set PATH such that the first 'java' executable found is not under a valid JAVA_HOME location.

Expected behavior
This will cause a failure for any application depending on java9.options being merged into the java command line options.

Diagnostic information:

Additional context