svrAdmin looks for `javac` unecessarily, breaking on RHEL with -headless JRE

Describe the bug When running ghidra as a server on RHEL 8 or 9 (and presumably others) the -headless JRE (for example, java-11-openjdk-headless is sufficient. However, the svrAdmin tool looks for the javac binary within $JAVA_HOME/bin/ and this package does not include this, as it is only the runtime environment. The binary is included in the -devel package (for example java-11-openjdk-devel which pulls in a bunch of unnecessary (for a server) GUI libraries and related junk. This bloats the environment.

To Reproduce Steps to reproduce the behavior:

1. Set up a RHEL8 or RHEL9 host (an unsubscribed UBI container is sufficient)
2. Install the java-11-openjdk-headless package
3. Unpack the ghidra release artifact & configure server.conf
4. Attempt to use svrAdmin

Expected behavior svrAdmin should operate as-is with just the JRE, without JDK components.

Screenshots

# note: server is up and operational in this example
[root@REDACTED scratch]# docker container exec -i -t ghidra svrAdmin -list
******************************************************************
JDK 11+ (64-bit) could not be found and must be manually chosen!
******************************************************************
Enter path to JDK home directory: /usr/lib/jvm/jre-11-openjdk
Not a valid JDK home directory. JDK is missing javac executable!

Attachments N/A

Environment (please complete the following information):

• OS: RHEL 8.6, RHEL 9.0, likely others
• Java Version: 11.0 (java-11-openjdk-11.0.15.0.10-2.el8_6.src.rpm)
• Ghidra Version: 10.1.4
• Ghidra Origin: official GitHub distro

Additional context

• Workaround available: AWS Corretto 11 RPM distribution as this includes the JDK elements without requiring all the GUI gunk.
• My containerized server repo can be used to test this behavior, see ghidraSvr-in-a-box commit cc3ddb1 if required. Note that subsequent commits replace the RHEL -headless JRE with Corretto.

[draeath]

Gotcha, I misunderstood.

I can confirm your workaround, looks good. (I did the replacement on line 125 only)

[ryanmkurtz]

It’s going through launch.sh, which requires a JDK:

https://github.com/NationalSecurityAgency/ghidra/blob/a641dd9d25cdd3630a9f1107b8ff5cca7c8dd135/Ghidra/RuntimeScripts/Linux/support/launch.sh#L125

It’s a trivial fix in theory…just pass -java_home instead of jdk_home. But, splitting things apart enough to do this is a bit more work.