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, but also takes away most of the guesswork. The following shows an example:

public class CdiExtension implements Extension {

    public void afterBean(final @Observes AfterBeanDiscovery afterBeanDiscovery) {
        afterBeanDiscovery
            .addBean()
            .scope(ApplicationScoped.class)
            .types(MyBean.class)
            .id("Created by " + CdiExtension.class)
            .createWith(e -> new MyBeanImpl("Hi!"));
    }
}

The above makes a bean available for injection into MyBean injection points and with the @ApplicationScoped scope, backed by a MyBeanImpl class.

A fully working example is provided in the Java EE 8 Samples project.

The example was tested on Payara Server 5, of which a snapshot can be downloaded from the snapshot repository. An initial alpha will be released very soon, but in the mean time the latest version can be downloaded here:
payara-5.0.0.173-SNAPSHOT.zip.

Arjan Tijms

JSF, a Java EE MVC framework, has supported extensionless URLs for some time via PrettyFaces (now merged to the general Rewrite framework) and OmniFaces. Both of these solutions used various workarounds to trick JSF into working with extensionless URLs.

Though JSF 2.3 does, unfortunately, still not support extensionless URLs fully out of the box via e.g. a single parameter, it can provide support for it by basically combining the new support for exact mapping and the API for obtaining a list of all view resources. Additionally combining this with the Servlet 3.1 feature for dynamically adding Servlet mappings and some JDK8 streaming and lambdas, makes it possible to enable extensionless support with just 2 statements (albeit somewhat long statements):

@WebListener
public class MappingInit implements ServletContextListener {

    @Override
    public void contextInitialized(ServletContextEvent sce) {
        FacesContext context = FacesContext.getCurrentInstance();

        sce.getServletContext()
           .getServletRegistrations()
           .values()
           .stream()
           .filter(e -> e.getClassName().equals(FacesServlet.class.getName()))
           .findAny()
           .ifPresent(
               reg -> context.getApplication()
                             .getViewHandler()
                             .getViews(context, "/", RETURN_AS_MINIMAL_IMPLICIT_OUTCOME)
                             .forEach(e -> reg.addMapping(e)));
    }
}

What the above code does is finding the existing FacesServlet, then getting all views for the entire application in a form that happens to be exactly suitable for extensionless URLs, and then adding each of them as mapping to the FacesServlet we previously found.

After adding the above shown WebListener to an application, its view can be requested via URLs like example.com/login, example.com/users/all etc.

The example was tested on Payara Server 5, of which a snapshot can be downloaded from the snapshot repository. An initial alpha will be released very soon, but in the mean time the latest version can be downloaded here:
payara-5.0.0.173-SNAPSHOT.zip.

Arjan Tijms

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:

@BasicAuthenticationMechanismDefinition(
    realmName="foo"
)

This will cause the container to enable a build-in bean with interface type HttpAuthenticationMechanism, but having an unknown (vendor specific) implementation.

Next we'll definite an alternative for this bean via a CDI producer:

@Alternative
@Priority(500)
@ApplicationScoped
public class ApplicationInit {

    @Produces
    public HttpAuthenticationMechanism produce(InterceptionFactory<HttpAuthenticationMechanismWrapper> interceptionFactory, BeanManager beanManager) {
        return ...
    }

A small challenge here is to obtain the bean with type HttpAuthenticationMechanism that would have been chosen by the CDI runtime had our producer not been there. For a decorator this is easy as CDI makes that exact bean injectable via the @Decorated qualifier. Here we'll have to do this manually. One way is to get all the beans of type HttpAuthenticationMechanism from the bean manager (this will include both alternatives and non-alternatives), filter ourselves from that set and then let the bean manager resolve the set to the one that would be chosen for injection. We then create a reference for that chosen bean.

The following shows this in code:

HttpAuthenticationMechanism mechanism =
    createRef(
        beanManager.resolve(
            beanManager.getBeans(HttpAuthenticationMechanism.class)
                       .stream()
                       .filter(e -> !e.getBeanClass().equals(ApplicationInit.class))
                       .collect(toSet())), 
            beanManager);

With createRef being defined as:

HttpAuthenticationMechanism createRef(Bean<?> bean, BeanManager beanManager) {
    return (HttpAuthenticationMechanism) 
        beanManager.getReference(
            bean, 
            HttpAuthenticationMechanism.class, 
            beanManager.createCreationalContext(bean));
}

We now have an instance to the bean to which we like to apply the interceptor binding. Unfortunately, there's a somewhat peculiar and very nasty note in the CDI spec regarding the method that creates a proxy with the required interceptor attached:

If the provided instance is an internal container construct (such as client proxy), non-portable behavior results.

Since the HttpAuthenticationMechanism is a client proxy (it's application scoped by spec definition) we have no choice but to introduce some extra ceremony here and that's by providing a wrapper ourselves. The interceptor will be applied to the wrapper then, and the wrapper will delegate to the actual HttpAuthenticationMechanism instance:

HttpAuthenticationMechanismWrapper wrapper = 
    new HttpAuthenticationMechanismWrapper(mechanism);

Having our HttpAuthenticationMechanism instance ready, we can now dynamically configure an annotation instance. Such instance can be created via CDI's provided AnnotationLiteral helper type:

interceptionFactory.configure().add(
    new RememberMeAnnotationLiteral(
        86400, "",       // cookieMaxAgeSeconds
        false, "",       // cookieSecureOnly
        true, "",        // cookieHttpOnly
"JREMEMBERMEID", // cookieName
        true, ""         // isRememberMe
    )
);

Finally, we create the above mentioned new proxy with the configured interceptor binding applied to it using the interception factory's createInterceptedInstance method and return this from our producer method:

return interceptionFactory.createInterceptedInstance(
    new HttpAuthenticationMechanismWrapper(wrapper));

A full example can be found in the Java EE 8 samples project.

Note that there's a small caveat here; if the Interceptor needs access to the interceptor bindings (which is almost always the case when the binding has attributes), you can't just inspect the target type as one would usually do in CDI 1.2 and earlier code. The interceptor binding annotation is not physically present on the type. At the moment it's not entirely clear how to obtain these in a portable way. The interceptors in the Java EE Security RI (Soteria) uses an RI specific way for now.

The example was tested on Payara Server 5, of which a snapshot can be downloaded from the snapshot repository. An initial alpha will be released very soon, but in the mean time the latest version can be downloaded here:
payara-5.0.0.173-SNAPSHOT.zip.

Arjan Tijms

Payara 5 is the first release that will include all of the Java EE 8 and MicroProfile 1.2 components, including a special build of Mojarra (JSF 2.3) based on the 2.4 master in which a lot of refactoring has been done, and a special build of Soteria (Java EE Security) based on the 1.1 master with several bug fixes.

The full list of changes are available from the links given below:

• Changes in Payara 5 RC 1
• Changes in Payara 5 Beta 2
• Changes in Payara 5 Beta 1
• Changes in Payara 5 Alpha 3
• Changes in Payara 5 Alpha 2
• Changes in Payara 5 Alpha 1

Payara 5 runs all the Java EE 7 samples, all the Java EE 8 samples and all of the MicroProfile 1.2 samples.

If no major bugs surface Payara 5 Final should be released soon.

Arjan Tijms

In the 2018 edition, there are 4 categories of questions:

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

Jakarta EE provides the opportunity to revitalise and modernise Java EE, but in order to do that it's more important than ever that we know what matters to all of its users out there.

So therefor we'd like to invite all Java EE users to participate in The Java EE Survey 2018

In the 2018 edition, there were 4 categories of questions:

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

Jakarta EE provides the opportunity to revitalise and modernise Java EE, but in order to do that it's more important than ever that we know what matters to all of its users out there.

We started the survey the 15th of March, 2018. Unfortunately a small barrage of other surveys would soon follow, among others the Eclipse Jakarta EE Survey, the Jakarta EE Logo selection, and the Baeldung survey. Despite all those other surveys going on at the same time we still managed to get 1054 respondents. Not as much as we hoped for, but still enough to have some idea of what's important to the community.

It must be noted that OmniFaces is a JSF utility library, so the public we attract is naturally more interested in JSF than the primary public of the many parallel surveys that were going on. We did track where the respondents originated from, and 344 of them took the survey directly on the omnifaces.org website.

It must also be disclosed that one of the OmniFaces members (the writer, Arjan), works for Payara. Payara however was in no way involved with either the creation of the survey or the report. Payara did tweet about the survey a couple of times.

Let's take a look at the outcome now.

Question 1 - Which versions of Java EE have you (historically) used?

This question was about which version of Java EE people have ever used, and hopefully will give us some idea of how much experience our audience has and how long they've been using Java EE.

It appears though that most of our respondents haven't used the older versions so much. Far less than half of the respondents has ever used Java EE 5. On the other hand, there's still a relatively big proportion of respondents that have used the precursor technologies of Java EE (the ones older than J2EE 1.2).

Question 2 - Which versions of Java EE have you recently (last couple of months) used?

Looking at what people have recently been working on we see that J2EE 1.3 and J2EE 1.4 is almost non-existent. The response for those is well within the error margin. There's still a number of people working on Java EE 5 applications though, which is now more than a decade old! Not surprisingly, most people are working with Java EE 7, for which all currently active vendors have a supported version out.

Maybe somewhat surprisingly is that 36% of the respondents are already using Java EE 8, given that not all vendors have a fully supported version out or have even implemented all Java EE 8 APIs yet. Of course, this can also mean respondents are using parts of Java EE 8. WildFly 12 for instance supports most Java EE 8 APIs, except for EE Security (which will come in WildFly 13).

Question 3 - Which application servers have you recently used?

Looking at which (Java EE) application servers are most frequently used there's a very clear winner, and that's RedHat's WildFly. More than half of the respondents have recently used this server. Trailing a good deal behind at the second place is Oracle's GlassFish. Despite being largely abandoned by Oracle and not supported, still 37% of responds use this. Payara Server and TomEE share the third place.

A slew of servers had so few respondents that taking the error margin into account qualifies them as practically unused by our respondents. This included Geronimo, the once promising server from Apache that silently and without any notice stopped, Resin, a very promising Web Profile implementation back then with its own CDI implementation (CanDI), which however never managed to get passed Java EE 6, and JOnAS, the mostly French server which had a number of its own unique component implementations as well, but like Geronimo just silently stopped at some point. Following is a number of mostly Korean, Japanese and Chinese servers. These servers are mostly used in their respective countries, and seemingly English language surveys are not (much) picked up by the users of these servers.

Question 4 - How would you rate the application servers that you've used?

For this question respondents could rate the servers they've used using 5 categories. There were two negative ones: "Hate it" and "Don't like it", a neutral one: "It does the job, but that's all", and two positive ones "Like it" and "Love it". The outcome has different aspects that we'll be looking at individually. Note that the servers that weren't effectively used by anyone are left out.

Love it

The first aspect we'll be looking at is a ranking of all servers that got the maximum appreciation: "Love it". Here we see Payara Server is the winner. Almost half of the people who used Payara said they loved it. At the second place we see WildFly again, where over a third of the respondents who use WildFly said they loved it. Do note that since WildFly is used much more than Payara Server, in absolute numbers more respondents from this survey loved WildFly. Statistics can be a tricky thing.

Quite interesting is that Liberty is relatively much loved and enters at the third place. Liberty is IBM's still relatively new server that does many things right compared to its older sibling WebSphere. Also interesting to see is the stark difference in love between Payara Server and GlassFish. Payara Server is directly based on GlassFish, but with many extra bug fixes and features.

Like it

In the "Like it" category we see WildFly and JBoss EAP topping the chart. Note that these too are largely the same server, with JBoss EAP essentially a kind of "LTS" of a specific WildFly version with the option to get a support subscription and extra bug fixes. With the exception of WebLogic and WebSphere, the servers are quite close together in this category.

Hate it

Skipping the neutral and dislike categories (they'll be included in the final score though), let's take a look at the hate category. Overal we see that there's relatively little hate among the respondents. Liberty, JBoss EAP, TomEE, GlassFish, Payara Server and WildFly all have very small percentages of hate. The only real exception is WebSphere here, and to a lesser degree WebLogic. In the case of WebSphere, it's perhaps not a surprise. Only its installer is already larger than many complete servers (around the 100MB), and it downloads in excess of 2GB of "stuff". Even in 2018 that's still excessive. After that an actual server needs to be created taking another 200MB or so. This and a number of other issues (e.g. not being able to run on macOS) doesn't make it much popular. Of course IBM recognised this long ago, and all new development is on Liberty, which is essentially everything that WebSphere is not.

Total score

For the total score we used a weighted sum, with the weights (factors) being -3 for "Hate it", -2 for "Don't like it", 1 for "It does the job, but that's all", 2 for "Like it" and 3 for "Love it". For this total score we see Payara Server still wins, but now it's only a small margin with WildFly, which is very close. This seems mainly attributed to WildFly having many more points in the "Like it" category. In the next group we see Liberty, TomEE, JBoss EAP and GlassFish all scoring quite close to each other. All the way at bottom we find WebLogic and WebSphere. WebLogic just about manages to get a positive score, but WebSphere's is deeply negative.

Question 5 - Which Java EE APIs have you used recently?

When looking at the Java EE APIs that people use most, JPA is the overal winner. This is interesting, since in recent years efforts for the JPA spec have been minimised, even to the point that one not rarely hears that JPA is "done" and people have moved on to e.g. MongoDB. Looking at the outcome of this survey this doesn't seem to be exactly the case. CDI follows close and lands at the second place. This is probably no surprise, as since its inception in 2009 CDI has rapidly increased in performance and is now for many cases the default type of bean to use.

Initially somewhat surprising is JSF scoring so high here, and landing just above JAX-RS at the 3rd place. This is surprising since there's a quite vocal community out there proclaiming the era of server side rendering frameworks has come to an end, and the future belongs to the client. For obvious reasons we at OmniFaces don't fully agree with that, but we're also not entirely blind to the fact that the client has indeed taken a large bite out of the total web framework market. As mentioned in the beginning of this article, OmniFaces is a JSF utility library, so our audience likely has a more than average amount of JSF users among it.

Truly surprising though is the high score of EJB, which is often cited as having its name tainted by the complexities of EJB 2 and never quite recovered. Even though EJB 3 is very usable, in Java EE 7 and above CDI can be used instead for quite a lot of cases. It could of course be that EJB is only used for a few small things such as its timer service, but this would need more research and possibly a follow-up survey to really get clear.

Java EE Security, a new spec in Java EE 8, is already used by 24% of the respondents. Given its young age this is quite a good outcome. JASPIC and JACC are both at the very bottom, but these APIs (SPIs actually) are not really aimed at application developers. They are used by higher level frameworks and vendors, e.g. the Java EE Security API strongly builds on JASPIC and will likely build more on JACC in a future release. So these APIs are being used, but just not directly by application developers. A somewhat similar thing also holds for JTA, which is mostly used under the covers by JPA and EJB, but is effectively used directly with the relatively new @Transactional and @TransactionScoped annotations.

Question 6 - Have you used a (standalone) Servlet container recently?

A standalone Servlet container is a server that supports at least the Servlet spec, and typically a number of strongly related specs such as the Servlet Container Profile of JASPIC (not full JASPIC), Expression Language, JNDI, JSP and WebSocket.

As it appears, about the half of the respondents have used such Servlet container, while the other half hasn't (and thus only used a full or web profile Java EE server).

Question 7 - Which Servlet containers have you used recently?

From the people who have used a Servlet container, the overwhelming majority used at least Tomcat. At 85% Tomcat largely dominates this segment. Still, 29% and 22% for Jetty and Undertow are nothing to sneeze at either, and seemingly a non-trivial amount of respondents use either Jetty or Undertow next to Tomcat (people could choose multiple servers).

Undertow's 22% is particularly impressive, as Undertow is not so much known as a standalone Servlet container but more as the Servlet container that Jboss EAP/WildFly uses. It's also relatively new, especially when compared to Tomcat and Jetty which both have existed since the dawn of times.

The "other" category was perhaps not entirely understood, as most respondents choosing this entered products that actually weren't standalone Servlet containers. WebLogic, GlassFish, Liberty and Payara certainly aren't. Grizzly and Netty come closer, but they actually are more akin to HTTP engines, and are themselves not Servlet compatible.

Other

Question 8 - Which additional Java EE libraries do you use with your Servlet container?

This question asked specifically about the Java EE libraries that people add to their Servlet containers. Java EE libraries here means an implementation of a Java EE spec, such as JPA and CDI, but not e.g. Guave, Spring, etc.

Consistent with the API usage outcome, JPA is added most often to a standalone Servlet container, followed by JSF, JAX-RS, Bean Validation and CDI. In this particular question though it was asked which exact implementation people add. As can be seen Hibernate wins hands down over EclipseLink (25%) and OpenJPA (7%). Likewise Mojarra (46%) wins over MyFaces (15%) and Jersey (45%) wins over RESTEasy (28%) and CFX (17%).

The EE Security API has only one standalone implementation yet, which is Soteria (there's another implementation by IBM, but it's embedded in Liberty and not suitable for standalone use). This one is quite new and only used by a couple of people, but it's nevertheless interesting that it is being used standalone.

The "Other" category wasn't entirely understood however. The idea was for other implementations of Java EE specs to be listed here, like e.g. Wink for JAX-RS, HornetQ, OpenMQ or JORAM for JMS, Narayana or JOTM for JTA, etc. None of these were mentioned though, and instead PrimeFaces, OmniFaces, DeltaSpike and Spring were mentioned, which aren't implementations of Java EE specs. Here it's probably the wording of the survey question that's to blame. One respondent did mention DataNucleus though, which is a JPA implementation, and suggested that the question is biased against it by not mentioning it. Given the importance of JPA this is indeed true, so we'll make sure to include DataNucleus next year.

Other

Question 9 - Have you used MicroProfile APIs recently?

MicroProfile is an industry effort to bring extra APIs into the EE fold for things which Java EE doesn't have an API now, such as configuration and metrics. At the same time MicroProfile is also a profile like WebProfile, where only those extra APIs are included as well as JAX-RS and CDI.

Despite all Java EE vendors, with the exception of Oracle, offering those extra APIs with their products, and some implementations being able to be used standalone as well, usage among the respondents was quite low. Only a little more over 15% said to have used MicroProfile APIs recently.

This may have to do with all of those APIs being still very young and haven't established themselves yet. Another reason could be that most vendors by default promote MicroProfile as its own isolated product and not as an extra set of APIs to be used together with the main Java EE ones (Payara is the only notable exception here). As most people would use for example the regular WildFly server (as opposed to the spin-off product WildFly Swarm), which doesn't have the MicroProfile APIs out of the box, this could be a potential barrier.

Question 10 - Which MicroProfile products have you used recently?

Looking at which server product those relatively few people that use MicroProfile APIs use it's again WildFly that tops the charts here, with more than 50% of respondents using this variation of the WildFly main server. Payara Micro follows closely with 45%. Compared to the (Java EE) server product the gap between WildFly and Payara is much smaller here. Payara also has all the MicroProfile APIs included out of the box with the EE Server product, and in this variation Liberty and Payara are used exactly as much. There are various other MicroProfile products, but they are not (yet) so popular (specifically when taking into account only a small proportion of respondents said to be using MicroProfile in the first place)

Seeing that Payara Micro is more used for MicroProfile APIs than Payara Server, one may come to the conclusion that the fact that most MicroProfile vendors don't support these APIs out of the box on their server product doesn't matter that much. While this may be true, it could also be that many users aren't quite aware Payara Server supports these APIs.

Question 11 - Which MicroProfile APIs have you used recently?

Config was the first MicroProfile API and arguably one of the APIs that's most missed in Java EE. A Java EE Configuration API was in the works, but it never materialised. It's perhaps no surprise that config is thus the most used API from the MicroProfile. Health, Metrics and JWT Authentication follow with some distance. Open API, Open Tracing and the Type-safe rest client are all quite new and haven't been implemented by all vendors yet, so it's not a big surprise these aren't used that much yet.

Question 12 - Which Java EE specific extension libraries have you used recently?

This question was specifically about Java EE extension libraries, meaning libraries that one can only use with Java EE. This mostly means libraries that extend or are plug-ins for JSF, CDI, JCA, etc. PrimeFaces is the clear winner here, followed with some distance by OmniFaces (but keep the bias in account, since the survey was promoted via the OmniFaces account and website). Given the popularity that Seam once had, and DeltaSpike being its spiritual successor, just over 20% feels a bit on the low side. DeltaSpike is certainly worth looking at though. Once one of the most frequently used JSF component libraries, RichFaces after being sunset by Red Hat has been reduced to only 13% usage, while newcomer BootsFaces has climbed up to that same percentage.

As far as the "Other" response goes, "MyFaces" was mentioned a lot, but this of course isn't a Java EE Extension library, but a Java EE Implementation library (it implements JSF, as mentioned in a previous question). Tobago, ButterFaces, IceFaces and PrettyFaces are indeed all Java EE extension libraries. Oracle ADF is too, although this is a somewhat specific one (it practically only really works on WebLogic). It's a question if one can really count Spring as a Java EE extension framework. Technically it is, but at the same time it mostly positions itself as an independent full stack framework.

So again, for next year we could do with an explicit definition of "Java EE specific extension library".

Other

Question 13 - Which APIs would you most like to see updated in the next version of Java EE (Jakarta EE)?

When asked which API (spec) people like to see updated, a natural instinct might be to say "all of them". Perhaps not including the ones they hate, or maybe even those so that they can be hated a little less. With only a finite amount of resources this is not always an option, so that's why this question specifically asks respondents to rank the available APIs.

We take a look at the results in three different ways; the amount of people who put an API on the number one position, the amount of people who put an API on the number two position, and finally the total weighted score per API.

APIs at number 1 of the ranking

As can be seen none of the APIs had a really absolute majority. The highest score here was JSF with just over 20%. The question is, did JSF score so (relatively) high here because the potential bias, or do many people see JSF as something that has potential but *really* could do with some desperately needed improvements? CDI and JPA are high on this list too, which matches the outcome of which APIs people use most. Java EE Security is somewhat of an outlier. Being a new spec in Java EE 8 it isn't used that much yet, but already people want to see it improved. As a side-note, Java EE Security 1.0 could only address some of the basics (the low hanging fruit). More was planned for 1.0, but a lack of resources prevented many of those other planned things (such as security interceptors, evens and custom authorization rules) to be actually included.

APIs at number 2 of the ranking

In the number 2 list we see some more variety in the category of APIs having more than 2% of the respondents choosing them, although we do largely see the same APIs again in the top tier. CDI now takes the lead, moving up one place from the number 1 list, and JAX-RS moves up 3 places. JPA is again at number 3, while JSF is at 4 now.

Total score

When we take a look at the total score, we see that the top tier is formed of JPA, CDI and JAX-RS, which is basically identical to the top tier of question 5, which asked what APIs people have used recently. Clearly, people like to see APIs that they actually use improve. In the total score ranking too, EE Security is the exception. It lands on the 4th place, just an inch away from JAX-RS. Interestingly though, JASPIC and JACC end at the last places. As mentioned above, it's likely not common knowledge that these two APIs are the foundation of EE Security.

JavaMail and JDNI are both two examples of APIs that are used more than that people want to have them improved. Likely they just do the job (sending mails resp. looking up resources) and people don't see much need for further improvements there.

Question 14 - What do you think about these options to improve Java EE / Jakarta EE?

This question asked for a variety of broad, somewhat cross-cutting concerns to improve Java EE overall (the potentially improved Java EE will be called Jakarta EE then). The choices with their keys in the graph were:

• CDI rebase - Rebase most Java EE APIs on CDI (remove JSF @ManagedBeans, remove JAX-RS @Context, ...)
• Remove deprecated - Aggressively remove everything that is already @Deprecated (e.g. getServlet() in ServletContext)
• Deprecate legacy - Aggressively deprecate and remove legacy features (e.g. JSP support in JSF)
• Add MP APIs - Add equivalents of some or all MicroProfile APIs to Java EE (e.g. Config, JWT, ...)
• Deployment models - Officially add alternative deployment models (Uberjar, run .war from command line, etc)
• Add JCache - Add JCache to Java EE so that both applications and internal components (such as JPA) can use it
• Rebase on Concurrency - Rebase most Java EE APIs that use threading to use Concurrency Utils thread pools
• Cloud connectors - Add more connectors to cloud services (e.g. Amazon SQS, MQTT, Apache Kafka)
• Security connectors - Add more connectors to security services (e.g. OAuth2, SAML, OpenID, Yubikey)

We'll be looking at two graphs for this one; the one which shows the options for which respondents choose "Please do this!", and the one with the weighted outcome (using the same weights as in question 4).

Please do this!

Of all the options presented, rebasing most Java EE APIs on CDI is the one that most people really want to see. It's followed closely by more security connectors (authentication mechanisms). Clearly the ones that currently ship by default with Java EE, namely FORM (+ custom form), BASIC, DIGEST and CERT aren't enough anymore. MicroProfile recognised this too and therefor added a JWT authentication mechanism as one of the initial new APIs.

Weighted score

When looking at the weighted score, we see that all options presented have community support. Security connectors though have the most support, followed with some distance by adding JCache. Rebasing on CDI and Concurrency Utils, which could indirectly be taken as a wish to have a better integrated platform, has much support as well. At the bottom of the graph we see "Remove deprecated" and "Deprecate legacy". Seemingly people support removing some of the cruft that's in Java EE, but they are not overly concerned about this.

It's interesting to see that the alternative "Deployment models", which according to some vocal voices is *the* reason Java EE has been losing ground (the AS model is allegedly outdated), doesn't bother our respondents that much either. A reason is perhaps that with popular tools such as docker it doesn't matter so much whether you put an AS in it, or an uberjar. The AS might be known outside Java EE as a super large monolith, but actual Java EE users probably know that a modern AS is ~70 to 100mb and starts between 1 and about 3 seconds, while an uberjar can easily be around that same size too and starts in about the same time as well.

Question 15 - Do you have any final comments on how Java EE / Jakarta EE can be improved in the future?

The final question was a fully open question where people could comment whatever they wanted. 179 respondents left a comment, which is about 16% of the total number of respondents. Overal the quality of the comments was quite good. We'll provide a few of them here:

"Take good care of it, don't leave legacy behind. But still move it forward. by all means remove already deprecated stuff. I feel things can often be don the old and the new way.. And the support forums are full of good recomendations on both old and new. And it's sometimes confusing not being an expert."

"Please, single set of bean annotations. Not mixture of CDI, EJB and JSF"

"Externalize configuration for both AS domain and the app for all configurable properties. - All AS settings must be configurable via command line."

"Make it easier to have something between a full application server and just a few features (i.e. I only need JSF, JAX-WS, JavaMail, and DB, but not JPA and EJB, etc.) so they don't have to be manually added in the app or grafted into the servlet container in some non-standard way. Also, I'd prefer to be able to easily choose which technologies (JSF: Mojarra vs MyFaces, JAX-WS: Metro vs Apache CXF, etc.). Just a general thing to watch out for: Don't assume all users will want to use Maven; be sure you provide another way to download."

Tag cloud

Without further ado, let's kick off with the first episode which is about the "favourite" pastime of most devs out there: estimating our work! (click on the image for a larger version)

Stay tuned for the next instalment!

Here they are in their daily standup with scrum master Robert:(click on the image for a larger version)

Stay tuned for the next instalment!

Piranha Micro takes the framework bits and with a minimal amount of glue code assembles these into what resembles a more traditional Jakarta EE Server (including an HTTP stack and the ability to run a single war archive). We'll be blogging about some interesting features this version of Piranha has soon. For now just a small status update, and that's that we're working hard on compatibility.

Last month we passed the MicroProfile JWT TCK (which infers a certain minimal level of compatibility with CDI, Jakarta REST and MicroProfile Config). This month we've been looking at the Java EE 7 samples suite. This is an older, but still very valuable resource to both test implementations and learn how to use the Jakarta EE (Java EE) APIs.

We're happy to announce that Piranha Micro is passing all of the appropriate JASPIC (Jakarta Authentication) tests, and a large number of the Servlet and JAX-RS (Jakarta REST) ones. The JASPIC ones are particularly nice to pass, since Piranha uses the (largely) new OmniFaces implementation called Eleos for this. Furthermore, the plain Servlet Security tests are under the hood powered by Eclipse Soteria which is a compatible implementation (CI) of Jakarta Security. To the best of our knowledge, this is another unique feature of Piranha (more about this in a later blog). Note that skipped tests for JASPIC are about EJB, which Piranha doesn't support yet.

The results from running Java EE 7 samples against the latest snapshot from master (20.1.0-SNAPSHOT) are shown below:

[INFO] Reactor Summary for Java EE 7 Sample: jaspic 1.0-SNAPSHOT:
[INFO] 
[INFO] Java EE 7 Sample: jaspic - common .................. SUCCESS [  1.044 s]
[INFO] Java EE 7 Sample: jaspic ........................... SUCCESS [  0.284 s]
[INFO] Java EE 7 Sample: jaspic - basic-authentication .... SUCCESS [  7.600 s]
[INFO] Java EE 7 Sample: jaspic - custom principal ........ SUCCESS [  7.132 s]
[INFO] Java EE 7 Sample: jaspic - programmatic-authentication SUCCESS [  4.075 s]
[INFO] Java EE 7 Sample: jaspic - lifecycle ............... SUCCESS [  5.602 s]
[INFO] Java EE 7 Sample: jaspic - wrapping ................ SUCCESS [  4.041 s]
[INFO] Java EE 7 Sample: jaspic - register-session ........ SUCCESS [  5.756 s]
[INFO] Java EE 7 Sample: jaspic - async-authentication .... SUCCESS [  0.272 s]
[INFO] Java EE 7 Sample: jaspic - Status codes ............ SUCCESS [  5.535 s]
[INFO] Java EE 7 Sample: jaspic - dispatching ............. SUCCESS [  5.546 s]
[INFO] Java EE 7 Sample: jaspic - dispatching JSF CDI ..... SUCCESS [  4.076 s]
[INFO] Java EE 7 Sample: jaspic - ejb-propagation ......... SKIPPED [  0.290 s]
[INFO] Java EE 7 Sample: jaspic - ejb-register-session .... SKIPPED [  0.238 s]
[INFO] Java EE 7 Sample: jaspic - jacc-propagation ........ SUCCESS [  5.495 s]
[INFO] Java EE 7 Sample: jaspic - invoke EJB and CDI ...... SKIPPED [  0.228 s]
[INFO] ------------------------------------------------------------------------

[INFO] Reactor Summary for Java EE 7 Sample: servlet 1.0-SNAPSHOT:
[INFO] 
[INFO] Java EE 7 Sample: servlet .......................... SUCCESS [  0.754 s]
[INFO] Java EE 7 Sample: servlet - simple-servlet ......... SUCCESS [  5.634 s]
[INFO] Java EE 7 Sample: servlet - async-servlet .......... SUCCESS [  0.215 s]
[INFO] Java EE 7 Sample: servlet - servlet-filters ........ SUCCESS [  3.674 s]
[INFO] Java EE 7 Sample: servlet - cookies ................ SUCCESS [  4.096 s]
[INFO] Java EE 7 Sample: servlet - error-mapping .......... SUCCESS [  4.037 s]
[INFO] Java EE 7 Sample: servlet - event-listeners ........ SUCCESS [  4.178 s]
[INFO] Java EE 7 Sample: servlet - metadata-complete ...... SUCCESS [  3.986 s]
[INFO] Java EE 7 Sample: servlet - web-fragment ........... SUCCESS [  0.147 s]
[INFO] Java EE 7 Sample: servlet - nonblocking ............ SUCCESS [  0.174 s]
[INFO] Java EE 7 Sample: servlet - protocol-handler ....... FAILURE [ 13.564 s]
[INFO] Java EE 7 Sample: servlet - resource-packaging ..... FAILURE [  1.939 s]
[INFO] Java EE 7 Sample: servlet - file-upload ............ SUCCESS [  3.205 s]
[INFO] Java EE 7 Sample: servlet - programmatic-registration SUCCESS [  3.977 s]
[INFO] Java EE 7 Sample: servlet - security-basicauth ..... SUCCESS [  4.037 s]
[INFO] Java EE 7 Sample: servlet - security-digest ........ SKIPPED [  0.283 s]
[INFO] Java EE 7 Sample: servlet - security-form-based .... SUCCESS [  4.133 s]
[INFO] Java EE 7 Sample: servlet - security-clientcert .... SKIPPED [  0.394 s]
[INFO] Java EE 7 Sample: servlet - security-clientcert-jce  SKIPPED [  0.395 s]
[INFO] Java EE 7 Sample: servlet - security-programmatic .. SUCCESS [  4.084 s]
[INFO] Java EE 7 Sample: servlet - security-deny-uncovered  SUCCESS [  3.997 s]
[INFO] Java EE 7 Sample: servlet - security-allow-uncovered SUCCESS [  3.998 s]
[INFO] Java EE 7 Sample: servlet - security-annotated ..... FAILURE [  3.975 s]
[INFO] Java EE 7 Sample: servlet - security-basicauth-omission SUCCESS [  4.000 s]
[INFO] ------------------------------------------------------------------------

[INFO] Reactor Summary for Java EE 7 Sample: jaxrs 1.0-SNAPSHOT:
[INFO] 
[INFO] Java EE 7 Sample: jaxrs ............................ SUCCESS [  0.557 s]
[INFO] Java EE 7 Sample: jaxrs - async-client ............. SUCCESS [  5.177 s]
[INFO] Java EE 7 Sample: jaxrs - async-server ............. FAILURE [  4.058 s]
[INFO] Java EE 7 Sample: jaxrs - beanvalidation ........... FAILURE [  4.178 s]
[INFO] Java EE 7 Sample: jaxrs - beanparam ................ SUCCESS [  4.105 s]
[INFO] Java EE 7 Sample: jaxrs - client-negotiation ....... FAILURE [  4.240 s]
[INFO] Java EE 7 Sample: jaxrs - db-access ................ FAILURE [  3.567 s]
[INFO] Java EE 7 Sample: jaxrs - dynamicfilter ............ SUCCESS [  4.885 s]
[INFO] Java EE 7 Sample: jaxrs - fileupload ............... SUCCESS [  4.671 s]
[INFO] Java EE 7 Sample: jaxrs - filter ................... SUCCESS [  4.226 s]
[INFO] Java EE 7 Sample: jaxrs - filter-interceptor ....... SUCCESS [  0.186 s]
[INFO] Java EE 7 Sample: jaxrs - interceptor .............. SUCCESS [  0.163 s]
[INFO] Java EE 7 Sample: jaxrs - invocation ............... SUCCESS [  0.149 s]
[INFO] Java EE 7 Sample: jaxrs - invocation-async ......... SUCCESS [  0.169 s]
[INFO] Java EE 7 Sample: jaxrs - jaxrs-client ............. FAILURE [  4.458 s]
[INFO] Java EE 7 Sample: jaxrs - jaxrs-endpoint ........... SUCCESS [  4.332 s]
[INFO] Java EE 7 Sample: jaxrs - jsonp .................... SUCCESS [  4.377 s]
[INFO] Java EE 7 Sample: jaxrs - link ..................... SUCCESS [  0.268 s]
[INFO] Java EE 7 Sample: jaxrs - mapping-exceptions ....... SUCCESS [  4.113 s]
[INFO] Java EE 7 Sample: jaxrs - paramconverter ........... SUCCESS [  4.300 s]
[INFO] Java EE 7 Sample: jaxrs - readerwriter ............. SUCCESS [  4.483 s]
[INFO] Java EE 7 Sample: jaxrs - readerwriter-json ........ SUCCESS [  0.204 s]
[INFO] Java EE 7 Sample: jaxrs - request-binding .......... SUCCESS [  0.149 s]
[INFO] Java EE 7 Sample: jaxrs - resource-validation ...... FAILURE [  4.474 s]
[INFO] Java EE 7 Sample: jaxrs - server-negotiation ....... FAILURE [  4.112 s]
[INFO] Java EE 7 Sample: jaxrs - simple-get ............... SUCCESS [  3.982 s]
[INFO] Java EE 7 Sample: jaxrs - singleton ................ SUCCESS [  5.907 s]
[INFO] Java EE 7 Sample: jaxrs - readerwriter-injection ... FAILURE [  2.542 s]
[INFO] Java EE 7 Sample: jaxrs - jaxrs-security-declarative SUCCESS [  4.497 s]
[INFO] ------------------------------------------------------------------------

Arjan Tijms

In total 59 issues were done for this release, which mostly included work for Payara Micro, but also includes improvements for Servlet compatibility among others. Note that Piranha is a work in progress and not yet ready for regular use, let alone production usage.

Piranha itself is an upcoming Jakarta EE and MicroProfile runtime, currently in its early stages of development. Piranha's main goal is to use Jakarta APIs as much as possible as a library, using a flat class loader, and no concept of deploying applications, in other words without being an application server.

Piranha Micro however builds on the core Piranha foundation to deliver something that comes closer to a server; it can run a single application in archive form, albeit it can't undeploy and redeploy (this is on purpose). Specifically for embedded use it features an isolated class loader. Contrary to a traditional application server where an isolating class loader is used to run multiple applications in separation from each other, its purpose in Piranha is to isolate the archive from the application and all its classes and config files that embeds Piranha.

The jar files with Jakarta EE APIs and their implementations (for example the Jakarta Faces API and the Mojarra implementation) are handled in a somewhat unique way in Piranha Micro. The native method it internally uses is to load these via Maven, as demonstrated by the following snippet of internal code:

// Resolve all the dependencies that make up a Piranha runtime configuration

ConfigurableMavenResolverSystem mavenResolver = Maven.configureResolver();

configuration.getRepositoriesList().stream().forEach(repoUrl ->
    mavenResolver.withRemoteRepo(createRepo(repoUrl)));

JavaArchive[] piranhaArchives = 
    mavenResolver
         .workOffline(configuration.isOffline())
         .resolve(configuration.getMergedDependencies())
         .withTransitivity()
         .as(JavaArchive.class);

// Make all those dependencies available to the Piranha class loader
ClassLoader piranhaClassLoader = getPiranhaClassLoader(piranhaArchives);

A related feature of Piranha is that jars loaded this way do not need to be stored and/or extracted on the filesystem first, but are loaded in-memory and directly passed to the custom class loader. Piranha Micro uses ShrinkWrap archives for this, which has the additional advantages that when archives are created programmatically for embedded usage, Piranha Micro can run these directly.

Due to the early stage of development, Piranha Micro is currently only readily available via its Maven Arquillian connector. It can be seen in action in the Java EE 7 Samples project. For instance by cloning the project and typing the following:

cd jaspic
mvn clean install -Ppiranha-embedded-micro

Arjan Tijms

In this blog we're going to take a quick look at what this server entails. As Jakarta EE is a very complete platform, from scratch implementations are rare to basically non-existent, so it's interesting to see what's exactly in Primeton AppServer V7.

Within a Jakarta EE certification request, a link where the product (or a trial thereof) can be downloaded is mandatory, and Primeton indeed provided one. Today's Internet users normally have it easy. One clicks on a download link, and the software effortlessly transfers to your machine. Thanks to 500mbit+ speeds which are becoming increasingly common in this part of the world, most downloads take mere seconds. If you're from a certain age though, you may remember how different this was in the late 80s and early 90s. Dial-up modems that would fail halfway (or not rarely, when at 99%), and a download of 1MB or less taking hours and hours.

The Primeton download brought some of these nostalgic memories back:

Challenge 1: Initially your are presented with a challenge: a box in which you have to enter something, and you have to type something back to get something again:

Puzzling... after some attempts and with the help of Chrome translate, it appeared to be a phone number. Of course, only Chinese numbers are accepted, and Chinese numbers are fairly difficult to obtain from outside China (a problem which we'll stumble upon once more later). Luckily the kind people at Primeton agreed to reduce the difficulty of this challenge and changed the challenge screen to:

Challenge 2: a new screen with multiple boxes, some of which drop-downs. How to beat this one? The first was a numerical box. After some trial and error it appeared it wanted a number of 11 digits, starting with 134 to 139, or 150 to 159, and some more. I opted for "13412341234", and hey ho, it was happy with that. Sub-challenge 2.1 beaten! But the other boxes proved more difficult to pass. No matter what I put into them, it kept giving me back "提示 请检查姓名,公司字段". Did it want only Chinese characters? Or only English? Perhaps of a certain length? Eventually it appeared that the secret combination one had to enter was hard refreshing the page again. It's not super clear how the system exactly detects this, but there you have it. It was now fully happy, and after leaving me in anticipation for a few seconds it provided me with the third challenge: a mysterious link and a code. (hint: the code is only for a short while on your screen, so copy it right away when you get it).

Challenge 3: The link looked something like this: https://pan.baidu.com/s/1TKf9B_puPZfDooooXXX (made up link), while the code looked this this: a8op (again, made up code). Entering the link, the mysterious website asked for the code. I expected this to involve a challenge as well, but somewhat to my surprise the code was accepted without an additional challenge. I was now presented with what appeared to be a download page:

Challenge 4: after some trial and error, it appears the challenge is to create an account. Initially this seems simple. After all, we create accounts all the time everywhere. How hard can this possible be? Well, the answer is: very hard, or in this case, very challenging. Where sites such as Reddit once wowed people all over the world in simplifying account creation as much as possible, Baidu wowed people by making it as hard as possible (for people outside China, that is). After being stuck for quite some time on this challenge, I basically admitted defeat. The key problem is that you need a Chinese phone number again, although there's a hidden registration form where you can provide numbers from countries like Nigeria or Korea, but unfortunately nothing from the EU. Luckily a Chinese friend could help me out, so I got an account. Yes, it's cheating a little. Having the account the site directed me to the fifth challenge; a riddle.

Challenge 5: the website presented me the following riddle: "Yundetectservice.exe". In the time of Internet and Google, old fashioned riddles are not much of a challenge and it appeared that the riddle referred to having to install something called Baidu Netdisk. This appeared to be relatively simple. So I installed this, and logged-in to it using the aforementioned account. When you try to download something using the teaser screen shown above, the riddle would come up again, which you can just answer with "yes", upon which the Baidu Netdisk will take over the download, and then present you with the sixth challenge.

Challenge 6: the Baidu Netdisk will display the file to be downloaded, keep you in suspension for a few seconds, then present you with a cryptic message:

Challenge 7: after puzzling for a bit on this one, it appeared you need to connect your Baidu account to a service called multcloud.com. There's a funny little sub-challenge here, where you need to create a folder on your Baidu cloud storage called "lin1118" and move whatever you want to download to there. The challenge again tries to throw up some decoys, like making you belief you can transfer the file to another cloud storage, like e.g. Google Drive, but this is again just a decoy. If you look closely, you can obtain a public share link to the file you want to download, which presents you with a download icon on its turn that actually starts to download!

But what fun would it be if it ended here so easily? There's a plot twist when the download suddenly stops! Resuming it will download maybe 200kb, maybe a whopping 2MB even, but never really more. It's throwing up a final challenge for you, the eighth one.

Challenge 8: getting the download to continue. Puzzling on this for a while using several different browsers, I finally beat this challenge using a download manager on Windows called Internet Download Manager (IDK). After installing this and attempting the download again, it will take it over and... is accepted by our game master and finally, finally allows us to download the file:

Now that was interesting! Who said downloading a file is boring?

Having spend nearly all my free time on this funny, but indeed time consuming challenge, I took a quick look at the archive. Inside are some installer scripts and a resources folder. In "resources/as_comps/" there's what seems to be the actual Jakarta EE 8 server: "pas-7.0.0.zip":

Opening that one, reveals a (to me) very familiar layout:

Now being GlassFish based is not that out of the ordinary in Jakarta EE land. The "Japanese 3" are all based on GlassFish as well, mostly having their own support channels and their own assortment of fixes. We're therefor very happy that Primeton has adopted GlassFish for its Chinese customers, and look forward to whatever this brings to the table concerning the upstream GlassFish maintenance.

Looking at the landscape of Jakarta EE compatible products, we now have 4 families of products: the GlassFish based ones, the JBoss based ones, JEUS and Open Liberty. It's expected that WebLogic will join this group soon (which is a unique implementation, though does share some bits with GlassFish), and hopefully Fujitsu will soon join as well (which is GlassFish based). For now the landscape looks like this:

Arjan Tijms

Fast forward 6 years, and we have arrived at Jakarta EE 8 essentially (a re-licensing of Java EE 8). Most servers from the previous instalment have Jakarta EE 8 versions out. WebLogic has its Java EE 8 version officially out, with a Jakarta EE 8 version coming soon (there is no technical difference between these two really). TomEE has started to implement Java EE 8 and in its latest version has gotten quite far, but is not there yet. Resin remained at Java EE 6 with seemingly no plans to update these. JOnAS has disappeared off the face of the earth, and so has Geronimo as server (though as a provider of APIs and their implementations it has stayed alive).

Without further ado, here's the matrix of Java EE 8/Jakarta EE 8 implementation components used by Java EE/Jakarta EE servers:

Each color a component has reflects the vendor with that color in the header. Essentially there's four vendors creating separate and re-usable Jakarta EE components:

Oracle and TMaxSoft do create components that implement Jakarta EE APIs, but only use them within their own server products. Things are however not that clear cut. As can be seen in the previous instalment, all the components that are now Eclipse components were Oracle components before. This is because Oracle donated all of its reusable components to the Eclipse Foundation. Although IBM only directly produces one reusable component (jBatch FRI), it did not too long ago acquire Red Hat. This means all Red Hat components are essentially IBM components now, just as when the Sun components became Oracle components after Oracle acquired Sun.

If we look at the servers itself, we see that only TomEE exclusively uses components from a single vendor; its own vendor Apache. WildFly uses many components from its own vendor Red Hat, but uses components for Faces, JSON, Concurrency and Security among others from Eclipse. WildFly uses a single Apache component, namely ActiveMQ Artemis. This however used to be Red Hat's own component, HornetQ, which it donated to Apache in order to merge the existing ActiveMQ and HornetQ communities and together work on the next generation message broker.

GlassFish uses most components from Eclipse, its own vendor, two from Red Hat and one from IBM. This is however not randmom. As the former RI (reference implementation) of Java EE, it incorporated all the RI components. Since Red Hat was leading two specs, and IBM one, it used the components from those spec leaders. In Jakarta EE the concept of the RI has been done away with and has been replaced by compatible implementations, of which there always needs to be at least one. Since GlassFish is no longer an RI, its community could potentially develop Eclipse implementations of CDI, Validation and Batch. At least for the former a development that could lead to this is being considered by Payara.

Derivative servers were not included in the table, as they have the same components as the server they are derived from (albeit these components could be in different versions). This includes Payara and Cosminexus (Hitachi Application Server), and JBoss EAP. It's perhaps interesting to note that Payara and Hitachi are joint co-leaders of the GlassFish project and devote a significant amount of resources to further the upstream GlassFish project together with former owner Oracle.

Also excluded is our own Jakarta EE runtime, Piranha. This is because at the time of writing Piranha is far from ready. Via the OmniFaces project Piranha does introduce new reusable Jakarta EE components; for Jakarta Authentication and Jakarta Authorization, which until so far hadn't been produced by anyone (JOnAS however once did start development for a reusable Jakarta Authentication/JASPIC component).

Arjan Tijms

Sometimes though it's hard to resist using these constructs in code, since we imagine our tiny app being larger than it actually is, or because we think it soon will be. Interestingly, when structuring companies very similar pitfalls seem to exist.

Poor OmniDev head of engineering Liz and her friend Jennefer, who's head of marketing, are about to find out: (click on the image for a larger version)

Stay tuned for the next instalment!

Previous strip: The productive standup

A good and competent boss will often consult with the staff to discover where the need is most pressing.
(click on the image for a larger version)

Even larger version

Stay tuned for the next instalment!

Previous strip: Perfecting the business structure

With the transfer of Java EE to Jakarta EE now almost completed, people are now starting to think about Jakarta EE 10, the first Jakarta EE release after Java EE 8 having new featues. As such it's a good time to poll the community again.

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

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

Compared to 2018, we simplified some of the questions somewhat, omitting some of the less popular options to make it more manageable. We added questions about the future of Jakarta EE and MP together, the preferred Jakarta EE cadence, and generally updated the choices (such as adding Quarkus, which wasn't quite on the radar in 2018 and our own Piranha Cloud).

Jakarta EE provides the opportunity to revitalise and modernise Java EE, but in order to do that it's more important than ever that we know what matters to all of its users out there.

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

One of the compatible implementations of Jakarta Security is Soteria. Soteria has been designed as a standalone library, that can be integrated with multiple servers. It depends on CDI, and the lower level SPIs Jakarta Authentication and Jakarta Authorization.

Soteria worked on Tomcat before, but there were some issues. For one, when adding a CDI implementation like Weld to Tomcat, the BeanManager ends up in the JNDI location java:comp/env/BeanManager, while the specification defined location should be java:comp/BeanManager. The latest version of Soteria now looks at this location too, so no patching is required anymore.

Another issue was that Tomcat implements the servlet container profile of Jakarta Authentication, but not Jakarta Authorization. There are essentially two options to overcome that here:

1. Add Jakarta Authorization support to Tomcat
2. Implement an SPI for Soteria to use native Tomcat Authorization code

<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version>9.0.0</version>
<scope>provided</scope>
</dependency>

<dependency>
<groupId>org.glassfish.soteria</groupId>
<artifactId>jakarta.security.enterprise</artifactId>
<version>2.0.1</version>
</dependency>

<dependency>
<groupId>org.omnifaces</groupId>
<artifactId>exousia</artifactId>
<version>1.0</version>
</dependency>

<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet-shaded</artifactId>
<version>4.0.0.Final</version>
</dependency>

<?xmlversion='1.0'encoding='utf-8'?>
<Context>
<Resource
        name="BeanManager"
        auth="Container"
        type="javax.enterprise.inject.spi.BeanManager"
        factory="org.jboss.weld.resources.ManagerObjectFactory"
/>
</Context>

<web-app
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaeehttps://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"
    version="5.0">
<security-constraint>
<web-resource-collection>
<url-pattern>/foo/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>g1</role-name>
</auth-constraint>
</security-constraint>

<security-constraint>
<web-resource-collection>
<url-pattern>/foox/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>g2</role-name>
</auth-constraint>
</security-constraint>
</web-app>

@BasicAuthenticationMechanismDefinition(realmName = "realm")
@ServletSecurity(value = @HttpConstraint(rolesAllowed = "g1"))
@WebServlet(urlPatterns = "/SecureServlet")
publicclass SecureServlet extends HttpServlet {

privatestaticfinallong serialVersionUID = 1L;

@Inject
    SecurityContext securityContext;

@Override
protectedvoid doGet(HttpServletRequest request, HttpServletResponse response) 
throws ServletException, IOException {
        response.getWriter().println(
"Has access to /foo/bar " + 
            securityContext.hasAccessToWebResource("/foo/bar", "GET"));
        response.getWriter().println(
"Has access to /foox/bar " + 
            securityContext.hasAccessToWebResource("/foox/bar", "GET"));
    }

}


@ApplicationScoped
publicclass MyIdentityStore implements IdentityStore {
public CredentialValidationResult validate(UsernamePasswordCredential usernamePasswordCredential) {
if (usernamePasswordCredential.compareTo("u1", "p1")) {
returnnew CredentialValidationResult("u1", newHashSet<>(asList("g1")));
        }

return INVALID_RESULT;
    }
}

Naming the app "security-test", deploying this to a default installed Tomcat 10 and requesting "http://localhost:8080/security-test/SecureServlet" via a web browser will show the basic authentication dialog from that browser. If we then authenticate with username "u1" and password "p1", we'll get to see the following result:

Has access to /foo/bar true
Has access to /foox/bar false

So what happened here?

Behind the scenes quite a lot. Soteria installed a ServerAuthModule with Tomcat, which uses Weld to find and call the CDI bean installed by @BasicAuthenticationMechanismDefinition. This bean calls the IdentityStoreMyIdentityStore, which is the one we defined in our small application and that validates the credentials we submit.

Furthermore, Exousia copied the security constraints that Tomcat collected to a Jakarta Authorization module, which is a store of permissions (aka Permission Store) that among others can be queried by Jakarta Authorization. The default implementation in Soteria of SecurityContext#hasAccessToWebResource indeed results in such a query. In our web.xml file we defined two constraints on URL patterns; /foo/* needing role g1 and /foox/* needing role g2. At the point of making that call, we're in role g1, so asking if we can access /foo/bar results in a true, while asking for access to /foox/bar results in a false. This shows that Jakarta Authentication (Exousia) works correctly on Tomcat and works correctly with Soteria.

There's a small caveat here. Exousia now copies the security constraints from Tomcat, but Tomcat keeps using its own internal repository for authorization decissions. The assumption here is that both Tomcat and Exousia perform the exact same algorithm, but there can of course be small subtle differences. A next step would be to integrate Exousia further in Tomcat by wrapping the Realm and delegating methods like hasUserDataPermission, hasResourcePermission, and hasRole.

Arjan Tijms

The first question is about which version of Java EE/Jakarta EE people use. While the final results are not yet in, let's take a sneak peek at the preliminary results.

Which versions of Java EE/Jakarta EE have you recently used? (select all that apply)

The Jakarta EE Survey 2020/2021 is still open. So if you haven't completed the survey yet, there's still time:

In this survey we asked several questions about Jakarta EE, what people use exactly, and what they would like to see next. The survey was promoted in October, after which we got about 500 responses. The survey was left alone for the next months, until a little promotion was done in February, resulting in about 100 extra responses. In total we ended up with 684 respondents in total, which is down from the 1054 we got last time.

Looking at the results we must keep in mind that surveys like this are by definition biased; the respondents are self-selected, and come from the pool of places that we (OmniFaces) reach. These are our own website, our Twitter account, the Jakarta EE news section, etc. The results may therefore be biased towards the more active OSS developer.

Overview of questions

1. Which versions of Java EE/Jakarta EE have you recently used?
2. Which application servers have you recently used?
3. How would you rate the application servers that you've used?
4. Which Java EE/Jakarta EE APIs have you used recently?
5. Have you used a (standalone) Servlet container recently?
6. Which Servlet containers have you used recently?
7. Which additional Java EE/Jakarta EE libraries do you use with your Servlet container?
8. On average, how many Java EE/Jakarta EE libraries do you add when using a Servlet container?
9. Have you used MicroProfile APIs recently?
10. Which MicroProfile products have you used recently?
11. Which MicroProfile APIs have you used recently?
12. What's your preferred situation regarding MicroProfile vs Jakarta EE?
13. What Jakarta EE and MicroProfile products do you prefer?
14. Which of the following products that support one or more Jakarta EE APIs, but are not traditional or certified EE application servers, have you heard of?
15. What would be the ideal cadence (time between major releases) for Jakarta EE?
16. Knowing that Jakarta EE 9 contains only the javax to jakarta namespace change, do you:
17. Which APIs would you most like to see updated in the next version of Jakarta EE?
18. How important are the following general options to improve Jakarta EE?
19. How important are the following more specific options to improve Jakarta EE?
20. Do you have any final comments on how Jakarta EE can be improved in the future?

Let's take a look at the results from this year with the first question:

Question 1 - Which versions of Java EE/Jakarta EE have you recently used?

Question 2 - Which application servers have you recently used?

It must be noted that Payara Server is a fork of GlassFish, and despite Payara slowly putting more distance between itself and GlassFish (by for instance using a different embedded database, a different default clustering solution, and incorporating their own developed MP components) they still share an overwhelming amount of code. Essentially Payara Server and GlassFish are in the same family.

Additionally, though marketed as two products, WildFly and JBoss EAP share the same codebase and are technically more or less identical (representing different points in time on the overal line of code).

The above means that TomEE as a server family comes in third. Here too, we asked a similar question in 2018. Then the results were as follows:

Once the two most dominant application servers, WebLogic and Websphere have gone back further to 10% resp. 8%. Open Liberty gained almost exactly what Websphere has lost, going from 8% to 11%. Though we can't tell from this survey, it's not unthinkable an amount of WebSphere users moved from WebSphere to Open Liberty as those two are both from IBM.

Question 3 - How would you rate the application servers that you've used?

As the chart with all results in it looks rather crowded, let's first take a look at one with the two extreme emotions "Love it" and "Hate it" in it. The "Like it" is also added for connection with the next graph.

Like in 2018, there's little hate for most servers, with the notable exception of WebSphere and to some lesser degree WebLogic. Maybe it's not a coincidence that those two are the only closed source servers used.

Let't take a quick look at the 2018 "Love it" results again to compare:

Let's now take a look at the graph with the less extreme emotions "Like it" and "Don't like it" and the neutral "Does the job".

Let't take a look at the 2018 "Like it" results to compare:

Question 4 - Which Java EE/Jakarta EE APIs have you used recently?

Comparing this outcome with the 2018 result doesn't really show any major differences:

Popular

{Persistence, CDI, REST, Faces, Enterprise Beans, Servlet, Transactions, Bean Validation}

Neutral

{Expression Language, JNDI, XML Binding, Mail, JSON Binding, XML Web Services, Messaging, Security, JSON Processing, WebSocket}

Not so popular

{Pages/Tags, Concurrency, Batch, Connectors, Authentication, Authorization}

It must be noted that Authentication and Authorization are SPIs, and as such not so much intended to be used directly by the average Jakarta developer. These are used however internally by Jakarta Security, and depending on the server or runtime by the Jakarta Servlet implementation as well. Because their standalone usage is so low, it's been proposed to fold them into Jakarta Security at some point.

Question 5 - Have you used a (standalone) Servlet container recently?

A standalone Servlet container is a server that supports at least the Servlet API, and typically a number of strongly related APIs such as the Servlet Container Profile of Jakarta Authentication, Jakarta Expression Language, JNDI, Jakarta Pages and Jakarta WebSocket.

As it appears, about half of the respondents have used such Servlet container, while the other half hasn't (and thus only used something like a full or web profile Jakarta EE server).

Comparing this outcome with 2018 shows yes and no have swapped places, but it's still quite close.

Which Servlet containers have you used recently?

Comparing this with 2018 we see both Jetty and Undertow have gained a few percentage points of popularity, while Tomcat has lost about as much:

Question 7 - Which additional Java EE/Jakarta EE libraries do you use with your Servlet container?

Perfectly corresponding with the APIs that people use in general, CDI is at the second place of things people add. 46% of them add Weld, while 6% adds OpenWebBeans.

As for Jakarta REST (JAX-RS) it's interesting to see that Jersey and RESTEasy are added about as often. Comparing with 2018 again, we see a few things:

Soteria, a Jakarta Security implementation has gone up quite a bit as well, relatively speaking. This is interesting. Soteria was particularly designed to be usable on multiple servers and runtimes, but until recently there were some practical issues with Soteria on Tomcat, and this has only been truly fixed after the survey started.

For the "Other" category, people mentioned Spring, PrimeFaces, OmniFaces and DeltaSpike, perhaps not unsurprisingly.

Question 8 - On average, how many Java EE/Jakarta EE libraries do you add when using a Servlet container?

We see here that 37% of users of a Servlet container in our target audience add more than 4 Jakarta EE libraries to their war archive. Adding exactly 3 was another popular choice, though interestingly enough adding exactly 4 was quite a bit less popular. Of course our target audience consists of users particularly interested in Jakarta EE, so the above absolutely does not men 37% of all Servlet container users add so many libraries.

Question 9 - Have you used MicroProfile APIs recently?

MicroProfile is an industry effort to bring extra APIs into the EE fold for things which Jakarta EE doesn't have an API now, such as configuration and metrics. At the same time MicroProfile is also a little like a profile such as WebProfile, where only those extra APIs are included as well as Jakarta REST, Jakarta JSON and CDI.

Lets right away compare the 2020 result to the 2018 one:

Question 10 - Which MicroProfile products have you used recently?

Interestingly, when it comes to MicroProfile, the Jakarta EE products of Red Hat and Payara are used approximately as often as their non-Jakarta EE products, with only a small edge for the non-Jakarta EE versions. It must me realised though that even though Quarkus and Payara Micro are not EE certified, they both contain many EE components.

Payara Micro is actually very close to Payara Server, with only a few EE components removed (like a Jakarta Messaging broker). Quarkus is more difficult to qualify in terms of EE. Via its app generator one can see it supports a bewildering amount of different components, and there's no explicit mention of EE. Eagle eyed readers however would be quick to recognise a multitude of components which are in fact originating from, based on, or used for Jakarta EE.

Something particular noteworthy is that this list doesn't really contain any "pure" MicroProfile implementation. With that we mean an implementation that only implements MicroProfile and nothing else. Somewhat ironically given the history, Helidon maybe comes closest to that, although it also integrates Jakarta Persistence and Jakarta Transactions, as well as Jakarta WebSockets.

We're particularly happy to see that Piranha Cloud has a small amount of users already. Piranha Cloud is our own platform. At the moment of writing it's still in development and not fully production ready yet. Comparing with the 2018 results shows many differences:

Payara Micro and Open Liberty both saw a rather big decline in usage. Hammock unfortunately stopped its development, although it still has a 1% user base left from its initial 3%.

Question 11 - Which MicroProfile APIs have you used recently?

Question 12 - What's your preferred situation regarding MicroProfile vs Jakarta EE?

1. MicroProfile joining up with Jakarta EE
2. MicroProfile and Jakarta EE being two separate frameworks

"There should be a common base - config + injection that both should use. Whether it is Jakarta or MP or both is not that significant I think"

"Microprofile as Cutting Edge Jakarta EE standardizing after things are well established "

"Having more than one standard is going to cause more confusion "

"Using MP as incubator for Jakarta EE but use the jakarta namespace also for MP. So the users will not need to migrate once the MP Apis are moved to Jakarata EE "

Question 13 - What Jakarta EE and MicroProfile products do you prefer?

1. Separate products for the EE and MP APIs
2. Single product for both the EE and MP APIs
3. Don't care

Question 14 - Which of the following products that support one or more Jakarta EE APIs, but are not traditional or certified EE application servers, have you heard of?

Only 36% of the respondents answered this question, so we'll mention two percentages here: the first the percentage relative to the total number of respondents, the second number relative to those who answered the question.

Question 15 - What would be the ideal cadence (time between major releases) for Jakarta EE?

Here we see that there's strong support for a yearly cadence under our respondents. Taking twice as much time (and hence including more per release), or taking half of that time (and thus including less per release) are about as populair. The existing cadence of 3 years did not appear to be very popular at all.

Some of the comments:

"LTS every 2 years, minor releases every year, bugfixes evey 6 months "

"Feature releases and LTS like Java SE does it for stability and innovation balance "

"Hard to say but 6 months would definitively be too short for us. We have many small applications with only a few releases each year (~ 1 to 4 releases). "

Question 16 - Knowing that Jakarta EE 9 contains only the javax to jakarta namespace change, do you:

1. Migrate to Jakarta EE 9 as soon as your favourite server (e.g. Wildly) comes out with an EE 9 version
2. Wait for Jakarta EE 10 with actual new features
3. Other

Some of the comments:

"Wait to give my other dependencies time to catch up on EE9 "

"We will try to migrate to jakarta EE 9 once tomee implementation is based on jakarta, without bytecode transformation and other libraries are migrated as well (logback, javamelody,etc). We think it will be a very painful task "

"Migrate as soon as all the (many) internal dependencies update "

"Depends on when my cloud service provider offers it"

"Do new development on the leading edge; migrate others as we go. "

Question 17 - Which APIs would you most like to see updated in the next version of Jakarta EE?

Looking at the total ranking we see the most desire for updates is in CDI, followed by Jakarta Persistence (JPA) and Jakarta Rest (JAX-RS). These three largely follow from what people actually use. Jakarta Security stands out here: respondents relatively speaking more often want to see it improved compared to how often they are using it. Jakarta Mail (JavaMail) is the opposite here. It's used more often compared to how often people like to see it improved.

This may be explained by Jakarta Security being a small and new API. Introduced in Java EE 8, it only covers the basics. Advanced features were initially left for Java EE 9, but then the entire transition to Eclipse started. Jakarta Mail likely simply does what it needs to do: send email. There's not that much demand for anything else there, it's a stable and fairly complete API.

Comparing with the 2018 results we don't see a lot of differences (note that for the 2020 question we folded several highly dependent APIs, such as all the Security APIs, into one):

Question 18 - How important are the following general options to improve Jakarta EE?

The features were as follows:

• Aligning specifications and features to take better advantage of CDI, making CDI truly the central component model for Jakarta EE
• Aligning specifications and features to take better advantage of Java SE innovations
• Including more commonly used features that are vendor-specific today or available outside Jakarta EE technologies
• Officially add alternative deployment models  such as the Uberjar, run .war from command line, etc.
• Aggressively deprecate and remove legacy features
• Aggressively remove everything that is already @Deprecated but still there

Taking advantage of new Java SE innovations is high on the list as well. This could include for instance fairly old things that have still not been fully utilised such as lambdas, or things that are theoretically old, but practically still very new too many people, such as modules. Records, and in the future light-weight user mode threads (aka fibers) could have a massive impact on some APIs.

Alternative deployment models were less popular among our respondents, although that could just mean people don't see a point in standardising them and using them in a vendor specific way is enough.

Removing and/or deprecating things ranked lowest. Perhaps this is somewhat surprising, as at the same time people ask to reduce the cognitive load in Jakarta EE, for which removing legacy things should surely help.

Question 19 - How important are the following more specific options to improve Jakarta EE?

• Add more SQL features to JPQL and the Criteria API such as sub-selects
• Make REST (JAX-RS) resources fully CDI beans, deprecate @Context
• CDI friendly equivalents for @Asynchronous, @Schedule and @Lock
• REST friendly, extensionless URLs for Faces (JSF)
• @Service CDI stereotype that seeks to deprecate EJB @Stateless
• Have Servlet and REST (JAX-RS) share a common HTTP engine
• Make Servlets fully CDI beans (in Jakarta EE only, allows for scopes and interceptors)
• CDI friendly, modernized equivalents for @RolesAllowed and @RunAs
• CDI friendly equivalent for @MessageDriven
• @ManagedExecutorServiceDefinition annotation for more portably defining managed executors

At the second place we see REST resources becoming fully CDI, and the CDI equivalents for @Asynchronous, @Schedule and @Lock, which corresponds well to the improvements for REST and the CDI alignment that people like to see at a more general level. REST URLs for Faces scores quite high as well. For this JSF 2.3 did important foundational work, but it's still a bit of a hassle to actually use it. For Faces 4.0 we are targeting a simple option to activate this, as well as a new action lifecycle.

Question 20 - Do you have any final comments on how Jakarta EE can be improved in the future?

"Jpa criteria is terrible to use. It would be good have an alternative "lite" criteria in jpa similar to hibernate one."

"JPA really is complex to use with the cloning; as long as you are in a request-response setting it is ok, but with a more long lived fat client it's complex. May introduce a mode where no clones are used."

"JNoSQL should align with the forthcoming ISO GQL rather than tying to TinkerPop."

"Standarize the jpa data repository abstraction (à la spring boot / micronaut data / quarkus panache). Merge MP config , fault tolerant, health check, rest client to Jakarta EE with the jakarta namespace. Make Jakarta Messaging support Kafka and standard messaging protocols... DEprecate ejb and move its APis to other corresponding specs Ahead of time CDI processing. Modularize the platforme (use some sort of starter instead of profiles) ... And we're good :)"

"I would like to see Jakarta EE 9 ASAP. At the moment I feel that there is an chaos and stagnation and more and more people are afraid to choose Java/Jakarta EE because they don't see the clear future."

"Release EE 10 ASAP, Spring is becoming de-facto standard "

"Remove EJB and include more security features of OAuth2, and other protocols. Also, make CDI very central to JakartaEE, and include latest Java SE features in future APIs of Jakarta EE. Also, let Jakarta EE support Java programming language exclusively, as primary and first class support. Other JVM languages should be given less preference over Java."

"There are 4 different annotations that 'inject' something: @Inject - inject a bean @Resource - inject a (typically) DataSource @EJB - inject an EJB @PersistenceContext - inject an EntityManager Wish it could all be just '@Inject' Also make sure works for constructor-injection as well as field-injection"

"Add Quarkus like build time optimizations, for example for CDI, Make the extensions API work in these environments, so these CDI implementations don't need a proprietary extension API"

"JEE was affected by seasonal fads, problems with updating and bureaucracy of big companies, I believe in the robustness, in the reliability for the craziest that the boys call me for continuing to start new projects my clients and I are very satisfied. Thank you for helping the community that is very strong and knows the power that the whole package has. As long as the JEE exists and I will use it."

"Make @DataSourceDefinition work with injected values vendor-neutral. Configuration in general across environments in a secure way."

"Get rid of legacy and complexity (focus on CDI) and get ready for cloud (MicroProfile)"

"I feel like MicroProfile born out of slow moving Java EE. Now both taking own route even though CN4J formed. May be once Jakarta 10 or 11 released. Make both Jakarta EE and MicroProfile under one brand. We already break namespace charge for Jakarta EE 9, not sure how many will upgrade for that immediately. Jakarta 10 might be good Candidate to remove some old or deprecated stuff, and then make Jakarta 11 naturally home for microphone. That's we taking of 2 years from now once Jakarta falls yearly release Cadence."

"Make every API based on CDI for consistency."

"Better specification related to microprofile and its interaction with Jakarta EE or its existing APIs like CDI or JAX-RS"

"make JEE and microprofile converge, I want to build a thin war and deploy it and needed resources from a simple command line that could be transformed into a systemd service or Podman container; hot reload on development mode."

A special mention for this comment, where the writer took quite a bit of effort: (we do wonder if this writer is familiar with Jakarta Security, or whether the security comment is refering to JASPIC/JACC and/or container specific/proprietary security):

" * first-class support for fully programmatic configuration and bootstrapping of all specs outside a JEE container. We should not need to use Arquillian, test modules from the spec vendors, or similar to write JUnit tests or to leverage our know-how with CDI, JPA, etc to write a non-server application.
* kill everything EJB with fire, nobody wants pooled beans with synchronization, wrapping of exceptions
* CDI annotations for calling a method periodically and on application startup.
* everything should be a CDI bean.
* OpenAPI support (contract-first development support by generating model, API interface from YAML, fully cover the spec when (de)serializing).
* JPA is a foot-cannon. Persistence as a side effect of in-memory object state is complex and thus unexpected behavior /mistake-prone and not worth the convenience. Also, mapping annotations are poorly thought out and can be contradictory (eg. a @XtoY can have both cascade and mappedBy set) or open to interpretation (eg should a @PrePersist work on an @Embeddable?). Vendors (at least Hibernate) don't fail on startup when annotations have contradictory settings but will have undefined behavior. Either create an alternative type-safe SQL building and ResultSet-to-Object mapper spec or refer users to Jooq, QueryDSL or similar.
* All the security stuff is awful, its much easier to write your own filter+interceptor for login and permission checking. Remove it
* Maybe support for working with AMQP, Kafka brokers (don't run them in the application server like JMS)
* It's probably all for nothing as Spring Boot has won and very few people will start a greenfield project in JEE."

P.s. we had a few users mention the many open PRs in the Mojarra project. Yes, we're aware, and hope to be able to look at them soon. Any help in doing reviews and/or tests is highly welcomed!

With MicroProfile and Jakarta EE now both at Eclipse, and both including approximately all of the same vendors again, there has been an increasing demand for somehow joining the efforts. We asked about this in our recent survey, where most repsondends would like to see them aligned.

This begs the question of how to do this exactly. MicroProfile is already using Jakarta EE APIs, and there's a strong desire to use MicroProfile Config in Jakarta EE. This would result in a circular dependency though, which is, perhaps, not ideal. One option in software engineering to break circular dependencies is to factor out the common dependencies into a new, shared, module.

Factoring out the Jakarta APIs that MicroProfile uses, and the MicroProfile API that Jakarta wants to use, would paint a picture such as this:

To the left we see the current MicroProfile APIs that are part of the MicroProfile platform, and are all exclusive to MicroProfile. Similarly to the right we see a selection of the Jakarta EE Web Profile APIs (some dependencies of several APIs, such as Authentication and Interceptors are left out).

In the future some additional APIs could move to the CN4J profile, but obviously this should not be too many. At the moment Jakarta Security is a candidate (in practice, @RolesAllowed/JWT is not rarely based on Jakarta Security).

Do note that the above is a personal proposal, and while discussed, is in no way endorsed by either the MicroProfile or Jakarta EE working groups, or the CN4J alliance. It's intended as an idea to base further discussion on.

Arjan Tijms

The last few months or so the GlassFish team has been working on removing this cruft, and making the release compatible with newer JDK versions. The primary target was to be able to compile the code with JDK 11 and be able to run it on that as well. A stretch goal was to have it compiling with- and running on JDK 16 too. As of PR 23446 we have now reached this goal:

Yet, this is a major milestone nevertheless. Thanks to everyone involved who helped to make this happen!

Arjan Tijms