Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Ja

[Werner Keil <werner.keil@xxxxxxxxx>]

Erik,

You are right that Microservices don't work for all cases and in some they even create an overhead and make apps perform worse than before.

MicroProfile always had the issue of trying to be an "unspec" (like an "unconference) because all it really does (much like Spring Boot or similar "Microframeworks") is cover as many of the common Microservice Patterns ( https://microservices.io/patterns/index.html) as it feels are useful.

So it never was a spec, the single JSR that was heavily inspired and also created by many MP committers (but not only them, we had more people also from different vendors like Oracle who never touched MP there) was done at the JCP like Java EE. Until it became obvious, that it would not be compatible with Jakarta EE there any more.

Someone mentioned Hibernate as an example of a "Implementation first" approach, Spring Batch would be another, but they left the specification and API to the JCP and did not do their own or only in the beginning. And both now are compatible implementation of the specs they helped shape.

Unfortunately the MP folks (at least a significant majority of those who voted in Google Groups, I could only see Oracle prefer "Push" while a few others abstained) decided they do not like to contribute their "unspecs" the same way e.g. Spring/Pivotal or Hibernate (later owned by Red Hat) have done via the JCP. Of course if MicroProfile as a whole applies the new Eclipse Foundation Specification Process, this could still work to turn the "unspecs" into real specs, but it will become more complicated, e.g. if "Spec Y" defined at Microprofile has  to work with "Spec A-X" all defined at Jakarta EE then we have at least two different namespaces for Java packages, Maven artifacts and more complicated things like XML or JSON Schemas, OpenAPI, etc. 

You are not right about Jakarta EE not having a "useful" version, take  https://jakarta.ee/compatibility/  most major players (50% of all Strategic Members the only Enterprise Member and one Participating Member) already got certified Jakarta EE 8 products. 

Of course their customers may not immediately migrate, some probably still use J2EE :-D but some will, especially in the cloud where this is often easier than on premise.

Regards, 

Werner

On Tue, Apr 7, 2020 at 10:40 AM Erik Brangs <erik.brangs@xxxxxx> wrote:

Hi,

On 07/04/2020 04:27, Reza Rahman wrote:
> * Basing a core, long-term, open standard on the concept of microservices (e.g. having a name like "MicroProfile") is very high risk as microservices themselves may not stand the test of time in the next five years or even past a serious economic recession when IT belt tightening inevitably happens. I think you likely know Thougthworks has essentially stated microservices may never enter the mainstream. In the blogosphere, there is an increasingly bold anti-microservices ethos. Lastly and most importantly this ethos is actually being realized in real world IT.

I never understood the hype around microservices. Microservices are not a silver bullet.

Like any other technology, microservices have benefits and drawbacks. If monoliths are a better fit for my requirements, I will build a monolith. I also won't convert existing applications to microservices just because I can. A move to microservice has to be triggered by requirements and I don't see that happening for the applications I work on.

> * There are a few cohorts of "Java EE" customers. There is a fairly sizable community that still hold faith in Jakarta EE for all the right reasons. These folks are rightfully vocal and passionate. There is a larger cohort now that is nervous and watching closely as to what is going on with Jakarta EE. There is yet another cohort that is actively moving away from Java EE. The problem with the strategy you are proposing is that it will inevitably create shock waves. The problems with shock waves is that their outcome is highly unpredictable. One outcome could be a successful transition to MicroProfile. Another equally probable outcome is that users many not view this transition so charitably and basically decide such a volatile and uncertain technology set is simply not for them and they need to seek out a more stable one that isn't asking them to make a giant leap of faith.

I certainly wouldn't want a "transition" to MicroProfile or a cloud-only approach.

I still want support for older deployment scenarios (e.g. one application server with multiple applications) and I still want Jakartaa EE to develop new features for this scenario.

Right now all of our web applications are being developed with Java EE (because no "useful" version of Jakarta EE has been released yet). We're using EE because it provides a stable platform that contains almost everything that we need and because we value the backwards compatibility. My hope is that Jakarta EE moves from "has almost everything you need"
in the direction of "has literally everything you need a for a run-of-the-mill application" over time.


Kind regards,

Erik Brangs
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community