Jersey 2.35 and corresponding Jersey 3.0.3 have been released recently. There is a number of new features.
We support JDK 17, JDK 16, JDK 15, JDK 14, JDK 13, JDK 12, JDK 11, and JDK 8. It means, Jersey is tested there, passes tests, and is perfectly functional. Except… It does not mean we support JDK 16 records. It does not mean we use JPMS and define the module-infos. It does not mean HTTP Patch requests work with the default HttpUrlConnector on JDK 16. But we are working on these features, too.
We support the Graal VM native image (please read the documentation and try our example). We support Optional<T> in the HTTP request parameters (QueryParam, PathParam,…). We implement MP Rest Client 2.0 (we are also compatible with MP Rest Client 1.4 API).
But mainly, we make progress towards Jakarta REST 3.1, and Jakarta REST 4.0.
Jakarta REST 3.1 brings a requirement that Feature and Dynamic Feature must be possible to define as a JDK service (by adding provider-configuration file) and it is loaded by the implementation. We allow this feature in Jersey 2.35 and 3.0.3, too.
The most important change planned for Jakarta REST 4.0 is the mandatory CDI integration. JAX-RS 2.0 introduced optional CDI integration: In a product that supports CDI, implementations MUST support the use of CDI-style Beans as root resource classes, providers and Application subclasses. Jakarta REST 3.1 deprecates @Context annotation: Note that future versions of this API will stop supporting injection via @Context as part of a tighter integration and alignment with Jakarta CDI.
Jersey 2.34 introduced a new module org.glassfish.jersey.ext.cdi:jersey-cdi-rs-inject, which enables injecting Jakarta REST injectables normally injected by @Context to be injected using @Inject, when using CDI. It is enough just to add the module to a classpath. This is one step towards pure CDI injection.
Jersey 2.35 introduced an experimental module org.glassfish.jersey.incubator:jersey-cdi-inject-weld. This module implements an InjectionManager that is completely CDI-based, with no HK2 involved. Currently, it works just with the jersey core modules, and we have an example that shows the module working (when running with “CdiInjectWeld” profile). This module will definitely be a subject of changes in the future. The current plan is to support CDI lite and CDI lite can be a reason for the complete redesign of the module. CDI lite, as well as CDI 4.0, is a subject for Jakarta EE 11, and the details of the changes are not known, yet.
Soon, Jakarta REST 3.1 release candidate will be released, and the first milestone release of Jersey 3.1.0 will follow. These artifacts are part of Jakarta EE 10 which is finishing and will go through a release review ballot; Jakarta EE 10 will be out during this winter.