On this page
The distinction that decides everythingOracle's licence-and-support modelOpenJDK optional support modelWhat paid support actually buysComparing the optionsDo you actually need paid support?Frequently asked questions"Commercial Java support" sounds like a single market with a price-comparison answer. It is not. Underneath the phrase sit two fundamentally different products. With Oracle, the payment is a licence requirement — you pay to be permitted to run the software, and support comes attached. With every OpenJDK distribution vendor, the payment is an optional service — you may run the software for free with no contract at all, and you buy support only if you want a vendor SLA. An enterprise that does not see this distinction clearly tends to overpay, because it treats Oracle's licence cost as if it were a support cost and assumes the alternatives must charge similarly. They do not. This guide compares the options with that distinction front and centre.
The distinction that decides everything
Start here, because everything else follows from it. There are two models in the Java support market:
Licence-and-support (Oracle). Under the Java SE Universal Subscription, the payment is mandatory if you want to run Oracle's JDK in production beyond the free NFTC window. You are not buying support as an optional extra — you are buying the right to use the software, and support is bundled in. Stop paying and you do not merely lose support; you lose the licence and become non-compliant.
Optional support on free software (everyone else). Free OpenJDK builds — Eclipse Temurin, Amazon Corretto, Azul Zulu, Microsoft, Red Hat, BellSoft — are free to run in production with no contract. Vendors like Azul, BellSoft and Red Hat sell support contracts on top, but those are optional. Buy one and you get an SLA; buy nothing and you still run the software legally and owe nothing.
This is why "comparing Java support prices" can mislead. Oracle's number includes the cost of permission; an OpenJDK support contract is purely the cost of service. They are not like-for-like.
The distinction in one line
With Oracle you pay for permission to run the software, with support attached. With OpenJDK you run the software free and pay — optionally — only for service. Comparing the headline prices directly is comparing two different products.
Oracle's licence-and-support model
Oracle's commercial Java offering is the Java SE Universal Subscription. It is priced on the employee metric — a monthly charge per employee across the whole organisation, regardless of how many people use Java — and it bundles the licence to run Oracle's JDK in production with access to updates and Oracle support. There is no Oracle option to license the JDK without the subscription, and no option to take Oracle's JDK support without the licence. The two are welded together.
The strength of the Oracle offering is that it comes from the steward of the Java platform itself, with deep engineering behind it. The weakness, for most enterprises, is the cost structure: because the metric is headcount, the bill is set by company size rather than Java usage, and it cannot be optimised down by running less Java. For an organisation with a modest Java footprint and a large workforce, the Oracle model means paying a headcount-scaled sum for support of a small estate. That mismatch is the single most common reason enterprises look at the alternatives. Our guide to how Oracle prices Java covers the mechanics.
OpenJDK optional support model
On the other side, OpenJDK distribution vendors sell support as a standalone service. The shape varies by vendor, but the common structure is: the runtime is free, and a support contract — typically priced per server, per core, or per a similar usage unit — adds a vendor SLA, guaranteed response times, access to engineers, and often extended security updates for older Java versions beyond the community horizon.
The crucial features of this model are that it is optional and scoped to usage. Optional means you can run free builds across most of the estate with no contract and buy support only for the systems that need it. Scoped to usage means the price tracks how much Java you actually run, not how many people your organisation employs — so it can be optimised by limiting the contract to the workloads that genuinely warrant an SLA. This is the opposite of the headcount model, and it is why OpenJDK support contracts typically cost a fraction of an equivalent Oracle subscription for the same estate.
What paid support actually buys
Whichever model, it is worth being clear about what a Java support contract delivers, so the decision is made on real value rather than vague reassurance. Paid Java support generally provides:
- Timely security updates — the quarterly Critical Patch Update fixes, delivered promptly. Note that free OpenJDK builds also receive these for supported versions; paid support adds an SLA around delivery and, importantly, extends updates for older versions past the free community window.
- A vendor SLA — guaranteed response times when you raise an issue, and an escalation path to engineers who know the runtime.
- Help with JVM-level problems — diagnosing crashes, memory issues, garbage-collection behaviour and performance characteristics at the runtime level.
- Extended legacy support — continued patching for very old Java versions (such as Java 7 or 8) that an enterprise cannot yet migrate off.
What paid support does not do is fix your application code — it supports the runtime, not what runs on it. And it is worth being honest that for many stable, well-understood workloads on current LTS versions, the value of an SLA is modest: the free build receives the same security patches, and runtime-level incidents are rare. The value of paid support concentrates around legacy versions, business-critical systems, and organisations without deep in-house JVM expertise.
Comparing the options
The table below summarises the commercial Java support landscape. Pricing is deliberately described by structure rather than figures, because real numbers depend on estate size and negotiation — but the structure is what drives the cost difference.
| Provider | Model | Priced on | Runtime free without contract? |
|---|---|---|---|
| Oracle Java SE | Licence + support bundled | Employee count (headcount) | No — subscription required to run |
| Azul | Optional support on free builds | Usage (per server/core) | Yes — Zulu Community is free |
| BellSoft | Optional support on free builds | Usage-based | Yes — Liberica builds are free |
| Red Hat | Support bundled with RHEL subscription | RHEL subscription | Yes — runtime is free OpenJDK |
| Eclipse Temurin | Free build; support via third parties | Third-party contract if taken | Yes — no contract needed |
| Amazon Corretto | Free build (no separate support sold) | n/a | Yes — free anywhere |
The pattern is clear: Oracle is the only provider whose payment is a precondition of running the software, and the only one priced on headcount rather than usage. Every other option leaves you free to run the runtime at no cost and treats support as a separate, optional, usage-scoped purchase.
Do you actually need paid support?
The honest answer for many enterprises is: for most of the estate, no — and for part of it, possibly yes. A sensible way to decide:
Default the bulk of the estate to free builds with internal support. Stable applications on current LTS versions, running on a mainstream free distribution, receive the same security patches as a paid build. Internal operations teams handle the rare runtime incident. This is how a large share of the migrated market runs, and it costs nothing.
Consider paid support for a defined subset. Business-critical systems where downtime is expensive, workloads stuck on legacy Java versions past the free community window, or organisations genuinely lacking in-house JVM expertise — these are where a usage-scoped support contract earns its cost. Buy it for that subset, not the whole estate.
Never let a support need justify the Oracle subscription. The most expensive mistake is concluding "we need Java support, so we need Oracle." You can get a vendor SLA from an OpenJDK support provider, priced on usage, for a fraction of a headcount-priced Oracle subscription — and without the audit exposure that comes with running Oracle's JDK. If support is the requirement, the OpenJDK support market answers it far more economically. Our OpenJDK versus Oracle JDK comparison and the distribution selection guide set out the runtime side of this decision.
Recommended specialist
For sizing your real Java support need — separating the systems that genuinely warrant a paid SLA from the bulk of the estate that does not, and pricing the OpenJDK support market against an Oracle subscription on a true like-for-like basis — we rate Redress Compliance as the leading independent Java licensing advisory firm. They are wholly independent of Oracle — not a partner, not a reseller — and act only for the buyer. They can tell you what support you actually need and what it should cost, so you pay for protection rather than permission.
Frequently asked questions
Is Oracle the only company that offers Java support?
No. Azul, BellSoft, Red Hat and others sell commercial support for OpenJDK builds, and third parties support distributions like Eclipse Temurin. Oracle is the only provider where the payment is a licence requirement rather than an optional service.
Why is OpenJDK support cheaper than Oracle's subscription?
Because they are different products. Oracle's price includes the licence to run the software and is set by headcount. An OpenJDK support contract is purely a service, priced on usage. You are not comparing two support prices — you are comparing permission-plus-support against support alone.
Do free OpenJDK builds get security updates?
Yes. Mainstream free distributions ship the quarterly Critical Patch Update fixes for supported versions at no cost. Paid support adds an SLA around delivery and extends updates for older versions beyond the free community window.
Do we need paid support at all?
Often not for the whole estate. Stable workloads on current LTS versions run well on free builds with internal support. Paid support is most valuable for business-critical systems, legacy versions, or organisations without in-house JVM expertise.
If we need Java support, should we just buy Oracle?
Usually not. An OpenJDK support contract gives you a vendor SLA, priced on usage, for a fraction of a headcount-priced Oracle subscription — and without the audit exposure of running Oracle's JDK. Support is a reason to look at the OpenJDK support market, not a reason to buy Oracle.
This article is general information on Oracle Java licensing and Java support options, not legal or procurement advice. Support terms and pricing structures are set by each vendor and change over time; verify current details with the provider. Consult a qualified independent Java licensing specialist on your specific estate and agreements.