Where Does Java Install To? Default Paths Explained Across Windows, macOS, and Linux

Java is one of the most widely used programming platforms in the world, but its installation behavior confuses a lot of people — especially because the answer changes depending on your operating system, the version you're installing, and which Java distribution you're actually using. Here's a clear breakdown of where Java lands and why it matters.

What Gets Installed When You Install Java?

Before getting into paths, it helps to know what Java actually installs. There are two main components:

  • JRE (Java Runtime Environment) — the piece that lets you run Java applications
  • JDK (Java Development Kit) — everything in the JRE, plus compilers and tools for developing Java software

For years, Oracle shipped them separately. Modern Java distributions (JDK 11 and later) bundle the runtime directly into the JDK, so most developers only install the JDK now. If you're just running a Java-dependent app like Minecraft or certain enterprise software, your installer may drop only a runtime.


Default Java Install Locations by Operating System

🖥️ Windows

On Windows, Java typically installs to one of two root directories depending on the source:

Oracle JDK / JRE (traditional):

C:Program FilesJavajdk-<version> C:Program FilesJavajre-<version> 

For example, JDK 21 from Oracle would land at:

C:Program FilesJavajdk-21 

OpenJDK and other distributions (Eclipse Temurin, Microsoft Build of OpenJDK, Amazon Corretto, etc.) often follow a slightly different convention:

C:Program FilesEclipse Adoptiumjdk-<version> C:Program FilesMicrosoftjdk-<version> 

Each vendor picks its own subdirectory under Program Files, so if you've installed multiple distributions, you may have several Java folders sitting side by side.

The JAVA_HOME environment variable is supposed to point to whichever installation you want treated as the active one. Many tools — build systems like Maven and Gradle, IDEs like IntelliJ and Eclipse — read JAVA_HOME to find Java rather than hunting through the filesystem.


🍎 macOS

macOS handles Java a bit differently and the location depends on how you installed it.

Installer packages (Oracle or Adoptium .pkg files):

/Library/Java/JavaVirtualMachines/jdk-<version>.jdk/Contents/Home/ 

This is the standard, system-wide location. Every JDK installed via a .pkg installer on macOS goes here, which is what makes the built-in macOS Java management tool work properly.

Homebrew installs:

/opt/homebrew/opt/openjdk/ 

or on Intel Macs:

/usr/local/opt/openjdk/ 

SDKMAN! (a popular version manager):

~/.sdkman/candidates/java/<version>/ 

macOS also has a helper tool at /usr/libexec/java_home that can list all detected JDKs and return the path to a specific version. Running /usr/libexec/java_home -V in Terminal gives you a quick inventory of everything installed.


🐧 Linux

Linux distributions vary the most. Package managers, manual installs, and version managers all deposit Java in different places.

Installation MethodTypical Path
apt (Ubuntu/Debian)/usr/lib/jvm/java-<version>-openjdk-amd64/
dnf/yum (Fedora/RHEL)/usr/lib/jvm/java-<version>-openjdk/
Manual .tar.gz extractWherever you extracted it (often /opt/java/ or /usr/local/java/)
SDKMAN!~/.sdkman/candidates/java/<version>/

On Debian-based systems, the update-alternatives system manages which Java version is active when you run the java command, even if multiple versions are installed.

Why the Install Path Actually Matters

For most end users running Java-dependent apps, the path is invisible — the installer handles everything. But it becomes important in a few situations:

Build tools and IDEs need to know where Java lives. If JAVA_HOME isn't set or points to the wrong version, builds break and IDEs throw errors.

Multiple Java versions are common in development environments. A developer might need Java 8 for a legacy project and Java 21 for a modern one. Version managers (SDKMAN!, jenv, Jabba) manage this by letting you switch the active path per project or terminal session.

Server environments often require explicit path configuration in startup scripts, especially for application servers like Tomcat or JBoss. Knowing the exact install path is necessary to configure these correctly.

Verifying your install is straightforward once you know the path. Running java -version in a terminal confirms which version is active, and which java (macOS/Linux) or where java (Windows) shows the executable path — though this reflects the active version, not necessarily every installed version.

The Variables That Change Your Outcome

Where Java ends up on any specific machine depends on several layered factors:

  • Distribution — Oracle JDK, OpenJDK, Eclipse Temurin, Amazon Corretto, Microsoft, Azul Zulu, and others each have their own conventions
  • Version — Java 8, 11, 17, 21, and beyond sometimes use different directory naming patterns
  • Installation method — system package manager, standalone installer, Homebrew, or a version manager all place files differently
  • Whether it's a JDK or JRE — older setups may have both; newer setups typically just have the JDK
  • Single vs. multiple installs — running several versions simultaneously creates multiple directories and requires deliberate path management

A developer running a single OpenJDK install via Homebrew on an Apple Silicon Mac has a completely different directory structure than a Windows developer using Oracle's official installer or a Linux sysadmin managing OpenJDK through apt. The paths above are defaults and conventions — actual environments regularly diverge from them.

Understanding which distribution you have, which installation method was used, and how your operating system handles path resolution is the real starting point for locating — and correctly configuring — Java on any given machine.