Dora NodaPaketo Buildpacks added Java 26 support in July 2026, the same week it shipped in major OpenJDK distributions. It will also never be the default. Java 21 stays the default until September 2026, when Java 25 takes over — and Java 26 gets dropped in favor of Java 27 the moment that next version arrives. A fully supported, fully buildable Java version can enter the buildpack, sit there the entire time it's current, and exit again without ever once being what a plain pack build gives a developer who didn't specify a version.
That's not an oversight. It's a documented policy, applied on a schedule, to every language runtime a buildpacks platform supports. Paketo's own words for it: "only Java LTS versions stay for a long time, even maybe… forever?!" Non-LTS releases like Java 26 get one cycle and then they're gone. For a developer who just runs git push and lets a platform figure out the build, none of this is visible — they get a working container either way. It's the platform underneath that has to know the rule exists, know when it fires, and rebuild accordingly, for every language it supports at once.
This post is a concrete accounting of what tracking that policy — and the dozen policies like it, one per language, running at once — actually costs a buildpacks-based platform to maintain, and what the same work looks like when there's no buildpack layer at all and it lands on the app author instead.
The rule that makes "never default" deterministic
Java's default-version behavior isn't ad hoc; it's governed by RFC #0014, a policy the Paketo Java subteam adopted through its own community process. The rule: the default changes once the latest released LTS version of Java is at least one year old. Java 25 is an LTS release that shipped in September 2025. One year later — September 2026 — it becomes the new default, dethroning Java 21, which had held that spot since November 2024 (before that, the default moved from Java 11 to Java 17 in March 2023).
The rule has an escape hatch of its own: the Java subteam can shorten the cycle by majority vote if a change is "sufficiently urgent." Absent that vote, the clock just runs. And running the clock is only half the policy — the other half decides what happens to versions that never become default at all. Paketo's own July 2026 announcement states it plainly: Java 26 "will be dropped for Java 27" the moment the next release lands. A non-LTS version's entire lifecycle inside the buildpack — added, buildable, current, gone — spans exactly one release cycle. LTS versions get a one-year countdown to relevance; everything else gets a single-cycle expiration date, no countdown at all.
The rebuild cadence sitting underneath the version bump
A default-version change is a headline event — it happens once a year or so, and Paketo writes a blog post about it. The actual maintenance load is a lot less occasional. Cloud Native Buildpacks' own operator guidance sets concrete SLA targets for keeping builder images current: stacks rebuild weekly even when no CVE is in play, just to keep non-vulnerable packages current, and when a CVE does land, the target is 48 hours for High/Critical severity and two weeks for Low/Medium.
Stack this against RFC #0014's yearly cadence and the shape of the treadmill comes into focus. The default-version bump is the visible, occasional decision. Underneath it runs a weekly-to-48-hour operational loop that has to hold for every builder image a platform actually has in use — Java 21's image, Java 25's, whatever non-default versions a tenant has pinned via BP_JVM_VERSION — for as long as any of them are still serving traffic. A platform running buildpacks isn't tracking "when does Java's default change." It's running a standing patch pipeline with a 48-hour clock on it, times every language runtime and every still-supported version of each one.
That cadence also isn't the end of the job — it's the trigger for a second one. A patched stack image existing in a registry doesn't automatically reach a tenant's already-running container; someone still has to rebase it, the operation CNB defines specifically for stamping a new base-image layer under an app's existing build without a full rebuild. A platform that tracks the 48-hour patch SLA but has no rebase step wired to its own deploy pipeline has done the tracking and skipped the part that actually closes the exposure window.
It's not one treadmill — it's one per language
RFC #0014 is Java's clock. It isn't everyone else's. Paketo's Node.js buildpack (node-engine) runs on a completely different mechanism: it carries whatever versions are Active LTS in the Node.js community, plus the current release, and drops a version whenever the community itself marks it end-of-life — no fixed one-year offset, no separate RFC vote. Node's clock is set by Node's own release calendar; Java's clock is set by a rule Paketo's own subteam wrote and can vote to override.
That difference matters more than it looks. A platform that supports Java, Node.js, Python, Go, and Ruby through buildpacks isn't tracking one version-lifecycle rule — it's tracking as many distinct rules as there are language subteams, each with its own default-change trigger, its own deprecation window, and its own community upstream driving the calendar. Python and Go follow yet another shape again: both buildpacks publish whatever versions a given buildpack release supports in that release's own release notes, with the default pinned in the buildpack's buildpack.toml rather than derived from a public RFC at all — so "when does the default change" isn't even answerable the same way across every runtime a platform ships. The "treadmill" in the phrase "language-version treadmill" isn't a single belt. It's a rack of them, running at different speeds, on different mechanisms, and something has to watch all of them at once.
What outsourcing this treadmill is worth on the open market
The clearest evidence that this tracking work has real, monetizable cost showed up on July 21, 2026, when BellSoft — the OpenJDK vendor behind Liberica — announced a hardened builder for Paketo, built on its Alpaquita OS, across six language runtimes: Java (Liberica JDK and Liberica NIK), Node.js, Python, Go, and Ruby. Its headline commitment is a 24-hour turnaround on any disclosed CVE, tighter than the CNB project's own 48-hour target for High/Critical severity — with a full SBOM and provenance record shipped on every image, and no changes required to an existing buildpacks-based workflow.
BellSoft also reported that adoption of buildpack tooling across its customer base more than doubled year-over-year from 2024 to 2025. Put those two facts together and the read isn't subtle: enough platforms found the weekly-rebuild, 48-hour-CVE, per-language-clock treadmill expensive enough to run themselves that a vendor built a business selling the outsourced version of it — priced against a faster SLA than the open-source baseline already promises. Nobody builds a 24-hour CVE commitment across six separate language ecosystems as a product bet unless the underlying tracking work is expensive enough, often enough, for enough platforms, that beating the community default by half a day is worth paying for.
What a Dockerfile-only platform hands the app author instead
None of this tracking disappears on a Dockerfile-only platform. It just changes who owns the clock. When an app author writes FROM eclipse-temurin:21-jre directly, they've taken on RFC #0014's job themselves, minus the RFC, minus the subteam, minus the blog post announcing the change. Nobody tells them Java 21 is approaching its LTS window's edge, nobody bumps their base image on a 48-hour CVE SLA, and nobody drops Java 26 for them the week Java 27 ships — they have to notice all three, on their own schedule, per repository, for every language every service uses.
The observed outcome of pushing that work onto individual authors is not hypothetical. A Kaspersky report published in June 2026 found that 64% of the 100 most-downloaded Docker Hub images — each with up to a million pulls — contained critical vulnerabilities, a gap the researchers attributed directly to pre-built images lacking automated patching: unlike a managed builder image, nobody rebuilds and redeploys them on any SLA at all. That's what "the treadmill is the app author's problem instead of the platform's" looks like when it's measured rather than assumed — not a slower version of the same tracking, but frequently no tracking at all.
Where bex lands on this
bex builds tenant apps with Cloud Native Buildpacks by default — the same convention Paketo, Google Cloud Buildpacks, and Cloud Foundry all build on — precisely so that Java's RFC #0014 clock, Node's LTS-and-current clock, and every other language subteam's deprecation window are the buildpack maintainers' job, not something bex's own team re-derives from scratch for every runtime it supports. Repos with a shape no buildpack detects still get a Dockerfile as an explicit, sanctioned escape hatch — but reaching for it means opting back into owning the exact clock this post just walked through, version by version, CVE by CVE.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
Sources:
- Paketo Buildpacks: ready for Java 26 & more! — JAVAPRO International
- Paketo Java Buildpacks Updates its Default JVM Version — Paketo Buildpacks Blog
- Paketo Java Buildpacks Updates Default to Java 21 — Paketo Buildpacks Blog
- Rebase — Cloud Native Buildpacks docs
- paketo-buildpacks/node-engine — GitHub
- BellSoft Announces Hardened Builder for Paketo Buildpacks — GlobeNewswire
- Nearly two-thirds of analyzed Docker Hub images contained critical vulnerabilities — Kaspersky
