| Re: [jakarta.ee-community] Thoughts on JakartaEE |
Hi
Pruning first sounds like a good idea.
Sorry for confusion about EL, I often use it for "EclipseLink", and with "Hibernate" I mean "Hibernate ORM" :)
Best regards
Emily Jiang je 25. 09. 19 ob 12:59 napisal:
_______________________________________________ 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-communityI don't think "Jakarta EE bad, Microprofile cool" is a fair statement, it's rather that MP complements it quite well and can't exist without JakartaEE which solves a huge chunk of the scope for MP. Spring is a fair comparison but they kind of do their own thing.
Very well said, Cen! At Code One, I did a talk on the comparison of Spring and MicroProfile. The slides can be found here. IBM bluecomputing team did an experiment on converting microservices written originally using Spring boot to MicroProfile. A series blogs on this experiement can be found here.I am biased towards "change it all" approach for the simple fact that we deploy microservices. We can take a single microservice, port it to new namespace and redeploy the docker container. Repeat 30 times as schedule permits. Once you port a few of them you already learn all the pitfalls for next port.Please share your view on the thread [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace.
I think there was also an idea floating around to prune the list first so that we can stablise some specs that hardly have a reason to be updated or moved-away technologies. If changing one spec involving 90% other spec changes, then it is not much difference between big bang and incremental. Personally, I also prefer incremental as there is not much business value to change something for no business need. However, for runtime, it is important to cope with old namespace javax and new namespace jakarta, no matter which approach is chosen. It is an implementation detail.
I have a love/hate relationship with EL and Hibernate because they are both good implementations with a few very annoying bugs, when weighted with annoyance factor, it tends to lean towards EL being slightly better so I am strictly on EL these days. :)
I am a bit confused here. EL is part of Java EE spec while hibernate is an implementation. When you say EL, do you mean some implementation instead of _expression_ Language?
ThanksEmily
On Tue, Sep 24, 2019 at 2:57 PM cen <cen.is.imba@xxxxxxxxx> wrote:
_______________________________________________It is hard to formulate a particular statement for me because of the scope of the problem so those are merely my observations with no strong opinion.
I don't think "Jakarta EE bad, Microprofile cool" is a fair statement, it's rather that MP complements it quite well and can't exist without JakartaEE which solves a huge chunk of the scope for MP. Spring is a fair comparison but they kind of do their own thing.
I am biased towards "change it all" approach for the simple fact that we deploy microservices. We can take a single microservice, port it to new namespace and redeploy the docker container. Repeat 30 times as schedule permits. Once you port a few of them you already learn all the pitfalls for next port.
I have a love/hate relationship with EL and Hibernate because they are both good implementations with a few very annoying bugs, when weighted with annoyance factor, it tends to lean towards EL being slightly better so I am strictly on EL these days. :)
Best regards
Werner Keil je 24. 09. 19 ob 15:21 napisal:
Cen,
It's hard to get a particular statement or desire from your many points.
I get a "Jakarta EE bad, Microprofile cool" sentiment, but that is not new.Without Java EE there would be neither Spring nor Microprofile.MP is a lot like Spring, but it is still in a very early stage, comparable to Spring 1.2 rather than 2.0, especially when you look at true adoption or answers to surveys.
Plus Jakarta EE 8 is 1 or sometimes 2 steps ahead of Microprofile specs that have not been upgraded to use Java EE 8 yet. It's a "Dependency Hell" because some need CDI 1.2, others already require 2.xA large number of Spring projects already uses the new Jakarta EE specs. ;-D
You discovered that EclipseLink has more than Bugzilla and the more recent important ones should be there. Bugzilla has many, but Hibernate ORM alone got 2861 open issues in its JIRA, so does that mean you consider both abandonware? ;-)
The "incremental vs. Big bang" discussion was about refactoring from javax to jakarta namespaces and not how many new specs Jakarta EE 9, 10 or 11 might include. For 8 everything was put in a new Maven Groupid but that is not the biggest effort.Think of JPA alone there are many XML files referring to Java or JCP.Whether all get changed with Jakarta EE 9 or only the most commonly used remains to be seen.
Werner
carlos andres de la rosa <kusanagi12002@xxxxxxxxx> schrieb am Di., 24. Sep. 2019, 13:46:
+1 taking into account what cen says for me now have more much sense the incremental approach than try to migrate everything at once.
IMHO
On Tue, Sep 24, 2019 at 1:33 PM Emmanuel Bernard <ebernard@xxxxxxxxxx> wrote:
+1. I like what you wrote Cen. It does matches my perspective as well.
On 23 Sep 2019, at 18:47, cen 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
--
_______________________________________________
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
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