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:
java.runtime.version=21
The value accepts several shapes:
- Major only:
21installs the latest patch of that major. - Full version:
21.0.4for OpenJDK 9 and up, or the legacy1.8.0_xscheme for OpenJDK 8. - Distribution-qualified: a
zulu-prefix (for examplezulu-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.versioninsystem.properties(say17to21), 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.