RESTEasy: the Jakarta REST implementation, tracked by branch

One implementation, several lines, one specification to follow

RESTEasy is a Commonhaus project aimed at providing productivity frameworks for developing client and server RESTful applications and services in Java. It is mainly a Jakarta RESTful Web Services implementation, and the README notes that you will find some other experimental code in the repository.

That framing matters. Jakarta RESTful Web Services is the Java API for RESTful services over HTTP, and the specification now lives under the Jakarta EE Project, where the whole specification can be read. RESTEasy is a portable implementation of that specification, which means the API surface of the library is decided by a specification committee and by the Jakarta EE release cycle, not by the project maintainers.

The consequence is visible everywhere in how the project is organised. There is no single current version. There are three maintained lines, each tied to a specification version, each with its own branch, its own JDK requirement and its own support promise. A team that wants the 6.2 behaviour cannot have the 7.0 behaviour, because the specification underneath them is different.

The project page is resteasy.dev, the licence is Apache-2.0, the last push was on 2026-10-14, and the recent releases include v7.0.5.Final and v6.2.19.Final, both on 2026-09-18, plus v7.0.4.Final on 2026-09-01.

Three lines, three JDK floors, three support levels

The branch and version support table is the single most useful page in the README, and it is worth reading as a decision table rather than a changelog.

The 8.0.x line lives on the main branch, targets Jakarta REST spec 5.0 which is still in development, requires JDK 21 or newer, and is in active development. The 7.0.x line lives on the 7.0 branch, targets spec 4.0, requires JDK 17 or newer, and is in active development with bug fixes. The 6.2.x line lives on the 6.2 branch, targets spec 3.1, requires JDK 11 or newer, and is in maintenance and security only.

Two things fall out of that. First, the oldest line is still supported, which is unusual and useful, because Jakarta EE platforms pin specification versions and an application deployed onto an older server cannot use a newer implementation. Second, the active development line is not the one with the most recent features in the widest sense, it is the one tracking a specification that is itself still moving, and the practical consequence for a team is that they are building against something that can still change.

The JDK numbers are a floor for the library, and the project also states its own build requirement separately, which is a bigger number than any of them.

Building needs a newer JDK than the library targets

The build section has a sentence that catches people out. RESTEasy currently requires JDK 25 or more to build, and it compiles down to Java 17.

So the build toolchain and the output are separated by eight years, which is a common pattern in the Java ecosystem and a common source of confusion for anyone who installs a JDK and expects the number in the support table to be the one you need.

The build itself is the Maven wrapper, and the README gives you the two variants. Without the tests, you clone and run one command.

$ ./mvnw clean install -DskipTests=true

With the tests, you may need to specify a profile, and you may need to configure the WildFly version the tests run against, which is what the server version variable is for.

$ SERVER_VERSION=27.0.0.Final ./mvnw clean -fae -Dserver.version=$SERVER_VERSION install

The -fae flag is worth noting, because it means fail at end, so one failing module does not stop the others, and for a project with this many modules that is the difference between a five minute report and a five minute list of everything that broke.

The label that makes CI test against an unreleased specification

There is a mechanism in the contributing guide that is unusual and quite elegant, and it is the part of the README worth reading twice.

Some changes cannot build against a released version of the Jakarta REST API, either because they implement a specification change that is still under review, or one that is merged but not yet released. The instruction is to note this in the pull request description so the requires-spec-snapshot label can be applied.

If the change implements a specific Jakarta REST pull request, the description includes a line linking the two.

Implements jakartaee/rest#1234

That line does two things. It links the pull requests together for the humans, and it is read by CI, which then builds and tests RESTEasy against that pull request. Once it is merged, or if there is no pull request to reference, the specification's main branch is used instead, and the line does not need updating after the specification change is merged.

The constraint on merging is the part with teeth. A pull request labelled requires-spec-snapshot must not be merged until the Jakarta REST API it needs is released and the label is removed. While the label is present the usual builds are skipped, and a dedicated workflow called Test against Jakarta REST Spec takes their place.

So the specification is not a document the implementation follows after the fact. A change can be merged into the specification and into the implementation in the same week, with CI proving the implementation works against the exact specification text that is about to be released.

One script, four jobs, and a pull request at the end

Releasing the project requires permission to deploy to Maven Central, and once everything is set up you run the release.sh script with two required parameters, the release version and the next development version. By default the release version cannot contain SNAPSHOT and the development version must contain it.

./release.sh --release 7.0.1.Final --development 7.0.2-SNAPSHOT

What the script does is listed in four steps. It runs the Maven release, executing mvn release:prepare and release:perform to build, tag and deploy the artefacts to Maven Central. It creates a GitHub release with generated release notes, which requires the GitHub CLI. It uploads the distribution ZIPs to that release. And it publishes the documentation by invoking publish-docs.sh, which pushes to the resteasy.github.io repository.

The last step has a wrinkle the README spells out. The documentation publishing step creates a pull request to the documentation repository automatically, and you need to review and merge that pull request to finalise the documentation update. So a release is not entirely automatic, and the human is in the loop at the end, on the docs.

The additional options are the usual ones, with a warning attached to one. There is a dry run that executes the process without pushing anything, a prerelease flag, a notes start tag, verbose output, and a force flag that allows SNAPSHOT in the release version, which the README marks as not recommended.

The requirements are the GitHub CLI, Maven Central credentials configured in your settings.xml, and write access to the documentation repository. The manual fallback, for when the automation fails, is to enable the release and central-release profiles when running Maven commands, and the manual GitHub release is a gh release create with generated notes and a verified tag.

Issues live in JIRA, and the module list is the feature list

Two practical details that are easy to miss.

The first is that issues are kept in JIRA, at issues.redhat.com/browse/RESTEASY, not in the GitHub issue tracker. That is a leftover of the project's history at Red Hat and it matters, because an issue filed in the wrong place is an issue nobody reads. It also means the project has a bug tracker with more structure than GitHub offers, which is what a project with a specification committee and multiple downstream vendors tends to need.

The second is the module list, because in a repository of this size the directory names are the feature list. The core is resteasy-core, with resteasy-core-spi beside it, and the client side is split across resteasy-client, resteasy-client-api and resteasy-client-utils. There is resteasy-cdi for dependency injection, resteasy-jsapi, resteasy-links, resteasy-reactor and resteasy-rxjava2 for the reactive and Rx integrations, resteasy-servlet-initializer, resteasy-stats, resteasy-upgrade-guide, and resteasy-wadl with a WADL connector for Undertow.

There are also two bill of materials modules, resteasy-bom and resteasy-dependencies-bom, which is how a project of this size keeps its dependency versions coherent across dozens of artefacts, and directories for the providers, the security providers, the server adapters, the distribution packaging, the testsuite, profiling tests and the WildFly integration, plus a docbook directory for the specification documentation and a gitleaks configuration and a DCO file for the contribution process.

Editorial conclusion

RESTEasy fits a Java team that has to implement the Jakarta REST specification rather than invent an API, and that can pick a line matching the specification version its platform already ships. It does not fit a team that wants the newest features without waiting for a specification release, since the 8.0 line tracks a spec that is still in development. Verify three things before you adopt a line: which Jakarta REST version your runtime provides, since the 7.0 line needs spec 4.0 and the 6.2 line spec 3.1, the JDK you build with, because building from source needs JDK 25 or newer even though the output targets Java 17, and where you will file issues, because the project uses JIRA at issues.redhat.com rather than the GitHub tracker.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. resteasy/resteasy on GitHub