The JDK

The JDK

For any Modern Java/JVM project, the first decision is which version of Java (the JDK) to use? Some guidelines:

• Java 21 is the most current LTS ("long-term support") version
• There are more recent versions with continuing improvements and additional features to try out
• If your personal or open-source project does not require a paid support contract, newer Java versions are a good choice
• For a full breakdown of the current JDK landscape (as of Jul 2022), see Which JDK Version and Vendor Should You Use on Your Project?, and a short list of recommendations at Which Version of JDK Should I Use?

In this project, you'll see the choice of Java 21 as this is the version to recommend in production.

In general, you will find that Adoptium is a go-to choice for the JDK.

There are many ways to install the JDK, most are platform-dependent. In general, your team will be better off using a "managed" approach, rather than with each person using binary installers. Popular choices include:

• Apt and friends for Linux or WSL
• Homebrew for Mac
• SDKMAN for multiple platforms

Note

This is the last clean commit to use JDK 17. If you are on JDK 21, please look at the current commits on this project. There are still some concerns in 3rd-party tooling in JDK 21, but you should keep your project up to date, and pickup key improvements and security fixes.

Managing your Java environment

Tools come to mind to manage your JDK environment in projects:

• jEnv
• Direnv

Both assume UNIX-type shells (Bash, Zsh, etc).

For those on Windows, you may need to use Cygwin, Git for Windows, or WSL2 to use these.

(Reminder: in general, when setting up your project environment, prefer the latest LTS version of Java, which is 21.)

Jenv

jEnv supports both "global" (meaning you, the user) and "project" choices of JDK (particular to a directory and its children) in which JDK installation to use. You may notice the .java-version file: this is a per-project file for jEnv to pick your project Java version. Do use jenv enable-plugins export and restart your shell. This ensures JAVA_HOME is exported to match your jEnv settings. Several tools use JAVA_HOME rather than the java or javac found in your PATH.

Try out jenv doctor to validate your setup and environment.

You may also find the gradle and maven plugins for jEnv useful.

Direnv

direnv is a general way to configure your environment. Rather than specifying a Java version, you edit a .envrc file and add JDK-specific environment settings (and another other environment settings) just as you would on the command-line. Typically in .envrc might be setup for your locally-installed JDK.

Another key example is setting OWASP_NVD_API_KEY and other secrets, et al, so that secrets are local to you, and not part of files you commit to the repository.

Important

For this reason, you should add .envrc and similar files to .gitignore, and ensure they are not committed to the code repository.

Tips

• When using jenv you may find some tools insist on a JAVA_HOME environment variable (even when java or javac are plainly in PATH). For these tools, you can use a .envrc file for direnv that includes:

  export JAVA_HOME="$(jenv javahome)"

• In Maven, use a property to fix the version of Java in place. But note naming for that property: java.version is defined by the JVM, and Maven creates a matching property. Recommended is to define your Java version with the jdk.version property, which has no collision with pre-defined properties.
• In Gradle, use the javaToolchains task to investigate issues with mismatching or confusing build paths, project configuration, and Gradle sorting it out. This is an issue for local-only builds; local builds using a container (such as via Earthly) lower these concerns.
• In GitHub Actions, building supports cross-checking multiple JVM versions, use the matrix feature. See the example GitHub actions.

Going further

TODO: Placeholder section