We were waiting so long! But it is here, Jakarta EE 10 is released, all the implementations Jersey depends on are final, and so Jersey 3.1.0, the final release compatible with Jakarta REST 3.1 is finally released!
There are a number of new features related to Jakarta REST 3.1, a few new specification-unrelated features, and some old functionality returned back.
Documentation
We split the documentation, to have it separated for
- Jersey 2.x (JAX-RS 2.1 – Jakarta EE 8 & Java EE 8)
- Jersey 3.0 (Jakarta REST 3.0 – Jakarta EE 9)
- Jersey 3.x (Jakarta REST 3.1 – Jakarta EE 10)
Jakarta REST 3.1 new features
Jersey 3.1 contains three main features. The first is SeBootstrap API, which is the API to deploy any Jakarta REST 3.1 application in an SE environment. It is particularly useful for microservices when the customer deploys an application into multiple environments, each backed by another vendor’s implementation.
In the SE environment, there is no WAR so the application is deployed directly by
Application application = new MyApplication();
SeBootstrap.Configuration.Builder configBuilder = SeBootstrap.Configuration.builder();
SeBootstrap.start(application, configBuilder.build());The second main feature introduced was multipart support. Multipart is defined by RFC 2388 and Jersey already implemented it (as well as other implementations), so it was brought directly to Jakarta REST API and standardized, for instance, the client:
List<EntityPart> multiPartEntity = new List<>();
list.add(EntityPart.withName("part-01").content("hello").build());
list.add(...);
GenericEntity<List<EntityPart>> genericEntity = newGenericEntity<>(list) {};
Entity entity = Entity.entity(genericEntity, MediaType.MULTIPART_FORM_DATA_TYPE);
...
Response response = target.request().post(entity);And the server endpoint, for instance:
@Path("/postFormVarious")
@POST public Response postFormVarious(
@FormParam("part-01") EntityPart part1,
@FormParam("part-02") InputStream part2,
@FormParam("part-03") String part3) {
...
}The third new functionality is the possibility to define the Feature as a Java service using META-INF/services/jakarta.ws.rs.core.Feature. The feature is then loaded automatically as if registered within the Configuration.
New HTTP Client Connectors
Jersey 3.1 supports additional new HTTP Client Connectors for:
- Apache 5 HTTP Client
- Helidon 3 HTTP Client
- Java 11 java.net.http Client (aka JNH Client)
Apache 5 HTTP Client Connector has been introduced a few releases back, but it is still new and worth mentioning. Helidon HTTP Client Connector is back after it has been removed in Jersey 3.0. Helidon 3 support of Jakarta is quite new, introduced this summer.
The new Java NET HTTP (JNH) Client debuted in Java 11, and it resides within the java.net.http package. The default Jersey HTTP Client uses the HttpUrlConnector, which does not support new HTTP methods such as HTTP PATCH, and this new JNH Connector (org.glassfish.jersey.connectors: jersey-jnh-connector) is hoped to provide all the possibilities the HttpUrlConnector was missing.
Microprofile 5 Alignment
Jersey 3.1.0 supports MicroProfile REST Client 3 and MicroProfile Config 3. Jersey 2.x supports MicroProfile REST Client 2.0 and MicroProfile Config 2, but Jersey 3.0.x was not supporting any of these; Microprofile 5 supporting Jakarta EE 9 was released only lately.
Other newsworthy functionality
The full list is available in the Road-Map summary, a list of changes in the release, or the Eclipse Jersey project website release information. To list a few noteworthy:
- JDK 20 is supported
- Jakson 2.13 Jakarta EE JAX-B/JAX-B/3 modules support
- Spring 6 module for supporting Jakarta EE friendly Spring
- Support of @Inject for Jakarta REST classes with org.glassfish.jersey.ext.cdi:jersey-cdi-rs-inject module
Future releases
Jersey still does not support JPMS, there is no module.info in the Jersey modules. JPMS can make some Jersey internal classes invisible to the users, but the classes might be widely used. Some discussion is expected about the classes and the visibility. The parallel release of Jersey 3.2.x containing the module.info and Jersey 3.1.x without it is planned for some time. When Jersey 3.3.x is released, there will be just one branch with the module.info and Jersey 3.1.x won’t continue to be released. Note that all the Jersey 3.1.x, Jersey 3.2.x, and Jersey 3.3.x are implementations of Jakarta REST 3.1.
Jakarta Config is a Spec new to Jakarta EE under development. Jersey plans to support configuration using Jakarta Config as soon as Jakarta Config is made final.
Jakarta REST 4.0 is being discussed, along with the more native support of CDI. That could bring some semantic changes in the Jakarta REST resources and Jersey makes preparations for it.
Thank you for using Jersey
As always, enjoy using Jersey, and let us know when there is any feature missing, or not working as expected.