User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
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:
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.
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?
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.
+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