Docs menu

Runtime versions

How Primcloud selects an OpenJDK version for your Java app, how to pin one via system.properties, and how to upgrade.

On this page

Primcloud runs OpenJDK as Azul Zulu builds. The versions you can install are part of the Primcloud Runtime and move as the Runtime is updated. The build log for each deployment, in the Deployments tab, shows the version that build installed. It defaults to the latest LTS, and you pin a version with a system.properties file at the root of your repo. Recent LTS releases (such as 17, 21, and 25) are all available; pick the one your app targets.

Pinning a version#

Add a system.properties file at the repo root and set the java.runtime.version key:

system.properties
java.runtime.version=21

The value accepts several shapes:

  • Major only: 21 installs the latest patch of that major.
  • Full version: 21.0.4 for OpenJDK 9 and up, or the legacy 1.8.0_x scheme for OpenJDK 8.
  • Distribution-qualified: a zulu- prefix (for example zulu-21) is accepted, though not required.

Give the major alone unless you have a reason to lock an exact patch. Primcloud then picks the newest patch of that major on every build.

No system.properties. You get the latest LTS OpenJDK. That default shifts forward as newer LTS releases become available, so an app with no pin follows along.

Upgrading#

Bump the pin and redeploy:

  • Major upgrade: edit java.runtime.version in system.properties (say 17 to 21), commit, and push.
  • Patch upgrade: drop any exact-patch pin (or bump it), commit, and push. Primcloud picks up the newest patch of the requested major on the next build.

The next build downloads the newer OpenJDK, then caches it. Crossing a major version boundary means one longer build while the JDK downloads, then normal speed from the deploy after that.

Before jumping majors, review Oracle's migration guide for the version you're moving to. A JDK bump can break your build or your runtime code, and nothing stops you from installing one that does.

When a version drops out of support#

OpenJDK majors follow their upstream support timelines. When one goes end-of-life:

  • Builds pinning that major keep working while the version is still available.
  • Once it's removed, builds that pin the dropped version fail with an "unsupported OpenJDK version" error.
  • Builds that pin a still-supported major keep working. Primcloud picks the newest patch of that major on every deploy.

Move to a newer supported major before your target's EOL date so you're not forced to upgrade under time pressure. New apps should target a current LTS unless a legacy dependency forces an older one.