Azul Payara 7: AI-Ready, Audit-Defensible, No Rewrite Required 

What ships in Azul Payara 7 today

Azul Payara 7 and Azul Payara Micro 7 are generally available as of May 2026. Azul Payara Server 7 is the first commercially supported Jakarta EE 11 runtime certified across all three profiles (Full Platform, Web Profile, and Core Profile) at GA. Built on Java SE 21 LTS and Java SE 25, it enables enterprises to adopt AI workloads, defend production systems under regulatory audit, and modernize for cloud-native deployment without rewriting existing Jakarta EE applications. Azul Payara Micro 7 carries Jakarta EE 11 Web Profile and Core Profile certifications, scoped to the cloud-native deployment model. Both ship with Java SE 21 LTS and Java SE 25 support, and the Azul Zulu JDK bundled under the same Azul contract as the application server. 

Oracle WebLogic and IBM WebSphere Traditional have not delivered Jakarta EE 11 certification. IBM WebSphere Liberty submitted full-platform Jakarta EE 11 certification in May 2026, after Payara 7’s GA release. 

Jakarta EE 11 runtime comparison

Runtime	Jakarta EE version	Jakarta Concurrency 3.1 (container-managed virtual threads)	Jakarta Data 1.0	Patch cadence	Commercial support
Azul Payara 7	EE 11 (Full, Web, Core)	Yes	Yes	Monthly	Yes (Azul; CNA)
Oracle WebLogic 15.1.1	EE 9.1 (latest GA)	No (EE 9.1 predates 3.1)	No	Quarterly CPU	Yes (Oracle)
IBM WebSphere tWAS V9	Java EE 7	No (pre-Jakarta)	No	Variable	Yes (IBM)
Red Hat JBoss EAP 8.1	EE 10	No (EE 10 ships Concurrency 3.0)	No	Per release	Yes (Red Hat)
IBM WebSphere Liberty 26.0.0.5	EE 11 Full Platform (cert. submit-ted May 2026, after Payara 7 GA)	Yes	Yes	Per release	Yes (IBM)
Eclipse  GlassFish 8	EE 11 (Full, Web, Core; Reference Implementation)	Yes	Yes	Community	Eclipse Community Project
WildFly 40	EE 11 implementa-tion in standard distribution	Yes	Yes	Community	Via JBoss EAP
Spring Boot 4.x	Not Jakarta EE certified	No (uses Spring’s concurrency model)	No (Spring Data is a separate API family)	Per release	Broadcom Tanzu

Sources: vendor product pages and release notes, May 2026.
CNA = CVE Numbering Authority.
Jakarta Concurrency 3.1 introduced standardized container-managed virtual threads in Jakarta EE 11; runtimes on Java SE 21+ still have Java’s general virtual threads available, but without Jakarta EE programming-model integration. 
WildFly is the upstream community project for Red Hat JBoss EAP and is not separately listed on the Jakarta EE Compatible Products page.
Open Liberty is the upstream community project for IBM WebSphere Liberty; certification submissions are filed separately for each. 

The three questions enterprise Java estates are asking right now

Three conversations are happening across enterprise Java estates today, each driven by a different stakeholder. 

• The board is asking the executive team how the company is using AI. Engineering responds with model providers, vector databases, and a Python service running alongside the existing Java estate. Procurement raises a different concern: vendor concentration. 
• The security team is reading the latest critical CVE in a Java EE specification implementation and asking who is on call to patch it across the estate. The answer depends on the version of the application server in production, the support contract attached to it, and the CVE response process the vendor has published. 
• The cloud transformation team has a project plan for rewriting a working Jakarta EE application to Spring Boot. The justification cites cloud-native deployment, microservices, and the modern Java framework story. The budget is 6 to 18 months of engineering time per application. 

Azul Payara 7 answers all three on the same platform. The major alternatives, taken in turn below, each fall short on at least one of the three. 

AI adoption on the Jakarta EE stack you already run

The dominant narrative says AI lives in a Python service alongside the Java monolith. That narrative produces working demos and runs into the operational reality nobody wanted: a second runtime alongside Java, with its own security perimeter, deployment pipeline, and on-call rotation, all to support one new feature category. 

The Jakarta EE 11 specification adds the two pieces that anchor a Java-native AI workload, and Azul Payara 7 ships both today. 

• Container-managed virtual threads. Jakarta Concurrency 3.1 in Azul Payara 7 provides container-managed virtual threads on JDK 21 and JDK 25. The application code that calls an AI model uses the same blocking, synchronous style your engineers already write. The runtime handles thousands of concurrent model calls without hand-tuned thread pools. The throughput risk of scaling AI workloads on traditional thread pools is moved into the platform. 
• Jakarta Data 1.0 for the AI data layer. Retrieval-augmented generation, the dominant enterprise AI pattern, needs a data layer that can store text and vector embeddings, query both relational and semantic data, and paginate through results. Azul Payara 7 ships Jakarta Data 1.0, which lets the application define a repository interface once and run it against PostgreSQL with pgvector, a document store, or any of the standard data backends. The AI data layer reuses the persistence patterns your developers already write. 
• What the alternatives ship. Each major commercial Java runtime falls short of the Jakarta EE 11 AI surface in a different way. Oracle WebLogic 15.1 sits at Jakarta EE 9.1 (the 2021 specification), which predates both Jakarta Concurrency 3.1 and Jakarta Data 1.0. IBM WebSphere Traditional V9 is supported on IBM SDK Java SE 8, which rules out virtual threads entirely (a Java SE 21 capability). Red Hat JBoss EAP 8.1 ships Jakarta EE 10 with MicroProfile gated behind the separate EAP XP 6.0 product subscription. Spring Boot is a different category: a single-vendor framework rather than a Jakarta EE runtime, and its AI surface is Spring AI and Spring Data, both Spring-specific. 

The existing Jakarta EE application hosts the AI capability, so the operations team gains a feature category without absorbing a second runtime. 

High velocity patches for security and compliance in the age of AI

The security and compliance question every enterprise asks at every renewal is the same: when a critical CVE is uncovered in the runtime that hosts our applications, what is the vendor’s response and how fast does the patch reach production? 

Azul Payara 7 ships with the operational answer to that question already in place. 

• Registered CVE Numbering Authority. Azul is an authorized CVE Numbering Authority (CNA) participating in the CVE Program administered by MITRE under CISA and DHS oversight. The CNA status means Azul publishes authoritative cybersecurity vulnerability information about Payara products through the official CVE Program rather than relying on third-party disclosure. 
• Monthly security patches on a published schedule. Every supported major version (Payara 4, 5, 6, and 7) receives monthly security patches on a calendar your security team can plan against. The May 2026 release window had a critical security vulnerability patched across all four supported versions simultaneously, including Payara 4, which has been in production for years. 
• Multiphase product lifecycle, published per major version. The Azul Payara lifecycle is structured into three phases (Full Support, Extended Support, and optional Lifetime Support), with dates published per major version on the Payara product lifecycle page. The procurement team can verify the support window for their production deployment against a public policy rather than a salesperson’s promise. 
• One Azul contract for the runtime and the JDK. Java SE 21 LTS and Java SE 25 ship under the same Azul subscription as the application server. Procurement, security, and on-call see one vendor relationship rather than two, which removes the cross-vendor escalation path that surfaces when an incident spans the runtime and the JVM underneath. 
• What the alternatives ship. Eclipse GlassFish 8.0 Final (February 2026) is the Jakarta EE 11 Reference Implementation, but the Eclipse Foundation does not provide a commercial support contract, and the specialist consultancies that offer paid backing for GlassFish operate at a niche scale relative to first-party enterprise support. WildFly is a community project whose only commercial path is buying Red Hat JBoss EAP, a separate product subscription. Oracle WebLogic delivers CVE response on a quarterly Critical Patch Update cadence. IBM WebSphere uses per-processor licensing with mandatory compliance tooling that, if misconfigured, triggers billing at the server’s full processor capacity. 

Azul Payara’s security policies move with the application into the next regulatory audit, with monthly patch evidence already on the calendar. 

Cloud modernization without the Spring Boot rewrite

A rewrite proposal is on the table, framed as modernization and budgeted at six to eighteen months of engineering time per application. Before the proposal reaches the next budget meeting, the structural question is worth asking: which part of the modernization goal requires rewriting the application, and which part is a deployment shape that can be changed under the existing application? 

For most of the modernization goals the rewrite proposal is invoking, the answer is the deployment shape rather than the code. The rewrite typically targets packaging (executable JAR instead of WAR), runtime location (containers and Kubernetes instead of traditional infrastructure), or scaling topology (microservices instead of a monolithic deployment). All three are runtime concerns. None of them touches the business logic, the persistence layer, or the security boundary inside the application. The three sub-points below trace this distinction through the actual mechanics. 

• Cloud-native deployment is a runtime capability. Azul Payara Micro 7 is a single executable JAR with two-to-five-second startup, built for Docker containers and Kubernetes. The same .war that runs on Azul Payara Server runs on Azul Payara Micro without modification. The deployment command is one line: java -jar payara-micro.jar –deploy your-app.war. Cloud-native, in the deployment-shape sense, ships under the existing Jakarta EE application. 
• Spring Boot is a framework, not a runtime. Rewriting an application to Spring Boot replaces every layer that touches Jakarta EE: controllers move from JAX-RS to Spring MVC, services from CDI to Spring beans, persistence from JPA configurations to Spring Data, security from Jakarta Security to Spring Security. The new application depends on Spring-specific annotations and libraries that do not run on any other framework without another rewrite. The standards portability the Jakarta EE application has today is traded for Spring concentration. 
• A one-day proof of concept settles the deployment question. Take a production application, deploy it to Azul Payara Micro 7 in a container, and run it on the customer’s existing Kubernetes distribution. Either the application runs cloud-native on the existing code, or the rewrite case is justified by the same one-day measurement. 
• What the alternatives ship. Spring Boot is a framework with no Jakarta EE certification, so the rewrite cost is exactly what the proposal is asking the budget to fund. WebSphere Liberty has the cloud-native deployment shape; its Jakarta EE 11 Full Platform certification was submitted in May 2026 after Payara 7’s GA. JBoss EAP 8.1 ships on Jakarta EE 10 with Galleon-based provisioning, a Maven BOM rename, and mandatory Security Realms migration to Elytron, which adds its own learning curve to any move from EAP 7. Oracle WebLogic has no microservice product line equivalent to Payara Micro, and Quarkus is a framework with selective Jakarta EE specification support that is not Jakarta EE certified as a whole. 

The modernization mandate is satisfied by changing the deployment shape, which preserves the application’s standards portability and avoids the 6-to-18-month engineering cost of a full rewrite. 

Four questions to ask your engineering leadership before the next budget meeting

The strategic position today: Azul Payara 7 was the first commercially supported Jakarta EE 11 runtime certified across all three profiles at GA. IBM WebSphere Liberty 26.0.0.5 submitted full Jakarta EE 11 Platform certification in May 2026 after Payara 7’s release. Oracle WebLogic, IBM WebSphere Traditional, and Red Hat JBoss EAP have not delivered Jakarta EE 11. If a Spring Boot rewrite or a Python AI service is on the table, ask these four questions before the budget is signed off. 

1. Has the team deployed the existing application to Azul Payara Micro 7? 
If the answer is no, the rewrite proposal is premature. A one-day proof of concept validates whether the existing application runs cloud-native on the same Jakarta EE code. 

2. What is the total cost of the rewrite, including dual maintenance? 
Factor in the team maintaining the old system, the team building the new one, the parallel QA cycle, and the production incidents the new build will generate that the old one does not. Compare that to a runtime migration that takes days. 

3. Which AI capabilities does the roadmap actually need, and which of them are in Jakarta EE 11 today? 
Virtual threads in Jakarta Concurrency 3.1 handle the concurrency of model calls, and Jakarta Data 1.0 handles the AI data layer. WebLogic, WebSphere Traditional, and JBoss EAP do not ship Jakarta EE 11 at all, so the AI roadmap on those runtimes is a roadmap to find elsewhere. 

4. What is the vendor’s security program and lifecycle policy in writing? 
Azul Payara is a registered CVE Numbering Authority with monthly security patches across all supported versions and a multiphase lifecycle published per major version. Spring Boot’s open-source support window is 13 months per minor release, and commercial support requires a Broadcom Tanzu Spring subscription on top of an OpenJDK distribution. 

Frequently asked questions

What is Azul Payara 7? 
Azul Payara 7 is a commercially supported Jakarta EE 11 application server, generally available as of May 2026. It was the first commercially supported runtime certified across all three Jakarta EE 11 profiles (Full Platform, Web Profile, and Core Profile) at GA, and ships with Java SE 21 LTS and Java SE 25 support under a single Azul subscription. 

Was Azul Payara 7 the first commercially supported Jakarta EE 11 runtime certified across all three profiles? 
Yes. Azul Payara 7 was the first commercially supported runtime certified across all three Jakarta EE 11 profiles at GA (May 2026). IBM WebSphere Liberty 26.0.0.5 submitted full Jakarta EE 11 Platform certification in May 2026, after Payara 7’s release. Oracle WebLogic 15.1.1 is at Jakarta EE 9.1 and IBM WebSphere Traditional V9 is at Java EE 7. No other vendor had all three profiles certified at the Payara 7 GA launch. 

How does Azul Payara 7 support AI workloads on Java? 
Azul Payara 7 ships two Jakarta EE 11 capabilities that anchor Java-native AI workloads. Jakarta Concurrency 3.1 provides container-managed virtual threads for handling thousands of concurrent model calls. Jakarta Data 1.0 provides a repository-pattern data layer that supports vector embeddings and retrieval-augmented generation (RAG) without adding a second runtime. 

How does Azul Payara 7 handle security patches and CVE response? 
Azul is a registered CVE Numbering Authority (CNA) under CISA and DHS oversight. Every supported major version of Payara, including versions 4, 5, 6, and 7, receives monthly security patches on a published calendar. The product lifecycle (Full Support, Extended Support, Lifetime Support) is documented per major version at the Azul Payara lifecycle page. 

Can I deploy Azul Payara 7 in containers and Kubernetes without rewriting my application? 
Yes. Azul Payara Micro 7 is a single executable JAR with two-to-five-second startup, designed for Docker containers and Kubernetes. The same .war file that runs on Azul Payara Server runs on Payara Micro without modification using a one-line deployment command. Cloud-native deployment is a runtime capability rather than a rewrite requirement. 

What is the difference between Azul Payara Server 7 and Azul Payara Micro 7? 
Azul Payara Server 7 is certified across all three Jakarta EE 11 profiles (Full Platform, Web Profile, Core Profile) and is designed for traditional and hybrid deployments. Azul Payara Micro 7 carries Web Profile and Core Profile certifications and is scoped to cloud-native deployments in containers and Kubernetes. Both ship under the same Azul contract and bundle the Azul Zulu JDK. 

What to do next

• Request an Azul Payara 7 evaluation. Azul’s field engineering team will run an architecture review against your current applications and infrastructure. 

• Run a one-day proof of concept. Take one production application, deploy it to Azul Payara Micro 7 in a container, and measure the result. 

• Share this with your engineering leadership. If a Spring Boot rewrite, a Python AI service, or an audit conversation is on the roadmap, the alternative is worth evaluating before the budget is approved.