Jakarta EE & Eclipse MicroProfile – ongoing discussions

Share
  • August 15, 2019
Technology

Right now, discussions about the future relationship between Jakarta EE and Eclipse MicroProfile are taking place. We already reported on the original proposal made by Sebastian Daschner, in which he wanted to formalize the collaboration between the two projects in the spirit of keeping Jakarta EE innovating at a pace more like that of Eclipse MicroProfile’s. We also interviewed him and heard his deeper thoughts on the relationship.

At the time, it seemed like the plan was to remain focused on getting Jakarta EE 8 out the door, and then open up the floor for more discussion. However, it seems this topic is hot enough that people can’t stop thinking about it.

Java EE Guardians

Yesterday, the Java EE Guardians tweeted that they are now actively discussing the relationship, and the conversation is neither straightforward nor comfortable.


Java Champion Josh Juneau kicked the discussion off by citing the Java EE Guardians’ recently completed survey, in which they asked “Do you believe that some of the MicroProfile APIs should be incorporated into Jakarta EE as standards?” The answer was a resounding yes. Now they just have to work out what exactly that means.

MicroProfile has proven to be a very important project for the future of Microservices in Java, and it makes sense to place some of these APIs into the standard Jakarta EE platform. Specifically, I believe that if someone wishes to utilize the Jakarta EE Platform in the future, they should automatically gain access to MicroProfile APIs such as Health Checking API, configuration, JWT Token security, and probably others. After all, I think we are all on board with making Jakarta EE the best platform for development of Java Microservices.
– Josh Juneau

A fragmented conversation

Similar conversations are taking place in the Jakarta EE mailing list and the Eclipse MicroProfile forum, which, as some contributors pointed out, could lead to misalignments and misunderstandings.

In the Java EE Guardians Google group, opinions are fairly divided. There are still a lot of voices requesting to leave the topic parked while Jakarta EE 8 is finished and released, especially because the whole conversation is irrelevant if Jakarta EE 8 flops for whatever reason. A successful platform is an important starting point for discussions about collaborating, and the concern is that getting everyone fired up into an intense discussion will distract from working on Jakarta EE 8. However, the cat is out of the bag for the moment.

Some are dead set against bringing the two together at all, either because they don’t want to see MicroProfile disappear into Jakarta EE, or because they want to avoid any possibility that the relationship might slow the pace of MicroProfile’s innovation.

SEE ALSO: Java Web Start is dead, long live Java Web Start!

David Lloyd wrote:

I for one don’t see any reason why Jakarta and MicroProfile need to be connected. Two different spec bodies, two different sets of specs. Moving specs from JCP to Jakarta is going to be painful enough but moving from JCP to MP to Jakarta is not tenable.

In the end it boils down to the same feeling of wanting to protect the burgeoning brand from getting bogged down in specifications that splinter the user base.

Others are open to the idea, even to the point of putting the idea of incubation back on the table. This idea was previously discussed by Sebastian Daschner, who has now taken the feedback he received into consideration and is no longer a proponent of making Eclipse MicroProfile an incubator of Jakarta EE.

What works best together?

Some specific ideas have already been put forward for a more pragmatic discussion about what specifications would work best with Jakarta EE and what should be left out. Java expert Werner Keil wrote:

Configuration is my first candidate, especially because it was developed both at MicroProfile and in the JCP in parallel for some time, until (with a bit of help by Spec Committee members like myself) it occurred to everyone involved, that the new rules for using the “javax” namespace would essentially make a JSR unusable to Jakarta EE.

Configuration has been put forward by other members as the most likely candidate for an initial collaboration, with Rest Client in second place. As for the rest, waiting until Jakarta EE 8 is off the ground seems to be the winning argument.

Uncertainty could be the worst outcome

The strongest concern expressed by many involved in the discussion is that the lack of unity and clear direction could be the worst outcome. When a lot of people use one or both of Eclipse MicroProfile and Jakarta EE, but they see the community is divided, or worse, that they are likely to start carving up specs in the name of collaboration, then users will simply choose a more stable tool for the job. Java veteran Reza Rahman wrote:

Two disjoint projects that look so much alike, have essentially the same set of players involved and essentially the same audience is ripe for creating all manners of confusion and doubt.

SEE ALSO: JEP 358 – Improved NullPointerExceptions

Closing thoughts

We will be watching this conversation closely as the community works out the best way to work together. Emily Jiang said in an interview with JAXenter about Jakarta EE last year that in her view, “we can treat MicroProfile as a sports car and Jakarta EE as a minibus. They have their own merits. I see them as complementary to each other.” One thing is clear: there’s still a lot to talk about before the sports car and minibus can work together.

 

The post Jakarta EE & Eclipse MicroProfile – ongoing discussions appeared first on JAXenter.

Source : JAXenter

You may also like...