Java Runtime Checklist

JDK, JAVA_HOME, Maven, Gradle and service runtime checks. Last updated August 28, 2026.

Java production problems often start outside the code: the wrong JDK is active, JAVA_HOME points to an old path, the service uses different memory flags, or Maven and Gradle build with a different runtime than the one used in production. OpenJDK publishes general install guidance at openjdk.org/install, while Oracle provides platform-specific JDK installation documentation. This page focuses on operational verification.

Identify Java and the JDK

java -version
javac -version
which java
echo $JAVA_HOME
readlink -f $(which java) 2>/dev/null

# Windows PowerShell
java -version
javac -version
Get-Command java
echo $env:JAVA_HOME
[Environment]::GetEnvironmentVariable("JAVA_HOME", "Machine")

Build tools

mvn -version
gradle -version
./mvnw -version
./gradlew -version

Service checks on Linux

For systemd services, inspect the real command line and environment before editing application properties.

systemctl status my-java-service --no-pager
systemctl cat my-java-service
journalctl -u my-java-service -n 120 --no-pager
ps aux | grep '[j]ava'
jcmd 2>/dev/null

Memory and JVM flags

Signal	Check	Meaning
OutOfMemoryError	Heap flags, container memory, GC logs	The process may be limited below the host's apparent memory.
Slow startup	JDK version, classpath, DNS, database reachability	Runtime and dependency initialization can hide as app delay.
Works locally only	`JAVA_HOME`, profiles, environment variables	Service environment differs from the terminal.
TLS failure	Truststore, JDK version, certificate chain	The runtime may not trust the target certificate.

Minimal runtime evidence

java -version
echo $JAVA_HOME
date -Is
hostname
ps aux | grep '[j]ava'
ss -tulpn | grep java 2>/dev/null
journalctl -u my-java-service -n 80 --no-pager

Java debugging gets faster when the team separates build-time Java, shell Java and service Java. They can be three different runtimes on the same host.