The transfer process for Jakarta EE continues on and on. Keeping track of what’s in and what’s out is still a work in progress but thanks to Arjan Tijms, project lead for Eclipse Mojarra and tech lead at Payara, we can now take a sneak peek at some of the plans, especially Payara’s.
However, it’s important to understand that even though a lot of individual Java EE 8 components have already been released as a Jakarta artefact with Eclipse licensing, the full Glassfish 5 build is yet to be released as a Jakarta artefact. As Arjan explained in his recent blog post, “purely from a code based view, this release would hit a major milestone that was set out on the transfer road map earlier.”
The road ahead is quite long and it includes plenty of smaller milestones, including adopting the newly re-released Jakarta versions of many of the Java EE and GlassFish components into Payara. Although the process for some components is faster than for others (for example Mojarra), some of the work should be done by the time Payara 5.191 is released.
What’s even more interesting is “how the existing specs and APIs in Java EE 8 are going to be evolved and how that brings us to a Jakarta EE 9,” Arjan mentioned in his blog post. But first things first — the Java EE specs need to be transferred and Eclipse and Oracle must reach an agreement about the use of the javax.* packages.
Although the Java EE API code, the direct implementations of that API and various supporting libraries (from the GlassFish project) have been transferred, as well as the TCK, along with all existing issues for both of these projects, JSF 3.0 or EE Security 1.1 cannot be released yet. Still, some of the projects have started working towards their next major API version, according to Arjan.
Let’s have a quick look at what has been done so far and what’s planned for the following projects:
JSF 3.0
First, JSF 3.0 will have to remove all the unnecessary bits and pieces that have been piling up over the years and have been retained because of the strict backwards compatibility requirements. For example, JSF native managed bean system will finally be fully removed after having been deprecated in stages ever since JSF 2.0.
Therefore, JSF 3.0 will not be backwards compatible. It is also expected to continue on the path of moving more of its own artefacts to CDI, which is something JSF had started doing in JSF 2.2 (FlowScope) and JSF 2.3 (many JSF artefacts injectable via CDI).
The list of new features includes adding an action module to JSF (which has already been prototyped by one of the JSF committers and can be found here), as well as making extensionless mapping (meaning no file extensions are used/needed when requesting JSF views) a default, with a simple option to switch it off again.
EE Security 1.1
EE Security 1.1 will probably focus mostly on the authorization concerns, Arjan explained in his blog post. The list of changes includes a CDI compatible @RolesAllowed alternative and they are also looking into having the interceptor just throw an exception when access is denied (like @RolesAllowed in EJB now does), or having it trigger an authentication dialog when access is denied (like @ServletSecurity in Servlet now does).
Allowing for custom authorization rules is also in the cards for EE Security 1.1. As a matter of fact, a prototype for this was created a while ago. Since there was no time to include it in EE Security 1.0, we’re eager to see if it’s going to be included in the next release.
There are also plans to add some additional authentication mechanisms such as OAuth2 and Open ID Connect and MicroProfile’s JWT is also a worthy contestant, even though “this also depends on if/how/when MicroProfile and Jakarta are or are not merging.” Speaking of authentication, having different authentication mechanisms in an application for different paths, and different authentication mechanisms for a single path and letting the user choose which one to use is also something they might look into.
JAX-RS 2.2
Although JAX-RS has some level of support for CDI, “the fact that JAX-RS resources are not CDI beans has unnecessarily held back the spec and has caused confusion even since JAX-RS was introduced in EE 6 (2009),” Arjan wrote.
Therefore, the plan is to make JAX-RS use CDI instead. However, this would mean that
- in JAX-RS 2.2 everything that can now be injected by @Context should also be injectable using @Inject and JAX-RS resources would be CDI beans by default (perhaps unless explicitly disabled).
- @Context would be deprecated. In JAX-RS 3.0 @Context would then be actually removed.
EE Concurrency 1.1
The plans for Java EE 8 included moving things like the EJB timer service and the @Asynchronous annotation to EE Concurrency but since they fell through, EE Concurrency 1.1 is going to inherit these plans. Therefore, the EJB timer service and the @Asynchronous annotation should be moved in updated versions to EE Concurrency. The implicit pooling feature of EJBs might also be moved to EE Concurrency.
According to Arjan, “a missing element of EE Concurrency is that the various concurrency services it provides, like the managed executor service, can only be configured in a vendor specific way, and typically not from within the application.” Therefore, they are considering adding portable ways to define and configure the concurrency services.
What’s more, since context and scope propagation is not fully defined, they intend to better specify this and/or provide a means to control propagation in code.
Does this all sound familiar? That’s because MicroProfile Concurrency also exists. For now, these two efforts must co-exist since Jakarta EE and MicroProfile are not officially merged.
Interceptors 1.3
Incerceptors is often thought as being part of CDI but it’s actually a separate spec — a sub-spec of EJB. One of the most meaningful changes being considered is adding the ability for an interceptor to change not only the method target and its parameters, but the bean target as well. Arjan explained that this change “would make things such as an @Poolable annotation far more straightforward to implement since in such case an interceptor would grab a bean instance from a pool and continue the call on that.”
Arjan’s blog post also includes plans (and ideas!) for JASPIC 1.2, JACC 1.7, Expression Language 3.1 and Requestlets 1.0 so head over to the Payara blog to find out more about what’s in store for these projects.
The post Checking in on Jakarta EE appeared first on JAXenter.
Source : JAXenter
