Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE

Thanks for pointing this out. I believe these are exactly some of the reasons why developers have the impressions/expectations they do.

One positive aspect of this is that it does make it clearer where the differences between Jakarta EE and MicroProfile are, reduces overlap/contention and creates a sensible relationship. I think it is also important to acknowledge that these MicroProfile characteristics are not really weaknesses and are in fact what some developers have looked from Java EE for a while, certainly with the advent of fine grained SOA/microservices. Fulfilling that gap in the ecosystem that Jakarta EE should probably not try to do I think is where MicroProfile really shines, especially going forward. I also think it is important to note that these characteristics do not necessarily mean an API is not production ready. It simply means the underlying use case, concept and domain may have too much fluidity itself.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

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: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Date: 1/20/21 4:47 AM (GMT-05:00)
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Subject: Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE

Isn’t the MPWG charter explicit that backwards compatibility is not a goal of MP? I’d assumed that it was drafted that way on purpose along with “Experiment and Innovate” and “provides an industry proving ground to incubate and experiment”?

 

It was from these charter principles and the strong desire from many to maintain WG independence that I suggested graduation to Jakarta EE in the first place.

 

Steve

 

From: cn4j-alliance <cn4j-alliance-bounces@xxxxxxxxxxx> On Behalf Of Scott Stark
Sent: 19 January 2021 20:59
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Subject: Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE

 

Correct, and that is what I am trying to get an understanding of as well. I believe config is a strong candidate for a spec that has different handling relative to the default behavior in MP. I believe Red Hat would vote for a change in handling on the MP side in order to use config on the Jakarta side. On the Jakarta side Red Hat would vote to not have to duplicate the effort that has already been put in.

 

The question is whether that could be a consensus view across the two WGs.

 

On Tue, Jan 19, 2021 at 2:09 PM Thomas Watson <tjwatson@xxxxxxxxxx> wrote:

My understanding is that there are only a few MP APIs considered for inclusion in Jakarta APIs.  Are there no MP APIs that would be considered for maintaining in a backward compatible way moving forward within the MP working group? Does such a demand for backward compatibility make it such that the API cannot be evolved within the MP working group?

 

I'm still trying to understand what the two working groups are open to for a solution to using MP APIs in Jakarta specifications.


Tom
 

 

 

----- Original message -----
From: Scott Stark <starksm64@xxxxxxxxx>
Sent by: "cn4j-alliance" <cn4j-alliance-bounces@xxxxxxxxxxx>
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
Date: Tue, Jan 19, 2021 1:43 PM
 

Yes, many and APIs were not intended to ever transition to the JCP. Even with the transition of JCP to Jakarta, there remain process, cost and lifecycle issues that would cause Red Hat to target MP over Jakarta.

 

 


Back to the top