Java Support
Last reviewed by Tyler Eastridge
AceMQ provides 24/7 Java support for production JVMs on Java 8, 11, 17, 21 and 25, on Oracle JDK or any OpenJDK build: an AceMQ engineer on a live bridge within 15 minutes of a P1, a written root-cause analysis after each one, and help with JVM crashes, memory and GC problems, TLS and certificate failures, and moves between LTS releases. AceMQ is distribution-neutral and produces no JDK patches, so security updates still come from the vendor of the build you run.
Support quotes answered within 1 hour, by a senior engineer.
Planning a build, upgrade or migration instead? See AceMQ Java consulting and services.
Customers
Partners
Incident Triage
Common symptoms in Java production environments, and the first thing an engineer checks when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| Pods restart with exit code 137 and the heap is not full | The container memory limit against the heap setting (-Xmx or MaxRAMPercentage), then everything outside the heap. We switch on Native Memory Tracking and read jcmd VM.native_memory, then count threads (stack size times threads), direct buffers, metaspace and the code cache. An OutOfMemoryError never appears because the kernel, not the JVM, ended the process. | Heap as a percentage of the limit with headroom, and caps on threads and direct memory |
| java.lang.OutOfMemoryError: Java heap space | A heap dump taken at the failure (-XX:+HeapDumpOnOutOfMemoryError), read by retained size to see what holds the memory. We separate a leak that grows without bound from a heap that is too small for the working set and from one request that loads far too much. | Fix the retaining reference or the query, or size the heap to the working set |
| OutOfMemoryError: Metaspace after redeploys | Class loader statistics from jcmd and the class count over time. On application servers and hot-redeploy setups the usual cause is an old class loader kept alive by a thread, a driver registration or a static cache, so each redeploy leaks the whole application's classes. | Remove the reference that pins the old loader, then set a metaspace cap |
| Latency spikes and long garbage collection pauses | GC logs (-Xlog:gc* on JDK 9 and later, -XX:+PrintGCDetails on Java 8) lined up against request latency. We compare pause length with allocation rate and look for humongous allocations on G1. We also check which collector the JVM actually picked, since Java 8 defaults to Parallel and JDK 9 and later to G1. | Heap and region sizing, or a change of collector |
| The JVM dies with a fatal error and an hs_err_pid file | The crashing frame in hs_err_pid: native library, JIT-compiled code or the JVM itself, plus the signal, the loaded libraries and the operating system and glibc level. A crash inside a JNI library points at that library; a crash in compiled code points at a JDK defect. | Native library update, or a JDK update or compiler workaround |
| SSLHandshakeException or PKIX path building failed after a JDK change | Which truststore the process really loads. A new JDK ships its own cacerts, so certificates imported into the old one are gone, and newer updates disable older protocols and algorithms through jdk.tls.disabledAlgorithms. We trace with -Djavax.net.debug=ssl:handshake. | Import the certificate into the right truststore, or update the peer that offers a disabled protocol |
| Startup fails after 8 to 17: InaccessibleObjectException or ClassNotFoundException for javax.xml.bind | Whether the failure is strong encapsulation or a removed module. JDK 17 denies reflective access to JDK internals that Java 8 allowed, and JAXB, JAX-WS and other Java EE modules left the JDK in 11. The stack trace names the package or class, and the dependency tree shows who needs it. | Upgrade the library, add the dependency, or --add-opens as a stopgap |
| High CPU with the application idle, or one core pegged | Repeated thread dumps (jcmd Thread.print) to separate application threads from GC and JIT compiler threads, then the container CPU quota against what availableProcessors reports. A runaway loop, a collector with too many threads for the quota and compilation churn look the same in top. | Fix the loop, or set the CPU count and GC threads to match the quota |
Typical resolution describes the usual fix for each symptom. Every P1 closes with a written root-cause analysis.
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
A JVM that is down, crash-looping, out of memory or failing every request. An AceMQ engineer joins a live bridge within 15 minutes, 24/7, to diagnose from heap dumps, GC logs, thread dumps and crash files, not to acknowledge a ticket.
Every P1 closes with a written RCA: what failed, why, the fix applied and the setting or code change that prevents a repeat. Delivered as standard, not on request.
Moves from Java 8 or 11 to 17, 21 or 25, with the library, framework and flag changes found and rehearsed on a copy before production. Frameworks set floors: Spring Boot 3 needs Java 17, and Apache Kafka 4.0 brokers need Java 17.
Which of your JDK builds are inside their vendor's support window, which are not, and what that means for security updates. Dates are read from each vendor's own page, not from a summary.
Heap, GC and thread settings checked against the container's real memory and CPU limits, with Native Memory Tracking to find what lives outside the heap.
Truststores, default security properties and disabled algorithms checked across the JDK builds in use, so the next base image change does not break a handshake.
Why AceMQ
The same AceMQ engineers stay on your account and learn which services run which JDK, so a P1 starts with a hypothesis rather than an interview.
You reach a senior engineer directly by phone, email or Slack. No queue collecting details to relay, and no approval between you and someone who can read a heap dump.
AceMQ sells no JDK, so it has no reason to steer you to Temurin, Corretto, Zulu, the Red Hat build, the Microsoft build or Oracle. It supports the one you run.
AceMQ produces no JDK patches and says so before you sign. A defect that needs a JDK code fix goes to the build vendor or the OpenJDK project, and we help you build the case.
Most Java incidents involve the application server or framework as much as the JVM. The same team covers Tomcat and Spring Boot, so the diagnosis does not stop at the runtime boundary.
Java sits next to Kafka, RabbitMQ, Elasticsearch and PostgreSQL in most estates. One AceMQ contract and SLA can cover them, with multi-technology discounts.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Version coverage
Each vendor sets its own dates for each LTS release. AceMQ supports all of these runtimes 24/7. The security updates come from the vendor, and AceMQ plans which release you should be on and when.
| Java LTS release | Oracle Java SE Extended Support until | Eclipse Temurin supported until (at least) | Amazon Corretto end of life | Red Hat build of OpenJDK, full support and end of paid ELS-1 | Microsoft Build of OpenJDK earliest end of support | Azul Core (Zulu) production support until |
|---|---|---|---|---|---|---|
| Java 8 | December 2030 | December 2030 | December 2030 | 30 November 2026 and 31 December 2032 | No Microsoft LTS build; limited Azure use of Temurin 8 | December 2030 |
| Java 11 | January 2032 | October 2027 | January 2032 | 31 October 2024 and 31 January 2032 | September 2027 | January 2032 |
| Java 17 | September 2029 or later | October 2027 | October 2029 | 31 December 2027 and 31 January 2029 | September 2027 | September 2029 |
| Java 21 | September 2031 or later | December 2029 | October 2030 | 31 December 2029 and 30 September 2031 | September 2028 | September 2031 |
| Java 25 | September 2033 or later | September 2031 | October 2032 | 31 December 2030 and 30 September 2033 | September 2030 | September 2033 |
Sources, all read on 31 October 2026: Oracle Java SE Support Roadmap (updated 20 October 2026); Eclipse Adoptium support page, which promises at least four years for LTS releases; Amazon Corretto FAQ; Red Hat's OpenJDK lifecycle article; Microsoft's support roadmap for its build, which says commercial support covers only Azure customers with a support plan; and Azul's support roadmap, where the dates are minimums and extended support adds up to two years. Oracle lists its dates as examples and marks later ones as subject to change. Oracle's Extended Support carries its own fees and promotional waivers, which Oracle sets.
The same dates, with what each vendor's support covers: Java LTS versions and end-of-life dates by vendor.
Where support stops
Support covers the people and process around a running JVM. It does not cover the JDK's own patch stream, and a page that blurs the two sends buyers into the wrong decision.
Engineers who diagnose, tune and upgrade the runtime in production, on-call response, root-cause analysis, upgrade planning and lifecycle advice, under one AceMQ contract and SLA.
The JDK build and its security updates. Oracle, the Eclipse Adoptium project, Amazon, Red Hat, Microsoft and Azul each publish their own, on their own dates. AceMQ produces none.
A crash or wrong result that traces to the JDK itself needs a code fix from the build vendor or the OpenJDK project. We reproduce it, write it up and raise it with the right party.
When your vendor stops updating a release, the choices are to move to a newer LTS, to buy that vendor's extended support, or to treat the host as an exception with controls around it. We lay out which fits your estate.
Dates and licensing terms change, so this page reads vendor dates from each vendor's own page. Licensing questions belong to your agreement and your counsel; AceMQ gives no licensing advice. End-of-life software support
Escalation Path
Every tier reaches a senior Java engineer. There is no tier-1 triage layer to get through.
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.
Pricing
AceMQ Java support contracts typically run $24,000–72,000 a year, depending on SLA level, scope (number of clusters or nodes, and environments) and deployment (bare metal, virtual machines, containers or Kubernetes).
| What moves the price | How it changes the contract |
|---|---|
| SLA level | Business-hours cover costs less than 24/7 cover with a 15-minute emergency response. |
| Scope | More clusters or nodes, and more environments, make a larger contract. |
| Deployment | Self-managed, cloud-managed and Kubernetes estates need different amounts of hands-on work. |
Covering several technologies under one contract, for example RabbitMQ, Kafka and Redis, earns an aggressive discount.
Typical engagements
Typical engagement scenarios: what the work covers and what it delivers. They describe the service, not past results.
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.NETKubernetesSupport options
AceMQ offers Java support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and emergency response for JVMs your team runs, proactive reviews that find memory, TLS and lifecycle problems first, managed Java runtimes on your own infrastructure, and managed Java runtimes on AceMQ infrastructure. Java 8, 11, 17, 21 and 25 are covered by AceMQ engineers working with partner Java specialists, on Oracle JDK or any OpenJDK build. JDK patches still come from your distribution vendor.
You run it, we back you up
Best for: Teams that run their own Java services and need a second pair of senior hands when a JVM misbehaves at 3am.
You run it, we watch it with you
Best for: Teams that want the stray Java 8 host or the wrong heap setting found in a review, not in an outage.
We run it in your cloud or data centre
Best for: Regulated estates that must keep workloads inside their own boundary and want someone else on the rota for the runtime.
We host it and run it, as a service
Best for: Teams that want their Java services run without a JVM on-call rota.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs Java day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for Java
Support is one part of what AceMQ does for Java. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
Two kinds of provider can sit behind a JVM. The vendor of your build supplies the JDK and its security updates, and some sell support for them. AceMQ supplies the engineers who run and troubleshoot the runtime in production, 24/7, whichever build you chose. Many teams use both: a free or vendor-supported OpenJDK for updates, and AceMQ for the incident on a Saturday night.
It includes a 15-minute emergency response 24/7, a written root-cause analysis after every P1, heap, GC and native memory analysis, TLS and truststore troubleshooting, LTS upgrade planning and lifecycle advice, delivered by AceMQ engineers with partner Java specialists. It does not include JDK patches, which AceMQ does not produce.
Yes, as production runtimes. AceMQ troubleshoots and tunes Java 8 and 11 now and plans the move to 17, 21 or 25 before your vendor's dates, which differ by build: Oracle Extended Support for Java 8 runs to December 2030, Temurin 8 is supported at least until December 2030, and Amazon Corretto 11 until January 2032. AceMQ does not produce security patches for releases the vendors have stopped updating.
Yes, on their own pages. Java support covers the JVM layer: crashes, memory, GC, TLS and upgrades. Tomcat support and Spring Boot extended support cover the application server and framework above it. One AceMQ contract can include all of them.
Support means your team still runs the services and has senior engineers to escalate to for an incident, a tuning question or an upgrade. Managed means AceMQ also does the operational work on the runtime layer on a schedule, on your infrastructure or ours, and holds the pager. Most teams start with support, add proactive reviews, and move to managed later if they want to.
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
Reactive cover, proactive reviews, or AceMQ running Java for you on your infrastructure or ours. A senior engineer scopes it with you, and 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.
