Jakarta EE Survey 2022

October 03, 2022

At OmniFaces we poll the community from time to time and again about Jakarta EE (previously Java EE) and related technologies.

With the transfer of Java EE to Jakarta EE now fully completed and Jakarta EE 10 released, people are now starting to think about Jakarta EE 11, the second Jakarta EE feature release. As such it's a good time to poll the community again. This year we're doing so in cooperation with OmniFish.

In the 2022 edition, there are 4 categories of questions again:

Current usage of Jakarta EE
Servlet containers
APIs related to Jakarta EE
The future of Jakarta EE

Compared to 2020, we simplified some of the questions once more; again omitting some of the less popular options to make it more manageable. We kept the questions about the future of Jakarta EE and MP together as this issue still isn't resolved. We also ask about the preferred Jakarta EE cadence. As Jakarta EE 10 is the first feature release, we haven't really established a cadence yet. EE 10 however was released 1 year and 4 months after Jakarta EE 9.1. The plan was for 1 year, but some issues with particularly the Concurrency TCK pushed it out.

Jakarta EE 10 is as mentioned the first feature release, and is generally well received, but in order to keep up the pace it's still very important that we know what matters to all of its users out there.

So therefor we'd like to invite all Jakarta EE users to participate in The Jakarta EE Survey 2022

Comments

Dynamic beans in CDI 2.0

August 15, 2017

A while ago we wrote about CDIs ability to dynamically add Bean<T> instances to the CDI runtime. A Bean<T> is a kind of factory for beans, that makes types available for injection, lookup via the bean manager , or by referencing them in expression language. CDI producers (via the @Produces annotation) fulfil a somewhat similar role, but they essentially only make the "create instance" method dynamic; the rest (like scope, types, etc) is more or less static. A programmatically added Bean<T> essentially makes all those aspects dynamic. As the previous article showed, dynamically adding such Bean<T> is a bit more work and it's quite verbose, as well as a little complex as the developer has to find out what to return as a default for various methods that are not directly of interest. CDI 2.0 has addressed some of the above issues by providing a very convenient builder that not only makes creating a Bean<T> instance far less verbose, bu

Dynamically adding an interceptor to a build-in CDI bean

August 23, 2017

In Java EE's CDI, beans can be augmented via 2 artefacts; Decorators and Interceptors . Decorators are typically owned by the application code and can decorate a bean that's shipped by the container ( build-in beans ) or a library. Interceptors are typically shipped by a library and can be applied (bound) to a bean that's owned by the application. So how do you bind a library shipped interceptor to a library shipped/build-in bean? In CDI 1.2 and before this wasn't really possible, but in CDI 2.0 we can take advantage of the new InterceptionFactory to do just this. It's not entirely trivial yet, but it's doable. In this article we'll demonstrate how to apply the @RememberMe interceptor binding from the new Java EE 8 Security spec to a build-in bean of type HttpAuthenticationMechanism , which is from the Security spec as well. First we configure our authentication mechanism by means of the following annotation: @BasicAuthenticationMechanismDefin

Should the community take over JSF.next or not?

June 13, 2017

JSF aka JavaServer Faces is a component based MVC framework that's part of Java EE and is one of the oldest Java MVC frameworks that's still supported and actively used (version 1.0 was released in 2004 ). Over time, Java EE itself has grown considerably and as such the resources required to maintain and evolve Java EE have grown as well. Now Oracle has indicated at several occasions that it just doesn't have the resources required for this, and for most constituent specs of Java EE it can do at most small updates, but in other cases can't do any updates at all. In order to lessen this immense burden on Oracle somewhat, the community has largely taken over for JSF 2.3 and Java EE Security API 1.0. The following graph (taken from a presentation by JSF spec lead Ed Burns) gives an indication: The question is how to continue for JSF.next ? Since the community has largely taken over JSF already, should this perhaps be made more formal by actually letting the

Jakarta EE Survey 2022