Any reason to not use /usr/bin/java as the path for GHIDRA_JAVA_HOME instead of full path to jdk/jre?

[UsuallyReadsTheManual]

My apologies if this is more of a 'well duh' question, but I've generally supported Ghidra server installs minimally, but as of late am trying to find easier ways to manage them as systems are patched and so forth.

Whenever I patch a system running Ghida server, and Java updates, I usually have to update the service config to point to the full path for the java install (e.g. openjdk-jre-1.x.x.x may become openjdk-jre-2.x.x.x). However, a quick 'which java' usually points me to /usr/bin/java for instance.

Is there any particular reason why I couldn't simply use the existing pointer from /usr/bin/java (which may point to say /etc/alternatives/ on a ubuntu system, or to the actual path on a RHEL system) in the server config file, thereby eliminating the need to update the server conf?

I understand various distributions may have slightly differing methods for pointing to the java path (including the fact you could specify JAVA_HOME and equivalents for the system itself as well), but I sort of scratch my head on why one wouldn't rely on a otherwise steady pathway to where java is installed by default in the server conf vs defaulting to the full path being manually provided (aside from cases with multiple java installs I suppose?).

Thoughts?

[ryanmkurtz]

You should be fine never specifying a java if the one on your PATH is always a supported version:

ghidra/Ghidra/RuntimeScripts/Linux/server/ghidraSvr

Lines 8 to 13 in 39e5485

	# The Java 21 (or later) runtime installation must either be on the system path, specified by the
	# JAVA_HOME environment variable or preferably set explicitly with the GHIDRA_JAVA_HOME variable
	# below. Since this script may be used during service initialization, reliance on environmental
	# settings such as JAVA_HOME may be problematic. It is also important to note that once installed
	# as a service, changes to this file or environmental settings may not have an affect on any service
	# scripts that was generated at the time of service installation.

[UsuallyReadsTheManual]

Makes sense, and I fully admit I completely missed that blurb when running through the conf last.
Thank you!