Java runtime vs JDK: licensing differences explained

Ask around an IT department how Oracle Java licensing works and you will, sooner or later, hear some version of: “the runtime is free, it’s the development kit you have to pay for.” It is a tidy, intuitive distinction. It is also wrong — and believing it is one of the more common ways organisations walk into Oracle Java audit exposure. Whether a piece of Oracle Java costs money has almost nothing to do with whether it is a JRE or a JDK. This guide explains the real difference between the two, why it does not drive licensing, and what actually does.

JRE and JDK: the technical difference

Start with what the two things genuinely are, because the technical distinction is real even though the licensing distinction is not.

The JRE — the Java Runtime Environment — is what is needed to run a Java application. It contains the Java Virtual Machine, the core class libraries, and the supporting files that let compiled Java bytecode execute. A machine that only needs to run Java software needs a JRE.

The JDK — the Java Development Kit — is what is needed to build Java applications. It contains everything in the JRE, plus the development tools: the compiler, the debugger, packaging and diagnostic utilities. A JDK is a superset of a JRE — it can both build and run Java. A developer’s machine needs a JDK; a server that simply runs a Java application needs, in principle, only a JRE.

That is the entire technical story, and it is genuinely useful for sizing installations. The mistake is to assume that this build-versus-run distinction maps onto a free-versus-paid distinction. It does not.

The "JRE is free" myth

The myth probably took hold because, for many years, Oracle distributed a consumer JRE widely and freely — it was the thing end-users downloaded to run Java applets and desktop applications, and it felt free because, for personal use, it was. Over time “the JRE is the free one” hardened into received wisdom inside IT teams.

The wisdom is now actively dangerous. Oracle’s commercial licensing terms attach to Oracle’s Java software — the binaries Oracle distributes — based on the licence under which a given release was published and the way it is used. Those terms do not carve out the JRE as a free exception. An Oracle JRE used in a commercial production setting under a licence that requires a subscription needs a subscription, exactly as the corresponding JDK would. An organisation that has installed Oracle JREs across hundreds of servers in the belief that runtimes are exempt has not avoided licensing — it has simply not measured the exposure it is carrying.

What Oracle actually licenses

To replace the myth with the real model, it helps to be precise about what Oracle is licensing. Oracle licenses its own builds of Java — the binaries you download from Oracle. Each Oracle Java release is published under a specific licence agreement, and that agreement governs what you may do with the binary for free and what requires payment.

The licence in force depends on the release. Older Java was distributed under the Binary Code License. Some Java releases were published under the Oracle Technology Network licence, which permits free development and testing use but requires a subscription for production and other commercial use. Current Java releases are published under the No-Fee Terms and Conditions licence, which permits broad free use including production for a defined period. Crucially, every one of these licences applies to the Oracle binary as a whole — the JRE portion and the JDK portion alike. None of them says “the runtime is exempt.” The licensing question is always “which Oracle release is this, under which licence, and how is it being used” — never “is this a JRE or a JDK.”

Why the version matters, not the package

The single most useful correction to make inside an IT organisation is this: the variable that drives Oracle Java licensing is the version and its licence terms, not the JRE/JDK package type. Two examples make the point.

Take a current Java release published under NFTC. The JDK of that release can be used freely in production for the defined period, and so can the JRE-equivalent of that same release — because the NFTC terms govern the whole binary. Now take an older release published under OTN. The JDK of that release requires a subscription for production use — and so does the JRE-equivalent of that same release, for exactly the same reason. In both cases the JRE and the JDK are treated identically; what changed the answer was the version and its licence, not the package.

This is why a Java inventory that records only “JRE” or “JDK” is nearly useless for licensing. The inventory must record the vendor (Oracle or an OpenJDK distribution), the exact version and update level, and the use case (development, testing, production). With those three facts the licence position is determinable. Without them, the JRE/JDK label tells you nothing about cost.

The standalone JRE has gone

There is a further reason the “JRE is free” framing is outdated: for modern Java, the standalone JRE barely exists as a separate product. From Java 11 onward, Oracle stopped shipping a separately downloadable consumer JRE. Modern Java is distributed as the JDK, and where a smaller runtime-only footprint is needed, it is produced by tailoring a runtime image from the JDK using the platform’s own tooling, rather than by installing a distinct “JRE product.”

The practical consequence is that, for any reasonably current Java, debating whether to license “the JRE” or “the JDK” is largely moot — there is one Oracle download, the JDK, and one licence governing it. The JRE/JDK distinction is now mainly relevant to legacy Java 8 estates, where standalone JREs were genuinely common. Even there, the licensing rule is unchanged: a Java 8 Oracle JRE is governed by the same Java 8 licence terms as the Java 8 Oracle JDK, including the BCL update trap that affects Java 8 generally.

Common deployment scenarios

A few real-world scenarios show how the rule plays out:

• Oracle JREs on production servers. Frequently assumed to be free because they are “just runtimes.” In fact governed by the version’s licence — if that licence requires a production subscription, every one of those JREs counts toward exposure.
• Oracle JDK on developer laptops. Often assumed to need licensing because it is “the development kit.” In fact, several Oracle licences explicitly permit free development and testing use — the developer JDK may well be free, depending on version.
• A bundled Oracle JRE inside vendor software. Some third-party applications ship an Oracle JRE. Whether that is covered can depend on the software vendor’s arrangement with Oracle — it must be checked, not assumed, and is covered in our bundled Java guide.
• An Oracle JRE left over on a desktop. An unused, un-uninstalled Oracle JRE is still an installed Oracle binary and can still appear in an audit count.

In every scenario, the JRE/JDK label is the least informative fact. The version, the licence, and the use case decide the outcome.

JDK and JRE in OpenJDK distributions

One place the JRE/JDK distinction does become genuinely simple is the free OpenJDK distributions. Eclipse Temurin, Amazon Corretto, and Azul Zulu publish OpenJDK builds — some offer a JDK and a separate runtime-only package — and both are free under the GPLv2 with Classpath Exception. There is no version, no licence, and no use case under which a free OpenJDK build flips to paid. Whether you take the full JDK or a runtime image, the cost is zero.

This is part of why migration to OpenJDK is such a clean answer to the whole JRE/JDK licensing question. Once an estate runs free OpenJDK distributions, the anxious accounting of “which of these is a runtime and which is a kit and which needs a subscription” simply disappears — nothing needs a subscription. Our comparison of OpenJDK distributions covers the options.

Getting your licensing right

1. Drop the JRE/JDK shortcut. Stop using “it’s a runtime” as a reason to assume something is free. It is not a licensing fact.
2. Inventory by vendor, version, and use case. For every Java install — JRE or JDK — record who built it, the exact version, and whether it is development, test, or production.
3. Apply the licence per release. Determine the governing licence (BCL, OTN, NFTC) for each Oracle version and apply its terms to the whole binary.
4. Re-examine the “free runtimes”. Audit the Oracle JREs that were assumed exempt — this is where unmeasured exposure usually hides.
5. Consider OpenJDK. Where the licensing accounting is burdensome, migrating to free OpenJDK removes the question entirely.

Getting independent help

The belief that the JRE is free and the JDK is paid is intuitive, widespread, and wrong — and it costs organisations real money, both in unmeasured audit exposure on “free” runtimes and in subscriptions bought for developer kits that may not have needed them. The accurate model is simpler than the myth: Oracle licenses its binaries by version, licence, and use case, and the JRE/JDK label does not change the answer.

Independent, buyer-side advisers build the accurate picture — with no Oracle partnership shaping it. Across 340+ Java engagements, that has helped organisations correct the JRE/JDK misconception, find the exposure it was hiding, and avoid paying where free use was permitted — contributing to more than $180M in client savings and a 68% average reduction on the audit claims that did arise. Our Java Compliance Assessment builds the version-and-use-case inventory, our Migration service moves the estate to free OpenJDK, and our Audit Defence service, backed by a money-back guarantee, defends a Java audit if one arrives.

Frequently asked questions