Uninstall Java and old JDKs on a Mac

To uninstall Java on a Mac, start with the folder /Library/Java/JavaVirtualMachines. Every JDK installed from a vendor's package, whether Oracle, Temurin, Zulu, Corretto or Microsoft, sits there as one folder per version. Moving a folder to the Trash in Finder, with an administrator's password, removes that JDK. Oracle's own uninstall instructions come down to the same step.

If you installed Oracle's Java 8 to run desktop apps or applets, there are three more items: a browser plug-in, the Java Control Panel and a folder in your Library. Oracle's help page lists them, and each one comes off in Finder too.

JDKs from Homebrew, SDKMAN and Coursier come off with those tools, which are command-line only, so this post describes what their commands do without spelling them out. JDKs inside apps, such as the one in Android Studio, belong to the app and stay until you uninstall it.

Leave /usr/bin/java alone. Oracle's documentation says the Java tools in /usr/bin are part of macOS, and removing the JDKs is what actually uninstalls Java.

Which Javas can a Mac have?

macOS hasn't included Java for years. Every Java on a current Mac was installed by you, by a tool you use, or by an app that brought its own. They sit side by side, and none of them replaces another.

Where it came from	Where it lives	How it comes off
A vendor's installer: Oracle, Temurin, Zulu, Corretto, Microsoft	/Library/Java/JavaVirtualMachines, one folder per JDK	Finder, with an administrator's password
Oracle's Java 8 for running apps	A plug-in, a settings pane and a Library folder	Finder, three items
Homebrew's OpenJDK formula	/opt/homebrew/Cellar on Apple silicon, /usr/local/Cellar on Intel	Homebrew's uninstall
SDKMAN	~/.sdkman/candidates/java	SDKMAN's own uninstall
Coursier	~/Library/Caches/Coursier/arc or jvm	Coursier's own commands
Gradle's toolchains	~/.gradle/jdks	Finder, as Gradle's documentation describes
Inside an app	The app's own bundle	Only by uninstalling the app

What's the difference between Java and a JDK?

A JDK, the Java Development Kit, is what developers install: the compiler, the tools and a runtime to run programs. JetBrains' documentation puts it simply: a runtime alone is fine for running Java applications but not for developing them.

"Java" on java.com usually means Oracle's Java 8 for desktops, which ran Java apps and, years ago, applets in web browsers. That's the one with the Java Control Panel. Most people who install Java today install a JDK, even just to run one program.

What does /usr/bin/java do?

It's a small program that's part of macOS, and so are javac and the other Java names in /usr/bin. They're wrappers: they find a JDK in /Library/Java/JavaVirtualMachines and run the real tool from it. Homebrew's own note on its OpenJDK says the system's Java wrappers find a JDK only once it's linked into that folder.

Oracle's documentation warns not to uninstall Java by removing the tools in /usr/bin, because the folder is part of the system software and the next macOS update resets it. On a current Mac it's on the protected system volume, so you can't change it anyway.

Which Java versions are current?

Oracle's support roadmap lists Java 8, 11, 17, 21 and 25 as long-term support releases, and Java 27 as the newest release, from September 2026. The next long-term release, Java 29, is planned for September 2027.

That's why a developer's Mac often has three or four JDKs: one long-term release for older projects, one for newer ones, and whichever version a tool asked for along the way. Old non-LTS releases, such as 22 or 26, are usually the easiest to remove.

How to find every JDK on your Mac

You can find them all in Finder. Choose Go › Go to Folder, type a path, and press Return. Apple's guide notes that a tilde stands for your home folder, so hidden folders such as ~/.sdkman open the same way. If a path doesn't exist, Finder says so and you can move on.

What's in /Library/Java/JavaVirtualMachines?

One folder per JDK, named by its vendor and version. Oracle's installation guide says each Oracle JDK goes in a folder named after its feature release, so JDK 25.0.1 lives in jdk-25.jdk. Other vendors use their own names:

Vendor	Folder in /Library/Java/JavaVirtualMachines	Where the name comes from
Oracle	jdk-25.jdk	Oracle's installation guide
Eclipse Temurin	temurin-25.jdk	Adoptium's installer page
Azul Zulu	zulu-25.jdk	Azul's installation guide
Amazon Corretto	amazon-corretto-21.jdk	Amazon's Corretto guide
Microsoft Build of OpenJDK	microsoft-25.jdk	Microsoft's installation guide
Homebrew's OpenJDK, if you linked it	openjdk.jdk or openjdk-17.jdk, a link	Homebrew's note on the formula

The folder can be empty. On the Mac measured for this post, running macOS 27, it existed with nothing inside, because every Java there came from Homebrew or lived inside an app.

Where else do JDKs hide?

• ~/.sdkman/candidates/java: one folder per Java version SDKMAN installed, such as 21.0.4-tem.
• ~/Library/Caches/Coursier/arc, or jvm in older Coursier versions: Java versions Coursier installed.
• ~/.gradle/jdks: JDKs Gradle downloaded for builds that asked for a particular version.
• /opt/homebrew/Cellar: folders named openjdk, or openjdk@ and a version, are Homebrew's.
• Wherever your IDE put a JDK it downloaded. IntelliJ IDEA's Download JDK dialog shows the installation path, and lets you change it.

How do you see the Java inside an app?

Control-click the app in Applications, choose Show Package Contents, and open Contents. A folder named jbr, jre or java with a Home folder inside is a bundled Java runtime.

On the Mac measured for this post, two apps carried one. Android Studio's jbr folder held Java 21 from JetBrains, at 96 MB. Apple's Transporter app, used to upload apps to the App Store, carried its own Java 21 runtime of 50 MB. Neither uses the JDKs you install, and neither is affected when you remove them.

How big is each JDK?

A full JDK is a few hundred megabytes. On that Mac, Homebrew's OpenJDK 17 took 305 MB. Runtimes bundled inside apps are often smaller, because apps can leave out the parts they don't use.

• Homebrew's OpenJDK 17, a full JDK305 MB · Review first
• Android Studio's bundled runtime96 MB
• Transporter's bundled runtime50 MB

Measured on one Mac running macOS 27 in October 2026, by space used on disk. Other vendors' JDKs are similar in size to Homebrew's; yours will differ.

So removing an old JDK frees a few hundred megabytes. The gigabytes on a Java developer's Mac are usually in Gradle's and Maven's caches, covered further down.

Uninstall Java on a Mac: Oracle's Java 8 for running apps

Oracle's help page on uninstalling Java from a Mac applies to Java 8, the version java.com offers for running Java apps. It says you need administrator privileges, and lists three items to remove.

What did Oracle's Java 8 install?

• The Java plug-in, /Library/Internet Plug-Ins/JavaAppletPlugin.plugin, which ran applets in browsers.
• The Java Control Panel, /Library/PreferencePanes/JavaControlPanel.prefPane, a settings pane for Java's updates, security level and cache.
• Java's own folder, ~/Library/Application Support/Oracle/Java, in your Library.

Oracle's page gives Terminal commands for these. The Finder route below removes the same three items, and keeps them in the Trash until you're sure.

How do you remove it in Finder?

1. Quit any app that uses Java, and your web browsers.
2. Choose Go › Go to Folder, enter /Library/Internet Plug-Ins and press Return. Move JavaAppletPlugin.plugin to the Trash, entering an administrator's password when asked.
3. Go to /Library/PreferencePanes and move JavaControlPanel.prefPane to the Trash, again with the password.
4. Go to ~/Library/Application Support/Oracle and move the Java folder to the Trash.
5. If the Oracle folder is empty now, move it to the Trash too.

The first two items are shared by everyone on the Mac. The third is in each account's own Library, so repeat step 4 in each account that used Java.

Where does the Java Control Panel live?

Oracle's help page opens it from the Java icon in System Preferences, as macOS used to call System Settings. The pane itself is the JavaControlPanel.prefPane file above. Removing that file removes the Java item from settings.

What is the Java deployment cache?

Oracle describes it as files Java stored while it ran, plus settings changed in the Java Control Panel. On a Mac it lives in ~/Library/Application Support/Oracle/Java, the third item above. Oracle has a separate page for removing it when Java is already gone and the cache stayed behind.

Does this remove Oracle's JDK too?

No. Java 8 for running apps and a JDK are separate installs. Oracle's page points to its JDK instructions for JDK 7 and later, which come next.

Removing a JDK from /Library/Java/JavaVirtualMachines

This is the main event on most Macs. Every vendor's macOS installer puts its JDK in this folder, and every vendor's uninstall instructions come down to removing that JDK's folder with administrator rights.

What does Oracle say about uninstalling its JDK?

Oracle's installation guide says you must have administrator privileges, then go to /Library/Java/JavaVirtualMachines and remove the folder for that JDK. It repeats the warning not to touch the Java tools in /usr/bin.

Its installers keep only one update of each feature release. Installing JDK 25.0.1 replaces JDK 25 by itself, and installing an older update over a newer one shows an error asking you to uninstall the newer one first. So you'll only ever find one Oracle JDK per feature release.

What about Temurin, Zulu, Corretto and Microsoft's JDK?

Adoptium says Temurin's package installs to a temurin folder there, and Azul's guide gives zulu folders. Amazon's Corretto guide gives the uninstall step: remove the amazon-corretto folder for that version, with administrator rights.

Microsoft's guide does the same for its microsoft folder, and also tells macOS to forget the installer's record. That record is a small note of what was installed, kept by macOS. Leaving it does no harm to your Mac.

How do you remove a JDK in Finder?

1. Quit your IDE, Terminal and any Java app.
2. Choose Go › Go to Folder, enter /Library/Java/JavaVirtualMachines, and press Return.
3. Select the folder for the JDK you're removing and choose File › Get Info to check its version and size.
4. Move it to the Trash, entering an administrator's password when asked.
5. Repeat for each JDK you no longer need, and leave the folder itself in place.

Open a new Terminal window afterwards if you use one, so the java command finds the JDK you kept.

Does removing a JDK affect other accounts?

Yes. /Library/Java/JavaVirtualMachines is in the Library folder at the top of the disk, shared by every account on the Mac, which is why moving a JDK from it needs an administrator's password. Check with anyone else who uses the Mac for Java before you remove one.

JDKs from SDKMAN, Coursier and Gradle are different: they live in one account's home folder and affect only that account.

What about JDKs from a .tar.gz download?

Oracle offers each JDK as a .dmg installer or a .tar.gz archive. The archive isn't installed anywhere by itself: it's a folder wherever you unpacked it, and tools find it only if you pointed them at it. Remove that folder in Finder like any other.

Oracle's guide also notes that after installing, you can delete the .dmg or .tar.gz file to save disk space. Check your Downloads folder for old ones, which are often as large as the JDK itself.

What did the JDK leave in your Library?

Very little. Homebrew's records of these JDKs, which list where each one leaves files, show a few small items for some of them: a preferences file and saved window state for Microsoft's, and saved window state for some Zulu versions. If you're removing every JDK, those can go too.

Look in ~/Library/Preferences for net.java.openjdk.java.plist, and in ~/Library/Saved Application State for folders starting with net.java.openjdk or com.azul.zulu. They're tiny, and only worth removing for tidiness.

Homebrew's OpenJDK and Java casks

Homebrew can install Java two ways: as a formula, which goes into its Cellar, or as a cask, which runs the vendor's own package and puts the JDK in /Library/Java/JavaVirtualMachines.

What's the openjdk formula?

Homebrew's own build of OpenJDK, with versioned formulas such as openjdk@17 and openjdk@21 next to the main one. It stays in the Cellar and isn't linked where macOS's Java wrappers look. Homebrew's note on it suggests linking it into /Library/Java/JavaVirtualMachines if you want those wrappers to find it.

On the Mac measured for this post, openjdk@17 had been installed on purpose, nothing else in Homebrew depended on it, and it had never been linked there. That's common: tools set up with Homebrew often find its Java by themselves.

How do you uninstall Homebrew's OpenJDK?

With Homebrew. It's a command-line tool, so there's no app or menu for this. Its uninstall removes the formula's folder from the Cellar and the links Homebrew made itself. If another formula needs Java, Homebrew refuses and names it, unless told to ignore dependencies.

The catalog's entry for the Homebrew Cellar rates it Review first and leaves removal to Homebrew. Deleting a Cellar folder in Finder leaves Homebrew's records pointing at nothing. The Homebrew cleanup post explains what Homebrew clears by itself.

Did you link it into /Library/Java?

Then remove that link yourself, because it's yours, not Homebrew's. Go to /Library/Java/JavaVirtualMachines and look for openjdk.jdk or a name like openjdk-17.jdk. Select it and choose File › Show Original: if it points into Homebrew's folder, move it to the Trash with an administrator's password.

A link whose original is gone does nothing, but it shows up as a broken JDK in tools that list Java versions, so it's worth removing.

What about Temurin, Zulu or Corretto installed as casks?

Homebrew's casks for them, such as temurin, zulu and corretto with version suffixes, run the vendor's package, so the JDK lands in /Library/Java/JavaVirtualMachines like any other. Uninstall them with Homebrew rather than Finder, so Homebrew's record of the cask stays in step.

SDKMAN, Coursier and other version managers

Version managers keep Java in your home folder, one folder per version, and switch between them. Each has its own way to remove versions, and none of them has an app.

How do you remove a Java version from SDKMAN?

SDKMAN installs each version into a folder for that tool, such as ~/.sdkman/candidates/java, and marks one version of each tool as your default. Its own uninstall option removes one version at a time.

The catalog rates SDKMAN candidates as Review first. It also holds Gradle, Maven and Kotlin if you installed them with SDKMAN. Keep the versions set as your defaults: projects and tools that use a removed version can't run it until SDKMAN installs it again.

How do you remove SDKMAN completely?

SDKMAN's documentation lists two steps. Optionally back it up, then remove the ~/.sdkman folder, which takes every Java and every other tool it installed. Then remove its initialisation lines from your shell settings, such as .zshrc or .bash_profile.

In Finder, choose Go › Home and press Shift-Command-Period to show hidden files. Move .sdkman to the Trash. Duplicate .zshrc as a backup, open it in TextEdit, delete the lines that mention sdkman-init.sh, and save.

What about Coursier?

Coursier installs Java versions for Scala and Java tools in ~/Library/Caches/Coursier/arc, or jvm in older versions. Despite the Caches folder, the catalog rates Java versions installed by Coursier as Review first: your shell or code editor may be set to use one of them. Check which Java they use before removing one, and let Coursier manage them.

And mise or asdf?

Both can install Java through their plug-ins, alongside Node.js, Python and more. They keep records of what they installed, so removing a version is their job, one version at a time. The post on uninstalling Node.js describes how these version managers work, since the steps are the same for every language.

JDKs inside IDEs and build tools

Several developer tools bring or download their own Java. Removing your JDKs doesn't touch most of them, and each has its own way to go.

Android Studio's JetBrains Runtime

Android's documentation says the JetBrains Runtime is an enhanced JDK distributed with Android Studio, and recommends using it to run the IDE. It lives inside the app, in a jbr folder. Android Studio also uses the JDK set in its settings to run Gradle builds started from the IDE.

Don't remove anything inside the app. The runtime goes when you uninstall Android Studio, and the post on uninstalling Android Studio covers that, with the SDK and emulators.

IntelliJ IDEA and other JetBrains IDEs

JetBrains' documentation says the IDE's bundled runtime is for running the IDE itself, not for developing Java. For projects, IntelliJ can download a JDK from its Project Structure settings, under SDKs, into a path shown in the download dialog.

The same settings remove an SDK from the IDE's list. JetBrains' documentation doesn't say that removing it there deletes the files, so check the folder the download went to. The post on JetBrains IDE caches covers the rest of what those IDEs keep.

Gradle's toolchains

When a Gradle build asks for a Java version you don't have, Gradle can download one. Its documentation says these auto-provisioned JDKs live in the jdks folder in Gradle's home, ~/.gradle/jdks, and that you remove one by removing its folder there.

It also suggests stopping Gradle's background daemon first, because the daemon remembers toolchains. Quitting your IDE and restarting the Mac does the same without Terminal.

Unity's OpenJDK

Unity installs OpenJDK as a module for Android builds, through the Unity Hub. Unity's documentation says it goes in an OpenJDK folder inside each Editor version's install, next to the Android SDK and NDK. It's removed with that Editor version in the Unity Hub. The post on Unity and Unreal caches covers the Editor versions themselves.

Flutter and other Android builds

Flutter builds the Android side of an app with Gradle. On a Mac that builds Flutter apps, run an Android build after removing a JDK, before you empty the Trash, to confirm a Java is still found. The post on Flutter's pub cache covers what Flutter keeps on its own.

How to tell which apps still need Java

Removing a JDK something still needs is the main way this goes wrong. A few minutes of checking avoids it.

Apps that bring their own

Apps with their own runtime, like the two measured above, don't use your JDKs at all. Look inside an app with Show Package Contents for a jbr, jre or java folder. If it has one, removing your JDKs won't affect it.

Apps and tools that use an installed Java

An app or command-line tool that relies on an installed Java fails to start, or says it can't find Java, once the last suitable JDK is gone. That's the sign to install one JDK of the version it needs, not to keep every old one just in case.

Projects and build settings

Projects often name their Java version. Look for a .sdkmanrc or .tool-versions file in a project's folder, a toolchain setting in its Gradle build files, or a Java version in Maven's pom.xml. JetBrains' documentation notes that IntelliJ reads .sdkmanrc and .tool-versions files and offers to download what they ask for.

Your shell's JAVA_HOME

Some setups name one JDK in a JAVA_HOME line in .zshrc or .zprofile. Show hidden files in your home folder with Shift-Command-Period and open those files in TextEdit. If the line names a folder you're removing, change it to the JDK you keep, or remove the line.

What uses Java	Where it finds it	After a JDK goes	What to check
Apps with their own runtime	Inside the app	Nothing changes	A jbr, jre or java folder in the app
The java command	/Library/Java/JavaVirtualMachines	It uses another JDK, or finds none	Which JDKs you're keeping
Your shell settings	A JAVA_HOME line	Tools see a missing folder	.zshrc and .zprofile
Gradle builds	Toolchains, IDE settings, JAVA_HOME	Gradle may download a JDK again	The build's toolchain version
IntelliJ projects	The project's SDK	The IDE asks for another	Project Structure › SDKs
SDKMAN or Coursier tools	Their own folders	They can't run that version	Your defaults in each tool

Gradle and Maven caches: where the space really is

Uninstalling Java doesn't touch the build tools' caches. They live in your home folder and are shared by every Java, Kotlin and Android project, and they're usually much larger than the JDKs.

Can you delete Gradle's caches?

Yes. The catalog rates Gradle caches as Safe: Gradle downloads or regenerates anything missing on the next build, which is slower. It also removes entries it hasn't used for 7 to 30 days by itself. If you're leaving Java behind entirely, the whole ~/.gradle folder can go, JDKs included.

What about Maven's local repository?

Maven local repository is Usually safe. Maven downloads its libraries again, but artifacts you installed from your own projects come back only when you build and install those projects again. Check before you remove ~/.m2/repository.

The post on Gradle and Maven caches goes through what's in each folder and what clearing it costs.

A worked example

Say a Mac has Oracle's JDK 17 and 21, Temurin 11 from an old course, Homebrew's openjdk@17, SDKMAN with two Java versions, and Android Studio. Its owner builds one Android app and one Java service on Java 21.

Deciding what stays

Android Studio runs on its own runtime, and the Android app's Gradle settings use it too. The Java service's build asks for Java 21. Nothing names 11 or 17, and the shell's JAVA_HOME line points at Oracle's 21. So Oracle's JDK 21 stays, along with Android Studio.

Removing the rest

In /Library/Java/JavaVirtualMachines, jdk-17.jdk and temurin-11.jdk go to the Trash with an administrator's password. Homebrew's openjdk@17 comes off with Homebrew, which removes about 300 MB. SDKMAN's two versions aren't used anywhere, so SDKMAN goes entirely: its folder and its lines in .zshrc.

Checking afterwards

A new Terminal window starts without SDKMAN errors. The Java service builds, and Android Studio syncs its project. A day later, the Trash is emptied: five JDKs of a few hundred megabytes each, and SDKMAN's folder.

Was it worth it?

For space, modestly. The bigger win is clarity: one JDK on the Mac, so every tool agrees on which Java runs. Gradle's caches, which the catalog notes can reach many gigabytes, were left alone, and Gradle keeps trimming them by itself.

Mistakes to avoid

Removing /usr/bin/java or the folder itself

Oracle warns against touching /usr/bin, and macOS protects it. Remove JDKs from /Library/Java/JavaVirtualMachines, one folder at a time, and leave that folder itself in place.

Deleting inside an app

The runtime inside Android Studio, IntelliJ or Transporter is part of the app. Removing it breaks the app and frees little. Uninstall the app if you don't need it.

Removing a JDK that a build or JAVA_HOME names

Check projects and shell settings first. A JAVA_HOME pointing at a removed folder confuses every tool that reads it.

Removing a Homebrew JDK in Finder

Use Homebrew, so its records stay right, then remove any link you made in /Library/Java yourself.

Pasting removal commands from the web

Commands that delete files skip the Trash, so a wrong path can't be undone. Everything here works in Finder and TextEdit, except where a tool only offers a command, and this post says where.

Emptying the Trash straight away

If a build breaks a day later, File › Put Back fixes it while the Trash is still full. After it's emptied, only a backup can.

If a folder refuses to move to the Trash at all, the post on apps and files that won't delete covers the usual causes. For apps' own leftovers, see where uninstalled apps leave files.

How the app does it

Wombit explains Java's folders like everything else on the disk. Select one in the map or the list, and the inspector says what it is, how safe it is to remove and what removing it costs, from the catalog's entry. It reads only names, sizes and dates, and file names and paths never leave your Mac.

Cleanup lists them by level:

• Gradle's caches are Safe. They count toward the safe total and start checked.
• Maven's local repository is Usually safe and waits for you to check it.
• SDKMAN's versions, Coursier's Java versions and Homebrew's Cellar are Review first, explained with each tool's own way to remove them. The app doesn't move them.

What you check goes to the Trash, where you can put it back until you empty it.

• ~/.sdkman/candidates

  SDKMAN candidates

  Java versions and other JVM tools, such as Gradle, Maven and Kotlin, that SDKMAN has installed.

  Review first · Explained only: never removed

• ~/Library/Caches/Coursier/{jvm,arc}

  Java versions installed by Coursier

  Java versions that Coursier downloaded and installed, for Scala and Java tools that use them.

  Review first · Explained only: never removed

• ~/.gradle/caches

  Gradle caches

  Dependencies, build cache entries and other files that Gradle keeps for all the Java, Kotlin and Android projects you build.

  Safe · Moves it to the Trash

• ~/.m2/repository

  Maven local repository

  Libraries and plugins that Maven has downloaded for your Java projects, plus artifacts you installed from your own projects.

  Usually safe · Moves it to the Trash

• /opt/homebrew/Cellar

  Homebrew Cellar

  Command-line tools and libraries installed with Homebrew, in one folder for each package and version.

  Review first · Explained only: never removed

JDKs in /Library/Java/JavaVirtualMachines and Oracle's Java 8 items have no catalog entry, so they're never offered for removal. On a Mac with Apple Intelligence, the inspector can give a Best guess at what one is, labelled as a guess. Remove them the way this post describes.

Seeing all of this is free. Cleanup is PRO, one $4.99 payment with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.