Oracle Java Licensing FAQ

Oracle Java Licensing FAQ

Oracle Java Licensing Basics and History

1. Isn’t Java free to use? Why do we need to worry about Oracle Java licensing now?

Historically, Java (from Sun Microsystems and later Oracle) was free to download and use even for commercial purposes. Before 2019, Oracle’s Java was provided under the Binary Code License (BCL), allowing Java to run on desktops and servers without charge.

However, Oracle changed its Java licensing model in 2019, requiring paid subscriptions for many commercial uses of Java. In short, Java is free if you use an open-source distribution (OpenJDK) or use Oracle’s Java only in certain ways (personal use or development/testing).

However, after 2019, a paid license or subscription is typically required for business use of Oracle’s Java SE​. This shift has made Java licensing a critical issue for companies to manage, whereas it was previously considered “free.”

2. What does “on-premise Java usage” mean in licensing terms?

“On-premise” Java usage refers to running Java on your organization’s computers, such as desktop PCs, laptops, and servers in your data center (or in VMs you control). Our discussion focuses on licensing for those environments. We exclude cloud-provider scenarios (for example, Java running in Oracle Cloud or other SaaS/PaaS where licensing might be included or handled differently).

If you install Oracle Java on a cloud VM (IaaS) that you manage, it’s essentially like on-prem from a licensing perspective – you are responsible for licensing it.

So, on-premise Java usage means any Java running under your control (outside of an Oracle-managed cloud service), where Oracle’s standard Java SE licensing and audits apply.

3. How was Oracle Java licensed before 2019?

Before 2019, Oracle Java was provided mostly under the Oracle Binary Code License (BCL). Under the BCL, you can run applications using the Java runtime and development kit on general-purpose computers​. There was no cost for these uses, and Oracle regularly provided free public Java updates and security patches.

Java SE (Standard Edition) was free for users and enterprises to deploy, except for a few optional advanced features (which required separate licensing – we’ll cover those next).

Many businesses simply downloaded the Java Runtime (JRE) or JDK from Oracle’s site and used it without any payments, as this was compliant with the BCL terms.

4. What is the Oracle Binary Code License (BCL) for Java SE?

The BCL was the license that governed Oracle’s Java SE 8 (and earlier versions) before the changes in 2019. It granted a free, limited right to use Oracle’s Java to run desktop and server applications​. Under BCL, you could internally use the complete Java software (JDK/JRE) without modification and without paying fees, solely for running programs written in Java​.

Important: The BCL excluded certain features and uses. For instance, using “Commercial Features” of Java under BCL was prohibited without a separate license. Also, the redistribution of Java (bundling it with your software for others) had some restrictions.

However, the BCL allowed free use for typical internal business applications. Oracle continued using BCL until Java versions were released on April 16, 2019; after that, Oracle stopped using the BCL for new Java releases​.

5. Was Java truly free for commercial use under the BCL?

Yes – for running standard Java applications, it was free, but with a notable caveat: certain advanced features were considered “commercial.” Under BCL, regular Java usage was free, but you needed a paid license if you used the extra tools tagged as Commercial Features (like Java Flight Recorder or Mission Control).

For example, running a Java-based web application on Java SE 8 did not incur fees. However, if your administrators enabled Flight Recorder (an in-JVM profiling tool) on that Java 8 server to troubleshoot performance, that would violate the BCL unless you had purchased Oracle’s Java SE Advanced license.

In summary, Java was free to use, but premium features within Java required payment. Before 2019, many companies didn’t need any Java license unless they wanted those advanced monitoring/management features.

6. What are Java SE “Commercial Features” and why do they matter for licensing?

Oracle designated some advanced Java features as Commercial Features in Java SE 8 (and 7), including tools like Java Flight Recorder, Java Mission Control, and Advanced Management Console.

They were bundled in the Oracle JDK, but the BCL license prohibited their use in production without a license​. This was Oracle’s early way of monetizing Java for enterprises that needed those capabilities.

For example, Java Flight Recorder allows recording JVM diagnostics data; under Java 8 BCL, you could not simply use it freely on a production server – you were supposed to obtain Java SE Advanced or Java SE Suite (paid licenses) to legally use that feature.

These Commercial Features matter because, during audits, Oracle’s team might check if any of these features were enabled. If they find evidence (log files, configurations) that Mission Control was used to monitor a production JVM, that could be flagged as unlicensed usage if you hadn’t purchased the proper Java SE Advanced license.

7. Did Oracle offer paid Java licenses or support before 2019?

Yes. Even though Java SE was free under BCL for general use, Oracle offered paid options for those who needed extra support or features.

The two main offerings were:

• Java SE Advanced and Java SE Suite: These were perpetual licenses (one-time purchase, with optional annual support) that gave you rights to use the Commercial Features and additional management tools. They also came with support and updates. These were typically used by enterprises that needed Java Flight Recorder, Mission Control, or usage in embedded systems.
• Java SE Support: Oracle provided an option for companies to pay for support on Java SE if they wanted security updates for older versions beyond the public update period. For instance, after public updates for Java 6 or 7 ended, a company could purchase an Oracle support contract to continue getting patches.
  In summary, before 2019, you could pay Oracle in certain situations, but it was optional. Most companies didn’t buy Java SE Advanced unless they specifically needed those advanced features. Most just used the free Java and got updates from Oracle’s public releases.

8. Can we still use older Java versions (like Java 8) without paying Oracle?

Suppose you downloaded an older Oracle Java version (Java 8 or earlier) under the old license. In that case, you can continue to use it under the terms you originally accepted​.

Oracle’s FAQ states that you may continue using legacy releases under their original license (e.g., BCL)​.

However, there are two big issues:

1. Security & Updates: Oracle stopped providing free public updates for Java 8 after January 2019​. If you keep using Java 8 indefinitely without paying, you won’t get any security patches (unless you find them from another source). Running outdated Java can be risky.
2. New Deployments: The free use under BCL covers what you downloaded. Suppose you try to update to a newer patch of Java 8 (released after January 2019) or install Java 11 or beyond from Oracle. In that case, those come under new licenses requiring payment (for commercial use).
   Example: A bank still running Java 8 update 201 (released in 2018 under BCL) on its servers can technically keep using that specific version for free. But it’s now several years old and has known vulnerabilities. Upgrading to Java 8 update 333 (released in 2022) would require a Java SE Subscription (since that update came out after public freebies ended). Oracle recommends staying up-to-date, which means paying for a subscription or moving to an alternate Java source if you want to use old versions safely.

9. What happened to Java 8 public updates after January 2019?

Oracle ceased free public updates for Java SE 8 for commercial use in January 2019​. Until then, Oracle had been releasing Java 8 patches publicly (anyone could download them).

After January 2019:

• Only individuals or development/testing users got free access to Java 8 updates (via Oracle’s OTN license, which we’ll discuss next).
• Without a subscription, businesses could no longer legally update Java 8 from Oracle’s site for production use. Oracle shifted Java 8 into a paid support model for commercial users.
  This was a crucial change. Many enterprises were caught off guard, as Java 8 was widely deployed under the assumption of free updates. Suddenly, if they wanted the April 2019 critical patch update for Java 8, they had to purchase a subscription or find an alternative source. Essentially, the “free Java 8 era” ended in January 2019 for companies. Oracle did continue offering Java 8 updates to customers who paid (and it will support Java 8 commercially through at least 2030 with those contracts​), but not to the general public.

10. What licensing changes did Oracle announce in 2018 for Java?

In 2018 (specifically around June 2018), Oracle announced it was moving Java SE to a subscription model​. This was the first major sign of change.

Key points of that announcement:

• Oracle introduced Java SE subscriptions for commercial users, meaning you’ll pay monthly for Java licensing and support instead of relying on free public updates.
• The subscription was to cover Java SE 8 updates beyond 2019 and Java 11 (and later) releases.
• Oracle defined pricing under familiar metrics: on servers, per-processor licensing (counting CPU cores with Oracle’s standard core factor rules), and on desktops, per Named User Plus (NUP)​. This was analogous to how Oracle licensed other software, like databases.
• This marked a pivot from the old model (free binaries, optional support) to a model where using Oracle Java in production long-term implied a recurring cost.
  The announcement was effectively: “If you are a business deploying Java SE in production, you will need to buy a Java SE Subscription to get updates and stay compliant going forward.” This set the stage for the changes that took full effect in January 2019 (when free updates stopped).

11. What is the Oracle Technology Network (OTN) License for Java SE introduced in 2019?

The OTN License Agreement for Java SE was introduced in April 2019, replacing the old BCL for new Java downloads​.

Under the OTN license, Oracle continued to let people download the JDK for free, but with significant restrictions on usage:

• It allowed free use for certain purposes, such as personal use and development, testing, prototyping, or demonstration​.
• Any commercial or production use of the Oracle JDK under this license was not free – it required a Java SE Subscription (or another paid license)​.
  In other words, after April 16, 2019, if you go to Oracle’s website and download (for example) Java 11 or Java 8 updates, you’re clicking through the OTN License. That license says: “You can use this JDK for free to play around, develop, or for personal (non-business) apps. But if you use it to run your business applications in production, you must pay.” This was a pivotal shift. It drove many organizations either to buy subscriptions or to switch to non-Oracle OpenJDK distributions, especially once they realized continuing to use Oracle’s JDK without paying would put them out of compliance.

12. Which uses of Oracle Java are free under the OTN license?

Under the OTN License (applicable to Oracle Java downloads from 2019 through 2021 for Java 8, 11, etc.), Oracle explicitly enumerated the free-of-charge use cases.

They include​:

1. Personal use – e.g., an individual running Java on their PC for non-business purposes (playing games, personal applications).
2. Developers can code and test with Oracle JDK, testing, prototyping, and demonstration, and companies can even use it in a test lab or demo environment without a fee.
3. Certain Oracle products use—The license made an exception if Java SE was being used with specific Oracle products (Schedule A/B in the license), such as Oracle’s software (for example, if you use Oracle SQL Developer, you can use the Java it requires without a separate license).
4. Certain cloud uses with Oracle Cloud Infrastructure products were also listed as free in the OTN license.
   Anything outside these scenarios requires a subscription. So, running Java on an internal business application server is not free under OTN. Running Java on your laptop to write Java programs is free. This clarified that Oracle still supported free usage for developers and individuals, but enterprises deploying Java in production had to start budgeting for Java.

13. We only use the Java Runtime Environment (JRE) and not the full JDK. Do we still need to pay for Oracle Java?

Yes, the license requirements apply equally to the Oracle JRE. Historically, Oracle offered the JRE as a separate download (especially for Java 8), but it was covered under the same license terms as the JDK.

There’s no licensing distinction between the JRE and JDK – if you use Oracle’s Java runtime in production, it counts as Oracle Java usage that might require a license​. In fact, from Java 9 onward, Oracle stopped providing a standalone public JRE installer; they distribute only the JDK (which includes the runtime)​.

So for newer versions, the question is moot – you’re using the JDK anyway. For Java 8, if you deployed the Oracle JRE 8 on users’ machines or servers, after January 2019, it became subject to the same subscription requirement as the JDK.

Example: A company has a legacy application that requires Java 8, and to run it, they installed the Oracle JRE 8 (not the full JDK) on 200 client PCs.

Even though it’s “just the JRE,” after the free update cutoff, those installations would technically need to be covered by a Java SE Desktop Subscription (the same as if they had the JDK installed). The JRE being a subset doesn’t exempt it from licensing rules.

Oracle Java SE Subscription (2019–2022 Model)

14. What is the Java SE Subscription model (2019–2022)?

Oracle’s Java SE Subscription (launched in 2018/2019) was a pay-as-you-go licensing model for Java SE. Instead of a one-time perpetual license, you paid a monthly fee per usage metric.

By subscribing, a company obtained:

• The right to use Oracle Java in production (beyond just personal/dev use).
• Access to regular updates and security patches for Java from Oracle (which were no longer publicly free for older versions).
• Access to Oracle’s support for Java (ability to file support tickets, etc.).
  This model applied to Java SE 8 (for updates post-Jan 2019) and all new releases up to Java 17 (until Oracle changed the model again in 2023). The Java SE Subscription was Oracle’s way to monetize Java by essentially selling Java as a service (continuous updates/support) rather than as a product. Organizations using Oracle JDK in production during 2019–2022 generally needed these subscriptions unless they had a prior license or chose an alternative distribution.

15. How was the Java SE Subscription licensed for desktops and servers?

Under the 2019–2022 subscription model, Oracle used two metrics:

• Java SE Desktop Subscription – licensed per Named User Plus (NUP), essentially per named end-user or employee using Java on a desktop. In practice, one NUP license was required per person or per device (whichever is lower – Oracle usually required a user license for each desktop with Java, with a minimum of 1 per device. The price was $2.50 per user per month​.
• Java SE Subscription for Servers – licensed per Processor on the servers where Java is installed. This followed Oracle’s standard definition of a processor: counting physical cores and applying a core factor (for example, Intel x86 cores have a 0.5 factor). The list price was $25 per processor per month​. Oracle required you to license all processors on a machine where Java was used (even if a particular JVM only used part of the machine).

So, if you had Java on 100 desktops, you’d pay 100 × $2.50 = $250 per month. If you had Java on a server with 4 CPUs (after core factor), that’s 4 × $25 = $100 per month. Both Desktop and Server subscriptions include support and patches.

16. How did Oracle define a “processor” for Java licensing?

Oracle’s definition of “processor” in the Java SE Subscription was consistent with how they license databases and other software:

• A processor is a hardware CPU core with a multiplier based on the CPU type. Oracle provided a core factor table (common Intel/AMD x64 cores count as 0.5, most SPARC as 0.5, etc.). So, two physical cores = 1 processor license if the factor is 0.5​.
• Thus, multi-core processors require multiple licenses. For example, a single 8-core Intel CPU = 8 × 0.5 = 4 processors (4×$25/month for Java).
• Virtual environments: If Java ran in a VM, Oracle’s rules typically required counting the assigned vCPUs or the underlying physical cores (depending on whether partitioning is soft or hard). Generally, they would not let you escape licensing by saying a VM only uses two cores if the host has more, unless you used approved hard partitioning. This is deep in Oracle’s policies, but SAM professionals usually apply the same logic as Oracle database licensing.
  Essentially, a “processor” for Java licensing was the same concept as any Oracle software: a metric for computing power. Oracle provided guidelines so you could calculate how many processor licenses your particular server needs. For simplicity, on Intel-based servers, count the cores and halve them (round up if needed). That’s how many Java processor subscriptions you’d need.

17. Did the Java SE Subscription include support and updates?

Yes. The subscription model was all-inclusive for the subscription term. By paying the monthly fee, you get:

• License to use the Oracle JDK/JRE in production (covering the machines/users you paid for).
• Java SE will receive security updates, bug fixes, and new patch releases during the subscription period (downloadable from Oracle’s support portal).
• Oracle Premier Support for Java, meaning you could open support tickets, get help for issues, etc.
  This changed from the old perpetual license days, where you’d buy a license and pay annual support separately. With a subscription, it’s bundled. However, it’s important to note that if you stop subscribing, those benefits and rights to use Oracle Java end (more on that next). So, it’s like renting Java with maintenance included. Many saw the inclusion of support as a benefit because you were always entitled to the latest updates without worrying about separate support contracts.

18. What if a company decided not to renew its Java SE Subscription?

If a Java SE Subscription lapses (you choose not to renew it after, say, your one-year term), your rights to use Oracle Java commercially and access to updates​end. This is a critical point: a subscription is not a perpetual license.

Oracle’s policy is that after termination, you should remove or stop using any Oracle Java software covered under that subscription (because your license to run those binaries was tied to the active subscription).

Oracle explicitly “recommends transitioning… to OpenJDK binaries” if you don’t plan to renew​. In practice, if a company lets a subscription expire, they won’t suddenly be sued as long as they discontinue use of Oracle Java. But if they continue to use it and just stop paying, they would be non-compliant.
Example: A small business had 50 Java SE Desktop subscriptions for a year but decides not to renew in 2025. At the end of the subscription, they should uninstall Oracle JDK from those PCs or replace it with OpenJDK builds. If an Oracle audit later finds they kept using Oracle Java in 2026 without a subscription, the company would likely have to pay for the gap.

19. Can existing Oracle Java licenses from before 2019 (like Java SE Advanced) still be used?

Yes. If an organization previously purchased Java SE Advanced, Java SE Suite, or other Oracle Java licenses under the old model, those licenses remain valid according to their terms. Typically:

• Java SE Advanced (for example) was a perpetual license that allowed use of Java SE 8 along with commercial features on a certain number of processors, plus support if you paid maintenance. If you acquired that, you can continue to use Java under that license instead of subscribing, as long as you stay within the scope (e.g., number of CPUs) you purchased.
• Many such customers continue to pay Oracle annual support to get updates, which Oracle continues to provide via My Oracle Support for customers with existing licenses​.
  However, Oracle stopped selling those old licenses once the subscription model emerged. They transitioned to selling subscriptions. So you generally can’t buy a new “Java SE Advanced” perpetual license now. But if you have one from the past, Oracle will honor it (and usually try to upsell you to the new model at renewal time). Always check the specific terms of your contract; some older Java licenses had use limitations (for example, tied to Java 8 only).

20. What is the Oracle No-Fee Terms and Conditions (NFTC) license introduced for Java 17?

In September 2021, alongside Java 17 (a Long-Term Support release), Oracle introduced a new twist: the Oracle No-Fee Terms and Conditions (NFTC) license​.

This license made Oracle’s JDK free for all users, including commercial, but only for a certain period or version range.

The idea was:

• The current LTS release (Java 17) is free to use in production without paying. This was Oracle’s response to feedback that many wanted a “free Oracle JDK.” So Oracle said, effectively, “Okay, you can use Oracle JDK 17 for free.”
• However, the free period is not indefinite—Oracle committed to providing updates for Java 17 under NFTC until one year after the next LTS release. Since the next LTS after 17 was Java 21 (released in September 2023), Oracle provided free JDK 17 updates up to September 2024​. After that, Oracle JDK 17 updates would no longer be free for commercial use.
  So NFTC is a kind of rolling license: as new LTS versions come out, the newest version is free for a period. Oracle JDK 17 and later (21, etc.) fall under NFTC when they are the latest. This allowed companies to use Oracle JDK without immediate cost and perhaps encourage upgrades. Important: older versions (Java 8, 11) did not become free under NFTC – this only applied moving forward from 17. It also has no support entitlement. NFTC gives free use and updates, but you need a subscription if you want support or stay on an older LTS beyond the free update period.

21. Does Oracle JDK 17 (or later) not require a subscription?

Oracle JDK 17 was free to download and use (even in production) during the NFTC period. From 2021 through September 2024, any organization could use Oracle’s JDK 17 builds and apply all the updates Oracle released without paying license fees.

This was a big change from JDK 11, which required an update subscription. However, this “free” status has conditions:

• Oracle JDK 17’s free updates ended one year after JDK 21 came out, i.e., after September 2024. Beyond that, if you wanted more Java 17 updates from Oracle, you’d need to become a customer (or switch to an OpenJDK provider for continued Java 17 support).
• During that free period, if you wanted support from Oracle (e.g., the ability to file support tickets), you wouldn’t have it unless you paid. NFTC is a no-cost license, but support is not included.
  In essence, Oracle JDK 17 was a free ride, but with an exit ramp: you’d eventually have to upgrade to Java 21 or start paying if you stayed on 17. As of 2023, Oracle JDK 21 is similarly free under NFTC (likely until a year after the next LTS). This approach encourages users to regularly move to newer Java versions to stay free.

Oracle Java SE Universal Subscription (2023–Present)

22. What changed in Oracle’s Java licensing in January 2023?

In January 2023, Oracle made a major change by introducing the Java SE Universal Subscription with a new metric: per-employee licensing​. They retired the old model of counting users or processors.

The key changes:

• All Java SE subscriptions were moved to an employee-count basis. If a business wants Java SE now, it must buy licenses equivalent to its total number of employees.
• Oracle combined the desktop and server subscriptions into one product (hence “Universal”). One subscription covers use on desktops, servers, or even third-party clouds without separate licenses​.
• This went into effect for new customers on January 23, 2023. Oracle allowed existing subscription customers to renew under the old metrics for a limited time, but the direction is firmly towards the employee metric.

So, after 2023, instead of thinking “I have X desktops and Y server cores to license,” it became “I have Z employees; I need to buy Java licenses for all Z of them.” This was a fundamental shift in how Java licensing works, effectively transforming it into an enterprise-wide agreement rather than counting installations.

23. What is the Oracle Java SE Universal Subscription (2023)?

Java SE Universal Subscription is Oracle’s current licensing offering for Java SE. It’s “universal” because one subscription type covers all platforms (client, server, cloud) and all usage, and it uses an Employee-based metric for pricing​.

In practical terms:

• A company signs up for Java SE Universal Subscription for a certain number of employees (which must equal at least the total number of employees in the company).
• By doing so, the company gets the rights to unlimited use of Oracle Java on any number of devices, VMs, or servers across the organization, as needed.
• The subscription includes access to all Oracle Java updates and support, just like the old subscription did, but now you don’t worry about specific machine counts—it’s site-wide coverage.
  Think of it as an “enterprise license” for Java – pay one fee based on size, use as much Java as you want. It simplifies compliance (no need to track individual installs for licensing purposes), at the cost of potentially over-licensing small users. The Universal Subscription also covers new Java versions as they come (Oracle would allow you to use Java 8, 11, 17, 21, etc., all under the same subscription).

24. How does the employee-based Java licensing model work?

Instead of counting Java installations or users, Oracle now counts “Employees.” Oracle’s definition of Employee for this license is broad: it includes all full-time, part-time, temporary employees, and the employees of your contractors or outsourcers who support your business​. In essence, if a person works for or on behalf of your company in any capacity and uses IT resources, they count.

Key points:

• You must license all such employees. The minimum number of licenses you purchase = total employee count (not just those using Java)​.
• The count is generally a one-time snapshot at the start of the subscription term (but you are expected not to undercount deliberately). If your employee count grows, you’d typically true it up at renewal.
• Contractors and consultants: Oracle also expects you to include them in the count if they work on your systems.
• There is an upper bound condition: if you somehow deploy Oracle Java on more than 50,000 processors (that’s an enormous deployment), Oracle requires a custom license—but in employee terms, that would correspond to a very large organization anyway​.
  So, practically, a company with 5,000 employees needs 5,000 Java licenses, even if maybe only 100 developers install the JDK. Oracle gives you unlimited Java usage, and in exchange, they take a fee for every employee as a proxy for company size.

25. How much does Oracle’s Java SE Universal Subscription cost?

The cost is $15 per employee per month at list price for small organizations (up to 999 employees)​. Oracle has a tiered volume discount model for larger employee counts:

• 1 – 999 employees: $15 per employee/month (list price).
• 1,000 – 2,999: $12 per employee/month​.
• 3,000 – 9,999: $10.50 per employee/month​.
• 10,000 – 19,999: $8.25 per employee/month​.
• 20,000 – 29,999: $6.75 per employee/month.
• 30,000 – 39,999: $5.70 per employee/month​.
• 40,000 – 49,999: $5.25 per employee/month​.
• (For 50,000+ employees or larger deployments, Oracle presumably negotiates custom pricing since 50k at $5.25 is already $262,500/month.)

These are list prices; Oracle may offer discounts based on negotiations or bundling. But at least: a company with 500 employees would pay 500×$15 = $7,500 per month (=$90k/year)​. A huge enterprise with 40k employees would pay roughly $210,000 monthly (>$2.5 million annually)​. This can be a significant cost for large organizations, so many started re-evaluating their Java usage.

26. Why did Oracle change Java licensing to an employee-based model?

Oracle’s stated reasons revolve around simplifying license management and providing flexibility. By having a single metric that covers desktops, servers, and the cloud, customers no longer have to track where Java is deployed​. This provides “universal” coverage, which Oracle pitches as convenient.

From a business perspective, this model also ensures Oracle captures the full size of the customer. In the old model, a clever customer could minimize licenses (e.g., only install Oracle JDK where needed and use OpenJDK elsewhere, or count just a subset of users).

With the employee model, Oracle effectively charges for your potential Java usage based on company size, not actual usage. This tends to increase Oracle’s revenue from Java in many cases (especially if only part of the organization previously used Oracle Java)​. It also aligns with how other enterprise software (like certain Microsoft licenses) covers entire organizations.

Oracle likely also wanted to reduce compliance work—it’s easier to verify employee counts (they can look at your annual report or ask HR for numbers) than to audit every server.

So, the change benefits Oracle with higher and more predictable revenue while pitching customers that it’s a simpler, all-you-can-eat deal (no need to count devices internally).

27. What are the differences between the legacy Java SE Subscription and the new Java SE Universal Subscription?

The main differences are summarized in the table below:

Aspect	Legacy Java SE Subscription (2019–2022)	Java SE Universal Subscription (2023–Present)
Licensing Metric	Per Named User (desktop) or per Processor (server)​. You had separate counts for each.	Per Employee of the organization​. One metric covers all usage (no device counting).
Scope of Use	Different SKUs for desktop vs server. Only covered specific machines/users you licensed.	Universal coverage – includes desktops, servers, third-party cloud deployments under one subscription​.
Coverage Model	Limited: you had to license each deployment (each PC or server core running Java). Unlicensed installations were not allowed.	Enterprise-wide: license every employee, then you can install Java anywhere in your org without additional fees. Essentially unlimited Java use once employee count is covered.
Cost Structure	~$2.50 per user/month (desktop); ~$25 per processor/month (server)​. Cost scaled with number of installations/cores in use.	$15 per employee/month for <1000 employees, with volume discounts for larger orgs (e.g., $5.25 at ~50k employees)​. Cost scales with total employee count, not actual Java usage.
Compliance Tracking	Needed software inventory tracking – ensure you don’t exceed the number of licensed users or install on unlicensed servers.	Simpler tracking – just need an accurate employee count. No need to track installations for licensing (still track for security/audit, but not for Oracle compliance purposes)​.
Typical Cost Impact	Could be economical if you had limited Java usage (e.g., a few servers). Large deployments could get expensive per core.	Often higher cost for companies with many employees but moderate Java use. It shifts cost up for large orgs that only used Java sparingly​, but could be cost-neutral or even lower for very Java-heavy orgs that already had to license many processors.

28. Could the new employee-based model increase Java licensing costs?

Yes, and in fact, many organizations have reported that it dramatically increases their costs. The impact depends on the ratio of your employee count to your actual Java usage:

• If you are a large company with relatively few Java applications, you must pay for every employee regardless. This can result in paying tens of times more than before. There are anecdotes of cost increases ranging from 2× up to 10× or more due to this change​.
• Suppose you were a company with extensive Java deployment on many servers. In that case, the cost might be comparable or even, in rare cases, less (for example, an org with nearly all employees using Java might have already been paying quite a lot under per-user licensing). But such cases are less common.

For example, consider a company with 10,000 employees that, under the old model, had Java on 50 servers (maybe 200 cores, which would be 100 processors after the core factor). Under legacy pricing, 100 processors × $25 = $2,500/month.

Under the new model, 10,000 employees × ~$8.25 = $82,500/month​.

That is a massive increase (33x more in that scenario). On the other hand, a small company with 50 employees and say 40 of them using Java might find the costs somewhat similar (50×$15 = $750/month, versus maybe 40 users × $2.50 = $100 and a few server cores $200 – so actually even there new model is higher).

The new model is costlier in most scenarios unless nearly every employee is already a Java user. Organizations are rightly concerned and looking at ways to mitigate this.

29. Can we renew our Java SE Subscriptions instead of switching to the new model?

Oracle allowed existing customers with the legacy Java SE subscription to renew under the old terms for a limited time, but this is not guaranteed in the long run.

According to Oracle’s FAQ, customers can renew their existing subscription (per user/processor) “to the extent permitted in their existing order. ” For example, if you have 100 NUP and 10 Processor licenses, you might be allowed to renew that same quantity​.

However, Oracle clarified that the Java SE Universal Subscription replaced the legacy subscriptions as of January 2023​.

In practice:

• If your renewal comes up and your usage hasn’t grown, Oracle might extend the old agreement once, but they are likely to push you toward the new model either at that renewal or the next.
• Oracle sales reps may use incentives or pressure to get you onto the new model (e.g., offering a slight discount on the employee metric if you switch now, or warning that legacy options will eventually end).
  So, while you might get a short-term extension on the old licensing, plan for the eventual transition. Many licensing advisors suggest Oracle will phase out the old subscriptions entirely, forcing everyone onto the employee metric shortly.

30. What if we only use Java on a few servers? Do we still need to license every employee?

According to Oracle’s new rules, if you use Oracle Java in production, you must license the entire employee count. There is no official “small deployment exemption” in the employee-based model.

This all-or-nothing aspect is one reason the new model is controversial. Even if only 5% of your employees use an application that runs on Oracle JDK, Oracle still counts 100% of your employees for licensing.

Oracle’s only alternative path is to stop using Oracle Java and use something else (OpenJDK, etc.) for those few servers, so you need not buy a subscription.

Example: A manufacturing company has 1,000 employees but only uses a Java program on a single server for their machine control system. Under the new policy, one Java server would obligate them to purchase 1,000 employee licenses (1,000 × $12 = $12,000/month at list).

This feels disproportionate, and such a company might look very hard at migrating that one application off Oracle Java to avoid the fee. Oracle’s stance is essentially: if you use it, you use it—there’s only one subscription option, so cover everyone.

31. Does the employee-based license cover unlimited Java use?

Yes. Once you have an active Java SE Universal Subscription for your full employee count, it covers unlimited installations and usage of Oracle Java within your organization. You no longer need to count devices or limit where you deploy Java for cost reasons.

Whether you install Java on 10 or 10,000 machines, the cost is the same (assuming your employee count stays the same). This is why we call it an “all-you-can-eat” model. Oracle’s documentation highlights that it greatly simplifies tracking since the deployment model (desktop, server, cloud, containers, etc.) doesn’t affect pricing​.

The only theoretical limit mentioned is if your usage exceeds 50k processors, but even then, it’s about arranging a custom license, not a hard stop. For practically all customers, it’s unlimited usage.

This can benefit companies with large deployments – you don’t worry about adding another server or user, because you’re already covered.

Remember, if your employee count increases significantly, you must true-up those licenses at renewal time (since you must always license to the current employee count).

Oracle Java Audits and Compliance

32. What triggers an Oracle Java audit?

Oracle can initiate a Java audit (either an informal review or a formal audit) for several reasons:

• Lapsed or reduced subscriptions: If a customer cancels their Java subscription or significantly decreases the quantity (e.g., not renewing all licenses), Oracle may suspect they didn’t actually stop using Java and thus initiate an audit.
• No Java spend in a Java-heavy industry: If you are a large organization with no record of Java subscription purchases, Oracle knows you likely use Java somewhere (Java is widespread). This discrepancy can trigger Oracle to “educate” you on compliance.
• Download activity: Oracle keeps logs of who downloads Java from its website. Oracle reps have pointed out how often Java was downloaded and then correlated that with zero license purchases​. If your company domain appears frequently in Oracle’s download logs, this can prompt an audit.
• Previous non-compliance issues: If you’ve been audited for something else (like Database or Middleware) and Oracle found compliance problems, you might also be on their radar for a Java audit.
• Whistleblowers or Oracle sales push: Sometimes, internal whistleblowers might report unlicensed use. More commonly, Oracle sales teams looking to meet quotas might push for a license review.

In summary, common triggers include changes in Java subscription status, evidence of usage without purchase, or simply being a large enterprise that Oracle suspects hasn’t “true-up” their Java licensing.

With the 2023 changes, some expect Oracle to increase audit activity because the potential compliance revenue is much higher (every unlicensed Java deployment could lead to an enterprise-wide license sale).

33. How does Oracle conduct a Java license audit?

Oracle’s License Management Services (LMS) group handles formal audits. The typical formal audit process is:

1. Audit Notification: Your organization receives an official audit notice letter, usually from Oracle’s LMS, stating that it is exercising its contractual right to audit​. This letter outlines that Oracle will review Java usage and asks for cooperation.
2. Kick-off Meeting: Oracle schedules a meeting to explain the scope, timeline, and data they need​. They will discuss what tools or scripts to use for data collection and set deadlines.
3. Data Collection: Oracle will provide scripts or ask you to run certain discovery tools. For Java audits, Oracle may use scripts that scan for installed Java versions on systems or accept data from third-party SAM tools​. They often want information like installation paths, versions, the last update applied, and whether any commercial features are enabled. You may need to run these on all servers and PCs in scope.
4. Data Submission: You deliver the collected data (often in Excel sheets or outputs from tools) to Oracle’s auditors.
5. Analysis: Oracle LMS analyzes the data and compares it to your entitlements (what licenses or subscriptions you have)​. They identify gaps, e.g., Java installations that are not covered by a subscription.
6. Preliminary Findings: Oracle shares initial findings. There may be some back-and-forth if you spot inaccuracies or have additional information.
7. Report and Resolution: Oracle issues a formal audit report outlining compliance issues and the licenses required to resolve them​. Then, you enter a resolution phase (which might involve negotiating to purchase licenses or subscriptions to settle the findings).
   A formal audit is a legal process. It’s typically outlined in your Oracle agreements that they can do this, and there will be an official NDA and communications. It’s important to cooperate within reason and verify Oracle’s data and conclusions.

34. What is an Oracle Java “soft audit”?

A “soft audit” is an unofficial or informal audit, often initiated by Oracle’s sales teams or account managers, not the LMS audit team. Oracle refers to these as license reviews or compliance checks.

Characteristics of a soft audit:

• It usually starts with a friendly email or call from an Oracle rep asking about your Java usage. They won’t call it an audit; they might say, “We’d like to understand your Java deployments to ensure you’re correctly licensed.”
• Oracle may request you complete a questionnaire or provide an inventory of Java installations. They might ask which versions you run and if you have subscriptions​.
• It’s less formal – no official notice letter. It might even be positioned as a benefit (“Let’s make sure you’re getting the most out of your Java and are in compliance.”).

Soft audits are often fishing expeditions. Oracle hopes you’ll volunteer information that reveals non-compliance. If you respond, “We have Java on 500 servers and no licenses,” the situation is likely to escalate.

Conversely, if you handle it carefully, you might address any issues before it becomes formal. Treating a soft audit seriously is important—providing accurate information, but you are not legally compelled to run Oracle’s tools.

Many organizations use this phase to proactively negotiate purchasing the needed subscriptions, thus avoiding a formal audit.

35. How does a formal Oracle Java audit differ from a soft audit?

The formal audit is a clearly defined, contractual process:

• Authority: Formal audits come from Oracle LMS (or Oracle’s appointed auditor firm) with a written notice, invoking audit clauses of your contract. Soft audits come from sales with no legal weight behind the initial request​.
• Process and Timeline: Formal audits have set timelines and required tasks (running scripts, delivering data by deadlines). Soft audits are more ad hoc; you might exchange emails or have calls, and you have more flexibility (until it escalates).
• Tools: Formal audits often involve Oracle-approved audit scripts or certified SAM tools to ensure data completeness​. In a soft audit, Oracle might ask you to manually report information or run a lightweight tool.
• Outcome: A formal audit ends with a formal report of compliance gaps and a demand to resolve (usually financial). A soft audit may end with a “suggestion” to buy licenses, but it might never produce a formal report if resolved early.
  In short, a formal audit is much more serious, like an official investigation, whereas a soft audit is a preliminary inquiry. However, data from a soft audit can lead directly to a formal audit if Oracle isn’t satisfied. Therefore, companies often engage their compliance experts even during a soft audit to avoid missteps that trigger a formal process.

36. What information does Oracle typically ask for during a Java audit?

In a Java audit, Oracle is looking to identify all the places where Oracle’s Java is installed and how it’s being used. Typical information requested includes​:

• List Java versions installed on all servers, VMs, desktops, etc. (e.g., “Java 8 update 271 installed in C:\Program Files\Java\…” on Machine X).
• Installation path and product – to distinguish Oracle JDK vs OpenJDK if possible, and to see if JDK or JRE. Also, whether any Oracle commercial features or tools (like Java Mission Control) are present.
• Usage context/application name—Sometimes, they ask what applications each Java installation supports​. This can help identify whether it might be covered by some other license (like an embedded use in an Oracle product) or just general use.
• Deployment environment—are these on physical servers, VMs, Docker containers, or Virtual Desktop Infrastructure (VDI) environments​? Oracle might be evaluating whether virtualization is used (it did not matter for licensing count in the new model, but it did matter in the old model).
• Java update history or patch level – specifically, they might want to know if updates released after certain dates are installed, as evidence of needing a subscription​. For instance, if a server has Java 8 update 251 (released after Jan 2019), that suggests usage of Oracle’s updates beyond the free period.
• Commercial feature usage: They might ask if any features like Flight Recorder have been enabled. In some audits, Oracle has scripts that check for certain JVM flags or files that indicate use of those features.
  Often, Oracle provides a script that outputs a comprehensive inventory. The data might be delivered in spreadsheets. It’s wise to review these scripts internally first (to ensure they aren’t over-collecting or misidentifying OpenJDK as Oracle JDK, etc.). The focus is essentially on where, what version, and since when Oracle Java has been used in your IT environment?

37. Does Oracle use special audit scripts for Java, and what do they check?

Oracle has developed scripts for Java audits, but unlike Oracle database audits, these are relatively straightforward. According to some reports, Oracle sometimes leverages third-party SAM tools’ outputs rather than proprietary scripts.

If they do provide scripts:

• They typically scan the file system for known Java installation directories (like “java.exe” or “libjvm. so” files) to find all Java installs.
• They gather the version number and update level of each Java found.
• They may collect the installation date of each Java instance​. (Notably, Oracle often asks for installation dates; this can be used to infer if it was installed when you had no license, enabling them to claim back-dated usage.)
• They might check environment variables or configuration files that indicate if certain features (like Usage Tracker or Flight Recorder logs) are present.
• In some cases, for Java 8, they might look at a file in the JDK that lists whether commercial features were unlocked (Java 8 had a flag to enable them).

One thing to be aware of is that the installation date can be a trap. Oracle auditors have asked for it and assumed you’ve been using Java since that date (seeking back fees).

An industry tip is to avoid providing installation dates if not required, or be prepared to argue that they don’t equal actual usage duration​.

Also, each auditor might do things differently; Java audits aren’t as standardized as Oracle DB audits​. The tools might simply be a Flexera or Snow license manager data collection configuration.

So yes, expect some kind of script or tool usage, but it’s not invasive (it shouldn’t, for example, execute any Java code – it just looks for files and reads metadata).

38. What are common compliance issues found in Oracle Java audits?

Some typical compliance findings in Java audits include:

• Unlicensed Java installations: The audit discovers Oracle Java installed on many systems not covered by a subscription. For example, a company might have Java on 300 servers but purchased subscriptions for only 100 – the other 200 are out of compliance​.
• Use of Java updates without entitlement: This is a very common one. The audit finds that the company installed Java updates (especially for Java 8) released after the free period. This indicates they used Oracle’s downloads without paying​. For example, Java 8 Update 231 or 271 is installed, but the company had no active subscription at that time—Oracle will flag each such instance.
• Some companies assumed old versions were free forever, so they didn’t realize the license had changed. Auditors often find older Java versions (like Java 8) running, and the customer thinks it was grandfathered in as free​. If those instances have been receiving updates, it’s an issue.
• Commercial feature usage: As discussed, if any evidence that Java Flight Recorder, Mission Control, etc., were used without an advanced license, that’s a compliance issue. This was more relevant in audits circa 2015-2020 for Java 6-8 users. Oracle might ask if the JVM option -XX:+FlightRecorder has ever been used, for instance.
• Misclassified usage: For example, a company might have thought that using Oracle JDK in a test environment is fine (it is under OTN), but if any of those “test” JDKs were also used to run a production task, Oracle could claim that it was unlicensed production use.
• Expired support contracts: In cases where a company had Java SE Advanced or a support contract that expired, Oracle might find they kept using the software beyond the terms.
  In summary, the biggest issue is using Oracle’s Java in production after the license changes without having a subscription. Auditors will usually find at least a few instances in any large organization unless that org was very proactive in switching to OpenJDK or buying subscriptions.

39. What are Java SE “commercial features,” and could they lead to audit findings?

As mentioned earlier, Java SE commercial features are extra functionalities in Oracle Java (especially in Java 8 and earlier) that require a separate license (Java SE Advanced or Suite).

Examples include:

• Java Flight Recorder (JFR)
• Java Mission Control (JMC)
• Advanced Monitoring and Management (like JMX console enhancements)
• Application Class-Data Sharing in certain modes, etc.
  In an audit, if Oracle can determine that these were used, they could claim you needed a Java SE Advanced license. How can they tell? For instance, JFR in Java 8 produces recording files (.jfr files); Mission Control might have been installed or run on a machine. Oracle’s audit script or questionnaire might specifically ask, “Have you used Flight Recorder or Mission Control?” If logs or evidence say “Flight Recorder started” on a JVM, that’s a red flag. Many organizations, not realizing the license implications, used these features since they were technically one click away in the JDK. Oracle introduced these 2013 to monetize Java​ and audits after that,t often checked for their usage. If found, Oracle would require the purchase of Java SE Advanced licenses (or nowadays, the universal subscription, which also covers those features). Note: These features were open-sourced in newer Java versions (11+), so this issue mainly applies to Java 8/7 audits. It’s still something auditors check if you have older Java deployments.

40. What happens if an audit finds we used Oracle Java without a license?

Suppose an Oracle audit concludes that you have been using Java without proper licensing. In that case, the typical outcome is that Oracle will demand you purchase the necessary licenses retroactively.

They will present a compliance report saying, for example, “You deployed X copies of Java for Y years without a subscription, so you owe us for those subscriptions.”

Specific consequences:

• Retroactive fees: Oracle often asks for back payment of subscription fees for the unlicensed period. If Java has been unlicensed for 2 years, they might bill 24 months of subscription for the relevant number of installations or employees (depending on the model).
• Purchase of current subscriptions: You will need to buy a current subscription or license to cover continued use. Often, Oracle will roll back the fees and future fees into a deal.
• Penalties: Oracle’s contracts typically allow charging the list price plus possibly 50% more as a penalty in audits. In many cases, Oracle might waive some penalties if you quickly agree to purchase the needed licenses. But they could charge interest on back fees or some penalty for breach—this is negotiable during settlement.
• Cease usage: If you absolutely refuse to pay, the other option is to remove Oracle Java entirely. But even then, Oracle might still invoice for past usage. In reality, most companies negotiate a purchase because Oracle can pursue legal action for license breach if the issue is not resolved.

So, the endgame is usually a deal where the audited company pays a sum (either buying subscriptions in the future, covering past use, or both). The audit report is a lever for Oracle’s sales team to close a subscription sale.

Sometimes this results in a hefty one-time true-up cost plus a multi-year subscription contract. The worst-case scenario (if a company stonewalls) could be legal action, but that’s rare – usually, it’s settled commercially.

41. Can Oracle require back payments (“retroactive” fees) for unlicensed Java usage?

Yes, Oracle commonly does this in audits. They will calculate what you “should have” been paying during the period of unlicensed use and ask for that as part of the settlement​.

They treat it as if you had been subscribed all along:

• For instance, if you used Oracle Java on 100 servers for 18 months without a subscription, Oracle might invoice 18 months × 100 processors × $25 (legacy model) or, under the new model, 18 months × employee count × $15.
• Since it’s a compliance issue, these back payments are often at list price (no discount). Sometimes Oracle gives a slight concession if you commit to a future contract.
• They may label it as buying “back-dated support” or “past subscriptions.” In effect, it’s a penalty for using the software unlicensed.
  It’s important to know Oracle is within its rights (contractually) to charge for unlicensed use. When you downloaded and used Oracle Java, you agreed to their license, which said that you need to pay if you use it beyond the free terms. From Oracle’s perspective, they’re just collecting what was due. From the customer’s perspective, it can feel like paying for something after the fact without knowing, but in audits of Oracle (and other software vendors), back-licensing is standard practice. Negotiation can sometimes reduce the retroactive amount – for example, Oracle might agree not to charge for 100% of the past period if you sign a new 3-year deal. Each case is different.

42. What penalties can result from Oracle Java non-compliance?

Besides paying for the licenses, Oracle can impose:

• Payment at list prices: This is not a “fine,” but you will lose any discount effectively. This can cost much more than if you’d negotiated licenses proactively.
• Audit fees: Oracle’s standard contracts sometimes say if you are out of compliance by a certain margin (like 5% or more), you might have to pay the costs of the audit. They might not always enforce this for Java, but it’s possible.
• Legal penalties: In extreme cases, if a company outright refuses to resolve a known license breach, Oracle could pursue legal action for copyright infringement or breach of contract. That’s very rare in Java; it’s usually resolved via purchasing licenses.
• Requirement to purchase a broader license: Oracle might force a customer into the newer model. For example, “Technically, you owe $X in back fees, but instead, just buy the Universal Subscription for all employees for 3 years.” This might not feel like a penalty, but you might not have otherwise bought it.
• No penalties (best case): If you handle it cooperatively, sometimes Oracle will waive back fees and just ask you to start subscribing moving forward, especially if the unlicensed usage was recent. This tends to happen more in soft audits or if the compliance gap is small. Don’t bank on it, but Oracle has discretion to be lenient.
  Overall, Oracle’s goal is revenue, not punishment. They rarely “fine” you beyond making you pay for the software. But because they charge at the highest rates for compliance cases, it feels like a penalty. The real sting is if they enforce the employee-count model on you (that could be a huge cost increase, as discussed). That effectively can be a penalty for not being compliant earlier, because now you have to go with the expensive model.

43. How can we prepare for an Oracle Java audit before it happens?

‘Preparation is key to minimizing risk.

Here are the steps:

• Inventory your Java installations regularly: You should know where Oracle Java is installed in your environment. Use software inventory tools or scripts to scan for “java” binaries and record versions​. This should cover servers, VMs, desktops, even build servers, etc.
• Track Java versions and update levels: Once you have an inventory, note which versions are installed and whether they’re Oracle or OpenJDK. Pay special attention to Oracle Java versions that are beyond public updates (Java 8u211+ or any Oracle Java 11+). Those likely require a license unless they’re strictly dev machines.
• Centralize and standardize Java usage: Try to control Java deployments. For example, decide on an official company Java distribution (maybe an OpenJDK one) and roll that out. Avoid ad-hoc downloads from Oracle’s site by developers or admins​. Limit Oracle JDK to only systems that truly need it (and are licensed), and you reduce audit exposure.
• Review entitlements and contracts: Keep a record of any Oracle Java licenses you have – maybe you bought Java SE subscriptions, or you have Oracle products that include Java (in which case, know the terms of those). During an audit, you’ll need to show what licenses you own.
• Internal audits: Conduct your internal compliance check periodically​. Simulate what an Oracle audit would find. Identify any unlicensed Java installations and either remove or get them properly licensed (or replace them with OpenJDK).
• Stay informed on license changes: Oracle Java rules changed in 2019, 2021, 2023… staying up-to-date (reading Oracle’s announcements or consulting with licensing experts) will help you know how to remain compliant and adjust your strategy proactively.
• Policies and user awareness: Implement a policy that no one should deploy Oracle Java software in production without approval. Educate your IT teams that “Oracle JDK is not free for production” so they don’t accidentally download and use it out of habit.
  By doing these, you can often catch compliance issues yourself and fix them (either by purchasing what’s needed or migrating to alternatives) before Oracle comes knocking. That way, an audit – if it happens – becomes a non-event because you’re already in good order.

44. What should we do if Oracle initiates a “soft audit” for Java?

If you get an informal inquiry from Oracle about Java:

• Don’t ignore it outright. While you have no legal obligation to answer a casual email, completely blowing it off could lead them to escalate to a formal audit sooner​. Acknowledge receipt and respond professionally.
• Buy time and gather info: Thank them for reaching out, and say you will investigate your Java usage internally and get back to them. Use that time to scan and see if you have compliance gaps.
• Answer carefully: Provide accurate information, but only answer what is asked. If Oracle asks, “How many copies of Java are you running?”, you might respond with something like, “We have X servers and Y desktops running Java SE, and we have Z licenses/subscriptions.” If you’re mostly compliant but have a few gaps you plan to fix, you don’t necessarily need to volunteer every minor detail initially. Avoid speculation or admitting guilt. Stick to facts.
• Consult experts if needed: If you suspect a big compliance issue, it might be worth getting a licensing consultant or legal counsel involved before responding. They can help craft a response or strategy (maybe you quietly switch some Java installs to OpenJDK or purchase a small number of subscriptions to cover any obvious holes before replying).
• Consider addressing minor issues proactively. For example, if you find 10 servers with unlicensed Oracle Java and it’s easy to replace them with OpenJDK within a short time, do it. Then, your response to Oracle can truthfully state that those installations are no longer Oracle Java.
• Maintain a cooperative tone: Something like, “We take compliance seriously. We have reviewed our Java usage. Here is the information you requested…” This sets a good tone that might keep it from turning hostile.

Remember, the goal in a soft audit is often to avoid a formal audit. Suppose you can satisfy Oracle that either you’re compliant or taking steps to become compliant (maybe by agreeing to purchase some subscriptions for what you’re using).

In that case, they might close the matter without escalating. Just be cautious not to give them data that could be misinterpreted. For instance, don’t casually send raw scan results that Oracle can miscount – summarize the info clearly and on your terms.

45. How should we handle a formal Oracle Java audit request?

When a formal audit happens:

• Engage stakeholders immediately: Notify your legal department and any software asset management team. Formal audits usually come with a letter that might require a legal response (acknowledgment). Ensure executives know, since audit letters often cc high-level contacts.
• Negotiate scope and method if possible: Sometimes, you can discuss with LMS what tools to use. For example, if you already have a SAM tool report that covers Java, ask Oracle if it will accept it to avoid running new scripts. Oracle might allow some flexibility.
• Execute Oracle’s scripts carefully: Review any script they send you before running it​. Run it in a test environment if possible, or at least read through it (they’re often simple shell or PowerShell scripts). Ensure it’s not collecting unrelated info like personal data. If it does, you might ask Oracle to modify it.
• Run a pre-audit internally: It’s wise (if time permits) to run the same discovery on your own and see the results​. That way, you know what Oracle will see and can correct any mistakes (like uninstalling an old Java that’s not in use) upfront. Oracle’s instructions often encourage you to verify the script outputs.
• Be timely and factual: Deliver the data Oracle asks for within the agreed timelines. Delaying without cause can aggravate the situation. But also keep evidence of what you delivered and when.
• Don’t overshare beyond scope: Provide exactly what they request, not more. If the audit scope is Java SE, you don’t need to volunteer information about, say, IBM JVMs or OpenJDK installations (except to say those are not Oracle and thus out of scope if asked, but they usually focus on Oracle binaries).
• Request clarification if needed: If something in the audit request is unclear or seems overly broad, ask for clarification in writing. For example, if they ask for “all environments where Java is used,” you might clarify if they want dev/test or just production.
• Maintain professional communication: All correspondence with the Oracle audit team should be polite, professional, and concise. Assume any email could later be seen in court (in the worst case), so avoid any phrasing that admits wrongdoing or confusion.

Throughout the audit, you can be cooperative but also protect your interests. If at any point you feel the auditors are asking for something unreasonable, you can push back (with legal support).

The key is to get through data gathering, then focus on resolving any findings via negotiation.

46. Can we negotiate the results if an Oracle Java audit finds us non-compliant?

Absolutely. The audit report is usually the starting point for negotiation rather than a final bill (unless you ignore it).

Here’s how to approach it:

• Review the findings in detail: Check if Oracle’s report counted any false positives. Common issues: mistaking an OpenJDK installation for Oracle (maybe because file paths are similar), or counting an old Java that was uninstalled. If you find inaccuracies, document them and present evidence to Oracle​. They can revise the findings.
• Understand Oracle’s calculation: They often propose something like “You need X employee licenses at $Y each” or “you need Z processor licenses back-dated.” Make sure you understand how they arrived at those numbers from the data.
• Consider remediation: In some cases, Oracle might be open to you removing or certifying the deletion of certain installs instead of licensing them. For example, suppose the audit found Java on 10 test servers. In that case, you might negotiate that you will uninstall those immediately, and Oracle might not require licenses for them (focusing only on production usage). It’s case by case.
• Negotiate future terms: Oracle might push you to sign up for the Universal Subscription. You can negotiate the price (maybe aim for a discount off the list, especially if the audit is causing a large unplanned cost). For instance, Oracle might waive some back fees if you commit to a 3-year deal​.
• Get multiple options: Don’t hesitate to counter Oracle’s initial offer. You could propose alternatives, like a smaller number of licenses if you plan to decommission some systems, a longer payment schedule, etc.
• Engage experts or legal: If the dollars are high, having a licensing consultant or lawyer experienced in Oracle audits can pay off. They can manage communications and help argue points (like “that installation was never used, so it shouldn’t count for 2 years of fees”).
• Aim for settlement: The goal is a signed agreement or purchase that Oracle accepts as closing the audit. Ensure the settlement document states that all findings are resolved by a certain date to protect you from additional claims on the same issue.

Yes, it’s negotiable. Oracle’s auditors expect negotiation—a company rarely pays the initial claim as-is.

As long as you can show you’re acting in good faith to become compliant (by buying what’s necessary, albeit at a possibly negotiated rate), Oracle will usually come to a deal. Remember to negotiate any non-financial terms, like some extra support or training, given you’re paying a lot – you can always ask.

47. Are Oracle Java audits increasing with the new licensing model?

Many in the industry anticipate that audits (or at least compliance checks) will increase because Oracle’s 2023 model potentially yields more revenue per audit.

Oracle hasn’t publicly announced “we will audit more,” but several licensing experts and consultancies have observed heightened Oracle focus on Java compliance:

• Consultant reports: Firms like House of Brick and Palisade Compliance noted that after the pricing change, Oracle representatives seem even more keen to discuss Java licensing with customers​. Palisade mentioned that Oracle reps simply state how many downloads a customer made and how many employees they have, implying a compliance issue without even doing a full audit.
• Risk profiles: Any Oracle customer not on the new model could be viewed as low-hanging fruit for sales to reach out and either audit or pressure into buying. Oracle’s revenue from Java subscriptions is now a significant line item, so they have the motivation to ensure no one is getting it for free if they shouldn’t.
• Audit vs. review: We might see more “soft audits” – emails to customers hinting that “if you use Java, you should be on this new subscription.” Those who ignore or push back might then face formal audits.
• Scope of audits: If a formal LMS audit for Database or Middleware is happening, they might also add Java usage questions, since now one audit can lead to selling an enterprise-wide Java license.

So, while we can’t quantify how many more audits will be required, the consensus is that companies should treat Java like any other licensable Oracle product. In the past, Java wasn’t a common audit target; now, it is.

We have indeed seen Oracle audit Java in recent years (2019–2022) to enforce the subscription model​ , and that trend is likely to continue or grow post-2023. The bottom line is to be prepared as if an audit could happen rather than assuming Oracle won’t bother.

48. What if we remove Oracle Java instead of paying for it?

This is a viable strategy for many. If the cost of compliance is too high, an organization can decide to eliminate Oracle Java from its environment.

Steps to consider:

• Inventory and plan: Identify all places where Oracle Java is in use. Determine what alternatives (OpenJDK or others) can replace each instance. Swapping to an OpenJDK build is straightforward in most cases, but in some, it may require testing (especially if the Java version changes).
• Execute migration: For each system, uninstall Oracle JDK/JRE and install a drop-in replacement like Eclipse Temurin, Amazon Corretto, or another OpenJDK distribution. Since these are binary-compatible, your applications should run fine, but you’ll want to test critical systems to ensure no surprises (like minor differences in cryptography libraries or fonts).
• Special cases: If you have older apps that depend on Java Web Start (an Oracle component discontinued after Java 8), you might need OpenWebStart as a replacement. If you have been using Oracle-specific tools, find their open-source equivalents.
• Documentation: Keep records of when you uninstalled Oracle Java on those systems. If later audited, you want to show that any Oracle Java found in the past is no longer present. Oracle’s FAQ even suggests moving to OpenJDK if you don’t renew your subscription​.
• Handle Oracle-provided Java: Some Oracle products come bundled with Java (e.g., WebLogic, Oracle DB for certain features). Usually, the use of Java is covered by that product’s license. If you only have Oracle Java because it came with Oracle software, you might already be licensed via that product – check that before removing it in such cases. (Often, you should not replace the Java inside an Oracle product unless Oracle allows it, but many Oracle server products now also work with OpenJDK).

By removing Oracle Java and using an open alternative, you can avoid needing any Java SE subscription.

Many organizations pursued this in response to the 2019 changes, and even more are doing so after the 2023 changes​.

It’s essentially what Oracle expected some customers to do rather than pay – they even provide free OpenJDK builds themselves (under GPL license) as an alternative.

Ensure you have the internal expertise or support to manage updates for whichever alternative you choose (though many, like Corretto, come with free long-term updates).

Alternatives to Oracle Java

49. What are the alternatives to Oracle’s Java distribution?

Oracle does not solely provide Java. There is a rich ecosystem of free OpenJDK-based distributions.

Some of the most popular alternatives:

• Eclipse Temurin (formerly AdoptOpenJDK): A community-driven build of OpenJDK managed by the Eclipse Foundation. Widely used, available for all major platforms, and free.
• Amazon Corretto: Amazon’s OpenJDK distribution. It’s free, multi-platform, and Amazon provides long-term support (they use it internally on AWS). Corretto is certified compatible with Java SE​ and comes with no-cost updates (Java 8 and 11 are supported for years, Java 17 to at least 2029)​.
• Azul Zulu: Azul Systems provides Zulu, a build of OpenJDK. They offer it for free (community editions) and also offer commercial support plans. They support many versions (even Java 6 and 7 with paid support). Azul also has a high-performance JVM (Azul Platform Prime) for those needing extra performance, but that’s a paid product.
• IBM Semeru (and IBM SDK): IBM’s OpenJDK-based distribution, particularly for IBM platforms and standard ones. IBM offers it for free and also provides support as part of its offerings. It used to be known as IBM J9 JVM (OpenJ9) as an alternative JVM, but they also do HotSpot builds.
• Red Hat build of OpenJDK: Red Hat leads the OpenJDK 8 and 11 update projects in the community. Red Hat provides its own tested builds, and if you have a Red Hat Enterprise Linux subscription, you get support for those. Even without RHEL, you can use their builds for free.
• Microsoft Build of OpenJDK: Microsoft now offers a distribution (they started this around Java 11 and 17) to support its Azure services and customers. It’s free for anyone to use, and Microsoft provides long-term updates.
• Oracle’s OpenJDK builds: Not to be overlooked, Oracle itself releases OpenJDK builds for each Java version (under GPL license) at jdk.java.net. These are free and have features identical to Oracle JDK for that version. The catch: Oracle only provides OpenJDK updates until the next version (e.g., Java 17 OpenJDK from Oracle was updated until Java 18 was released). After that, Oracle’s OpenJDK site stops updating that version (leaving it to others like Red Hat/Adoptium to continue). However, you can use Oracle’s OpenJDK binaries as a starting point.

All these options are based on the same source code (the OpenJDK project), meaning they all pass the TCK (compatibility tests) for Java SE. This ensures that your Java applications will run similarly on any of these. The differences come in support and update policies, not core functionality.

50. Is OpenJDK the same as Oracle JDK?

From a functionality perspective, OpenJDK and Oracle JDK are equivalent for Java versions 11 and later. Oracle’s JDK binary is built from the OpenJDK codebase, with minor differences (including Oracle’s branding and some components like installers).

Historically, there were a few differences:

• In Java 8, Oracle JDK had some closed-source features (as discussed, JFR, etc.) and the Oracle JRE installer, whereas OpenJDK 8 had purely open components. However, Oracle open-sourced those commercial features in later updates and in Java 11.
• Starting Java 11, Oracle JDK and OpenJDK builds have no meaningful technical differences. Oracle even says Java 11 and later releases are “functionally identical” between Oracle JDK and the corresponding OpenJDK release​.
• Oracle JDK may have some extra packaging (like Windows .msi installers, which some OpenJDK providers now also offer). It might have slightly better out-of-box font or crypto configurations on some OS, but those are trivial to adjust.

Crucially, code that runs on Oracle JDK will run on any standards-compliant OpenJDK build. They all pass the same TCK (Technology Compatibility Kit) tests for Java SE.

For example, Amazon Corretto is a certified Java SE, meaning it’s essentially the same from an application perspective​. So, outside of the support/license umbrella, using OpenJDK instead of Oracle JDK is usually seamless.

Many companies have switched their production JVM from Oracle Corporation to Eclipse Adoptium or others without making any code changes.

51. Are free Java distributions reliable and secure for enterprise use?

Yes, the free distributions are reliable and widely used in enterprises. The key considerations:

• Security updates: OpenJDK distributions get the same patches as Oracle (because Oracle contributes to OpenJDK). When Oracle releases a Critical Patch Update (CPU) for Java, the OpenJDK project simultaneously releases patches. Vendors like Amazon, Azul, etc., then build those into their distributions, often on the same day. For instance, Amazon Corretto releases updates on the CPU schedule, so you’re not lagging behind Oracle.
• Long-term support (LTS): Different vendors commit to different support timelines. Amazon has publicly committed to supporting Corretto 8 until at least 2026, Corretto 11 until 2027, and Corretto 17 until 2029​. Azul offers even longer support for older versions if you pay. The free community (Adoptium) usually supports an LTS for some years (e.g., 4 years). So you can choose a vendor that matches the timeframe you need.
• Performance and compatibility: They use the same HotSpot VM (or, in IBM’s case, sometimes OpenJ9, another high-quality JVM). You shouldn’t see performance regressions; sometimes, you might even see improvements or quicker adoption of fixes. For example, some OpenJDK builds might include backported fixes sooner.
• Enterprise adoption: Many large organizations have already moved to open-source Java. Companies like IBM and Microsoft run on OpenJDK internally, and even Oracle’s cloud services often run on OpenJDK. The fact that these are open-source means many eyes are on the code—issues are caught and fixed by a broad community, not just Oracle.
• Support: The only thing you don’t get by default with free is a support line to call if something goes wrong. But you can purchase that from vendors (Azul, Red Hat, etc.) if needed, often for much less than Oracle’s cost. Or if you have capable engineers, you might handle it in-house or rely on community forums, which are quite robust for Java.

In summary, using a free OpenJDK distribution is a standard practice now. It’s not seen as risky or second-tier. They receive the same critical fixes (since they originate from the same OpenJDK updates Oracle uses). The main diligence needed is to keep up with applying those updates, just as you would with Oracle’s.

52. Can we mix Oracle Java and OpenJDK in our environment?

Yes, you can, but you’ll want to manage it carefully. Some points:

• Allowed from a license perspective: There’s no rule that you must exclusively use one or the other. You could have some systems on Oracle JDK (perhaps where you need Oracle’s support or specific reasons) and others on OpenJDK.
• Be mindful of compliance: If you mix, ensure that every instance of Oracle JDK remains appropriately licensed. Sometimes, after migrating most systems to OpenJDK, a few Oracle JDK installations might linger unnoticed—those can still trigger compliance issues, so track them.
• Ensure compatibility: While Oracle JDK and OpenJDK are compatible, mixing them could reveal minor differences. For example, an app tested on Oracle JDK 11 and running on OpenJDK 11 should behave the same. But let’s say an admin script specifically parses the output of Java version and expects “Oracle” in it—that might break when using OpenJDK, which says something else. Such things are rare and trivial to fix.
• Configuration management: It’s wise to standardize per system or application. For instance, decide that all your production servers use Amazon Corretto 11, but maybe your developers use Oracle JDK 17 locally for some reason. That’s fine, but document these choices. It’s easier for operations if there’s consistency, but technically, mixing doesn’t cause runtime conflicts as long as each application or server uses one JVM or the other.
• Avoid confusion: Make it clear in documentation or naming which Java is which. For example, you might adjust environment variables or installation paths (e.g., install OpenJDK to C:\Java\OpenJDK\... and Oracle to C:\Java\Oracle\...) so it’s easy to differentiate.

Mixing might be a transitional strategy while migrating off Oracle, or a deliberate strategy if only a subset of systems truly require Oracle’s distribution. Over time, many aim to eliminate the Oracle to simplify things and avoid accidental unlicensed use.

53. What about Java updates and patches if we leave Oracle?

When you stop using Oracle Java and switch to alternatives, you still need to keep up with security patches, but those will come from your new distribution’s maintainers:

• Coordinated release: The Java community operates on a quarterly patch cycle (the same as Oracle’s CPU schedule). All major distributions (Adoptium, Corretto, etc.) release updates around the same time as Oracle’s CPU (Critical Patch Update) releases. For example, if Oracle releases Java 11.0.18, Adoptium and Corretto will release 11.0.18 as well within a day (often the same day).
• Access to patches: With OpenJDK, patches are open source. So if a zero-day vulnerability is discovered, you’re not dependent on Oracle alone; the OpenJDK project will patch it, and vendors will build it. This is a good thing — you won’t be left behind regarding security.
• Long-term availability: One consideration is how long the community patches a Java version. For example, the community (led by Red Hat for 8 and 11) usually continues until a bit after the next LTS. Red Hat maintained OpenJDK 8 updates until May 2026 (which aligns with extended support), and OpenJDK 11 until around 2027, likely (since Java 17 is out). But even when the community stops, vendors like Amazon step in – e.g., Amazon Corretto 8 will still get free updates through at least May 2026​, Corretto 11 through Sept 2027​, and Corretto 17 through 2029​. Azul offers longer if you pay.
• Upgrading: If you plan to always stay within freely supported versions, you might adopt a strategy: upgrade to each new LTS within a year or two of its release. This way, you can rely on free community support. For instance, when Java 17’s free support window ended in 2024, you might move to Java 21, which will be free (Oracle’s NFTC or otherwise open) for a few years, etc. This requires effort, but it keeps you on a secure, free path.
• In-house patching: In theory, since OpenJDK is open source, one could patch it themselves if needed. But that’s rarely necessary given the vendors providing patches. Still, having the code guarantees you’re never locked out from fixing something critical.

In summary, leaving Oracle doesn’t leave you vulnerable – you just switch to getting your patches from a different entity (which often is just as timely). Just ensure you install those updates when they come. The processes (testing the new patch in QA, rolling it out) remain the same as they were with Oracle, only the source of the binaries changed.

54. Are there any functional differences when switching from Oracle JDK to another distribution?

Practically speaking, no major functional differences for standard Java applications. All distributions conform to the Java SE standard.

However, a few minor points to be mindful of:

• Crypto Policies: In Java 8, Oracle JDK had “unlimited strength crypto” policy files separately, whereas OpenJDK might default to unlimited. In Java 11+, this is moot as unlimited crypto is the default. So, usually no difference.
• TLS Certificates: Each JDK has a keystore of root CA certificates (for SSL/TLS). There might be slight differences in those trust stores. For instance, one distribution might include an additional certificate or exclude one that Oracle had. It’s rare, but if your application relies on a certain Root CA presence, double-check the new JDK’s cacerts. You can always import the missing ones manually.
• Graphics & Fonts: There could be minor differences in font fallback for apps that use AWT/Swing or font rendering. Oracle JDK on Windows had some proprietary font rasterizer in Java 8, IIRC. In modern versions, it’s all open, so there is likely nothing noticeable.
• Deployment tools: Oracle’s JDK used to include Java Web Start in Java 8 and the Oracle Plugin. OpenJDK 8 does not include Web Start (because it was proprietary), so you’d need the separate OpenWebStart tool if required. In Java 11+, Web Start is gone entirely. If you were using the Oracle Java Control Panel or Auto-Update, note that those aren’t in OpenJDK (but are client features mostly irrelevant to server use).
• Version string: The java -version output will differ (Oracle’s says Java HotSpot(TM) 64-Bit Server VM and includes “Oracle” in the runtime name; others might say Eclipse OpenJ9 VM or just OpenJDK 64-Bit Server VM). Some software or scripts might parse this. Ideally, they shouldn’t rely on a specific vendor string, but you might need to adjust them if they do.
• Commercial features availability: On OpenJDK builds, those commercial features (Flight Recorder, etc.) are actually available as open source now (JFR is open in OpenJDK 11+ and can be used freely). So you might gain JFR usage, whereas you avoided it before due to Oracle licensing. JMC (Mission Control) is a separate open source project that works with OpenJDK JFR. So functionally, you don’t lose capabilities by leaving Oracle; you remove the licensing restriction on now open-source features.

In summary, you swap the JDK for 99% of applications, and everything runs as before. It’s always good to run a full regression test when you change the JVM, just to catch any environment-specific assumptions.

However, thousands of companies have made this swap without issues—one reason Oracle’s new model is controversial is that switching is feasible for so many.

55. What are the risks of running an old Java version without updates?

If you decide not to pay Oracle or migrate to a new Java or alternative distribution, you might be running an outdated Java version (say Java 8 update 202 from early 2019).

The risks include:

• Security vulnerabilities: Over time, many security flaws have been discovered in the Java runtime. Without updates, these remain unpatched in your environment. For example, flaws that allow untrusted code to break out of the Java sandbox or execute arbitrary code could be exploited by malware (if using Java in a client context) or attackers who manage to feed data into your Java server applications. There have been remote code execution vulnerabilities in the JDK, so regular updates are critical.
• Compliance and regulatory risk: If you operate in a regulated industry or follow security standards (like PCI DSS for payment processing), using software that is out of support (no security fixes) might violate those standards, and auditors may flag it.
• Compatibility issues: Less of a risk, but as time goes on, new protocols or standards (TLS versions, cipher suites, etc.) may not be supported on your old Java. For instance, you’ll hit issues if an outside service you integrate with requires TLS 1.3 and your old Java 8 doesn’t support it. Modern protocols and algorithms might not be backported.
• No vendor support: if something goes wrong (memory leak, crash, etc.), you can’t get help from Oracle unless you pay. And with an old version, community forums might tell you to update.

Oracle strongly advises against running out-of-date Java in production​. An outdated JVM on desktops could allow malware to exploit it (though browser plugins are gone, an outdated Java could still be an entry point if users run untrusted jars).

On servers, if it’s a closed environment, the risk is lower than a directly internet-exposed service, but still, many attacks start from insiders or via data that triggers vulnerabilities.

If, for some reason, you must freeze a Java version and not update it (maybe an old application that you can’t change and it only runs on Java 6, etc.), consider isolating that environment as much as possible – firewall it off, no internet, etc.

However, the better approach is to update the application or provide a secure environment (e.g., run it on an up-to-date OS with other security layers).

In general, not patching Java is analogous to not patching an OS – it becomes the weak link in your security.

56. How do alternative Java vendors make money if their JDK is free?

While many Java vendors provide the runtime for free, they often have business models such as:

• Paid Support: This is the primary one. A company might use the free binaries for a while, but for mission-critical systems, they may buy a support contract. For example, Azul offers Azul Platform Core (support for Zulu OpenJDK), where, for a fee, you get SLA assurances, timely security fixes (beyond community if needed), and legal indemnification. Red Hat includes OpenJDK support as part of RHEL subscriptions. These support contracts are typically cheaper than Oracle’s subscriptions and can cover only your desired systems.
• Premium Features or Products: Azul has Platform Prime (formerly Zing), a paid JVM with special low-latency GC and performance features. Amazon doesn’t sell Java, but by providing Corretto free, they may attract more Java workloads to AWS (indirect monetization).
• Enterprise Tools: Some might develop management or monitoring tools around Java. For instance, if someone offered an enterprise management dashboard for your Java deployments, that could be commercial.
• Cloud Services: Oracle gives Oracle Java for free on Oracle Cloud instances. Amazon gives Corretto for free, but it ties into AWS services. Microsoft’s OpenJDK feeds Azure services. So these vendors support Java in bolstering their ecosystems.
• Donations/Community: Eclipse Adoptium is a non-profit; it’s supported by member companies (IBM, Microsoft, etc.) and likely doesn’t aim for profit itself, but the member companies get value in having a robust free Java for their needs.

Essentially, the free runtime is a bit of a commodity now. Vendors differentiate in support (hand-holding enterprises through issues) or additional value-add.

This is similar to Linux distributions – the kernel is free, Red Hat sells support and add-ons. So while you can use Java for free from these sources, if you ever need more, there’s a path to pay for premium offerings.

But many users find they don’t need to pay at all, which is fine – those who do need it fund the ecosystem for others.

57. Could using an alternative Java distribution affect our application vendor support?

This is a good question to check when you have third-party applications that run on Java:

• Most vendors support “Java SE standard”: If an application vendor says “requires Java 11”, they usually don’t mandate “Oracle Java 11”. They care that a Java SE 11 implementation is present and passes the TCK (which OpenJDK ones do). In recent years, most software vendors have updated their support statements to explicitly include OpenJDK. For example, many enterprise software providers certify on “Adoptium/AdoptOpenJDK” or the Red Hat build of OpenJDK.
• Vendor bundles Java: Some applications have an embedded Java runtime (like a .jar with a bundled JRE). If so, the vendor has approved licensing (hopefully). For example, Atlassian products are used to bundle AdoptOpenJDK, which is free. If a vendor bundles Oracle JRE, then ideally, they have a redistribution agreement, and you, as the end user, are not required to have a separate Java license for that usage (commonly known as “Schedule B” rights in Oracle’s OTN license).
• Ask the vendor: If you have a critical app, ask the vendor’s support: “Do you support running on OpenJDK (like Corretto or Temurin)?” Most will say yes. Some might not have formally tested a specific distro, but since all OpenJDK 11 are essentially the same, it usually isn’t an issue. Some vendors, to be safe, only list “Oracle JDK” in documentation, but often their support will still assist you as long as the issue can be reproduced on Oracle JDK (in worst case you might have to show the bug isn’t due to the JVM by switching to Oracle JDK for testing).
• Oracle products: If the vendor is Oracle itself (like Oracle E-Business Suite, Oracle WebLogic), they often include the required Java or specify exactly which version to use. Historically, Oracle’s products were tied to Oracle JDK, but nowadays, even Oracle’s WebLogic Server is certified on OpenJDK. Still, it’s best to follow Oracle’s guidance for Oracle products – that product’s license might cover the Java usage. For example, running Oracle WebLogic might include rights to the needed Java (check the WebLogic license doc).

Most third-party apps will work fine on OpenJDK and be supported. Just double-check any mission-critical ones. In the rare case a vendor says “we only support Oracle JDK,” you could:

• Pressure them by saying Oracle JDK now has costly licenses and that their policy is unfriendly (they sometimes update their policy if enough customers push).
• Use Oracle JDK for that one application and cover it with a license (or see if that vendor has a distribution license covering you – some vendors have deals where their customers don’t need separate Java licenses).
• If that stance doesn’t change (depending on your leverage), consider alternative software that is more open-friendly.

58. What about Java in embedded or redistributable form?

Embedded use of Java (for example, Java running on devices, or bundling a Java runtime with software you ship to customers) is a different licensing scenario.

Oracle has/had separate “Java SE Embedded” licensing and the Binary License for Redistribution:

• Java SE Embedded: Oracle historically offered specialized licenses for embedding Java in low-power devices or hardware, often with a one-time fee per device. Those are still available and have not changed with the employee metric (the employee metric is for internal use, not external distribution)​.
• OTN Schedule A/B: The OTN license for Java SE allowed certain applications to include Oracle JRE (Schedule A covers certain Oracle products and technologies). If your product is listed or fits those categories, you could redistribute Oracle JRE with it for free. However, most commercial ISVs would get a formal redistribution agreement with Oracle to include Java in their software.
• If you are an ISV who wants to include Java with your app, you can either use an open-source JDK (no permission needed; just follow GPL if you modify it) or contact Oracle for an embedded licensing deal. Oracle’s FAQ suggests contacting sales for an embedded Binary License agreement. These deals are usually separate from the employee subscription and might be more cost-effective if you ship many copies.
• If you are using an app that includes Java, then the question is, do you need to license that Java? Generally, no – the application vendor is responsible for licensing the Java they bundle. Oracle’s OTN license has an allowance: if you are an end-user of an application that contains Java, you as the end-user don’t need a separate license for Java in that context (that’s what point 3 in the OTN exclusions refers to: “use by/with an approved product… or as an end user of an application provided by someone else”).

For on-premise usage, embedded licensing is less of a concern if you are not shipping software outside but just using Java internally.

If you build a hardware device with an integrated Java runtime, you’d either use an OpenJDK (some do, like Azul, which has embedded offerings) or get an Oracle embedded license.

In the context of audits, Oracle would not typically audit a customer’s products that include Java being redistributed; they would approach the vendor in that case.

So, for most IT managers, the main thing is to confirm that the vendor has it covered if a third-party app came with Java. Often, the vendor’s documentation will say, “This product includes AdoptOpenJDK (or Oracle JRE) under license…” etc.

59. Is there any benefit to staying with Oracle’s Java rather than switching to OpenJDK?

Given the costs, one might wonder why anyone would pay Oracle. There are a few potential reasons to stick with Oracle Java:

• Oracle Premier Support: Some organizations value the fact that they can call Oracle for JVM support. If an issue arises deep in the JVM (memory leaks, crashes), Oracle support can be helpful and provide emergency patches. With OpenJDK, you rely on community or in-house expertise if you’re not paying anyone. That said, companies like Azul or Red Hat can support their distributions similarly.
• Long-term patch availability: Oracle commits to providing security updates for older versions for subscribers far into the future (e.g., Java 8 through at least 2030)​. Having Oracle’s official updates for a decade might be valuable if you cannot upgrade certain applications. Some open JDK providers dropped off earlier (but others, like Azul, will cover it if you pay them). Still, Oracle is a single source for very long-term patches.
• Oracle-specific tooling: Oracle has some tools and services exclusive to its JDK. For example, Oracle’s Java Management Service (JMS) in Oracle Cloud can track your Java usage enterprise-wide (mainly to help you manage/monitor, and also to ensure compliance). Only Oracle Java customers can use JMS at the moment. Oracle also offers something called Java SE Subscription Enterprise Management (a feature including the Advanced Management Console), which helps manage desktop Java versions. If those tools are important to you, that’s a reason to stay.
• Indemnification: Oracle presumably indemnifies its customers against intellectual property claims regarding Java. Some companies need that legal safety net (though other vendors also indemnify, e.g., Azul does for its customers​ about open source licensing issues). With Oracle, you know the steward of Java is backing you.
• Internal policy and validation: Sometimes, enterprises have policies like “we only use vendor-supported software.” For whatever reason, they may not consider a free community build as meeting that standard, whereas an Oracle contract does. It can also be a perception of risk – some decision makers feel safer paying Oracle (“nobody gets fired for buying Oracle” logic). Over time as OpenJDK use has proven safe, this is less of an issue, but it can still factor in conservative organizations.
• Bundled usage with Oracle products: If you’re an Oracle-heavy shop (using WebLogic, Oracle DB, etc.), Oracle might bundle Java support in a larger deal, or already have it as part of some suite. Sticking with Oracle Java might not incur significant extra cost in such cases.

In summary, the benefits revolve mostly around support, risk mitigation, and certain management conveniences. For many companies, these benefits do not outweigh the costs, which is why many migrate.

But for some, especially those who need 24/7 vendor support or have very complex Java systems where having Oracle’s ear is important, staying with Oracle Java (under subscription) might be worth it.

It often comes down to a cost-benefit analysis and how critical Java is to your operations.

60. What should organizations do now regarding Oracle Java?

Organizations should take a strategic approach:

• Discover and Assess: First, identify all the Oracle Java usage in your environment (inventory) and map out which ones are unlicensed or could become an issue​. Also note what versions they are on and why Oracle Java is being used (could OpenJDK replace it?). This gives you the scope of potential risk or cost.
• Decide on a Java strategy: Broadly, you have two paths – subscribe or migrate (or a mix). If Java is crucial and you want the least change, budgeting for Oracle’s Java SE Universal Subscription might be safe. If cost is a concern, plan to migrate most, if not all, Oracle Java to free alternatives. Many are choosing the latter due to the new pricing.
• Consider partial solutions: Some organizations might subscribe to a portion of the usage and shift the rest to OpenJDK. However, with the employee metric, this doesn’t work to save money because Oracle doesn’t sell small increments – it’s all or nothing. So, more realistically, decide if there are any cases where you must use Oracle’s Java (maybe a vendor requirement or an old app where you trust only Oracle’s build) – those might compel you to subscribe. If not, aim to eliminate Oracle Java usage and go 100% OpenJDK, avoiding subscription.
• Engage stakeholders: Get buy-in from security teams (since you’ll need to ensure patching is maintained with whichever route), from application owners (some may worry about switching Java, so you’ll need their testing and support), and from procurement/CIO (if you plan to purchase a subscription, it’s a budget item to approve; if migrating, it’s a project to resource).
• Implement controls: If you go the OpenJDK route, implement policies that forbid downloading Oracle JDK without approval. Provide your IT teams with approved OpenJDK builds. Possibly block Oracle’s Java download sites to avoid accidental use. This prevents “shadow IT” from reintroducing Oracle Java.
• Future-proof: Keep an eye on Oracle’s moves. They’ve changed the model before; they could do so again. Also, watch the OpenJDK ecosystem; for instance, if Adoptium stops supporting an LTS earlier than you need, plan to transition to another distro or upgrade. Have a policy to regularly upgrade Java (e.g., adopt every LTS by 1-2 years after release) so you’re never in a position of running an unsupported Java.
• Budget for support if needed: If your org requires SLA support but you want to avoid Oracle, consider budgeting for a third-party support contract (with Red Hat, Azul, etc.). Those costs are generally much lower and can cover your needs.
• Educate and train: Ensure your developers and system admins understand the plan. If the plan is “we’re moving to OpenJDK,” teach them the minor differences in tooling (like using key tools, etc., all the same) and reassure them. If the plan is “we’re buying an Oracle subscription,” educate them on not deploying more than needed (though with employee metrics, usage doesn’t change cost, but still, for security, you’d limit where Java is installed).

Finally, Java should be treated as a managed asset. In the past, it was just there freely; now it has licensing implications. So, include it in your SAM (Software Asset Management) program. Keep records of what you have and under what license.

If you subscribe, periodically verify you’re within compliance (with the employee metric, it’s straightforward: keep your employee count documentation ready). If you go open source, ensure you have truly removed Oracle binaries.

With proper management, you can avoid surprises (like an audit) and ensure your Java usage remains secure and compliant at the lowest cost.

Recommendations for Managing Oracle Java Usage

• Inventory Regularly: Maintain an up-to-date inventory of all Java installations in your environment (including version and vendor) to know where Oracle Java is running. This will help identify any installations that might require a license​.
• Standardize on OpenJDK if Possible: Where feasible, use open-source Java distributions (e.g., Eclipse Temurin, Amazon Corretto) instead of Oracle JDK. This avoids licensing fees. Test your applications on these alternatives and adopt a standard across the organization to reduce complexity. Many companies have successfully switched to OpenJDK with no issues.
• Use Oracle Java Only Where Necessary: If certain systems must use Oracle’s Java (due to vendor requirements or specific features), isolate those cases. Ensure you have the proper subscription for them, and consider if they can be phased out or migrated in the future. The fewer places you use Oracle Java, the lower your compliance risk and cost.
• Stay Current on Patches: Whether using Oracle JDK or an alternative, apply Java security updates promptly. Using Oracle Java with a subscription, leverage Oracle’s quarterly updates. If you use OpenJDK, get updates from your chosen distro on the same schedule. Never let Java installations fall far behind on patches – this is critical for security.
• Monitor Oracle’s Policy Changes: Oracle’s Java licensing and support roadmap can change (as seen in 2019 and 2023). Designate someone to monitor Oracle announcements, Java SE support roadmaps, and industry news​ . This ensures you won’t be caught off-guard by new licensing requirements or opportunities (like the NFTC free periods on new versions).
• Establish Internal Policies: Create clear internal guidelines about Java usage. For example, “Oracle JDK is not to be used for production without approval from the SAM team,” or “All new Java applications will use [Chosen OpenJDK] runtime.” Educate developers and IT staff on these policies so they don’t accidentally download Oracle Java and introduce compliance issues.
• Centralized Java Management: Use management tools (like endpoint management solutions or even Oracle’s Java Management Service if you are a subscriber) to track and control Java installations. This helps ensure old versions get updated or removed and prevents the unchecked proliferation of Java on desktops and servers.
• Audit Your Java Usage Internally: Periodically perform self-audits. For instance, run discovery tools to find any Oracle JDK installations and verify they are authorized. This way, if Oracle initiates an audit, you’re confident about what they will (or won’t) find. If you find issues, address them proactively (uninstall or get licenses).
• Be Prepared for Audits: Keep documentation of your Oracle Java entitlements (subscriptions, legacy licenses) handy. If using the employee-based model, maintain an official record of the employee count. Should an audit request come, you can respond efficiently with accurate information. Consider engaging a licensing expert preemptively to review your Java compliance posture – they can provide assurance or highlight hidden gaps.
• Evaluate Support Needs: If you require enterprise support for Java but want to avoid Oracle’s costs, look at third-party support options. Vendors like Azul, IBM, or Red Hat can support OpenJDK deployments. This can give you professional help when needed (and legal indemnification) at a lower cost than Oracle.
• Plan for the Future: Java will continue to evolve (new LTS releases every two years). Have a strategy to upgrade your applications regularly to supported Java versions. This way, you can take advantage of free support periods (if using Oracle’s NFTC approach) or ensure long-term support from open-source providers. Upgrading also improves performance and security.
• Cost-Benefit Analysis: Periodically re-evaluate the cost vs. benefit. If Oracle’s licensing becomes too expensive relative to its value, invest in migration. If your environment changes (say, adopt a new third-party app that demands Oracle JDK), factor that into your compliance plan. Always weigh the convenience of Oracle’s offering against its price, considering alternatives that might achieve the same outcome for less.
• Engage with Application Vendors: Communicate with your software vendors about their Java support. If any still expect Oracle JDK, ask if they support OpenJDK—most do. This dialogue not only clarifies your position but also signals to vendors that customers prefer open standards, which can influence their future support statements.
• Document Everything: Keep clear records whenever you remove Oracle software or switch Java versions. If you ever need to prove to Oracle (or an auditor) that “we stopped using Oracle Java on these servers as of last year,” having change management records or inventory reports will help your case. Documentation can also be your friend when negotiating with Oracle – showing a plan or proof of reduced usage might lead to a better deal if you still need some licenses.

By following these recommendations, organizations can minimize compliance risks, control costs, and maintain flexibility in their Java usage.

Java remains a vital platform for many businesses. Proactively managing it will ensure you get the benefits of Java without unwelcome surprises from licensing audits or bills. Stay informed, stay compliant, and leverage the rich Java ecosystem.