Proposal on Jakarta EE’s innovation & relationship w/ MP [cross-posted]

[Sebastian Daschner]

Hi there,

Cross-posting the following blog [1] from the jakarta.ee-wg mailing list [2]. A few folks suggested to post this to this list as well. Feel free to chime in here on in the Jakarta list.

At the JCrete unconference, a few of us were brainstorming about the vision of Jakarta EE and especially the relationship with MicroProfile. I wanted to start that discussion in order to get everybody on the same page especially how the relationship between Jakarta EE and MicroProfile, and Jakarta’s innovation should look like. I believe that a lot of us agree on things already, however, I believe it would accelerates the process if we start that discussion.

The following is a proposal on the bigger picture of the Jakarta standardization process, the relationship with MicroProfile, and the fact that there is a need for an incubation process. Please note that everything is up for discussion. My original view was to use MicroProfile as an incubator for Jakarta [3], however, some folks within the community have expressed their concerns with that idea since the MicroProfile brand gets more and more established and is seen as more than just an incubator technology.

Motivations & reasoning

- There is a huge need to advance and innovate on Enterprise Java. Also, we need the possibility to innovate and discard some of the innovation without being carved in stone in standards, already.
- We need a process to rebase the incubators on the baseline, in order to use updated APIs from other specifications.
- We need an umbrella that ensures that multiple technologies work well together. The incubator projects need to work well with the baseline specifications as well.
- We need to make it as easy as possible for end users to use Jakarta EE and its incubators and to update to newer versions once things get incorporated into the baseline.
- We need to agree on the details of incubators and standards, regarding format and contents of technical documentation, examples, and Java packages.
- MicroProfile is establishing its brand and ecosystem which is seen as production-ready technology (more than just an incubator) and which is something we might want to keep.
- We might want to start these considerations now, in order to align stakeholders and to decide what the picture looks like, even things only get realized weeks and months from now.

Proposed process

- The Jakarta umbrella contains specifications that are part of the baseline (which corresponds to the Java EE umbrella).
- Jakarta incubators are the typical way to innovate and advance Jakarta in newer technologies. Published versions of incubators can be used in combination with the Jakarta baseline, and offer a quicker way to implement and discard things.
- Jakarta incubators are based on a specific version in the baseline branch and can and should re-use the technology contained in the baseline. Incubators use the same design principles and the jakarta Java package in order to make it easy for early adopters to switch from incubator dependencies to specifications.
- Longer-running Jakarta incubators can and should be rebased to a recent Jakarta version in order to use the latest technology and to facilitate usage for implementers and users.
- Jakarta incubators that have proven themselves can get included into the baseline branch as proper Jakarta standards. In order to make that transition easier, incubators use the jakarta Java package and follow a certain (simplified) process on documentation, specification, and code examples. However, everything inside an incubator may change before transformed into a Jakarta specification.
- All Jakarta incubators and specifications need to provide a specification, targeted to implementers and users, as well as documentation and getting-started code examples on commonly-used patterns, targeted to users. The documentation must include a short motivation why and in which cases the technology is required, and enable users without prior knowledge to get started quickly.
- The MicroProfile brand and ecosystem stays as is and can continue to evolve as is with all its current projects. Jakarta incorporates the efforts and innovation that already happened within MicroProfile, with adaptions where required. Once Jakarta includes new specifications, for example Config, it might make sense to rebase MicroProfile to then include these new standards instead of its current projects.

Diagram

I propose to advance the future of Jakarta EE with the following technology:

New standards in Jakarta EE

- Configuration (Jakarta-Config) will be a new specification project in the Jakarta baseline. It originates from the efforts behind the withdrawn Config JSR, and MicroProfile Config.
- Model View Controller (from JSR 371)
- JCache (from JSR 107)
- Deployment specifications: standardizing the way how to deploy and modern apps, how to provide libraries, what the runtime directory layout looks like, thin deploy artifacts, etc.

Updates on EE standards

- Concurrency: incorporating approaches from mp-context-propagation and bulkheads from mp-fault-tolerance
- Security: incorporating approaches from mp-jwt-auth
- JAX-RS: incorporating approaches from mp-rest-client where reasonable

New incubators in Jakarta EE

- Fault-tolerance: circuit breakers, timeouts, retries, fallbacks, features taken from mp-fault-tolerance
- Observability: features from mp-metrics, mp-open-tracing, mp-health
- Testing: incorporating ideas and approaches from Arquillian, Spring Test, Testcontainers, and maybe more
- Reactive-streams / messaging: features taken from mp-reactive-streams and mp-reactive-messaging
- LRA (or different name): approaches taken from mp-lra
- Open API: features from mp-open-api

Sebastian 

[1] https://blog.sebastian-daschner.com/entries/jakarta-microprofile-innovation-proprosal
[2] https://www.eclipse.org/lists/jakarta.ee-wg/msg00328.html

[3] https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee

[David Lloyd]

On Wed, Jul 24, 2019 at 7:50 AM Sebastian Daschner <ma...@sebastian-daschner.com> wrote:

- Configuration (Jakarta-Config) will be a new specification project in the Jakarta baseline. It originates from the efforts behind the withdrawn Config JSR, and MicroProfile Config.

This seems unreasonable.  Exactly what problem are you trying to solve here?

MicroProfile is a real existent standards body of its own already, completely independent from JCP or Jakarta.  People are using these specifications; they're in the wild.  What could possibly be the benefit of fragmenting the MP Config user base, or that of any other MP specification, by restarting it all over again in Jakarta (with an incompatible package name space, at a minimum)?  How would implementations cater to audiences when someone might be using both the Jakarta and MicroProfile variants at once?  Does this not invite potentially disastrous fragmentation?

And, as was stated by multiple people on the other thread, I agree that now is not the time to even float this idea - Jakarta EE (unlike MP) is not even out the door yet, making the entire thing baseless speculation.  And cross-posting only worsens the overall fragmentation of the discussion.  At *best* you could ask "how would you, the MP community, like to kill off MP and make it just be an incubator for Jakarta"?  To which I think many of those who have invested time and effort into these specifications and their implementations would probably say "no way, forget it".  Why would they not?  To suggest otherwise is, in my view, to suggest that the MicroProfile specifications are somehow lesser in value, and are seen as such by those who develop and use them, which for me at least is completely untrue.

I for one don't see any reason why Jakarta and MicroProfile need to be connected.  Two different spec bodies, two different sets of specs.  Moving specs from JCP to Jakarta is going to be painful enough but moving from JCP to MP to Jakarta is not tenable.

--

- DML

[Andy Guibert]

I share the same concerns as David. If we try to incubate/rework MP specs as we bring them over to JakartaEE, then this will force fragmentation/cannibalization of the MP userbase because they will have to move from org.eclipse.microprofile.* --> jakarta.* packages. Users are already dealing with this problem enough going from javax.* --> jakarta.* so lets not make the problem worse.

If JakartaEE was willing to adopt some MP specs as-is (i.e. without changing APIs and package names) then I am perfectly fine with that. Similar to how MP has adopted several Java EE specs as-is (e.g. CDI, JAX-RS, JSON-B).

If JakartaEE and MP both find a spec useful, they should share it and collaborate on it -- not try to steal ownership of it and fragment its existing user base in the process.

- Andy

[Sebastian Daschner]

Thanks for your responses. Both answered inline:

Exactly what problem are you trying to solve here?

The question how Jakarta will be able to innovate, and which technologies and features should be included first in that innovation process.

What could possibly be the benefit of fragmenting the MP Config user base, or that of any other MP specification, by restarting it all over again in Jakarta (with an incompatible package name space, at a minimum)?  How would implementations cater to audiences when someone might be using both the Jakarta and MicroProfile variants at once?  Does this not invite potentially disastrous fragmentation?

For Jakarta to be successful, it ultimately needs to update it's current specifications, but will also need to include solutions and approaches done by MicroProfile, however, in a way where all Jakarta specifications benefit from it. For example, users might want to use configuration from the whole Jakarta umbrella in a unified way. If you look at MicroProfile, we already have the situation with CDI and JAX-RS, which are used in MicroProfile yet can't evolve on their own, that's why we have mp-rest-client, and likely other such cases in the future, talking about fragmentation. I'm happy to hear different proposal that tackle this issue and the constraints that I tried to describe in my blog.

And cross-posting only worsens the overall fragmentation of the discussion.  At *best* you could ask "how would you, the MP community, like to kill off MP and make it just be an incubator for Jakarta"?  To which I think many of those who have invested time and effort into these specifications and their implementations would probably say "no way, forget it".

I've been asked by others multiple times to cross-post this to this mailing list. Please feel free to ignore. (Unlike in the past) I'm not suggesting to make MicroProfile an incubator for Jakarta because of concerns that a few have expressed and what is similar to what you're describing as well.

In this proposal, I'm talking about the Jakarta view, which new things might be adopted and how Jakarta might advance further. It's not suggesting to "kill off MP" and doesn't hinder it from producing new projects, new releases, or totally ignoring Jakarta specs, at all. I do believe now is the best time to have this conversation to be able to start quickly once all previous organizational issues have been sorted, and already have an idea where the enterprise community has agreed upon.

If JakartaEE was willing to adopt some MP specs as-is (i.e. without changing APIs and package names) then I am perfectly fine with that. Similar to how MP has adopted several Java EE specs as-is (e.g. CDI, JAX-RS, JSON-B).

I would agree with that, however, how can we then ensure that what is adopted can advance while potentially using / be compatible with all other technology in the whole Enterprise Java?

If JakartaEE and MP both find a spec useful, they should share it and collaborate on it -- not try to steal ownership of it and fragment its existing user base in the process.

Happy with that as well, and happy to have such a collaborative discussion, ideally now.

Sebastian

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/2e9fe051-7a23-40fd-8dfa-7b660460052b%40googlegroups.com.

[Andy Guibert]

> I would agree with that, however, how can we then ensure that what is adopted can advance while potentially using / be compatible with all other technology in the whole Enterprise Java?

Keep in mind that individual MP specs can cut releases whenever they want. Suppose JEE has adopted an MP spec, collaborated with MP on it, and then added some new feature to the spec. Maybe there is a JEE platform release coming up, but MP doesn't have a platform release coming up any time soon. That individual MP spec can still cut a release so the new function can be included into the upcoming JEE platform release.

The main reason (to my knowledge) why MP hasn't evolved JavaEE specs is that they have been "frozen" for a few years because of the JavaEE-->JakartaEE transition, not because MP members lack influence in those specs. In fact, the MP community has committers on all of the shared JavaEE specs, so we are certainly capable of proposing features to these specs that MP would benefit from.

Overall I'm happy to have JEE adopt MP specs, but it _must_ be done in the same way that MP has adopted JEE specs -- without forking the spec and its userbase.

On Thursday, July 25, 2019 at 5:25:25 AM UTC-5, Sebastian Daschner wrote:

Thanks for your responses. Both answered inline:

Exactly what problem are you trying to solve here?

The question how Jakarta will be able to innovate, and which technologies and features should be included first in that innovation process.

What could possibly be the benefit of fragmenting the MP Config user base, or that of any other MP specification, by restarting it all over again in Jakarta (with an incompatible package name space, at a minimum)?  How would implementations cater to audiences when someone might be using both the Jakarta and MicroProfile variants at once?  Does this not invite potentially disastrous fragmentation?

For Jakarta to be successful, it ultimately needs to update it's current specifications, but will also need to include solutions and approaches done by MicroProfile, however, in a way where all Jakarta specifications benefit from it. For example, users might want to use configuration from the whole Jakarta umbrella in a unified way. If you look at MicroProfile, we already have the situation with CDI and JAX-RS, which are used in MicroProfile yet can't evolve on their own, that's why we have mp-rest-client, and likely other such cases in the future, talking about fragmentation. I'm happy to hear different proposal that tackle this issue and the constraints that I tried to describe in my blog.

And cross-posting only worsens the overall fragmentation of the discussion.  At *best* you could ask "how would you, the MP community, like to kill off MP and make it just be an incubator for Jakarta"?  To which I think many of those who have invested time and effort into these specifications and their implementations would probably say "no way, forget it".

I've been asked by others multiple times to cross-post this to this mailing list. Please feel free to ignore. (Unlike in the past) I'm not suggesting to make MicroProfile an incubator for Jakarta because of concerns that a few have expressed and what is similar to what you're describing as well.

In this proposal, I'm talking about the Jakarta view, which new things might be adopted and how Jakarta might advance further. It's not suggesting to "kill off MP" and doesn't hinder it from producing new projects, new releases, or totally ignoring Jakarta specs, at all. I do believe now is the best time to have this conversation to be able to start quickly once all previous organizational issues have been sorted, and already have an idea where the enterprise community has agreed upon.

If JakartaEE was willing to adopt some MP specs as-is (i.e. without changing APIs and package names) then I am perfectly fine with that. Similar to how MP has adopted several Java EE specs as-is (e.g. CDI, JAX-RS, JSON-B).

I would agree with that, however, how can we then ensure that what is adopted can advance while potentially using / be compatible with all other technology in the whole Enterprise Java?

If JakartaEE and MP both find a spec useful, they should share it and collaborate on it -- not try to steal ownership of it and fragment its existing user base in the process.

Happy with that as well, and happy to have such a collaborative discussion, ideally now.

Sebastian

On Wed, Jul 24, 2019 at 8:14 PM Andy Guibert <andy....@gmail.com> wrote:

I share the same concerns as David. If we try to incubate/rework MP specs as we bring them over to JakartaEE, then this will force fragmentation/cannibalization of the MP userbase because they will have to move from org.eclipse.microprofile.* --> jakarta.* packages. Users are already dealing with this problem enough going from javax.* --> jakarta.* so lets not make the problem worse.

If JakartaEE was willing to adopt some MP specs as-is (i.e. without changing APIs and package names) then I am perfectly fine with that. Similar to how MP has adopted several Java EE specs as-is (e.g. CDI, JAX-RS, JSON-B).

If JakartaEE and MP both find a spec useful, they should share it and collaborate on it -- not try to steal ownership of it and fragment its existing user base in the process.

- Andy

On Wednesday, July 24, 2019 at 9:40:34 AM UTC-5, David Lloyd wrote:

On Wed, Jul 24, 2019 at 7:50 AM Sebastian Daschner <ma...@sebastian-daschner.com> wrote:

- Configuration (Jakarta-Config) will be a new specification project in the Jakarta baseline. It originates from the efforts behind the withdrawn Config JSR, and MicroProfile Config.

This seems unreasonable.  Exactly what problem are you trying to solve here?

MicroProfile is a real existent standards body of its own already, completely independent from JCP or Jakarta.  People are using these specifications; they're in the wild.  What could possibly be the benefit of fragmenting the MP Config user base, or that of any other MP specification, by restarting it all over again in Jakarta (with an incompatible package name space, at a minimum)?  How would implementations cater to audiences when someone might be using both the Jakarta and MicroProfile variants at once?  Does this not invite potentially disastrous fragmentation?

And, as was stated by multiple people on the other thread, I agree that now is not the time to even float this idea - Jakarta EE (unlike MP) is not even out the door yet, making the entire thing baseless speculation.  And cross-posting only worsens the overall fragmentation of the discussion.  At *best* you could ask "how would you, the MP community, like to kill off MP and make it just be an incubator for Jakarta"?  To which I think many of those who have invested time and effort into these specifications and their implementations would probably say "no way, forget it".  Why would they not?  To suggest otherwise is, in my view, to suggest that the MicroProfile specifications are somehow lesser in value, and are seen as such by those who develop and use them, which for me at least is completely untrue.

I for one don't see any reason why Jakarta and MicroProfile need to be connected.  Two different spec bodies, two different sets of specs.  Moving specs from JCP to Jakarta is going to be painful enough but moving from JCP to MP to Jakarta is not tenable.

--

- DML

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[Alasdair Nottingham]

Sebastian,

In your email you start out by saying your original view was that:

> My original view was to use MicroProfile as an incubator for Jakarta [3],

which isn’t necessarily inconsistent with how MicroProfile was originally formed given we said that things MicroProfile would come up with would be standardized through an appropriate body. However as MicroProfile has matured and gained traction as a viable programming model I think the community has grown beyond that. I think you recognize that because you follow up with this (sorry for splitting your sentence)

> however, some folks within the community have expressed their concerns with that idea since the MicroProfile brand gets more and more established and is seen as more than just an incubator technology.

However your proposal essentially relegates MicroProfile exactly to be an incubator because you detail how everything in MicroProfile should be moved into a spec in Jakarta EE. That leaves MicroProfile either dead, or it leaves it as exactly an incubator that no one would use, preferring instead to wait for it to be in Jakarta EE because then the package will be final.

If your goal is for MicroProfile and Jakarta EE to both be successful communities moving forward your proposal does nothing to help this and everything to undermine MicroProfile as a viable community, API standardization process. If you’d come along saying we should move the API’s and shut MicroProfile down I would disagree, but I’d at least think the proposal was self consistent.

One of the nice things about the MicroProfile specifications is that they are additive to the core Java EE specs being borrowed. This means that we don’t need to do what you are suggesting. I know there are a lot of people in Jakarta EE who seem to covet the API’s produced in MicroProfile, but I think these two communities can continue to co-exist in a complimentary way without essentially shutting down or undermining the progress being made in this community. I think if we are going to talk about the future relationship of Jakarta EE and MicroProfile it needs to be done in a way that builds on, and enhances what has been provided here, not moving it, respecifying it and renaming all the classes.

Just my 2 cents worth
Alasdair

> To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/37c53c21-bd65-459e-a37a-b8b1d91e6358%40googlegroups.com.

[Werner Keil]

All,

MicroProfile was born out of discussions a few members of the Java EE platform EG had ever since Java EE 6 or 7. Some of us are also in the Jakarta EE platform project, so while Jakarta EE 8 won't have room for that, starting with either 9 or above there should be space for other profiles than Web or Full. Whether that's called "Micro" or something else, we shall see.

>If JakartaEE was willing to adopt some MP specs as-is (i.e. without changing APIs and package names) then I am perfectly fine with that. >Similar to how MP has adopted several Java EE specs as-is (e.g. CDI, JAX-RS, JSON-B).

This won't work both ways because the specs in the "jakarta" namespace (leaving aside their "javax" predecessors which are essentially frozen now) are not supposed to incorporate APIs or libraries from either "org.eclipse.microprofile" or others, e.g. Dropwizard, just to take another example. It works the other way of course. 

There are two or three types of MicroProfile features, if you look at https://github.com/eclipse?utf8=%E2%9C%93&q=microprofile

There are a couple of self-contained APIs like

- config

- health

-metrics 

Each of those could become possible Jakarta EE specs and seem the best candidates for the kind of incubator Sebastian suggested.

Then there is

- microprofile-rest-client

Which already is a kind of fork and fragmentation from the JAX-RS spec. 

If it could become part of akarta RESTful Web Services it would be beneficial to everyone involved.

There are a few corner cases

- fault-tolerance

is pretty Failsafe ported into MP by its original author, but I don't see his original project use it in any way. 

Hystrix is no longer maintained by Netflix. There are alternatives like https://dzone.com/articles/resilience4j-and-sentinel-two-open-source-alternat

Until the makers of more than one of those got together, mp-fault-tolerance is still a a niche that was driven by just one author and without others willing to adopt it, one can hardly call it a broad enough to become a Jakarta spec at this point. A Jakarta incubator may offer a room to mature and broaden it.

All the others like 

- mp-openapi

- mp-lwt

- mp-opentracing

...

are pretty much "glue" between some third party standard like OpenAPI or "pseudo-standards" and Java EE 8. 

There is no spec as such, those kinds of standards and specs are defined by the OpenAPI Initiative, the Cloud Native Computing Foundation or similar places. These glue and connector type projects make a vast majority of MicroProfile and they won't die or go away if the 3-5 standard-worthy ones should graduate to Jakarta EE or elsewhere.

So there is no one-fits-all answer to this, but hope some specs that are self-contained may follow the path Sebastian (and others before him) suggested.

Werner

Am Donnerstag, 25. Juli 2019 21:21:29 UTC+2 schrieb Alasdair Nottingham:

Sebastian,

In your email you start out by saying your original view was that:

> My original view was to use MicroProfile as an incubator for Jakarta [3],

which isn’t necessarily inconsistent with how MicroProfile was originally formed given we said that things MicroProfile would come up with would be standardized through an appropriate body. However as MicroProfile has matured and gained traction as a viable programming model I think the community has grown beyond that. I think you recognize that because you follow up with this (sorry for splitting your sentence)

> however, some folks within the community have expressed their concerns with that idea since the MicroProfile brand gets more and more established and is seen as more than just an incubator technology.

However your proposal essentially relegates MicroProfile exactly to be an incubator because you detail how everything in MicroProfile should be moved into a spec in Jakarta EE. That leaves MicroProfile either dead, or it leaves it as exactly an incubator that no one would use, preferring instead to wait for it to be in Jakarta EE because then the package will be final.

If your goal is for MicroProfile and Jakarta EE to both be successful communities moving forward your proposal does nothing to help this and everything to undermine MicroProfile as a viable community, API standardization process. If you’d come along saying we should move the API’s and shut MicroProfile down I would disagree, but I’d at least think the proposal was self consistent.

One of the nice things about the MicroProfile specifications is that they are additive to the core Java EE specs being borrowed. This means that we don’t need to do what you are suggesting. I know there are a lot of people in Jakarta EE who seem to covet the API’s produced in MicroProfile, but I think these two communities can continue to co-exist in a complimentary way without essentially shutting down or undermining the progress being made in this community. I think if we are going to talk about the future relationship of Jakarta EE and MicroProfile it needs to be done in a way that builds on, and enhances what has been provided here, not moving it, respecifying it and renaming all the classes.

Just my 2 cents worth
Alasdair

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/37c53c21-bd65-459e-a37a-b8b1d91e6358%40googlegroups.com.

[David Lloyd]

On Thu, Jul 25, 2019 at 4:01 PM Werner Keil <werne...@gmail.com> wrote:
>
> All,
>
> MicroProfile was born out of discussions a few members of the Java EE platform EG had ever since Java EE 6 or 7. Some of us are also in the Jakarta EE platform project, so while Jakarta EE 8 won't have room for that, starting with either 9 or above there should be space for other profiles than Web or Full. Whether that's called "Micro" or something else, we shall see.
>
> >If JakartaEE was willing to adopt some MP specs as-is (i.e. without changing APIs and package names) then I am perfectly fine with that. >Similar to how MP has adopted several Java EE specs as-is (e.g. CDI, JAX-RS, JSON-B).
>
> This won't work both ways because the specs in the "jakarta" namespace (leaving aside their "javax" predecessors which are essentially frozen now) are not supposed to incorporate APIs or libraries from either "org.eclipse.microprofile" or others, e.g. Dropwizard, just to take another example. It works the other way of course.
>
> There are two or three types of MicroProfile features, if you look at https://github.com/eclipse?utf8=%E2%9C%93&q=microprofile
>
> There are a couple of self-contained APIs like
> - config
> - health
> -metrics
>
> Each of those could become possible Jakarta EE specs and seem the best candidates for the kind of incubator Sebastian suggested.

Not without breaking compatibility. And unless they're removed from
MP, not without splitting the community as well. And what happens
when some hapless user ends up with both Jakarta EE and MP versions of
a thing on their class path? How would that work?

Why is it necessary for Jakarta EE to gobble up everything? Why not
leave MP alone and let each project decide if they want to abandon MP
and move to Jakarta instead? Maybe it was originally intended for MP
to be an incubator but those days seem to be past. I think that some
of these specifications are pretty entrenched now. I don't see what
is to be gained by uprooting them and moving them, or worse yet,
dividing any of them amongst two standard bodies.

If an MP specification has not yet released a final version, then
maybe it's worth asking that spec team/community if they want to move
over to Jakarta. But otherwise, moving specs for the sake of moving
specs just seems rife with problems. What am I missing?

--
- DML

[Werner Keil]

It's not a standard and it never intended to be.

MP 4.x or whatever will have to adopt to Jakarta EE otherwise it would end up dead and frozen.

Meaning the implementing code and most of the apps will have to adjust to Jakarta specs then anyway, so shifting e.g. config from org.eclipse.microprofile to jakarta.config in another release is just the same kind of effort.

Spring which many consider a role-model for some of the MP efforts actually picked up the first Jakarta EE specs already, at least the lower hanging "fruits" like Jakarta Activation among others.

Werner

[Werner Keil]

Sebastian,

Coming back to your original post (I did not see the picture in the email digest before) thanks for the suggestions.

I was also at JCrete both joining and moderating Jakarta EE related sessions.

I also spoke to those leading MVC or JCache who were also there.

As for MVC, there is an issue around the JSR Ivar mentioned they have to resolve with Oracle legal. It sounds doable and since it won't affect Jakarta EE 8 yet, there should be enough time to solve it.

As for JCache, the feedback that Greg received offering it to MP or Jakarta EE seems not overly enthusiastic, as he mentioned at JCrete, so maybe someone could convince both Hazelcast and Oracle it makes sense, otherwise we may not see it till Jakarta EE 13 if ever.

Every new Jakarta EE feature has to start in an incubator mode. Right now everything is in Eclipse Incubator, so one cannot tell the difference, but e.g. https://projects.eclipse.org/projects/technology.nebula vs. https://projects.eclipse.org/projects/technology.nebula.incubator shows a Technology project with an Incubator. MicroProfile should have done that some while ago, it's not understandable why it refused to for so long.

There are some Eclipse IDE distributions, especially around EMF where the download page states, it contains incubating features.

Of course, something along the lines of "--enable-preview" (https://openjdk.java.net/jeps/12) could be a way to use incubating features in Jakarta EE.

Werner

[Alasdair Nottingham]

--enable-previews is really a statement about the implementation not the standard.

I don’t think it would be appropriate for Jakarta EE specs to mandate such a thing. 

Alasdair Nottingham

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/13e8e190-b6ad-424b-91fb-11d5bfeccbab%40googlegroups.com.

[Mark Little]

Agreed and also the way Java EE before it adopted other specifications, e.g., we didn’t fork CORBA from the OMG!

Mark.

[Emily Jiang]

There are a few corner cases

- fault-tolerance

is pretty Failsafe ported into MP by its original author, but I don't see his original project use it in any way. 

Hystrix is no longer maintained by Netflix. There are alternatives like https://dzone.com/articles/resilience4j-and-sentinel-two-open-source-alternat

Until the makers of more than one of those got together, mp-fault-tolerance is still a a niche that was driven by just one author and without others willing to adopt it, one can hardly call it a broad enough to become a Jakarta spec at this point. A Jakarta incubator may offer a room to mature and broaden it.

I disagree with your summary. MP Fault Tolerance was influenced by Failsafe and Hystrix. What made you think it is one author without others willing to adopt it? This statement is pretty negative.

By the way, personally, I think time is not right to discuss the future of MicroProfile and Jakarta EE as MicroProfile is doing very well and we should not slow it down by projecting a uncertain future, besides Jakarta needs time to settle down with javax namespace moves and the first releases needs to be done.

This blog summarises what I think very well and I still believe MicroProfile should be treated as a sports car while Jakarta EE should be treated as a minibus.

Thanks

Emily

[Alasdair Nottingham]

While I disagree with quite a bit of what Werner said I don’t feel comfortable assigning words like minibus and sports car to JakartaEE and MicroProfile respectively because the two words are loaded with negative connotations for the respective communities. While I agree that merging right now would be premature and counter productive we should also remember that the two communities have a somewhat symbiotic relationship so we need to be positive about each other. 

Alasdair Nottingham

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5fd255f8-1001-4119-9536-a5f4ed8695e3%40googlegroups.com.

[Alasdair Nottingham]

I should probably add I don’t think you meant it that way. I just don’t want people to read the terms negatively and I’m concerned they could. 

Alasdair Nottingham

[m.reza.rahman]

I agree wholeheartedly that we need to figure out workable solutions for the entire ecosystem while minimizing needless conflict and abrasive interactions. The more abrasive these discussions get, the more it is likely to harm everyone here and help those who likely never wished us well in the first place.

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

[Emily Jiang]

Thanks Alasdair! I like both communities wholeheartedly and didn’t mean any negative comparison! I just want to say that they are not compete with each other. On the contrary, they are complementary each other!

I suggest we park the discussion for now as it’s premature to discuss this. Besides, both communities have urgent items to focus on, e.g. javax namespace changes, releasing Jakarta EE8, growing pains in MicroProfile conversation (we need to get some standalone releases to umbrella releases)...

Thanks 

Emily 

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/gVAabao5oXQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/54FAA084-0E02-4D25-8074-F60DE6045EAB%40gmail.com.

[Werner Keil]

Emily,

The observation, that even though MP Fault Tolerance could have received input by others like Hystrix, the list of downstream repositories on GitHub https://github.com/eclipse/microprofile-fault-tolerance/network/dependents just doesn't show either of these projects using it.

Can you point us to something that contradicts that observation?

A vast majority are samples and PoC or similar projects, the only implementors to spot are a few like the "usual suspects" including Payara, Tomee or OpenLiberty as well as Helidon or Thorntail. 

So why doesn't a project like Failsafe act as an implementation yet?

While Sebastian's initiative is very positive, knowing how long certain things took since we started discussing them e.g. in Java EE 6 about a decade ago tells me, it won't happen overnight and it also won't happen for all the mentioned specs and projects right away.

The downstream usage numbers are even with most of them being samples a good indicator for the health and usage of those features.

microprofile-config has nearly 400 downstream usages while microprofile-reactive-messaging has only 4 !

Config is something not only the JCP attempt makes a bit more of a pillar to other specs. We met Simone, who is one of the Jetty project leads at JCrete and he had never heard of MP Config (or even JSR 382 AFAIK) before that. However Jetty has many use cases for configuration https://www.eclipse.org/jetty/documentation/9.4.x/quick-start-configure.html. Some of it may be a bit exotic, but at least Apache Commons Config has support for ini-files.

Then there's another major config project at Eclipse (also driven by Red Hat btw.) https://github.com/vert-x3/vertx-config with nearly 1600 downstream users. Both https://github.com/eclipse/microprofile-config/graphs/contributors and https://github.com/vert-x3/vertx-config/graphs/contributors started in 2016 only a few months apart, so they had a similar time for adoption.

So in that sense the car analogy is not so wrong, also when it comes to adoption (compare the number of Ferrari or Porsche sold to the VW "Bulli" or other Volkswagen minivans) and Jakarta EE would allow certain features much broader visibility and adoption.

Aside from projects that wish to participate, the general idea of a Jakarta EE incubator is pretty good and hope it won't take another decade before it can be applied? ;-)

Werner

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5fd255f8-1001-4119-9536-a5f4ed8695e3%40googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/gVAabao5oXQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/54FAA084-0E02-4D25-8074-F60DE6045EAB%40gmail.com.

[Emily Jiang]

Werner,

So why doesn't a project like Failsafe act as an implementation yet?

Now, I see your confusion. MicroProfile specifications are designed for microservice/app developers, which are not intended to be adopted a third-party libraries which will be wrapped again. However, if some libs wants to use them, it is fine. MicroProfile specification is comparable to Java EE specs. e.g. CDI has two implementations. Some runtime consume one of two implementations. Will you say none of Java EE specifications are popular because only a couple of implementations available?

As for MicroProfile Fault Tolerance, it is an abstraction layer sitting over and above Failsafe or Hysterix. Some runtime uses failesafe or Hysterix to implement MicroProfile Fault Tolerance, but for runtime such as Open Liberty, Thorntail, Payara, TomEE, Helidon, etc. Once the runtime adopts the spec, microservice developers are rest assured that their apps using FT are portable.

In summary, the intention of MicroProfile specifications is not for other third-party libs to adopt this, but they can if they wish. Therefore, using the third-party adoption as a success factor is flawed.

Thanks

Emily

[Werner Keil]

Emily,

> Will you say none of Java EE specifications are popular because only a couple of implementations available?

No and the number of downstream users of an API or spec don't just show implementations. They show everything that references the API via Maven or a similar dependency management. So it shows, if a spec is used (by public/open projects on GitHub) more widely than others. Of course if 90 or 100% are just POC or demo code this can be misleading, but even 10 demos using one spec or API compared to 1000 or more shows a difference.

> the intention of MicroProfile specifications is not for other third-party libs to this

That sounds a bit weird, if a spec is not adopted, why even define it? Not everything is seen via those dependency stats, but e.g. the https://github.com/eclipse/jetty.project has various modules using Hazelcast, Infinispan or CDI. Vert.x has a "bridge" for Micrometer: https://github.com/vert-x3/vertx-micrometer-metrics, but not MP Metrics. If there was it would show as a downstream project.

So you won't see how many deployments of a particular server or container are out there, but even bridges or drivers should be visible. 

Log4J has around 290k such downstream usages, that certainly includes all those abstraction layers like SLF4J bridges for it or Apache-Commons-Logging.

Werner

[Werner Keil]

Emily

> As for MicroProfile Fault Tolerance, it is an abstraction layer sitting over and above Failsafe or Hysterix. 

This makes FT also seem a lot more like a "glue" or bridge between CDI and the mentioned technologies. Like some others that were mentioned in this thread. 

If you look at Spring and Spring Boot, a lot of Java EE specs like Servlet, JMS or JTA among others are used by them. Spring already started using several new Jakarta EE specs in the new namespace like Jakarta Annotations.

On the other hand, Spring inspired and sometimes heavily shaped a few of the newer specs including CDI (its Inject core), JBatch, MVC or most recently Jakarta NoSQL. 

Then there are many more parts where Spring also acts as integrator or "glue" between Dropwizard, Hystrix, Kafka and everything else that is popular or useful. Only a small handful of its modules or features turned into Java EE or similar specs. 

One should not expect much different with MicroProfile. Maybe one or the other like the obvious Config (which also got some inspiration and use cases from Spring) 

Nobody is going to force all of MicroProfile to convert, at least not in my impression

Having an Incubator is a good idea and whenever the Spec Committee is a little less busy with getting Jakarta EE 8 out of the pipeline, I'll make sure to raise the subject there as well.

Werner

[John Clingan]

Sorry, lots of PTO and travel. I've been following this thread (here and in Jakarta) but haven't laid down my thoughts yet. Lots of good discussion on this thread. Interestingly, David nailed a couple of point that I was going to make - the problem that is trying to be solved and the risk of forking.  MicroProfile is much more like an open source project than a standards organization. We love lightweight processes and moving quickly. I think MicroProfile and Jakarta EE are coming at the problem of specs from completely different angles right now - and both approaches are valid, BTW.

Someone mentioned in this thread that many MicroProfile committers are also involved in Jakarta EE. Those same committers value the different approaches each project brings.  The general feeling of MicroProfilers I have talked to is that combining the two is premature and I agree. I think Jakarta EE needs to get a couple of releases under its belt, needs to define a release strategy, execute on the strategy, etc, before we should re-engage on this topic. MicroProfile is executing extremely well and we need to keep that momentum.

[Werner Keil]

For a vast majority of the features that were mentioned here I fully agree, also see the thread so far.

However because a standardization effort was made at JCP.org before the contributors and Spec Leads (most are also involved in MicroProfile Config) Configuration is a different story. Unless everyone involved came to the conclusion, that the MP Config project was not suitable as a configuration subsystem of containers like say Jetty, Glassfish or Tomcat/TomEE as well, it would be even more harmful to the entire effort if it was delayed till Jakarta EE 20 or 25. Nobody would still need it then, while a successful inclusion to the Jakarta EE platform with 9 or 10 gave it a chance to also work for other specs that so far did this in separate ways.

Config is also among the very few MP features, that is used by nearly 100% of all runtimes that implement "some" of it, while others are not always so widely used. So if others are used more frequently (GitHub offers a good indicator, there Config also has more downstream usage than all the others) at MicroProfile then a need and justification to standardize could arise for more of them and Jakarta EE will also have some more releases as well.