Browse Learn Clojure Foundations as a Java Developer

Java Environment Variables

Use PATH, JAVA_HOME, and optional Java selection variables deliberately so Clojure, Maven, Gradle, editors, and CI agree on the same JDK.

Environment variables are not the interesting part of Clojure setup, but they often decide whether your tools can find the same JDK. Treat them as routing rules for JVM tools.

The two variables Java engineers usually care about are:

  • PATH: tells the shell where to find commands such as java, javac, clj, and clojure.
  • JAVA_HOME: points to the root directory of the intended JDK for tools that consult it.

How Java Is Found

Different tools use different lookup rules. The Clojure CLI can find Java through a configured Java command, PATH, or JAVA_HOME; Maven, Gradle, IDEs, shells, and CI may each add their own layer.

Variable or setting Used by Good value
PATH Shell commands and many scripts Contains the selected JDK bin directory before stale Java entries
JAVA_HOME Maven, Gradle, scripts, some editor integrations JDK root, not the bin directory
Editor project JDK IDE/editor REPL launcher Same major version as terminal unless intentionally different
CI Java setup Build pipeline Explicit version, not image accident

The safest rule is simple: verify from the same entry point you will use to run Clojure.

Platform Patterns

On macOS and Linux, shell startup files often control terminal behavior:

1export JAVA_HOME=/path/to/jdk
2export PATH="$JAVA_HOME/bin:$PATH"

On macOS, this helper can select an installed JDK:

1export JAVA_HOME=$(/usr/libexec/java_home)

On Windows Command Prompt, verification often looks like:

1echo %JAVA_HOME%
2where java
3where javac

In PowerShell:

1$env:JAVA_HOME
2Get-Command java
3Get-Command javac

Do not copy paths blindly between machines. The path format, install location, CPU architecture, and package manager can all differ.

Avoid Global CLASSPATH

Java developers sometimes reach for a global CLASSPATH when a program cannot find a dependency. Avoid that habit for Clojure projects.

Clojure tools, Maven, Gradle, and test runners should construct the project classpath from project configuration. A global CLASSPATH can hide dependencies on one machine and break the same project everywhere else.

If you are tempted to set… Prefer…
Global CLASSPATH Fix deps.edn, project.clj, Maven, or Gradle config
Global JAVA_HOME only Project-specific version manager or documented setup when teams need multiple JDKs
Random PATH edits A reproducible install or version manager
IDE-only JDK config Also verify terminal commands and CI

What To Put In A README

For a Clojure project, include a short environment block:

1Java: use the team-supported LTS JDK
2Verify: java -version && javac -version
3REPL: clj or editor-connected project REPL
4Tests: documented command or alias

That is usually more valuable than pages of installer screenshots because it tells readers what state the project expects.

Knowledge Check

### What should `PATH` do in a Java/Clojure setup? - [x] Let terminal commands find the intended JDK executables. - [ ] Store Clojure source files. - [ ] Replace dependency configuration. - [ ] Pin all Maven artifacts. > **Explanation:** `PATH` controls command lookup. If it points to the wrong Java first, Clojure tools may start on the wrong JVM. ### Why should you avoid a global `CLASSPATH` for Clojure projects? - [x] It can hide project dependency problems and make builds machine-specific. - [ ] Clojure cannot use classpaths. - [ ] Java ignores global variables. - [ ] It disables the REPL. > **Explanation:** Project tools should build the classpath from project configuration so results are reproducible. ### What is the most useful environment check for team onboarding? - [x] Verify the terminal, editor, and CI all use the intended Java version. - [ ] Set every environment variable globally. - [ ] Use a different JDK in every tool. - [ ] Skip verification once Java is installed. > **Explanation:** Consistency across entry points prevents the classic "works in my IDE" setup failure.
Revised on Saturday, May 23, 2026