macOS - Software Lifecycle - Uninstall Java

What the Oracle Java uninstaller does

This Automox Worklet™ removes Oracle Java JRE and JDK installations from macOS endpoints by deleting the canonical Java directories that the Oracle installer creates. The Worklet covers system-level paths under /Library, plus per-user copies of the same directories that appear when a Mac user installs Java under their own home folder.

The evaluation script enumerates local accounts with dscl . list /Users and builds two path arrays. The JRE array includes /Library/Internet Plug-Ins/JavaAppletPlugin.plugin, /Library/PreferencePanes/JavaControlPanel.prefPane, /Library/Application Support/Oracle/Java, and each user's mirrored Oracle Java support folder. The JDK array includes /Library/Java/JavaVirtualMachines and the same path under each user. The remediation script walks both arrays and removes every match with rm -rf.

For JDK paths, the Worklet inspects the contents of JavaVirtualMachines and only triggers removal when a child directory name contains the string jdk, so the policy will not blindly wipe a directory that an admin has repurposed. The behavior is the same for the Oracle plug-in, the Java Control Panel prefpane, and the Oracle Java application support folders, which are removed whenever they exist.

Why remove Oracle Java from macOS endpoints

Oracle Java on a Mac is one of the most reliable attack-surface findings in a modern endpoint inventory. Oracle ended public updates for Java 8 in early 2019, and Java 11 LTS exited Oracle premier support in 2023. A long tail of older JRE installs continues to live in /Library/Internet Plug-Ins/JavaAppletPlugin.plugin and /Library/Application Support/Oracle/Java because the original installer never removed them. Each of those EOL runtimes is a published CVE target that no longer receives security patches from Oracle, and the JavaAppletPlugin in particular re-enables an applet runtime that browsers have long since blocked. Compliance frameworks treat unsupported runtimes as a finding: CIS macOS benchmarks call for removing unsupported software, PCI-DSS Requirement 6.3 prohibits unpatched components, and HIPAA Security Rule 164.308(a)(5)(ii)(B) expects malicious-code protection on every endpoint.

Stale Oracle JREs concentrate on the Macs that nobody routinely audits: developer laptops carrying a JDK from a 2018 internal app, contractor returns where Java was installed for one vendor portal, marketing iMacs running an Adobe build that bundled the JRE. Scheduling this Worklet against the Mac group removes the JavaAppletPlugin.plugin and JDK directories from each endpoint at evaluation time, then reports per-host exit codes so a SOC 2 reviewer can see which Macs were carrying an unsupported runtime at audit close.

How Oracle Java removal works

1. Evaluation phase: The Worklet collects every local user with dscl . list /Users (filtering out underscore-prefixed system accounts), then builds the JRE path array (/Library/Internet Plug-Ins/JavaAppletPlugin.plugin, /Library/PreferencePanes/JavaControlPanel.prefPane, /Library/Application Support/Oracle/Java, plus the same /Users/<user>/Library/Application Support/Oracle/Java path for each account) and the JDK path array (/Library/Java/JavaVirtualMachines plus the same path under each user home). It exits 1 if any JRE path exists or if any child of a JDK path contains 'jdk' in its name, which marks the endpoint non-compliant in Automox and queues remediation.

2. Remediation phase: The Worklet re-walks the same JRE and JDK arrays and calls rm -rf on each detected path. JRE-class targets (Oracle browser plug-in, Java Control Panel prefpane, Oracle Java application support folders) are removed whenever they exist. JDK-class targets are scanned for child directories whose names contain 'jdk' (e.g., jdk-17.0.9.jdk, jdk1.8.0_341.jdk); when one is found, the JavaVirtualMachines parent is removed. The script prints each path it acts on, so the Automox activity log captures exactly what was deleted on each endpoint.

Oracle Java removal requirements

• macOS endpoint with the Automox agent installed; both Intel and Apple silicon Macs are supported because the Worklet operates on file paths rather than architecture-specific binaries

• Root execution context (the default Automox agent context), required to delete /Library/Internet Plug-Ins/JavaAppletPlugin.plugin, /Library/PreferencePanes/JavaControlPanel.prefPane, /Library/Application Support/Oracle/Java, and /Library/Java/JavaVirtualMachines

• No running Java applications or java processes on the endpoint at remediation time; quit any IDE, build tool, or vendor app that embeds a JRE before the policy runs to avoid orphaned file handles

• Confirm that no third-party application on the policy scope depends on Oracle Java; common holdouts include legacy ERP clients, niche scientific tooling, and a small number of enterprise VPN clients that bundle their own JRE

• If a supported Java is required after removal, plan a follow-up deployment of OpenJDK (Temurin, Zulu, or Amazon Corretto) so endpoints land on a patched, vendor-supported runtime rather than reverting to Oracle Java

Expected Mac state after Oracle Java removal

After remediation, the Oracle Java footprint on the Mac is gone. /Library/Java/JavaVirtualMachines no longer holds any *.jdk bundle, /Library/Internet Plug-Ins/JavaAppletPlugin.plugin is removed, /Library/PreferencePanes/JavaControlPanel.prefPane no longer appears in System Settings, and /Library/Application Support/Oracle/Java is deleted from both /Library and each user's home folder. The java -version command returns 'No Java runtime present, requesting install,' which is the expected macOS behavior when no JDK is installed and the Apple Java stub is the only thing on PATH.

Validate from Terminal with these checks: ls /Library/Java/JavaVirtualMachines should return 'No such file or directory'; ls '/Library/Internet Plug-Ins/JavaAppletPlugin.plugin' should also fail; /usr/libexec/java_home should exit non-zero with 'Unable to find any JVMs matching version'; and the Java Control Panel should be missing from System Settings (or System Preferences on older macOS). The next Automox evaluation run reports the endpoint compliant without applying remediation a second time, because the JRE and JDK path arrays no longer match. For audit evidence, capture the Worklet's stdout from the activity log; it lists every path the remediation removed on each endpoint, which is enough to attach to a CVE retirement ticket or a compliance attestation.