Jakarta EE & MicroProfile – two names, one family?

Recently, Sebastian Daschner wrote a blog post containing a proposal about Jakarta EE’s innovation and its relationship with MicroProfile. We got in touch with him and asked him a few questions about the proposal, the current state of affairs, and what happens next. Read on to find out what he had to say.

JAXenter: MicroProfile and Jakarta EE both aim to simplify the development of Java EE applications for cloud/microservices contexts. Historically, Jakarta EE is the successor of Java EE, MicroProfile was created as a new project when Oracle had little to say about the future of Java EE. But the future of Java EE is now clear – Jakarta EE under the aegis of the Eclipse Foundation. Why do we need an Eclipse MicroProfile project at all?

Sebastian Daschner: Right now, Jakarta EE is not out of the door yet, and MicroProfile includes very valuable projects. A few things inside MicroProfile come directly from EE, such as CDI or JAX-RS, but MicroProfile Config, Fault Tolerance, Metrics, OpenAPI, and others complement Enterprise Java with very much required technologies. A lot of projects use Java EE in combination with MicroProfile, which is supported by multiple runtimes, for example Open Liberty or Payara, and which is a pragmatic solution as of today.

JAXenter: If you look at it now: What are the technological differences between Eclipse MicroProfile and Jakarta EE?

Sebastian Daschner: Technologically, the differences are minimal: The package name is different, and MicroProfile includes less than Java EE / Jakarta EE. On the other hand, MicroProfile projects usually come with the same “look and feel”, the same developer experience, and declarative approaches that we know from Enterprise Java. Right now, MicroProfile projects can innovate and advance faster than Java EE standards could before. Also, Jakarta EE is only about to be shipped, so for now there’s no progress yet in the specifications that were part of EE.

SEE ALSO: Last chance to get Very Early Bird tickets for JAX London!

JAXenter: Now at JCrete you have developed a proposal on how MicroProfile and Jakarta EE could work together in the future. How did this come about? Who is behind the ideas?

Sebastian Daschner: I wanted to start the discussion about what the innovation process in Jakarta might look like. Although Jakarta EE is not out of the door just yet, I believe it’s a good time to start thinking about some critical questions; for example how Jakarta will innovate, what happens with the work that has been done in MicroProfile, and what could an ideal picture – from a user perspective – in the future look like. But the motivation was mainly to start the discussion on this important topic.

At JCrete we had an informal discussion with other Enterprise Java community members, from IBM and Red Hat, and we were discussing the points that ultimately led to this proposal.

JAXenter: Would you briefly summarize the main points again? What did you suggest?

Sebastian Daschner: One of the main points is that we need to come up with a consensus and ultimately with a well-defined process for what incubator projects look like and how they emerge. The reason for that is simply because the main advantage of EE was always the consistency in developer experience, how APIs are being used, uniform design principles, for example convention over configuration, declarative approaches, etc. A year ago, I wrote up some of these principles that I think made EE a great technology in a blog post: https://blog.sebastian-daschner.com/entries/jakarta-ee-design-principles. To keep this advantage, I believe it’s required to have a more uniform idea.

…I think of Jakarta and MicroProfile as one family, we need to make sure that all specifications can benefit from the updates being made.

Another point to be solved is how we handle the situation that we already see some branching in Java EE and MicroProfile, simply due to the fact that we can’t advance Java EE specs such as JAX-RS or CDI just yet, which for example resulted in MicroProfile REST Client. From a plain technological perspective it of course makes more sense to update JAX-RS, but that’s the only thing that could be done in that situation. Similarly, we have had the Config JSR, that was based on MicroProfile Config and was planned to be created under the JCP and now has been restarted under Jakarta. Now, thinking a bit more ahead in the future, Enterprise Java, and again, from a technological view, I think of Jakarta and MicroProfile as one family, we need to make sure that all specifications can benefit from the updates being made. That means that everything in Jakarta sooner or later would need to use innovations being made, for example in configuration. The thing to discuss is how to put this picture together, ideally from a user’s perspective, with a uniform developer experience, shared design principles, same package names, etc.

JAXenter: On the mailing list, concerns were expressed that the proposal might divide the communities; that users would always have to decide whether to support either MicroProfile or Jakarta EE – or both. Do you also see the danger of division?

Sebastian Daschner: Yes and no. On a specification level, we do have some signs of divisions already, for example looking at REST Client, Config JSR, Concurrency / Context Propagation, which all are there for very good reasons. From a users perspective I don’t see a big danger, since a lot of projects use a combination of Java EE and MicroProfile already, simply because most projects need both technologies. That’s also why we have multiple runtimes supporting both. However, again from a whole Enterprise Java perspective, it just makes sense to see the whole set of technologies that both brands contain as one family, and we should think about how to combine that in the future, ideally in an unified picture.

…I do think the (sometimes heated) discussions are valuable, simply because they do touch very important points…

JAXenter: Another comment related to the independence of Eclipse MicroProfile: The idea was for the MicroProfile to adopt new standards from Jakarta EE and, in case of doubt, replace them with its own components. Does this not degrade MicroProfile to an incubator after all?

Sebastian Daschner: I don’t necessarily agree, since MicroProfile projects are very much production-ready and being used in production. An incubator sometimes implies that a technology is somewhat immature, like a beta version. Where we do have the innovator status is that right now, MicroProfile projects can certainly advance and innovate much faster, which for the sake of the whole Enterprise Java I think is a good thing.

JAXenter: How will the discussions continue? Will there soon be a decision on the subject?

Sebastian Daschner: Yes, I do hope that we will have some decision at some point, but however, I do think the (sometimes heated) discussions are valuable, simply because they do touch very important points, also from a naming and branding perspective. That was actually my initial goal: not to convince everyone with one opinionated proposed solution, but to just get everybody involved, gather as many valid arguments as possible and then to see what’s a reasonable way forward. And I do believe now is a good time to get this started.

JAXenter: Thank you very much!

The post Jakarta EE & MicroProfile – two names, one family? appeared first on JAXenter.