Atbash Core Profile Jakarta EE

CDI 4.0 Lite and Potential Pitfalls

The CDI Lite specification is specifically created for the new Jakarta EE 10 Core Profile. This lite version is created to allow the discovery of CDI bans and preparation of the CDI container at build time.

This blog goes a bit deeper into a potential problem that you can encounter when building Core profile applications and running them on a Jakarta runtime concerning this CDI 4.0 Lite.

CDI Lite

To populate the CDI container with all the beans and the metadata to create the beans on demand like for the RequestScoped context, the CDI code needs to perform some initialisation.

Until now, the only available option is to perform a scan of the classpath and find the classes eligible as a CDI bean. Another source for beans is the CDI Portable Extensions that can register additional beans programmatically by the runtime or the application itself.

In the last few years, there are many initiatives to reduce the startup time of applications in various ways. The scanning of the classpath is a process that can be moved to the build phase if you have all classes available at build time. As you know, the JVM allows additional classes and libraries are added at runtime that was not available at build time. So, in case you move the metadata and bean discovery to build time, you need to make sure all classes are known and available or you need to provide the info.

The CDI Lite specification introduced the BuildCompatibleExtension interface to have the ability to move the scanning to the build phase of your application. This mechanism works similarly to the CDI Portable Extensions, where you have the opportunity to execute some methods during one of the 5 phases of the process.

At the same time, some classes are marked as not relevant for CDI Lite, as they are not really useful for the applications that are built with the Core Profile. Examples are the SessionScope and ConversationScope since REST applications are typically stateless. Keeping session information is in this case not required.

One single API artefact

The underlying narrative for creating the CDI Lite solution makes sense, but the single API solution is less obvious.

CDI lite contains most of the classes of the previous version of CDI and a few additional ones, like the BuildCompatibleExtension interface.
CDI full comprises CDI lite and a few additional concepts like the SessionScoped annotation that were available from the previous version of CDI but which didn’t fit into the CDI lite concept.

But the CDI 4.0 API artefact contains all classes, those of CDI Lite and CDI full.

Your project has only the option to add this single CDI API dependency to your project, as provided since the runtime has already these classes. And when your application is compiled and built against this API, it might fail at runtime.

You as a developer could have used or referenced a class from the CDI Full specification but you use a Core Profile certified runtime. This runtime only needs to support the CDI Lite classes and is not required to implement the other ones of CDI Full. So the application you successfully build fails at runtime. And you didn’t get notified of this problem during build time.

Testing for CDI Full classes usage

For this reason, I have created a small library that can inform you if you made use of one of the CDI Full classes in your code. You can write a test based on this code that fails when you make use of such a class. This way you get warned upfront that it might not run in production.

To make use of this library, add the following dependency to your project


With this dependency, you can write the following test method

void testCompliance() {
    TestCoreProfile tester = new TestCoreProfile("be.atbash");

The TestCoreProfile can determine those classes in the package you specify as a parameter, and in sub-packages, where you make use of a CDI Full class. If the list is empty, you are safe and good to go running it on a Core profile implementation.

Instead of using your top-level package, you can also specify a package from one of the CDI libraries that you have added to your project. This will tell you if that CDI library is safe to use on a Core Profile product.


CDI Lite groups all concepts of the CDI specification that is supported on the new Jakarta EE Core Profile. It also allows gathering information for the CDI container at build time.
But there is only 1 single artefact, containing all CDI Lite and Full classes. This means that even if your application compiles and builds successfully, it might fail on a Core Profile product. This is because you used some CDI Full-only classes that are not supported in Core Profile.
With the Jakarta Core Tester, you can find out if you referenced one of the CDI Full classes and it will run safely on your runtime.

Want to lean more about Jakarta EE 10 Core Profile?

This topic was discussed during my JakartaOne LiveStream event of 2022. Have a look at the presentation if you want to know more about the Core Profile “Explore the new Jakarta EE Core Profile“.

Atbash Training and Support

Do you need a specific training session on Jakarta or MicroProfile? Or do you need some help in getting up and running with your next project? Have a look at the training support that I provide on the page and contact me for more information.


Atbash release

Release of Atbash Runtime v0.4

The Atbash runtime version 0.4 continues on exploring the Jakarta EE Core profile. With the release of version 0.3, the product provided the specifications of the Core profile in a modular runtime. This modularity is improved in this version and besides the specifications of the Core profile, there is now support for security, through the MicroProfile JWT Auth specifications, and data by integrating the MicroStream data solution.

The runtime is still starting very fast and can be used on JDK 11, JDK 17, JKD 18, and JDK 19 ea.

Security support

As mentioned in an earlier post the MicroProfile JWT Auth specification, is a good candidate to secure the REST endpoints that hold a central position in the Core Profile.

Since the time that the blog about the security in the Core profile was written, many additions were added to the underlying library that provides the JWT support in the Runtime. The library is updated to include many smaller improvements but also the check that a JWT token with an unencoded body should not be accepted.
Although specified in the JWT Specification, this is not included in the MicroProfile version.

Data Solution

The Core profile does not include any specification around data. The JDBC specification is part of the JVM itself. So that could be used, but over the years, many other solutions were presented to reduce the code overhead. The JPA specification is very broadly used in the Java enterprise world. But also many no-SQL solutions are popular and also a specification is in progress.

But for Atbash Runtime the MicroStream solution is included. It provides you with an ultra-fast data solution where data is stored as Java objects within the heap and binary stored in external storage so that data survive a process restart.

The integration is in an experimental phase and will be improved in the following versions, including some concepts that can be found in the integrations provided by MicroStream itself.

Activate modules

The two additional modules, the security and data one, are not active by default. When you download the Zip file of the runtime, see the download section, the modules are included but not active.

There are two options to

-m microstream
-p full

BOM and API artifacts

When you create an application, as a developer you need a dependency that brings in all the classes and interfaces that are part of the API of the specifications. Since this version 0.4, several artefacts are available to bring in just those specifications that you want to use in your applications.

You can add the following entry in the maven project file


And have the classes related to Servlet, CDI, JAX-RS, JSON-P, JSON-B, and MicroProfile config available in your project. Just as with the Jakarta dependencies, the scope should be specified as provided as the Atbash runtime has already these classes available.

Another dependency is the full-api that provides the specifications that are included in the core-api, also the specification of MicroProfile JWT Authentication and classes of MicroStream are available.

To accommodate the creation of a customised runtime, see next section, a BOM artifact is available. This allows you to individually add the dependencies you need.

Add the BOM artifact to the dependencyManagement section and select the dependencies that you need for your application.



Custom Packager

As mentioned, the default download of Atbash Runtime contains all modules but only those modules of the Core profile are active by default. With the Custom packager, you can create a version of the runtime with only those modules that you need. It allows you also to create a version where some additional modules like the Security or MicroStream module are active by default. Although with a simple script that sets some command line parameters, is also doing exactly the same.

The Packager is not made available for download in a binary form but you can easily build it from code. Check out the code from Github, and launch a mvn package using JDK 11. Within the packager directory, you will find some more information on using the packager at this page.


You can download the abash Runtime version 0.4 zip from this URL: After that, you can unzip it and execute the JAR file in the top-level directory.

As of this release, you can also verify the download to make sure it is unaltered and identical to the version that I have built. This is the procedure to verify the signature.

openssl dgst -sha256 -verify atbash-runtime-signature.pem -signature

The future

The main work will be targeted at a real Jakarta EE 10 Core Profile product based on Jetty 12. Additional features around the observability of the runtime will also be added on top of this 0.4 version.


Jakarta EE Security

Where is the Security Specification in Jakarta EE Core profile?

The Jakarta EE Core profile targets the smaller runtimes, those that focus on delivering support for applications with REST endpoints only. For that reason, the main specifications included in the profile are the JAX-RS specifications and the specifications around JSON, JSON-P and JSON-B.

Another very important specification was targeted for Jakarta EE 10 and this new core profile, Jakarta config. The discussion about it is still going on. It is thus not included yet. That is the reason why the Atbash Runtime includes an implementation of the MicroProfile Config specification for the moment.

But there is another very important aspect that seems to be forgotten for this core profile, security.

Jakarta Security specification

For the moment, there are no plans to include a security-related specification in this core profile and this is a missed opportunity. Security is a very important aspect of each application but as usual, it doesn’t receive enough attention. Although there were several major security issue events in the last 6 months, we all remember the log4shell vulnerability.

Within the Jakarta family, we have the Jakarta Security API specification which combines the more low-level specifications Authentication and Authorisation. It also makes it easier for the developer to define the requirements without relying on the runtime to perform the setup. Within cloud environments, we should be able to start our application without extensive setup of the server or runtime.

But this Security API specification is not really a good candidate to be included in the Core profile. First of all, it depends on many other specifications and some of them are archaic and not really adapted to be used in these small runtimes targeted to the cloud.

But most of all, there is no support for the token-based security that is typically used in microservices and the applications that stands as a model for these Core profile runtimes.

The JSON Web Tokens (JWS token specification) are an ideal means to carry the information about the user on the requests. Within the header, a cryptographically signed JSON carries the information about the identity and the permissions of the user who made the (initial) call to the environment. With the signature, we can be sure the content is not tampered with and we can make use of the groups and role information available in the token to determine if the user is allowed to perform the action.

And we only need to use the public key of the key pair to verify the signature. This public key can be kept cached and only occasionally refreshed from the process that creates those JWT tokens. The verification and the usage of the JWT tokens do not require calls to external systems and are ideal to implement performant systems.

MicroProfile Security specification

This is a major gap in the support of technologies for Jakarta EE that calls itself ‘Cloud-native Enterprise Java’. But also within MicroProfile, there is no adequate support for JWT tokens. You have the MicroProfile JWT Auth specification that defines functionality for the MicroProfile runtimes that are using JWT tokens.

But there are several restrictions on top of the JOSE (Javascript Object Signing and Encryption) specification that make the MicroProfile specification less useful. The configuration is defined so that an application can only be used by one token emitter. You can define only one issuer, only one signature algorithm, you can indicate that a JWS or JWE token is used but not both at the same time, etc.

This makes that applications that make use of the MicroProfile JWT Auth specification are in fact part of a distributed monolith. You cannot use it in a real microservices situation as it will be called by many different applications, including external systems using different token providers.

Side note, since the majority of the companies that claim to do microservices are actually just building a distributed monolith, the problem with the MicroProfile JWT Auth specification is not impacting the majority I guess.

Security in Atbash Runtime

Since security is an important and vital aspect of any application, the upcoming version of the Atbash runtime will have support for JWT tokens. It is based on the JOSE specifications and for convenience, is using the MicroProfile JWT Auth API but not having the many restrictions of the MicroProfile Specification.

The configuration parameters are interpreted slightly differently, like the key defining the issues is interpreted as a list. This still allows the developer to only allow tokens from one source, but also allows the application to be used in real microservices situations and accept multiple issuers.

A first draft of the implementation is included in the main branch of the GitHub repository and will be refined in the coming weeks before the release is made.


Although security is a very important aspect of each application, specifications, and products should help the developers to implement the security requirements they have. There is no Security specification included, nor is there one planned in the new upcoming Core profile of Jakarta EE.

In fact, Jakarta EE does not have a specification that is useful in cloud-native environments since there is no support for JWT tokens.

But also the MicroProfile security specification is not a solution in all cases since it restricts the tokens to one issuer. Making it only useable in a distributed monolith situation and not in a real large-scale microservices environment.

The JWT token implementation within Atbash Runtime is based on the API of MicroProfile JWT Auth but overcomes the limitations of the MicroProfile specification by supporting the configuration of multiple sources, multiple algorithms, and using JWT and JWE tokens at the same time.
Sounds good? Give it a try when the next version will be available in a few weeks.

Atbash Jakarta EE

Testing the Jakarta EE Core Profile with Atbash Runtime.

What is the Core Profile?

The Jakarta EE specifications have already two profiles, the Full profile, and the Web profile. The Web Profile contains a set of specifications that are geared toward the typical Web Applications. It groups the typical Web Application specifications like Servlet, REST, JSON, JPA, Faces, Security, etc …

The Full profile contains all the Java Enterprise specifications and adds to the above list specifications like WebServices, Messaging, the full EJB specification, connectors, etc …

But the trend in the last years is, mainly due to the move to the cloud, to have smaller runtimes that only need a limited set of specifications.

The MicroProfile specifications are built on top of a limited set of Jakarta specifications, JAX-RS, CDI, JSON-P, and JSON-B.
MicroProfile, although many specifications are useful in all architectural cases, has a focus on microservices and smaller runtime. This has led to the idea to have a specific profile within Jakarta EE that groups a, specific adapted set of specifications in a Core Profile.

The goal of the profile is defined as (see here

To provide a profile that contains a set of Jakarta EE Specifications targeting smaller runtimes suitable for microservices and ahead-of-time compilation.

Which specifications?

The idea, since the Core profile is not yet available, is to combine the following specifications

  • Jakarta Servlet
  • Jakarta REST (JAX-RS)
  • Jakarta CDI lite
  • Jakarta JSON-P
  • Jakarta JSON-B
  • Jakarta Configuration

The CDI lite specification focuses around using build-time Compatible Extensions so that the runtime can be used in Ahead-of-time compilation scenarios like GraalVM. When there are no runtime discovery features and everything is known at compile-time, it makes the native compilation much easier.

The Jakarta Configuration specification will be based on the current MicroProfile Configuration specification and is hopefully, after several attempts to standardise this within Java Enterprise, finally available.

What is Atbash Runtime?

The Core Profile is not yet available and will not be available in May 2022, the expected release date of Jakarta EE 10. Mainly because the Jakarta Configuration specification is not ready yet, and the work related to Jakarta EE 10 took more time so there was not enough time available to perform some work around this new Profile.

The idea of Jakarta specifications is also that it is based on some experience and not only on some theoretical assumptions. That was the basis of my idea to create a runtime that contains the specifications of the Core Profile.

The work started some 6 months ago in my spare time and the goal was to create a runtime that combines the mentioned specifications. At that time, only Jakarta EE 9.1 was available. So the current version of Atbash Runtime, version 0.3, is based on

  • Jakarta Servlet 5.0
  • Jakarta CDI 3.0
  • Jakarta REST 3.0
  • Jakarta JSON-P 2.0
  • Jakarta JSON-B 2.0
  • MicroProfile Config 3.0

And it combines the following frameworks

  • Jetty 11.0.8
  • Jersey 3.0.4
  • Weld 4.0.3
  • Jackson Databind 2.13.1
  • Custom implementation of MicroProfile Config based on SmallRye Config.

How can I try it out?

First of all, you can download the zip file to install the runtime from this download URL. It is only 13.3 Mb in size.

Unzip this into a directory of your choice. It will create several JAR files in a directory structure.

Start your application with

java -jar atbash-runtime.jar path-to/application.war

And the application is available on port 8080 (default, can be changed by command line parameter). The runtime is built with JDK 11 and tested on JDK 11, 17, and 18.

Besides this instance mode, there is also a domain mode so that you can remotely access the runtime to, for example, deploy applications on a running process.

It has a modular structure that will be explored more in future versions and has typical extras like an embedded mode, Arquillian adaptor, Docker image, and integration testing framework based on TestContainers.

You can read more about them in the user guide.

What is next?

The following ideas are on my table to experiment more with this runtime and the idea of a Core Profile Runtime

  • Upgrade to the Jakarta EE 10 versions of the specifications now that they become available.
  • Add security like the MicroProfile JWT specification.
  • Add some data access including the fast Java-native object graph persistence provided by MicroStream.

And of course, your ideas and feedback are valuable for the realisation of the Core profile with Jakarta EE.