How to install Java News Roundup: GraalVM, Jakarta Data, JNoSQL, Azul

What happened

The last week of August 2026 brought a busy cluster of Java ecosystem releases, touching everything from native compilation and cloud runtimes to data access layers and reactive frameworks. Whether you run Jakarta EE applications on bare metal, containers, or cloud-managed infrastructure, at least one of these updates is relevant to your stack right now.

Working through all of them in a single sitting can feel overwhelming, so this guide organizes the releases into what shipped, what builders need to act on, concrete upgrade steps for the most commonly used components, known friction points, and what the community is signaling will arrive next.

Atmosphere 4.0 reached general availability, marking the first major version milestone for the async and WebSocket framework in several years. GraalVM published a point release, as did Azul Payara and Quarkus. WildFly 41 received a maintenance update. Jakarta Data and Eclipse JNoSQL each published milestone releases, meaning they are progressing through their specification and implementation cycles but are not yet final. Open Liberty shipped a beta build targeting its September 2026 edition. Docker images for GlassFish became available, making containerized deployments of that runtime more accessible without a manual image-building step.

How it works

Atmosphere 4.0 is a major-version boundary, which means its changelog is the first place to look before upgrading any application that relies on its async or WebSocket APIs. Point releases for GraalVM, Azul Payara, and Quarkus are generally safe to consume but should be validated against your native image configurations and extension sets respectively. The WildFly 41 maintenance release addresses accumulated fixes in a stable stream, so teams running WildFly 41 in production should treat it as a routine but recommended update rather than an optional one. The Jakarta Data and Eclipse JNoSQL milestones matter if you are building against those specifications ahead of their final releases; applications already consuming earlier milestone builds should test against these newer milestones to catch API shifts before the specifications finalize. The Open Liberty beta is an early look at the September edition and is suitable for developer evaluation but not production deployment.

For Atmosphere 4.0, update the dependency coordinates in your build file to reference the 4.0 release, then run a full build and review any compile errors that surface from API changes across the major version boundary. Run your integration tests before deploying, paying particular attention to any code that touches WebSocket lifecycle callbacks or async context handling.

For the GraalVM point release, download the updated distribution from the GraalVM project site or update the version pinned in your toolchain configuration. If you build native images, rebuild them against the new release rather than reusing previously compiled artifacts, since native image binaries are tightly coupled to the GraalVM version that produced them.

Why it matters

For Azul Payara, follow the standard Payara upgrade path: back up your domain configuration, replace the installation directory with the new distribution, and restart your domain. Verify that your deployed applications pass smoke tests before routing production traffic.

For Quarkus, update the Quarkus BOM version in your build file and let dependency management resolve the rest. Run the full test suite locally. If you use the Quarkus CLI, update it separately since it is versioned independently of the framework itself.

For WildFly 41 maintenance, download the updated distribution, apply it to your existing domain or standalone configuration using the standard WildFly upgrade procedure, and verify your deployments start cleanly.

Who is affected

For Eclipse JNoSQL and Jakarta Data milestones, update the relevant dependency versions in projects where you are tracking milestone builds. Treat these as dev or staging updates only; the milestone designation means the API surface can still shift before the final release.

For the Open Liberty September beta, pull it from the Open Liberty site for local evaluation. Do not deploy it to production environments.

For GlassFish Docker images, pull the image from the published registry, validate it against your application in a local or staging environment, and integrate it into your container pipeline as you would any other base image update.

What to watch next

Atmosphere 4.0 is the release most likely to require code changes because major version increments in mature libraries often remove deprecated APIs that were retained through prior minor releases. Budget time for a dependency audit before assuming a drop-in upgrade. GraalVM native images must be rebuilt; shipping a binary compiled against an older GraalVM version and running it against a newer runtime is not a supported path. Jakarta Data and JNoSQL milestone builds are not API-stable, so production systems should not consume them until the final specifications are published. The Open Liberty beta carries the same caveat at the runtime level.

The Jakarta Data and Eclipse JNoSQL milestone progression signals that both specifications are approaching finalization, so their next releases are worth tracking closely. The September 2026 Open Liberty edition will move from beta to general availability on its regular cadence. Any follow-on patch releases from Quarkus, GraalVM, or Azul Payara addressing issues found in this round of point releases would follow their standard patch timelines.