Java Licensing, OpenJDK & Support
Last reviewed by Tyler Eastridge
AceMQ helps enterprises that run Java in production leave Oracle Java SE subscription pricing, choose an OpenJDK distribution (Eclipse Temurin, Amazon Corretto, Azul Zulu, the Red Hat build or the Microsoft build), plan moves between LTS releases, and keep the runtimes supported 24/7 with a 15-minute emergency response. AceMQ is distribution-neutral: it ships no JDK, produces no JDK patches and gives no licensing advice, so your Oracle agreement and your own counsel stay the reference for the licensing question.
A senior engineer, not an SDR. No sales sequence attached.
Without rewriting your applicationsFor production incident cover, see AceMQ Java 24/7 support.
Customers
Partners
The Problem
Eight Java problems that teams bring to AceMQ, from a letter from Oracle nobody can answer to a service that restarts with exit code 137. If one describes your quarter, that is where the work starts.
Oracle has written to you about Java SE and nobody can say how many Java installs the company has, or on which hosts
An Oracle JDK 8 or 11 build went into a base image years ago and nobody knows which services still run it
A Java SE subscription is counted per employee, so the quote follows headcount rather than how much Java you actually run
Temurin in CI, Corretto on AWS, Oracle JDK on the data center servers: three builds and no owner for the standard
Java 8 is still in production because a library, an app server or a vendor product has not moved on
The 8 to 17 or 21 upgrade stalls on removed Java EE modules, strong encapsulation errors and a library nobody maintains
Services that ran fine on the old JDK restart with exit code 137 after the base image changes
Nobody can say who to call at 3am when the JVM itself crashes or a TLS handshake fails after a JDK change
A good fit if you run Java in production across many services and need an inventory, a vendor-neutral view of the OpenJDK options, or senior engineers on call for the JVM layer.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy Java.
How it breaks, and the fix
A new base image brings a newer JDK and pods start restarting with exit code 137. The heap is not full and the log shows no OutOfMemoryError, because the container was killed from outside the JVM. How the heap was sized against the container limit decides whether the rollout holds.
Rollout of a new JDK image
One deployment, three pods, a memory limit on each
Three pods run on the old JDK. Each has a container memory limit and a heap setting that fits inside it, so memory use is steady and nothing restarts.
The new image rolls out. Pods 1 and 2 restart with exit code 137: heap plus metaspace, thread stacks, code cache and direct buffers pass the container limit, and the kernel kills the process. The heap itself was never full, so the application log is silent.
The rollout is paused and the heap is resized as a percentage of the container limit, with room left for memory outside the heap. Native Memory Tracking confirms where the rest goes, and the rollout resumes pod by pod.
The JVM sizes its default maximum heap as a quarter of the container's memory limit, and teams then raise it with -Xmx or -XX:MaxRAMPercentage until the heap alone nearly fills the limit. Metaspace, thread stacks, the JIT code cache, direct buffers and native libraries live outside the heap, so total memory passes the limit while the heap still has room, and the kernel kills the process. Java 8 builds before 8u191 did not read container limits at all and sized the heap from the host's memory, so an upgrade can change behavior in either direction. The fix is set long before the rollout: a heap percentage that leaves headroom, Native Memory Tracking switched on in a test run, a capped thread count, and GC and CPU settings checked against the container's real CPU limit, because by default a container with fewer than two CPUs or about 1.8 GB of memory gets the Serial collector.
Our Services
AceMQ runs five Java service lines: estate inventory, OpenJDK distribution selection, Oracle JDK to OpenJDK migration, 24/7 runtime support and a fixed-scope runtime health check. Support can follow any of them. AceMQ ships no JDK and gives no licensing advice.
A written record of every Java runtime in the estate, so a licensing, patching or migration decision starts from facts rather than recollection.
A neutral comparison of Temurin, Corretto, Zulu, the Red Hat build and the Microsoft build against your platforms, release lines and support needs.
Moving services from Oracle JDK to a chosen OpenJDK build, and from one LTS release to the next, in pilots and waves with a rollback for each.
24/7 engineers for the JVM layer in production: crashes, memory and GC problems, TLS and certificate failures, and LTS upgrades that go wrong.
The fixed-scope entry engagement: a written report on how your JVMs are configured and what they are running on, which your team can act on with or without AceMQ.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ Java support gives you an AceMQ engineer and a 15-minute first response when a JVM is crashing or failing in production, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. JDK patches still come from your distribution vendor: AceMQ does not produce them.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
How It Works
An AceMQ Java engagement runs in four stages: a scoping call with a quote within 1 hour, an inventory, a written plan, then migration waves or ongoing cover. Each stage ends in writing.
Quote within 1 hour
A senior AceMQ engineer asks what you run: Java versions and builds, how they are packaged, where they run, what sits on top (Tomcat, Spring Boot, Kafka, vendor products) and what has prompted the question. A quote request is answered within 1 hour.
Scoped per estate
Every JDK and JRE found on hosts, container images, CI agents and inside bundled products, listed by version, vendor build, update level and the application that uses it. This is the technical record your licensing and legal people work from.
Scoped per estate
A recommendation in writing: which distribution or distributions, which LTS release per application, the order of migration and the risks found on the way. Options are compared on what your estate needs, not on what AceMQ sells.
Ongoing or fixed scope
Pilot services first, then the rest in waves. The work ends with a standard base image, a scan that catches stray installs, and a runbook for the next update. You can stop there or add 24/7 cover.
A senior engineer, not an SDR. No sales sequence attached.
Leaving Oracle Java SE
Oracle sells the Java SE Universal Subscription by an employee-based metric, and its price list counts full-time, part-time and temporary employees, plus the employees of contractors and outsourcers who support internal operations, whether or not they use Java. That is why the first question is a technical one: what is running, and where.
Find every runtime
Scan hosts, container images, CI agents and vendor products that bundle their own JRE. Record vendor, version and update level for each. A build labeled OpenJDK and an Oracle JDK look alike on a host, so the scan reads the java.vendor property and the release file, not the directory name.
Your agreement
Which Oracle releases and update levels you may run, and under which license, is a question for your Oracle agreement and your counsel. AceMQ gives no licensing advice. It supplies the technical facts: what runs where, since which update, and what a replacement would have to match.
Pilot
Pick the build, then run it against low-risk services first. From JDK 11 on, Oracle's JDK and OpenJDK builds come from the same source, so the differences are mostly license, packaging and support. On Java 8 the bundled tools differ more, so the test plan is longer.
Roll out and hold the line
Replace the JDK in base images and installers, block unmanaged Oracle JDK downloads in CI, and keep the scan running so a stray install does not reappear after the next team spins up a container.
Typical engagements
Typical Java engagements from AceMQ: what the environment looks like, what AceMQ assesses or changes, and what the engagement delivers. Each card links to the full write-up.
Mid-Sized Distribution Company
A typical engagement for a company that wants to leave an Oracle Java SE subscription or avoid one: inventory every Java runtime, compare OpenJDK distributions against the estate, and write the migration plan.
JavaOpenJDK
Docker
KubernetesSaaS Platform Team
A typical engagement for Java services that restart with exit code 137 after a base image brings a newer JDK: the heap is not full, no OutOfMemoryError appears, and the memory that matters lives outside the heap.
JavaKubernetesDocker
Prometheus
SaaS Observability Vendor
Ongoing 24/7 support for an Elasticsearch estate suffering repeated parent circuit breaker trips and long garbage collection pauses under aggregation load.
Elasticsearch
KibanaKubernetesJava
Global Payments Processor
Assessment of APM instrumentation coverage and trace completeness across a service estate where distributed traces kept breaking at service boundaries.
Datadog
OpenTelemetryKubernetesJava
Python
Digital Commerce Platform
Remediation of application latency and memory growth traced to APM agent configuration on the customer's own JVM and container estate.
New RelicJavaKubernetes
LinuxInsurance Services Provider
Ongoing support for distributed tracing across a mixed New Relic and OpenTelemetry estate where traces broke at instrumentation boundaries.
New RelicOpenTelemetryJava.NETKubernetesSolutions
AceMQ covers Java end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed Java on your infrastructure and fully managed Java on AceMQ infrastructure, plus end-of-life versions.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running Java for you.
Compare the four Java support tiersSide by side
Oracle's subscription bundles its JDK builds, updates and support under one per-employee price. The alternatives split those three things: a build vendor supplies the JDK and its updates, and AceMQ supplies the engineers who run it in production. Each row below answers one question about the choice.
| Question | Oracle Java SE subscription | OpenJDK build with vendor support (Azul, Red Hat and others) | Free OpenJDK build (Temurin, Corretto, Microsoft) with AceMQ |
|---|---|---|---|
| How is it priced? | Per employee across the whole organization, including staff of contractors and outsourcers who support internal operations, whether or not they use Java (Oracle price list, 8 October 2026). Oracle sets the numbers and AceMQ does not reprint them. | Set by each vendor, often by server or core rather than headcount. Ask each vendor for a quote for your estate. | No license fee for the JDK. AceMQ support is a separate contract, quoted on request. |
| Where do security updates come from? | Oracle, while the subscription runs and the release is in Premier or Extended Support. | The vendor, on its own published schedule for each LTS release. | The publisher of the build: the Eclipse Adoptium project for Temurin, Amazon for Corretto, Microsoft for its build, each on its own published dates. AceMQ produces no JDK patches. |
| Who answers when the JVM crashes at 3am? | Oracle Support, through a service request, for the Oracle JDK builds the subscription covers. | The vendor, for defects in its own build. | An AceMQ engineer within 15 minutes, 24/7, for diagnosis and operations. A defect that needs a JDK code fix goes to the OpenJDK project or the build vendor, because AceMQ does not patch the JDK. |
| What do you have to change? | Nothing. This is the option that needs no migration. | Replace the JDK in images and installers with the vendor's build, then test TLS, truststores and default settings. | The same replacement, plus an update routine you own. AceMQ writes the plan and the standard stays with your team. |
| How long can you stay on Java 8? | Extended Support to December 2030, per Oracle's support roadmap. | Azul lists Java 8 production support to December 2030. Red Hat's full support for OpenJDK 8 ends on 30 November 2026 and optional paid Extended Life Cycle Support (ELS-1) runs to 31 December 2032. | Eclipse Temurin 8 is supported at least until December 2030. Amazon Corretto 8 reaches end of life in December 2030. |
| When does it fit? | You want one vendor accountable for the JDK and you accept per-employee pricing. | You want a vendor to stand behind the JDK with an SLA, and you want to leave Oracle. | Your team applies updates routinely, runs on Kubernetes or a cloud that publishes its own build, and wants senior engineers on call rather than a second JDK contract. |
For support dates by release and vendor, read Java LTS versions and end-of-life dates by vendor.
One partner, not five
Java rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
Guides from AceMQ engineers on Java LTS dates and support options, plus the AceMQ services around the runtime: Tomcat, Spring Boot, Kubernetes and end-of-life software support.
FAQs
Five answers on Java from AceMQ: the Oracle question, distribution choice, code changes, LTS targets and what AceMQ does not sell.
Still have questions about Java? Email an Expert
AceMQ cannot answer that, because it gives no licensing advice: your Oracle agreement and your counsel decide. The facts that matter are these. Since 23 January 2023 Oracle sells Java SE through the Universal Subscription, priced per employee across the organization, and Oracle's roadmap says Oracle JDK 8, 11, 17 and 21 updates fall under the Java SE OTN license, which is free only for personal and development use. Oracle JDK 25 is free under Oracle's No-Fee Terms and Conditions (NFTC) license. AceMQ's part is the inventory that shows what you actually run.
It depends on where you run Java and who you want to call. Eclipse Temurin, Amazon Corretto and the Microsoft build are free to download and run, and each vendor says where its own commercial support applies: Microsoft's, for example, covers only Azure customers with a support plan, on Azure workloads. Azul and Red Hat sell commercial support for their builds. AceMQ is neutral because it sells none of them: the written plan compares them on your platforms, release lines and support needs.
Usually the application code does not change, but the surrounding configuration can. From JDK 11 on, Oracle's JDK and OpenJDK builds come from the same source. What changes is the truststore contents, default security properties, bundled tools and the base image. On Java 8 the differences are larger. That is why the work runs as a pilot on low-risk services before any wave.
Java 17, 21 and 25 are the LTS releases to plan around, and Oracle's roadmap lists the next planned LTS as Java 29 in September 2027, dates subject to change. Frameworks set a floor: Spring Boot 3 needs Java 17, and Apache Kafka 4.0 brokers need Java 17. Moving straight from 8 to 21 or 25 means one migration instead of two, but only if every library on the path supports it. The written plan sets the target per application.
No. AceMQ ships no JDK, produces no JDK patches, offers no license audit defense and is not a reseller of Oracle Java SE or of any distribution. Security updates come from the vendor of the build you run. AceMQ provides the engineers: the inventory, the plan, the migration work and 24/7 support for the runtime in production, alongside your distribution vendor's support if you buy it.
Yes. AceMQ works on Java in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your Java environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Java is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer reviews your Java estate, tells you what to inventory first, and quotes the work. Quote requests are answered within 1 hour.
Production incident right now?Email a Java Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
