Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Thoughts on JakartaEE


Glassfish used to be the RI under the old JCP regime, but based on what's changed with Jakarta EE there has to be no "Reference Implementation" any more, if 2 or more "Compatible Implementations" (as of now Payara is not there yet, but OpenLiberty and Wildfly already are) are available so close to the GA of a new Jakarta EE version, there is no need for another implementation as per the guidelines. It is up to the community, but since both Wildfly and Payara are also largely driven by Open Source projects, these are as community driven as Glassfish.

It is probably a good question, whether on the long run IBM will afford two very similar Jakarta EE implementations (OpenLiberty and Wildfly) or merge their efforts into one whichever the marketing and other management teams feel has a better chance with its customers...


On Mon, Sep 23, 2019 at 7:27 PM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
+1, cen!  Although I do think there are some features that still need to get into Jakarta EE...  And, I also wonder whether the support for Glassfish will survive/thrive in Eclipse, or if Payara will be relied on more heavily...  good observations though!  Thanks!

Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    

From:        cen <>
To:        Jakara EE community discussions <>
Date:        09/23/2019 11:47 AM
Subject:        [EXTERNAL] [] Thoughts on JakartaEE
Sent by:


After reading a ton of mailing list material and blog posts I'd like to
share some thoughts on JakartaEE.

I use a lot of JavaEE and MP daily and contribute to one of MP framework

The javax naming is very unfortunate but won't really be a big problem
for us microservice users since we can update one service at a time.
Other than refactoring costs I don't see anything problematic, I think
application server users will have much more trouble.

MP was the best thing that happened to JavaEE because it allowed us to
take the stable and mature modules from JavaEE and combine them with
modern approaches that were missing in the spec. Seeing how successful
MP has been so far, I wouldn't merge the projects but collaboration
between projects to make specs more interop is welcome. Duplicating
specs for roughly the same things would be the major fail.

I have mixed feelings about JakartaEE adding a ton of new features to
attract new users. While some new features would be welcome, I see the
core modules pretty feature complete. I am not sure people would switch
massively to JakartaEE for any reason but I do know existing developers
will probably stay if platform feels alive which was not the case for
the past few years. As an existing user I am more concerned about the
state of some important reference implementations with long standing
bugs which are an annoyance in day-to-day work. Looking at - Eclipselink for example screams of abandonware
although now that all projects are on github contributing is thankfully
much easier. I already had some positive experience contributing to
upstream RI so that's feels good.

Best regards, cen

_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top