Oracle Java SE vs Java EE licensing.

"Java SE" and "Java EE" sound like two flavours of the same product, and that resemblance causes real money to be spent in the wrong place. They are different things, with different histories and — crucially — completely different licensing situations. This guide separates them cleanly so you know which one actually carries an Oracle bill.

Java SE and Java EE are two different things

Java SE (Standard Edition) is the core Java platform: the language, the virtual machine, and the standard libraries. It is what you install when you install "a JDK". Every Java program, of any kind, runs on Java SE.

Java EE (Enterprise Edition) was never a platform you install on its own. It was a set of additional specifications — for servlets, persistence, messaging, transactions, dependency injection and more — layered on top of Java SE and implemented by application servers. Java EE was the enterprise API standard; Java SE was, and is, the runtime underneath it.

The single most useful sentence to remember: Java SE is the runtime; Java EE was a specification layered on top of it. The licensing risk in 2026 lives almost entirely with Java SE.

What happened to Java EE

Java EE began life as J2EE under Sun Microsystems. Oracle acquired Sun in 2010 and inherited it. Then, in 2017, Oracle made a decision that reshaped the landscape: it handed Java EE to the Eclipse Foundation as an open, vendor-neutral project. Because Oracle retained the "Java" trademark, the project could not keep the name — so Java EE was renamed Jakarta EE.

The hand-over was thorough. Governance, specifications and the reference implementations all moved to the Eclipse Foundation. A later technical consequence was the namespace change from javax.* to jakarta.*, which application code must adopt to use newer Jakarta EE versions. The point for licensing is simple: Oracle no longer owns or licenses the enterprise specification. Java EE, as an Oracle-controlled product, no longer exists.

How Java SE is licensed today

Java SE is where the Oracle relationship still matters. The licence depends on which build you run:

• Oracle JDK — Oracle's branded build. Free under the legacy BCL and under the current NFTC, but licensable under the OTN terms that govern JDK 8u211+ and JDK 11–16 in production. Paid use is sold as the Java SE Universal Subscription, priced on the employee metric.
• OpenJDK distributions — Eclipse Temurin, Amazon Corretto, Microsoft Build of OpenJDK, Red Hat build of OpenJDK and Azul Zulu are free Java SE runtimes with no Oracle licence obligation.

So when an organisation has a "Java licensing problem", it is virtually always a Java SE problem — an Oracle JDK running under licence terms that require a subscription.

How Jakarta EE is "licensed" today

Jakarta EE itself is open source and free. The specifications are published openly by the Eclipse Foundation, and there is no per-user or per-processor fee to use them. What you choose is an implementation — a Jakarta EE application server — and most of the major ones are free and open source. The catch worth understanding is that an application server is a piece of software that runs on a Java SE runtime. The server may be free; the JDK underneath it is the thing that may not be.

In other words, the licensing question never disappears — it just moves down a layer. You can run a free Jakarta EE server all day long, but if you run it on an OTN-licensed Oracle JDK in production, you still owe Oracle for the Java SE underneath.

WebLogic, application servers and Java

One Oracle product keeps the words "Java" and "enterprise" tied together: Oracle WebLogic Server. WebLogic is Oracle's commercial Java EE / Jakarta EE application server, and it is licensed as a separate Oracle product in its own right — not as part of any Java SE subscription.

The relationship that catches organisations out is the bundling. A licensed Oracle product such as WebLogic includes a restricted-use entitlement to the Java SE it needs to run that product. That entitlement does not extend to using the same Oracle JDK for your own separate applications. Treating "we have WebLogic, so our Java SE is covered" as a blanket truth is one of the most common and most expensive misreadings in this area. WebLogic licensing and Java SE licensing are different obligations that happen to touch.

Where the confusion comes from

• The names. "SE" and "EE" imply two editions of one licensed product. They are not.
• The history. Oracle did once own Java EE. People who learned the landscape before 2017 carry an out-of-date mental model.
• Application-server bundling. Servers ship with a JDK, so teams assume the JDK is "part of" the server's licence. Sometimes it is, in a restricted way; usually it is not.
• Marketing language. Vendors talk about "enterprise Java" loosely, blurring the runtime and the specification.

What you actually pay for

Component	Owner	Licensing position
Java SE — Oracle JDK	Oracle	Conditional — BCL/NFTC free, OTN licensable
Java SE — OpenJDK builds	Community / vendors	Free
Jakarta EE specifications	Eclipse Foundation	Free, open source
Open-source Jakarta EE servers	Community / vendors	Free (paid support optional)
Oracle WebLogic Server	Oracle	Separately licensed Oracle product

Read down that table and the pattern is clear: the open enterprise specification costs nothing, while the two genuine Oracle cost centres are Oracle JDK (Java SE) and Oracle WebLogic. Focus your compliance attention there.

Common mistakes to avoid

• Budgeting for "Java EE licences". There is no such Oracle product to buy. Jakarta EE is free.
• Assuming WebLogic covers all your Java SE. Its bundled Java entitlement is restricted to running WebLogic itself.
• Ignoring the JDK under a free app server. The server being free does not make the Oracle JDK under it free.
• Confusing the namespace change with a licence change. javax to jakarta is a technical migration, not a licensing event.

The javax to jakarta namespace change

One technical consequence of the move to the Eclipse Foundation deserves a clear word, because it is often mistaken for a licensing event. When the enterprise specification became Jakarta EE, the long-standing javax.* package namespace was changed to jakarta.*. Application code and libraries that use newer Jakarta EE APIs must adopt the new namespace.

This is a code migration, not a licence change. It can require real engineering effort — updating imports, dependencies and sometimes third-party libraries — but it does not create or remove any Oracle licensing obligation. The namespace your code uses has no bearing on whether the Java SE runtime underneath it is an Oracle JDK or an OpenJDK build. Teams sometimes conflate "we need to do the jakarta migration" with "we have a licensing problem"; the two are entirely unrelated. Your Oracle exposure is determined by the JDK, not by the package names in your source.

It is, however, a sensible moment to review the runtime. An application already being touched for the namespace migration is an application that can just as easily be moved onto a free OpenJDK build at the same time — folding a licensing improvement into work that is happening anyway.

Frequently asked questions

Is there a Java EE licence I need to buy?

No. Java EE became Jakarta EE in 2017 and is now an open, free specification governed by the Eclipse Foundation. There is no Oracle Java EE product to license.

Does Oracle still own Java EE?

No. Oracle transferred the enterprise specification to the Eclipse Foundation, where it was renamed Jakarta EE. Oracle retained the Java trademark, which is why the name had to change.

If we run WebLogic, is our Java SE covered?

Only in a restricted way. WebLogic includes an entitlement to the Java SE needed to run WebLogic itself. It does not license Oracle JDK for your own separate applications.

Are Jakarta EE application servers free?

Most of the major ones are free and open source. But the server runs on a Java SE runtime — and if that runtime is an OTN-licensed Oracle JDK in production, the JDK still needs a licence.

Where does our real Oracle Java cost come from?

Almost always from Java SE — Oracle JDK running under licence terms that require a subscription — and, separately, from Oracle WebLogic where that product is in use.

Conclusion

The Java SE versus Java EE question matters because it tells you where to point your compliance budget. The enterprise specification — now Jakarta EE — is open and free, and no longer an Oracle product at all. The real Oracle exposure sits with Java SE, the runtime that everything else depends on, and with WebLogic where that product is in use. Map your estate against the table above, treat the Oracle JDK and WebLogic lines as the ones that carry cost, and you will stop spending energy — and money — on a "Java EE licence" that does not exist.