Quarkus and Jakarta EE: Together, or not?

In this article, I answer a question that I have seen asked on various forums: Will Quarkus be compatible with Jakarta EE? To understand our answer to that question, it is helpful to know the history of Quarkus and what we're trying to achieve with it. So, please indulge me while I lay that groundwork.

A short history of Quarkus and Java EE

When Emmanuel Bernard, Jason Greene, Bob McWhirter, and I first discussed kicking off the ThornFly.x proof of concept, which would later become Quarkus, we had conversations about where Java EE (now Jakarta EE) would eventually fit. I think we all agreed that we already had the best open source implementation of Java EE in the form of WildFly and Red Hat JBoss Enterprise Application Platform (JBoss EAP). Creating yet another addition to this space seemed confusing at best. At worst, we feared that it would split our engineering and open source community efforts.

Unfortunately, we had another reason to resist making Quarkus compatible with Java EE: Despite the best and often Herculean efforts of Red Hat engineers, our communities, and other vendors, Java EE was seen as slow-moving, monolithic, and not a good option for new developers—especially anyone looking at building microservices and targeting greenfield efforts.

Some of this perception was inflated by negative press from detractors, but there was also truth to it, based on the use cases that Java EE was developed for over two decades ago.

Eclipse MicroProfile

All of this might sound familiar if you've watched Java EE for a while and observed the development of Eclipse MicroProfile. In 2016, Red Hat, Tomitribe, IBM, and a host of others came together to launch MicroProfile. We intended to take the best bits of Java EE and combine them with other open source efforts that were not considered appropriate for Java EE (for example, some of the good things happening with Netflix OSS at the time). From this foundation, we would release a set of open standards focused on enterprise microservices.

In the years since, Eclipse MicroProfile has gone from strength to strength, with a vibrant community, many specification releases, and a range of open source implementations. It has also been embraced by Java community leaders, who appreciate being able to use selected Java EE APIs and run certain MicroProfile implementations within a Java EE application server.

Quarkus innovations and MicroProfile

Having Quarkus track and influence MicroProfile makes sense: Developers already familiar with Java EE can reuse their skills and knowledge, and we can reuse many of our existing, compatible specification implementations as Quarkus extensions. With that said, we will have to evaluate whether Quarkus needs to be fully MicroProfile compatible. That decision is based on how quickly we innovate in Quarkus and whether those innovations are generally applicable to the MicroProfile community. As Red Hat has said from the outset, we don't believe in innovating within standards. Not every Quarkus innovation will necessarily become part of MicroProfile, and not all of our suggestions are likely to be accepted for MicroProfile. That's perfectly fine; it's one sign of a vibrant community.

The reactive paradigm

For a concrete example of what I mean, much of the MicroProfile community resists embracing the reactive paradigm. At Red Hat, we have been heavily involved in the reactive space for many years, with efforts such as Eclipse Vert.x and now Knative/Serverless. However, we see limits to bringing existing Java EE specifications to the reactive effort because Java EE's original designs are synchronous. We haven't always been able to persuade the wider community of that, so we focused our reactive innovations on Vert.x, and now on Quarkus. We believe that we can show how important these new approaches are and how well our communities are adopting them. By innovating elsewhere, we might eventually persuade the MicroProfile communities to adopt the reactive paradigm.

What about Quarkus and Jakarta EE?

Most developers know that Java EE has moved to the Eclipse Foundation and is now rebranded as Jakarta EE. The new mission for enterprise Java under Eclipse is to drive cloud-native, mission-critical applications. Can't we fold that into Quarkus?

Well, let's not get carried away. So far, Jakarta EE 8 is technically equivalent to Java EE 8. And Jakarta EE 9, which is being released later this year, is focused on package-name changes from javax to jakarta. What becomes of Jakarta EE 10, and how well (or if) Jakarta and MicroProfile play together will be determined.

As with any open source effort, many factors must come together for an optimal outcome. At the least, Jakarta EE has to offer a much quicker release cadence for updates and innovation. Jakarta EE also must distinguish itself from the negative perceptions associated with Java EE. To do well, it should appear so different from Java EE that there is, in fact, an immediate new problem.

Java EE's success is based on prioritizing backward compatibility and slow-moving changes. That priority has allowed operations teams to confidently deploy mission-critical applications that would not require changes for months or years at a time. While Jakarta EE might be able to both fulfill its new mission and address the past use cases, it won't be an easy juggling act. It's not likely to materialize overnight.

Will Quarkus be Jakarta EE compatible?

I've given a brief version of the background, so let's return to the original question: Will Quarkus be compatible with Jakarta EE? The short answer is that I can't see that happening with Jakarta EE 8 or Jakarta EE 9. Of course, I would never say never: No one can predict where Jakarta EE is headed. However, making Quarkus Jakarta EE-compatible would be very difficult to accomplish with full native-Java support. Attempting it would also likely confuse the perception of what Quarkus is today. Quarkus doesn't need to be compatible with Jakarta EE to succeed. And, besides, we've got a better opportunity to track and influence the future of the Java enterprise standard with WildFly and JBoss EAP.

Conclusion

Now, I recognize that this news might be hard for some community members to accept, especially based on the interest we've seen about this topic. But I hope that you will understand our reasoning, even if you disagree with it. Red Hat and the wider community have a huge opportunity with Quarkus to redefine enterprise Java in a Kubernetes world. Doing that will require all of our attention and effort. So, I'll leave you with what Douglas McIlroy said about the Unix philosophy: "Make each program do one thing well; to do a new job, build afresh rather than complicate old programs by adding new features."