Java SE Commercial Features – Usage Rights

Java SE Commercial Features – Usage Rights

Not every Java feature was always free. For years, Oracle charged extra for certain advanced tools inside Java. These “commercial features” included powerful monitoring and diagnostic capabilities, such as Flight Recorder and Mission Control. Using them without a paid license was against the rules.

Today, most of those features are open and free – but if you’re running older Java versions, the legacy risks remain.

In this guide, we’ll explain which Java SE features used to require payment, how that changed with OpenJDK, and what still requires caution.

We also show you how to check your Java usage and stay compliant, especially if you manage enterprise Java applications.

Pro Tip: If you’re using a JDK older than version 11, assume the old commercial feature rules still apply to you.

Read our guide to more scenarios where Java may or may not require a license, Oracle Java Technical Scenarios & Edge Cases.

What Were Java’s “Commercial Features”?

In plain terms, commercial features were advanced Java tools that Oracle included in the JDK but made available only to paying customers.

They were bundled with the Oracle JDK download but disabled by default. Unless you had an Oracle Java SE subscription or license, you weren’t supposed to turn them on.

These features provided deep insight into the Java Virtual Machine (JVM) and application performance, making them very useful for troubleshooting and monitoring—but they came with a licensing catch.

Here are some common examples of Oracle’s commercial features from past Java releases:

• Java Flight Recorder (JFR): A low-overhead profiler that records JVM events and performance data. (Required a commercial license in Oracle JDK 8.)
• Java Mission Control (JMC): A graphical analysis tool to visualize JFR recordings and live JVM metrics. (Bundled with Oracle JDK, but license required to use beyond evaluation.)
• Advanced Management Console (AMC): A centralized management tool for tracking and controlling Java installations (mainly in enterprise desktop environments). This has always been part of Oracle’s paid Java SE Advanced suite.
• Application Class-Data Sharing (AppCDS): An extended class-sharing feature to improve startup by archiving application classes. (In early versions, this enhancement to Class Data Sharing was a commercial add-on.)
• Java Usage Tracker: A tool that logs how and where the JDK is used. (Ironically, meant to help admins track Java usage, but turning it on required a paid license.)
• JVM Resource Management: An API for fine-grained tracking of resource consumption (memory, CPU) by the JVM. (This was an experimental commercial feature in JDK 8 and JDK 9 that had to be unlocked with a special flag.)

These were all built into Oracle’s Java distributions. Your developers or admins might have seen them in documentation or even in the bin directory.

The crucial point is that using any of these in production without an Oracle Java license meant you were out of compliance. Even a one-time use (for example, recording a flight trace to troubleshoot an incident) technically breached the license terms if you didn’t have a Java SE Advanced license or subscription at that time.

Pro Tip: One tiny JVM flag in Java 8 (such as enabling Flight Recorder) could quietly put you out of compliance. A single use is enough to trigger licensing obligations.

What about Java in IoT and embedded systems? – Embedded Java Licensing for IoT & OEM.

How Licensing Worked Before Java 11

Under older Oracle JDK versions (Java 6, 7, 8, and even 9/10), the default license was the Oracle Binary Code License (BCL).

This allowed you to use the base JDK for free in production, but excluded the commercial features. Oracle’s rule was simple: if you unlock or use those premium features, you must pay for a commercial Java SE license.

In practice, Oracle JDK 8 and similar required a special JVM flag to activate commercial features: -XX:+UnlockCommercialFeatures. If you started your Java application with this flag (and the specific feature flag, like -XX:+FlightRecorder for JFR), the JVM would print a message to the console indicating “Commercial Features enabled”.

From that point, any use of the Flight Recorder or other locked feature meant you needed an Oracle Java SE Advanced license. Even if you didn’t explicitly set that flag, some tools might have enabled it behind the scenes. For example, connecting Oracle’s Mission Control GUI to a running JVM could toggle Flight Recorder on.

The big issue was that many organizations weren’t aware of this. It was easy to assume everything in the JDK was free. Some admins unknowingly ran these features in production to diagnose issues, not realizing they were triggering a paid feature. Oracle’s auditors, however, knew exactly what to look for.

During audits, they would ask for proof of any use of JFR, JMC, or the usage tracker. If their scripts or your logs showed that they were used, Oracle could demand back-dated license fees for Java SE Advanced.

Pro Tip: If Oracle JDK 8 logs show “commercial features enabled” even once, be prepared for Oracle to consider that a license violation.

Older versions of Java, Oracle Java Binary Code License (BCL) Explained.

OpenJDK and the Big Shift in Java 11

Java 11 was a turning point for Java’s licensing and features. With the release of JDK 11, Oracle made a dramatic change: most formerly commercial features were open-sourced and added to OpenJDK.

In other words, the free open-source builds of Java now include these tools without special licenses. Java Flight Recorder (JFR) and Java Mission Control (JMC) are no longer Oracle-only pay-to-use add-ons. They became available to everyone in the OpenJDK community builds.

From a functionality standpoint, OpenJDK 11 and Oracle JDK 11 are almost identical. You no longer need a secret flag to unlock JFR – it’s enabled by default (and usable under the normal open-source license).

Oracle even removed the -XX:+UnlockCommercialFeatures flag starting in Java 11, because there was nothing left to unlock. This effectively “reset” the playing field: if you moved to Java 11 using an OpenJDK distribution, you could use Flight Recorder, Mission Control, and other previously restricted tools freely.

The only differences that remained were in branding, support, and update availability (Oracle’s builds came with Oracle’s support and maybe longer patch timelines, while OpenJDK builds were community-supported or supported by other vendors).

The table below sums up a few major features and how their status changed before vs. after JDK 11:

As shown above, Java 11 eliminated the need for a license for the most popular features, such as JFR and JMC, by making them open source. Class Data Sharing (CDS), which had an “AppCDS” extension that required a license in Java 8, was fully open in Java 11 as well.

However, certain tools that are more standalone (like the Advanced Management Console) remain proprietary to Oracle’s distribution and still require a paid subscription.

Pro Tip: Java 11 was essentially a reset button for Java features. But you only benefit if you actually upgrade. Staying on older Java versions means the old rules (and risks) still apply.

What’s Still Restricted Today

By now (Java versions 11 through 21 and beyond), almost all the runtime diagnostic features that were once commercial have been open-sourced in OpenJDK.

If you use an OpenJDK-based distribution (from Oracle or any other provider), you can use Flight Recorder, Mission Control, advanced monitoring flags, etc., without worrying about a special license.

Oracle’s own JDK releases since 11 are functionally the same in this regard – they include JFR and such as freely usable features.

However, a couple of Oracle-specific tools remain restricted even today:

• Advanced Management Console (AMC): This is not included in OpenJDK. It’s an Oracle proprietary application for managing Java installations across an enterprise (for example, tracking which PCs have which Java versions, controlling security settings, etc.). Using AMC requires an Oracle Java SE Subscription.
• Java Usage Tracker: This feature, which logs usage data to support compliance, is available only in Oracle’s JDK. If you turn on usage tracking in Oracle JDK 8 or 11+, that action requires a commercial license. (In open-source JDK builds, this feature either doesn’t exist or isn’t supported.)

In short, if you stick to pure OpenJDK builds from providers like Eclipse Temurin, Amazon Corretto, Azul Zulu, etc., you won’t even have these proprietary components to worry about.

But if you use Oracle’s distribution and enable AMC or the usage tracker, you’ll need a valid Oracle subscription.

Always be aware of which JDK you are deploying – Oracle’s official binaries still come with licensing requirements for certain use cases (especially in production), even though the technical feature gap has closed.

Identifying Commercial Feature Usage in Your Environment

How can you tell if your organization has been using these commercial features (intentionally or accidentally)? It’s important to audit your Java environments to remediate compliance risks.

Use the following checklist to guide your review:

✅ Inventory your JDK installations: Identify all the Java installations in your servers and workstations. Note which ones are Oracle JDK vs. OpenJDK (or other distributions). This is critical, since Oracle JDK is the one that has hidden commercial features.

✅ Check Java versions: Pay special attention to any versions before Java 11. Java 8 is the most common older version still running in many enterprises – and it’s the one where commercial features were often used. Anything older than 11 warrants a closer look.

✅ Scan startup logs and console output: For Oracle JDK 8, when a commercial feature was enabled, the JVM typically logged a message like “Commercial Features have been enabled.” Search your application logs (or ask your ops teams) for any such messages. Also, look for mentions of Flight Recorder starting, Mission Control connections, or usage tracker logs being written.

✅ Verify if Flight Recorder or AMC are in use: Check your Java application launch scripts or JVM options for things like -XX:+FlightRecorder or -XX:+UnlockCommercialFeatures. Also, if your team uses Java Mission Control to monitor live systems, that could indicate Flight Recorder was activated. For AMC, check whether it’s installed and whether any team is using it to manage Java—if so, that’s a commercial feature in play.

✅ Standardize on a free Java build in the future: As a preventive measure, decide on a standard OpenJDK distribution for future deployments. For instance, you might choose Temurin (Adoptium) or Amazon Corretto for all new Java installs. This avoids the issue altogether because those builds don’t include the locked commercial add-ons.

Pro Tip: Commercial feature use can go unnoticed. Do a quick log audit for terms like “Flight Recorder” or “Commercial Features enabled” before Oracle’s auditors come asking for them.

Risk Areas in Older Environments

Organizations that have been running Java for many years should be especially cautious.

Here are some common trouble spots where commercial features slip in and create risk:

• Legacy Java 8 production servers: These often have had Java Flight Recorder turned on during a performance firefight. Months or years later, an audit could reveal that one-time use.
• Outdated monitoring scripts or DevOps tools: Some environments set up automated profiling or monitoring on Java 8 using Mission Control or JFR recordings. If those scripts were left in place, they might be reactivating commercial features with every deployment.
• Developer “trials” that bled into production: Perhaps a team tried out Java Mission Control or the Usage Tracker during development, and the config accidentally went to production. It might not leave obvious signs, but it could leave forensic evidence (such as usage log files or JFR recordings).
• Neglected desktops with Oracle JDK: An enterprise might have Oracle’s JDK installed on hundreds of developer or user desktops with the Advanced Management Console deployed to track them. If the Java SE subscription lapsed or was never obtained, that’s a compliance gap.

These scenarios often only come to light during an audit or a thorough internal review. The risk is that they represent unknown liability – you might owe Oracle for licenses retroactively if such usage is uncovered. It’s best to proactively eliminate or replace these risky configurations.

Migration Paths to Safe Usage

If you discover that you are using features that were once commercial (or you simply want to avoid any risk), there are clear steps to mitigate the risk.

Think of it as migrating to a safer, license-compliant Java footing:

1️⃣ Upgrade to OpenJDK 11 or later: The simplest fix is to move your applications to Java 11 or a newer LTS version (such as Java 17 or Java 21), using an OpenJDK-based distribution. By upgrading, you not only get performance and security improvements, but you also leave behind the era of locked commercial features. Newer Java versions include those features by default with no special flags needed.

2️⃣ Use trusted OpenJDK builds (with support if needed): You don’t have to compile OpenJDK yourself. Consider adopting a well-known distribution like Azul Zulu, Eclipse Temurin, Amazon Corretto, or Red Hat OpenJDK. These are free to use in production and offer the same capabilities. If you require support, companies like Azul, IBM, and Amazon offer support subscriptions for their builds – often at a lower cost and without feature restrictions.

3️⃣ Retire Oracle-specific tools: If you have been using the Advanced Management Console or Java Usage Tracker, plan to phase them out. For Java management across desktops, consider alternative approaches (e.g., third-party endpoint management tools) or simply keep Java up to date via standard deployment mechanisms. For usage tracking, you can replace it with internally developed scripts or third-party monitors that don’t require Oracle’s tool.

4️⃣ Update your automation and policies: Ensure your CI/CD pipelines, Docker images, and installation scripts are all standardized on the chosen OpenJDK distribution. Remove any hard dependency on “oraclejdk” images or downloads. Also, communicate a policy within your IT teams: no Oracle JDK in production unless there’s a very specific, approved reason. This prevents someone from accidentally introducing Oracle JDK (with its potential licensing traps) via an update or new deployment.

Pro Tip: Migrating to OpenJDK isn’t just a technical upgrade—it’s a compliance reset. It frees you from Oracle’s Java license worries in the future, as long as you stick with truly open versions.

When an Oracle License Still Makes Sense

Is there ever a reason to stay on Oracle’s paid JDK in this new landscape? For many organizations, the answer is “probably not,” especially if you’re only after the features (which are now available elsewhere for free).

However, there are a few scenarios where using Oracle’s Java and paying for a subscription might still align with your needs:

• Need for Oracle’s support and updates: Oracle offers 24/7 support and long-term updates for its JDK. If your enterprise requires direct support from Oracle and the guarantee of updates beyond the public free timelines, a subscription might be justified. Some companies value having Oracle on the hook for any Java issues.
• Advanced Management Console usage: If your company relies heavily on the Advanced Management Console to manage Java on thousands of desktops, you’ll need an Oracle subscription since no other vendor provides that exact tool. You would have to weigh the cost vs. the benefit of that centralized management.
• Certifications or third-party requirements: A few specialized software vendors or scenarios might “certify” only Oracle JDK for their product. If running that product forces you to use Oracle’s Java, you might opt to license it rather than risk running an unsupported configuration.

If none of the above apply, then sticking with Oracle’s JDK means paying for something you don’t actually need. The open-source alternatives have become drop-in replacements. Many organizations save costs by switching and only keeping Oracle licenses for the systems where they’re necessary.

Final Take

Oracle’s commercial features used to be a stealthy way to monetize Java usage.

They were built into the JDK, waiting for you to flip a switch – and if you did, Oracle could send a bill. Since Java 11, that model has largely been dismantled. Most of those once-paywalled features are now part of the free OpenJDK, available to everyone. This is great news for developers and architects because it removes barriers to using powerful tools like Flight Recorder.

However, legacy versions and habits can still bite you. If your environment is running older Oracle JDKs, you must stay vigilant. Audit your systems for any use of the old commercial flags or tools. Make it a priority to upgrade or migrate away from configurations that put you at risk. The cost of complacency could be an unexpected audit finding and a costly true-up.

In summary: keep your Java usage clean and modern. Standardize on OpenJDK or other free distributions, especially for production. Educate your teams on which Java features used to require a license, so they understand why you’re making these changes.

And if you ever see the word “commercial” pop up in any Java setting or documentation for your environment, treat it as a red flag to investigate. By doing so, you’ll ensure that you leverage all of Java’s powerful capabilities with peace of mind about license compliance.

Read about our Java Advisory Services.

Do you want to know more about our Java Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit