Free lesson · Java Basic To Advance

Environment

Easy6 min readjava

Getting Java Working on Your Machine

A surprising number of senior engineers stumble on Java environment setup. The fundamentals haven't changed in 20 years, but each operating system handles things slightly differently, and version management is its own small skill. This Topic covers what you need to actually get Java working — not just installed, but configured well enough to do real work.

We covered the basics in Topic 1.1 (install JDK 21+, pick an IDE). This Topic goes deeper: managing multiple Java versions, configuring PATH and JAVA_HOME, build tools, and the small environment details that matter.

Choosing a JDK Distribution

Multiple vendors ship JDKs. They all implement the same Java specification, so functionally they're interchangeable, but they differ in licensing, support timelines, and bundled features.

For most readers, the right choice is one of:

Eclipse Temurin (formerly AdoptOpenJDK). Free, open-source, community-supported, widely used. The safe default for learning and most professional work.

Amazon Corretto. Free, Amazon-supported, with long-term support guarantees that match AWS service lifecycles. Excellent choice for AWS-heavy environments.

Oracle JDK. Free for development; commercial license required for production use at most companies. Reasonable for learning but check your employer's policy before using it at work.

Microsoft Build of OpenJDK. Free, Microsoft-supported, optimized for Azure. Reasonable choice if you're in the Microsoft ecosystem.

For the rest of this course, I'll assume Eclipse Temurin unless something specific requires another distribution. The differences for learning are negligible.

Installation by Operating System

macOS

The cleanest approach uses Homebrew:

brew install --cask temurin@21

This installs the JDK in /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home. macOS has a clever mechanism for managing multiple JDK versions through /usr/libexec/java_home:

# List all installed JDKs
/usr/libexec/java_home -V

# Get the path to a specific version
/usr/libexec/java_home -v 21

To make a specific version your default, set JAVA_HOME in your shell config (~/.zshrc for zsh, ~/.bashrc for bash):

export JAVA_HOME=$(/usr/libexec/java_home -v 21)
export PATH=$JAVA_HOME/bin:$PATH

Linux

On Debian/Ubuntu:

# Install via apt
sudo apt update
sudo apt install openjdk-21-jdk

# Or download Temurin manually from adoptium.net

On Red Hat/Fedora:

sudo dnf install java-21-openjdk-devel

Set JAVA_HOME in ~/.bashrc or ~/.profile:

export JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64
export PATH=$JAVA_HOME/bin:$PATH

The exact path varies by distribution. Use update-alternatives --list java to find it.

Windows

The cleanest approach uses winget (Windows 10+):

winget install EclipseAdoptium.Temurin.21.JDK

Or download the MSI installer from adoptium.net.

After installation, set environment variables through System Properties → Advanced → Environment Variables:

• JAVA_HOME → C:\Program Files\Eclipse Adoptium\jdk-21.0.x-hotspot
• Add %JAVA_HOME%\bin to Path

Verify with java --version and javac --version in a new Command Prompt or PowerShell window.

Managing Multiple Java Versions

Real development work often requires multiple Java versions simultaneously. You might maintain a Java 8 legacy service while writing new Java 21 code. Switching JDKs manually is error-prone.

The standard tool for this is SDKMAN! (Linux/macOS) or jenv (Linux/macOS), or jabba (cross-platform).

SDKMAN!

# Install SDKMAN!
curl -s "https://get.sdkman.io" | bash

# List available Java versions
sdk list java

# Install a specific version
sdk install java 21.0.2-tem

# Switch to a different version
sdk use java 17.0.10-tem

# Set a default
sdk default java 21.0.2-tem

SDKMAN! also manages Gradle, Maven, Kotlin, Scala, and other JVM ecosystem tools. It's the standard for serious Java development on Unix-like systems.

jenv

jenv is simpler — just Java version management:

brew install jenv
jenv add /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home
jenv add /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
jenv global 21
jenv local 17   # in a specific project directory

The local command creates a .java-version file in the current directory, so different projects automatically use different Java versions.

graph TD
    A[Your machine] --> B[JDK 8<br/>legacy]
    A --> C[JDK 17<br/>some projects]
    A --> D[JDK 21<br/>new code]

    E[Version manager<br/>SDKMAN! or jenv] -.->|controls active version| A

    F[Project A] -.->|.java-version 8| B
    G[Project B] -.->|.java-version 17| C
    H[Project C] -.->|.java-version 21| D

    style E fill:#7c3aed,color:#fff
    style F fill:#3b82f6,color:#fff
    style G fill:#3b82f6,color:#fff
    style H fill:#3b82f6,color:#fff

This diagram shows how to manage multiple Java versions on a single machine. You install JDK 8, 17, and 21 simultaneously. A version manager like SDKMAN! or jenv controls which version is active. Individual projects can specify their required Java version via a .java-version file in the project directory. When you cd into the project, the version manager automatically switches to that version. This pattern is essential for developers maintaining multiple projects with different Java version requirements.

Build Tools

You'll need a build tool for any non-trivial Java project. The two dominant choices:

Maven. XML-based configuration, declarative, ubiquitous in enterprise. Configuration goes in pom.xml.

Gradle. Groovy or Kotlin DSL, more flexible, common in newer projects and Android. Configuration goes in build.gradle or build.gradle.kts.

For learning, either is fine. Maven is more common in enterprise Java; Gradle is more flexible. We'll cover both at depth in Module 12.

Install via SDKMAN! or your OS package manager:

# SDKMAN!
sdk install maven
sdk install gradle

# Homebrew
brew install maven gradle

# apt
sudo apt install maven

For a minimal Maven project structure:

my-project/
├── pom.xml
└── src/
    ├── main/java/com/example/App.java
    └── test/java/com/example/AppTest.java

For Gradle, replace pom.xml with build.gradle (or build.gradle.kts).

IDE Configuration

We mentioned IDE choice in Topic 1.1 (IntelliJ IDEA Community is the safe default). Beyond installation, a few configuration points matter:

Set the project SDK to match your JDK. IntelliJ: File → Project Structure → Project SDK. Mismatches between IDE SDK and command-line JAVA_HOME cause confusing errors.

Enable annotation processors if needed. Some libraries (Lombok, Dagger, MapStruct) use annotation processing. Enable in IntelliJ: Settings → Build → Compiler → Annotation Processors.

Configure code style. IntelliJ has good defaults but check that they match your team's conventions. Two-space indents are uncommon in Java (most teams use four).

Install useful plugins. SonarLint for static analysis, CheckStyle for style enforcement, Lombok plugin if your project uses Lombok.

Environment Variables That Matter

Three environment variables relate to Java setup:

JAVA_HOME — points to your JDK installation directory. Required by many build tools, IDEs, and frameworks. Should NOT include /bin at the end.

PATH — should include $JAVA_HOME/bin so you can run java, javac, etc. from anywhere.

CLASSPATH — historically used to tell Java where to find classes. Avoid setting this globally. Modern build tools (Maven, Gradle) and the -cp flag on java are the right ways to specify classpaths. A globally-set CLASSPATH is a common source of mysterious errors.

# Good — these in your shell config
export JAVA_HOME=/path/to/jdk-21
export PATH=$JAVA_HOME/bin:$PATH

# Bad — don't do this
export CLASSPATH=/some/path:/another/path

Verifying the Setup

After installation, run this checklist:

# 1. Java launcher works
java --version
# Should print: openjdk 21.x.x...

# 2. Compiler works
javac --version
# Should print: javac 21.x.x

# 3. REPL works
jshell
# Type: System.out.println("Hello")
# Type: /exit

# 4. Build tool works
mvn --version
# or: gradle --version

# 5. JAVA_HOME is set
echo $JAVA_HOME    # Unix
echo %JAVA_HOME%   # Windows
# Should print the path to your JDK

# 6. PATH includes JDK
which java
# Should print a path inside your JDK installation

If all six commands work, your environment is correctly set up.

Common Pitfalls

Warning: Multiple Java installations fighting each other. Especially on macOS, where multiple JDKs can be installed simultaneously, the active java command may not be what you expect. Use which java and java --version to confirm. Use a version manager (SDKMAN!, jenv) to manage this cleanly.

Setting JAVA_HOME to the bin/ directory. JAVA_HOME should point to the JDK root, not JDK_ROOT/bin. The latter breaks build tools that append /bin/java themselves.

Setting CLASSPATH globally. Historically common, now a source of bugs. Let build tools manage classpaths.

Mixing JDK and JRE. Some installers offer separate JDK and JRE downloads. For development, always get the JDK — the JRE alone won't include the compiler.

Forgetting to restart shells after env changes. Changes to ~/.bashrc or ~/.zshrc don't take effect until you open a new shell or run source ~/.bashrc.

Why This Matters in Interviews

Interview: Environment questions don't usually come up in algorithmic interviews, but they do come up in onboarding-style discussions, take-home assignments, and system design interviews where you discuss build and deployment. A candidate who can fluently discuss JDK distributions, version management, build tools, and the JAVA_HOME setup signals practical experience that pure code-writers may lack.

Practical interview prep: have at least one project running end-to-end on your machine. Be able to demonstrate compiling, running, and debugging it.

Try It

Exercise: Set up a complete Java development environment:

1. Install JDK 21 via your preferred distribution
2. Install SDKMAN! (or jenv if you prefer) and use it to manage Java versions
3. Install Maven and Gradle (you'll use one or both later)
4. Open IntelliJ IDEA Community Edition and create a new project — confirm it detects your JDK correctly
5. Run the six verification commands above and confirm all succeed

If anything fails, search the error message and fix it before continuing. A solid environment now saves hours later.

Back to Java Basic To Advance