Thanks for pointing this out. The whole premise behind Jakarta EE was that it would become a more nimble, but still credible open standard. The same of course goes for the promise that Jakarta EE was to become a trusted standard for cloud native Java as a unifying and stabilizing element the same as Java EE had been for so many years for server side Java.
If the truth is that those stated objectives are no longer really honest, that is what we should be clear to consumers about and give them an informed choice of where they would like to place their continued trust.
Reza Rahman Principal Program Manager Java on Azure
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message -------- From: Werner Keil <werner.keil@xxxxxxxxx> Date: 9/25/19 9:25 AM (GMT-05:00) To: Jakara EE community discussions <jakarta.ee-community@xxxxxxxxxxx> Subject: Re: [jakarta.ee-community] Thoughts on JakartaEE
Actually I guess that might change with Jakarta EE because it should not take 2 or 3 years any more between Jakarta EE updates even if it is only some spec.
Cen,
absolutely. I also consider Jakarta EE 8 as the stable base, the "boring OS" with less frequent releases.
For me MicroProfile is the reflection of current e.g. CNCF, also upcoming, standards with faster release cadence.
So far, I always used them together,
--adam
> On 23. Sep 2019, at 18:47, cen <cen.is.imba@xxxxxxxxx> wrote:
>
> Hi,
>
> 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 implementations.
>
>
> 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 bugs.eclipse.org - 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
>
>
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
|
