SOLR-16721 Java version detection fails when _JAVA_OPTIONS is set

[janhoy]

https://issues.apache.org/jira/browse/SOLR-16721

[ZhongRuoyu]

Thanks @janhoy! I can confirm that this patch works in Homebrew/homebrew-core#126571.

[andywebb1975]

This made me wonder if there's a way to get just the version number from java more cleanly, but I don't see anything in the man page :-(

[janhoy]

There's also JAVA_TOOL_OPTIONS which is treated the same way, so there may be one extra line above the version line. See https://stackoverflow.com/questions/28327620/difference-between-java-options-java-tool-options-and-java-opts

[janhoy]

This made me wonder if there's a way to get just the version number from java more cleanly, but I don't see anything in the man page :-(

Yea, that's crazy - imagine all the parsing of versions in all kind of scripts that could be avoided. But I think there's no such option.

[janhoy]

There's also JAVA_TOOL_OPTIONS which is treated the same way, so there may be one extra line above the version line. See https://stackoverflow.com/questions/28327620/difference-between-java-options-java-tool-options-and-java-opts

Changed the grep to grep -v '_OPTIONS' to handle this case too

[andywebb1975]

Removing the head -1 means multiple lines will pass through - so if java -version changed to something along these lines we'd get a multi-line value back:

openjdk version "1.8.0_362"
OpenJDK Runtime Environment (build 1.8.0_362-b09)
OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)
SomeOS version "1.42.5"

Keeping the head -1 (after the grep) would protect against this - so I think that's worth putting back in.

(See comment above)

[janhoy]

Yep, with your example you'd get this output:

8
42

Agree it won't hurt adding back the head