I feel it needs to be said I didn't read too strong of an opinion either but just yet another person trying to make a well intentioned attempt to help sort this stuff out.
Let us hope we can get to some kind of solution soon where none of us have to wonder too much what the other is thinking or really means.
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: cen <cen.is.imba@xxxxxxxxx> Date: 9/24/19 9:56 AM (GMT-05:00) To: jakarta.ee-community@xxxxxxxxxxx Subject: Re: [jakarta.ee-community] Thoughts on JakartaEE
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.x
A 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
+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
+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
--
Carlos
Andres De La Rosa | Software Architect
_______________________________________________
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
|