When managing multiple Java versions on Debian-based systems, update-alternatives handles version switching but doesn't automatically set JAVA_HOME. This creates complications for:

• Build tools like Maven/Gradle
• Java applications requiring JDK paths
• Containerized environments
• CI/CD pipelines

Here are three robust approaches to derive JAVA_HOME from the current Java alternative:

# Method 1: Using readlink with alternatives
export JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:/bin/java::")

# Method 2: Using update-java-alternatives
export JAVA_HOME=$(update-java-alternatives -l | awk '{print $3}' | head -1)

# Method 3: For systems with java-config
export JAVA_HOME=$(java-config -J)

For deployment scripts, consider this comprehensive solution:

#!/bin/bash

set_java_home() {
    local java_cmd
    if type -p java >/dev/null; then
        java_cmd=java
    elif [[ -n "$JAVA_HOME" ]] && [[ -x "$JAVA_HOME/bin/java" ]]; then
        java_cmd="$JAVA_HOME/bin/java"
    else
        echo "Java not found" >&2
        return 1
    fi

    if [[ "$java_cmd" ]]; then
        local java_path=$(readlink -f $(which $java_cmd))
        if [[ "$java_path" ]]; then
            export JAVA_HOME=$(dirname $(dirname "$java_path"))
            echo "Detected JAVA_HOME: $JAVA_HOME"
            return 0
        fi
    fi
    return 1
}

# Usage in scripts:
if set_java_home; then
    # Proceed with application launch
    "$JAVA_HOME/bin/java" -jar app.jar
else
    exit 1
fi

Special considerations for:

# Docker containers with minimal installs:
if [[ -d "/usr/lib/jvm/default-java" ]]; then
    export JAVA_HOME="/usr/lib/jvm/default-java"
fi

# Amazon Corretto installations:
if [[ -d "/usr/lib/jvm/java-11-amazon-corretto" ]]; then
    export JAVA_HOME="/usr/lib/jvm/java-11-amazon-corretto"
fi

Always validate your JAVA_HOME detection:

validate_java_home() {
    if [[ ! -d "$JAVA_HOME" ]]; then
        echo "JAVA_HOME path does not exist: $JAVA_HOME" >&2
        return 1
    fi
    
    if [[ ! -x "$JAVA_HOME/bin/java" ]]; then
        echo "Java binary not found in JAVA_HOME" >&2
        return 1
    fi
    
    echo "Java validation successful:"
    "$JAVA_HOME/bin/java" -version
    return 0
}

When writing deployment scripts or Java application launchers on Debian-based systems, you'll quickly encounter the gap between update-alternatives selection and actual JAVA_HOME detection. The default JVM switching mechanism doesn't automatically propagate to environment variables due to Debian policy decisions.

Here are three production-tested approaches to resolve this:

# Method 1: Using update-alternatives directly
JAVA_HOME=$(readlink -f /usr/bin/javac | sed 's:/bin/javac::')

# Method 2: Via java command inspection
JAVA_HOME=$(dirname $(dirname $(readlink -f $(which java))))

# Method 3: For OpenJDK installations specifically
JAVA_HOME=$(update-alternatives --list java | head -1 | sed 's:/jre/bin/java::;s:/bin/java::')

For enterprise environments, consider these enhancements:

#!/bin/bash

# Fallback chain for JAVA_HOME detection
detect_java_home() {
  local java_cmd=$(command -v java)
  [ -z "$java_cmd" ] && return 1
  
  local java_path=$(readlink -f "$java_cmd")
  
  # Handle JRE vs JDK paths
  if [[ $java_path == *"/jre/"* ]]; then
    echo "$java_path" | sed 's:/jre/bin/java::'
  else
    dirname "$(dirname "$java_path")"
  fi
}

JAVA_HOME=${JAVA_HOME:-$(detect_java_home)}
[ -z "$JAVA_HOME" ] && echo "Java not found" >&2 && exit 1

When creating systemd unit files, you can inject the detected path:

[Service]
Environment=JAVA_HOME=$(dirname $(dirname $(readlink -f /usr/bin/java)))
ExecStart=/opt/app/bin/start.sh

Many Java tools (Maven, Gradle, Tomcat) require proper JAVA_HOME configuration. The solutions above ensure:

• Consistent behavior across all Java processes
• Proper toolchain detection
• Correct library paths for JNI applications