Table of Contents
Jersey 4.x is implementation of Jakarta REST 4.0, part of Jakarta EE 11. For APIs and implementations in Jakarta EE 11, JDK 17 minimum is required. However, some modules may require higher versions of Java SE. See Section 2.1, “Java SE Compatibility”.
Jakarta REST 4.0 dropped classes bound to JAX-B, since JAX-B has been removed from Jakarta EE 11 Core
profile. These classes were jakarta.ws.rs.core.Link.JaxbLink
and
jakarta.ws.rs.core.Link.JaxbAdapter
along with related methods working with these
classes.
Some modules supporting obsolete libraries were dropped.
The Apache 4 HTTP Client supported by jersey-apache-connector
is replaced by jersey-apache5-connector
, using the Apache 5 HTTP Client.
jersey-jetty11-connector
based on Jetty 11 HTTP Client has been dropped, with
jersey-jetty-connector
based on Jetty 12 HTTP Client as a replacement.
The same with jersey-container-jetty11-http
with jersey-container-jetty-http
atop Jetty 12 as a replacement.
jersey-container-simple-http
module was removed without a replacement.
Given JDK 17 does not allow reflection on JDK internal classes, it is no longer possible
to support additional HTTP methods with the default HttpUrlConnector
, such as popular
HTTP Patch.
Jersey 4.x still uses HK2 as a main DI framework. However, in the future releases (5.x+), the main
DI container would be the CDI container. In CDI, it is not possible to register beans in the injection
container in runtime the way it is possible in HK2 using AbstractBinder; the
AbstractBinder is moved to the jersey-hk2
package.
Also, a releated org.glassfish.jersey.internal.inject.Bindings
class was moved
into the same package. A few internal Binding
subclasses and related Jersey
most innate classes are hidden from public usage.
See Section Chapter 25, Custom Injection and Lifecycle Management.
Jersey stopped providing jersey as a bundle, known as jaxrs-ri
. Jersey jars used
in the bundle was only a subset of possibilities Jersey provides with a variety of modules each of
which handles an additional customer use-case. Some modules are not designed to be together on a
classpath with a module from the jaxrs-ri
bundle and that has been leading to a confusion.
The jaxrs-ri
bundle also contained third party libraries with a different licensing
than Jersey, which also led to a confusion about whole jaxrs-ri
bundle and
Jersey itself license.