I thought I would put this out there to make sure there is no confusion – MicroProfile != Jakarta EE. Wait, of course they are not! They include different specifications! Yes, but I am click-baiting. Plus, there is this assumption that MicroProfile is an extension of Jakarta EE and this assumption needs to be directly challenged. BTW in the context of this post, I use Jakarta EE and Java EE interchangeably, albeit with minor temporal differences.
First, let’s cover some technicalities. Java EE consists of ~33 JSRs. MicroProfile 2.2, the current release as of this post, consists of four Java EE JSRs (CDI, JAX-RS, JSON-P, JSON-B). It also consists of eight home-grown specifications, not to mention one additional standalone specification in MicroProfile Reactive Streams Operators.
There is some overlap between MicroProfile and the afore-mentioned Java EE JSRs, which was not an accident. However, there seems to be too much assumption around MicroProfile being an extension of Jakarta EE because of the overlap. When MicroProfile was founded, we wanted to ensure some level of familiarity with the large Java EE developer base. A large number of Java EE implementations added MicroProfile support, helping to make MicroProfile a success. Don’t get me wrong, I really want this to continue! However, MicroProfile specifications have been very good about not assuming any additional Java EE APIs. In addition, the lightweight MicroProfile processes that are employed would likely conflict with Jakarta EE processes. That’s OK!
There is alignment between the two projects. MicroProfile does want to maintain compatibility with Jakarta EE since that is a very important delivery channel for MicroProfile. In addition, MicroProfile intentionally avoids duplicating Jakarta EE functionality. Keep in mind that a large portion of the active MicroProfile community overlap with Jakarta EE (myself included), and we see each community as having its own strengths.
So, let’s turn from APIs to implementations. Hammock was an early MicroProfile implementation that had no intention of being a full Java EE compatible application server. Oracle added Helidon last year. Quarkus, a recently announced project, has no intention of being a Jakarta EE implementation either. It picks up technologies that it thinks enable it to focus on Kubernetes Native Java. This includes MicroProfile, some Java EE specs, and many additional technologies unrelated to either. Check out the growing list. “Yeah John, but these are close enough to call it Java EE”. Ummmm, no, not even close. There is a precise definition of Java EE (and soon Jakarta EE) defined by TCKs, and it there is no reference to “close enough” in them 🙂 However, as mentioned by Mark Little, what is learned by Quarkus can be used to influence standards like Jakarta EE and MicroProfile in the future.
Stay tuned. I have more thoughts to share.