Jakarta EE

OmniFish supports Jakarta EE 10

OmniFish announces enterprise support for Eclipse GlassFish, Jakarta EE 10, and a new cloud-native Jakarta EE runtime

OmniFish announces enterprise support for Eclipse GlassFish, Jakarta EE 10, and a new cloud‑native Jakarta EE runtime

Estonia, September 2022

OmniFish are proud to announce they’ve established themselves as a new international company in the field of Jakarta EE support, specifically supporting the application server Eclipse GlassFish, a new cloud‑native Jakarta EE runtime Piranha Cloud, and their associated components such as Mojarra, the Jakarta Faces implementation. 

OmniFish, based in Estonia, EU, welcomes the new Jakarta EE 10 version. They are going to support Jakarta EE 10 applications on Eclipse GlassFish 7, which will be released later in October 2022. Moreover, OmniFish have recently joined the Jakarta EE Working Group and they are strongly committed to contributing to the Jakarta EE standards. Some of the OmniFish founders are well-known Jakarta EE experts, which provides strong guarantees that OmniFish will become one of the key players in evolving and modernizing the Jakarta EE platform.

OmniFish provide support for the Eclipse GlassFish server and the Piranha Cloud runtime, invest a lot in their development

Eclipse GlassFish, with OmniFish providing enterprise support, again becomes a reliable open source Jakarta EE application server backed by a commercial company, which invests heavily into its development. Previously owned and supported by Oracle, and before that by Sun Microsystems, GlassFish has been contributed to the Eclipse Foundation. Since then, OmniFish have significantly contributed to the advancement of Eclipse GlassFish, with well over 1600 code changes (commits), which is more than 60% of all the changes since the contribution. 

OmniFish is now leading the development of the final version of Eclipse GlassFish 7, which is planned to be released later in October 2022. For this upcoming release, OmniFish engineers have dramatically increased test coverage, fixed a large number of defects, realized architectural and performance improvements, and added full Jakarta EE 10 and JDK 17 support.

Piranha Cloud is a new runtime re-imagining the usage of Jakarta EE APIs in very small, embedded, and highly modular runtimes. This approach is a radical departure from the application server model. Piranha Cloud is developed from scratch but shares many implementation components with Eclipse GlassFish, such as Soteria, Mojarra, Jersey, and many more.

Quotes from the OmniFish founders:

Ondro Mihályi, OmniFish director and co-founder: 

We at OmniFish are here to support customers that build and maintain systems based on Eclipse GlassFish, need to modernize their Jakarta EE solutions, improve performance or save costs. With Piranha Cloud, we also provide a safe and supported journey from Eclipse GlassFish to cloud-native deployments with a modern and efficient runtime.

Arjan Tijms, OmniFish director and co-founder:

OmniFish will show its dedication to Jakarta EE by continuing to support Eclipse GlassFish, and additionally bringing Jakarta EE 10 compatibility to Piranha Cloud, which enables a wider range of users to take advantage of the Jakarta EE APIs.

David Matějček, OmniFish director and co-founder:

Some time ago I contacted Arjan and we started discussing the state of Jakarta EE, Eclipse GlassFish, and other projects. When Ondro joined us later, we decided to start our own company which would boost Eclipse GlassFish and Jakarta EE development to make it modern, useful, and supported for production systems.

OmniFish aims at the application servers market and fast-growing cloud and serverless markets

OmniFish are the biggest contributor to the Jakarta EE 10 compatible Eclipse GlassFish 7 and a major contributor to the Jakarta EE 10 specifications. They are in a prime position to provide the best professional support for Eclipse GlassFish possible. It is estimated that the application servers market size will double by 2028, reaching USD 40.96 billion.  According to the OmniFaces survey, GlassFish is the 3rd most frequently used server, with a 22% share. Even though Eclipse GlassFish is open source and free to use, there’s a lot of potential for OmniFish to grow by providing support and services around it.

OmniFish also heavily contributes to the Piranha Cloud runtime, which aims to provide Jakarta EE functionality to build native cloud and serverless applications. As Piranha Cloud builds on the same components as Eclipse GlassFish, it provides a natural transition for Jakarta EE applications to cloud and serverless deployments. It is estimated that the cloud services market size will triple by 2030, reaching USD 1620 billion. OmniFish expects that this growth will result in increased interest in cloud-native runtimes like Piranha Cloud and will open opportunities for other OmniFish services and products based on it.

Ondro Mihályi, OmniFish director and co-founder: 

We at OmniFish have put a lot of effort to turn the upcoming Eclipse GlassFish 7 into a modern and reliable application server so that our clients can use it and sleep peacefully. Meanwhile, we’re working on Piranha Cloud as a new generation cloud runtime, based on our experience with GlassFish and other Jakarta EE servers. We are 100% dedicated to making our partners and clients successful with Eclipse GlassFish and Piranha Cloud. We aim to provide a cost-efficient and reliable path to modernizing their Jakarta EE applications, should our clients choose on-premise deployments or uplift their applications to cloud.

Who is behind the OmniFish company?

OmniFish, formal name Omnifish OÜ, was formally established as a company in 2022 by Ondro Mihályi, Arjan Tijms, and David Matějček, with headquarters in Estonia, EU. During the same year, it joined the Eclipse Foundation and the Jakarta EE Working Group as a Participant member. With employees located in several countries in the EU and partners across the world, OmniFish is an international company aiming at the global market. 

Arjan Tijms is a Java Champion, was Jakarta Faces co-spec lead under the JCP and Mojarra committer, and a Jakarta Faces and Jakarta Security EG member under the JCP, and current project lead of Jakarta Security, Jakarta Authentication, Jakarta Authorization, Jakarta Expression Language, Jakarta Faces, and committer of Eclipse Mojarra, Eclipse Soteria and author of the award-winning OmniFaces library. He has published three books with Apress on the topic of Jakarta EE and has written many articles about Jakarta EE.

Ondro Mihályi is a project member of Jakarta Batch, Jakarta Messaging, and Jakarta Config specifications. He was also a core member of the Microprofile team. He’s an experienced Jakarta EE lecturer, a frequent conference speaker, a Java Champion, and the leader of the Czech Java User Group. He co-authored the Java EE 8 Microservices book published by Packt.

David Matějček is an expert in the Eclipse GlassFish server, he’s worked with it and its predecessors and alternatives for more than 15 years. David is a senior software architect and expert in quality assurance, testing, automation, troubleshooting, and fixing defects, he is also a member of the Jakarta Persistence and the Jakarta Faces teams, and contributes to open source projects for many years.

OmniFish can be reached via their contact page, or on Twitter at @OmniFishEE. More information about the company can be found at https://omnifish.ee.

Jakarta EE 10 is coming with GlassFish 7

Jakarta EE 10 is coming with GlassFish 7

Jakarta EE 10 and GlassFish 7 soon (300px)

Yes, Jakarta EE 10 is just behind the door, with a rich set of new useful features. GlassFish 7 is also very close to its final release, coming with Jakarta EE 10 support. And it’s now actively maintained and commercially supported by OmniFish. Therefore you can start using Jakarta EE 10 very soon on a reliable and production‑ready server backed by a commercial company. But first, what’s coming to Jakarta EE 10?


The future of EJB

The Future of EJB

EJB, or Enterprise Beans, are Java classes with a number of container provided services attached to them, such as transactions, remoting and security. In this article we will take a look at what we can expect for EJB in the future.


Once upon a time EJB was almost synonymous with what was called Java EE or J2EE back then (Jakarta EE now). It suffered from many issues though, although it did incrementally got better. We’ll explore some of those issues next.

The past

The very first version of EJB was released before XML even existed and featured a rather awkward “programmatic” configuration, where a java class had to be compiled and its binary and serialised version used as configuration file. The second version of EJB introduced the now ubiquitous XML configuration, but featured a heavyweight programming model with rather annoying things like the much dreaded home interface. There were tools needed to generate things like proxies, as reflection wasn’t a thing yet. Also included was a very flawed persistence model called Entity Beans (not to be confused with the later Jakarta Persistence “Entities”, which are totally different).

The third version of EJB started a kind of renaissance for the technology in 2006. The entire EJB 2 API wasn’t needed anymore and instead a simple class with an annotation could be used. On the surface it looked almost indistinguishable from modern day bean technologies, although still with some restrictions such as a required “business” interface and the requirement of EJB beans to be packaged inside their own jar. These restrictions were lifted in 2009 with EJB 3.1. A great simplification was achieved by introducing a subset of EJB without many of the more troublesome and archaic constructs that had troubled EJB before; EJB Lite.

At the same time that EJB 3.1 was introduced, a new component model was added to Java EE: CDI. Though both are “beans with annotations”, the approach and philosophy beween EJB and CDI are completely opposite. EJB tried to be a facade over many other technologies in Java EE, such as e.g. JTA (now Jakarta Transactions). That meant EJB had its own rules and annotations for transactions, and used JTA internally. In CDI things work exactly the other way around; CDI offers a core component model, for which other APIs such as Jakarta Transactions can provide pluggable things such as scopes and interceptors. In the CDI approach, Jakarta Transactions builds on CDI instead of CDI abstracting over Jakarta Transactions. Unfortunately a few mistakes crept into CDI as especially in the beginning people didn’t quite agree on CDI becoming this core model, or CDI becoming another attempt at doing EJB, but in broad lines other APIs building on CDI is what CDI is about.

The Present

In the years after EJB 3.1 various APIs such as Jakarta Faces rebased on CDI, and new APIs such as Jakarta Security and Jakarta MVC were introduced that fully build on CDI from the get-go. Several features of EJB, such as the @Asynchronous annotation, were implemented in other APIs as a CDI compatible feature. EJB Full incrementally inched closer to EJB Lite, by removing Entity Beans (CMP/BMP), CORBA/IIOP Distributed Interoperability, and the embedded EJB container, as well as making the entire Enterprise Beans 2.x API Group optional.

The Future

With EJB being greatly de-emphasised in favour of CDI and many APIs in Jakarta EE that build upon CDI, there’s almost certainly not going to be any further innovation in EJB itself. That is, no new features are foreseen to be added. On the other hand, due to the large amount of existing code that uses EJB beans, the technology is also not expected to be removed from Jakarta EE anytime soon.

A possible future direction for EJB is to rebase it on CDI. Instead of having those two essentially competing component models in Jakarta EE, we would end up with just one. EJB would essentially be a compatibility API for existing applications, or perhaps a convenience API for those who appreciate the fact that with EJB one annotation gives you a lot of things and behaviour vs the more ala-carte approach of CDI where you combine different annotations. Interesting is that David Blevins from TomEE wrote about something like this almost a decade ago.

The first step to get to this future would be to create an EJB implementation, passing the EJB Lite TCK, fully implemented using CDI and technologies that build on CDI, such as Jakarta Concurrency and Jakarta Transactions. The OmniBeans project is one example of an attempt to do exactly that. This project tries to implement EJB Lite with as little of its own code as possible, delegating as much as possible to the aforementioned APIs. For instance, the following EJB bean can be used with the current version of OmniBeans:

import jakarta.ejb.AsyncResult;
import jakarta.ejb.Asynchronous;
import jakarta.ejb.Stateless;

public class AsyncBean {
    private static final Logger LOGGER = Logger.getLogger(AsyncBean.class.getName());

    public Future<Integer> multiply(int number1, int number2) {
        try {
        } catch (InterruptedException ex) {
            LOGGER.log(SEVERE, null, ex);

        return new AsyncResult<>(number1 * number2);

Using OmniBeans, the above bean would become a regular CDI bean, with @Stateless translated to a custom scope that emulates some of the semantics of the real @Stateless in EJB, and the @Asyncronous annotation translated to a CDI based interceptor. At the moment of writing the support is still limited, as transactions aren’t yet supported and neither does the @Asyncronous support comes from Jakarta Concurrency. There’s obviously a lot of work to be done still, but the beginning is there. Ideally we would end up with pluggable implementations of Jakarta Enterprise Beans, Jakarta Concurrency and Jakarta Transactions, which could then be somewhat trivially added to our own Jakarta EE runtime Piranha Cloud or perhaps to up and coming Jakarta EE Core Profile runtimes such as Rudy De Busscher’s AtBash Runtime.

Even after there’s a CDI based EJB implementation, it might still not be feasible to have the EJB (lite) specification fully rebase on CDI. There are existing EJB containers in GlassFish, JBoss, Open Liberty, TomEE, etc, for which it may not be doable to convert them, let alone replace them. Alternatively it might be an option to investigate if there’s any value in having a specified CDI-based EJB variant next to EJB Lite and EJB Full. Time will tell.