Azul has announced a new chief revenue officer. That is not the interesting part. The interesting part is the estate the announcement quietly assumes. Enterprise Java is under new pressure from AI workloads, fresh scrutiny of cloud bills. Its licensing model prices headcount rather than code.
What actually changed at Azul
The release names Matt Camassa as chief revenue officer and describes the products he will sell. It contains no technology.
Azul’s real recent news sits elsewhere. In September 2026 it added an AI Assistant to Azul Intelligence Cloud. It lets an engineer ask a question about a Java estate in natural language. The answer comes from JVM Inventory and Code Inventory data.
Its Prime runtime has published 2x to 5x faster warm-up than standard OpenJDK by letting JVMs learn from each other. Neither appeared in the appointment release.
AI has moved into the Java estate
Azul’s 2026 State of Java Survey drew on more than 2,000 Java professionals. It found 62% of organisations now use Java to code AI functionality, up from 50% a year earlier. Thirty-one percent say more than half of the Java applications they build contain AI.
Treat the figure with care, since Azul sells Java runtimes and the survey supports its market. But the direction is not controversial. Most of the systems where AI eventually has to run — transactional platforms, backend services, data pipelines — are already Java. Oracle shipped Java 26 in March 2026 with features aimed squarely at that reality, including structured concurrency for agentic workloads and ahead-of-time object caching to cut startup time.
The licence bills headcount, not Java
The harder pressure is commercial. In January 2023 Oracle moved Java SE to a per-employee subscription. Published list pricing runs from $15 per employee per month at the smallest organisations to $5.25 at the largest.
The metric does not count installations, cores or users. It counts people, including full-time, part-time and temporary staff, plus contractors and consultants supporting internal operations, whether or not they touch Java. One qualifying Oracle JDK install can price an entire workforce.
Licensing analysts benchmark an average cost increase of roughly 340% against the old processor-based model. A typical claim is built as employee count multiplied by list price, with back-license periods reaching to January 2023. A 5,000-employee company opens above $2.5 million at list.
2026 tightens it further. Oracle JDK 21’s free support window closes around September, and JDK 17 Premier Support ends the same month. The employee-based subscription is now the only model Oracle sells. Azul’s survey found 81% of organisations migrating at least part of their Oracle Java estate to a non-Oracle OpenJDK distribution, with cost the top driver and 21% already audited.
The enterprise Java estate nobody can see
Here is the part that connects to the AI story. Most organisations cannot say which of their Java code actually runs.
Azul estimates up to 50% of enterprise Java codebases may be unused. For an organisation with 100 developers, it argues, maintaining that dead code consumes the capacity of five full-time employees. Its survey found 63% saying dead or unused code hurts productivity.
The distinction that matters is between code that could run and code that does. Static analysers answer the first question. They flag Spring beans that are wired but never invoked, feature-flagged modules that were gated off and forgotten, and reflection-driven components that look reachable. Runtime data answers the second.
That gap is not cosmetic. Unused code carries dependencies, and dependencies carry vulnerabilities.
Why the security noise is worse than it looks
Java’s dependency surface is enormous. Research puts open-source dependencies at an average of 71% of the code in typical Java projects.
That makes scanning hard, and the scanning itself has a known blind spot. A study of the 1,808 most popular Java Maven projects found 899 of them, just under half, included at least one modified known-to-be-vulnerable dependency. Across those projects, researchers identified 7,712 unique CVE entries that metadata-based scanners missed, because re-bundling and re-packaging strip the metadata those tools read.
That explains a figure in Azul’s survey that otherwise looks strange. Fifty-six percent of organisations deal with Java-related CVEs daily or weekly, up from 41% a year earlier. Yet 30% say their teams waste more than half their time on false positives. Teams are drowning in alerts, and the alerts are not always about code that runs.
AI is now writing the Java too
The loop closes here. Thirty percent of respondents to Azul’s survey said more than half of their new Java code is created by AI tools, with ChatGPT the most cited.
That raises a question the tooling does not yet answer well. If AI writes a large share of the code, and most organisations cannot see which code executes, then provenance and runtime visibility become the same problem. You need to know what the model produced and whether it ever ran.
The performance lever
There is a cost story that does not involve Oracle at all. Azul’s survey found 97% of organisations taking action to reduce public cloud spend, with high-performance Java platforms among the top five strategies. It also found 74% reporting more than 20% unused compute capacity.
Faster runtimes mean the same workload on fewer instances. That is the argument for Azul Prime, Alibaba’s Dragonwell AI Extension and Oracle’s own Java 26 enhancements alike. It is also, conveniently, the argument each vendor makes for its own product.
The India angle
India is where a lot of this estate is maintained. Java is described as the largest backend stack in the country by a wide margin, with banks, enterprises, global capability centres and product companies holding decades of production Java investment.
That makes the licensing question sharper locally. A senior Java developer in India costs roughly $36,000 to $45,000 a year, against $130,000 to $175,000 in the United States. The Oracle metric prices employees, not developers, so a large Indian workforce with a modest Java footprint can generate a bill out of proportion to the code it runs.
The counterargument
The claim that Java is becoming the control plane for enterprise AI deserves scepticism. Python still leads for training, research and prototyping, and the pragmatic pattern most teams describe is to train in Python and serve in Java.
The Java Community Process’s own material concedes the point. It argues Java’s three decades of compressed insight are well suited to AI work, then notes that quantifiable evidence is in short supply, and that nobody yet knows what makes a language platform preferable for a given model.
So the honest position is narrower than the marketing. Java is where enterprise data and transactions already live, which makes it a sensible place to run AI in production. It is not where the models are built.
What to watch
Three signals. Whether runtime visibility becomes standard, because the licensing and security cases both depend on knowing what executes. Whether the Oracle migration wave completes before the 2026 support deadlines force the decision. And whether the AI-generated code share keeps climbing without a matching rise in review and provenance tooling.
The estate nobody can see is the one that decides the bill.
Editor’s Note
This analysis draws on Azul’s October 2026 release and its 2026 State of Java Survey & Report, Oracle’s Java SE subscription documentation, published Oracle Java licensing analysis, the Java Community Process’s Java for AI material, Oracle’s Java 26 release coverage, independent research on Java dependency and vulnerability detection, and published data on Java adoption and the Indian developer market. Where a figure or claim is a company’s own, we say so.