Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Hi Reza.
No need to get sad, it's just an opinion. 

I am not at all saying that Jakarta EE is not worth it. At the moment there are 2 communities that is not going to be combined into one (at least not now, maybe not ever)

However, we are in the situation that Jakarta EE needs config (and later maybe other APIs). In my opinion we can:

1) Create a new (similar) specification under Jakarta that looks like MicroProfile Config but it's not and users can not move between them. I.e config code written in MicroProfile Config is different that in Jakarta Config. Having more than one standard for the same thing just becomes messy (just look at all the travel adaptors for electrical plugs you need when you travel) This is however what JSR382 is doing.

2) Just use the MicroProfile Config spec as is in Jakarta EE. Not sure if Jakara will do that or want that because MicroProfile can not guarantee backward compatibility and might make breaking changes. It also (anyway) take away the brand from the namespace as it would be org.eclipse.microprofile. However, at least there is just one standard, so IMHO a better idea than 1.

3) Do what I suggested, where we start creating APIs and Specs under multiple workgroups and processes, but using the same (non-branded) namespace. This allows us move Specs between Umbrellas without any code changes. Better for the developer/users.

Yes we loose some branding when the developer do the import of the namespace, but we never really had that (Java EE / J2EE was never in the namespace, only javax that is in more than Java EE)

We would still have the brand in the maven artifact of the umbrella, so when a developer use Jakarta EE, that would be in the pom. However, if the developer use the individual specification in the pom, there will be no branding, not from MicroProfile nor from Jakarta.

I do not think this suggestion shows we can not get together like you suggest, in fact I think it's the opposite. Doing option 1 is showing we can not.
In fact I would argue that having the ability to create specifications in multiple workgroups is more scalable that just having one process and one workgroup

Anyway ,happy to debate this - I might be wrong.

Cheers


On Wed, Sep 25, 2019 at 5:19 PM reza_rahman <reza_rahman@xxxxxxxxx> wrote:
Your email is right on point.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Thomas Andraschko <andraschko.thomas@xxxxxxxxx>
Date: 9/25/19 11:07 AM (GMT-05:00)
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

Sorry reza but i'm not sure if i understand your mail correctly in relation to my mail or the blogpost?

reza_rahman <reza_rahman@xxxxxxxxx> schrieb am Mi., 25. Sep. 2019, 16:49:
If I had not put so many years behind this technology and didn't have the perspective of how many real people these decisions will touch, I would almost find some of this humorous. Instead of course it simply makes me sad.

We are twisting ourselves into knots around a simple truth - you need one simple, overarching solution for so many good reasons and so much effort was put into making Jakarta EE that solution - only to decide the whole thing maybe wasn't worth it and we need to invent yet another abstraction as a patch that prominently symbolizes our inability to come together for a common cause shared by all of our users and consumers.

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: Thomas Andraschko <andraschko.thomas@xxxxxxxxx>
Date: 9/25/19 9:53 AM (GMT-05:00)
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

IMO org.eclipse.enterprise.* instead jakarta.* would make JakartaEE somthing like minor and 
unimportant. Just like "some random lib hosted on eclipse".

Just replacing all javax with jakarta for the packages is the perfect choice IMO.
javax.faces -> jakarta.faces

Just not sure about CDI as the namespace is javax.enterprise.inject.
I think moving JSR330 annotations to CDI and call it jakarta.inject would be a very very nice decision.

Phillip Kruger <phillip.kruger@xxxxxxxxx> schrieb am Mi., 25. Sep. 2019, 13:50:
Hi All.

I have some thoughts on the new package name (Jakarta).

Just an idea. Let me know what you think.


Phillip


On Mon, Jun 10, 2019 at 3:32 PM reza_rahman <reza_rahman@xxxxxxxxx> wrote:
The broader Java EE community I suspect will be more than happy to volunteer for such an initiative.

Reza Rahman
Principal Program Manager
Java on Azure

Please note views expressed here are my own as an individual community member and do not represent the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Martijn Verburg <martijnverburg@xxxxxxxxx>
Date: 6/10/19 8:19 AM (GMT-05:00)
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

That's what I'd been assuming - a namespace change and a coordinated effort by the vendors to uplift their tooling.  

Example, it was a slow start to start with converting popular libs to jigsaw/module system but once we got all of the key folks involved it's moved very quickly.

Is there a shared list anywhere of the major tools that need updating (compile and runtime)?

Cheers,
Martijn


On Mon, 10 Jun 2019 at 11:43, Mark Little <markclittle@xxxxxxxxx> wrote:
Unless we go back to one of the very first Big Bang proposals and only change the namespace and nothing else. That’d be the quickest solution (for Big Bang).

Mark.


On 9 Jun 2019, at 22:33, Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:

For big bang approach, I think there is still one open question.
As per Bill's notes, " Big Bang proposal says "some or all" will be moved to jakarta.*; it allows us to leave behind specs that we plan to abandon.",
this suggests further talk needs to happen for deciding the spec shortlist. I think the list needs to be refined first before the decision is made. I fear if big bang approach is chosen, we need more discussion to finalise the list. Further delay is unavoidable. One of the possible outcome is after a lengthy discussion, only 10-20 specs are to be maintained. This sounds incremental to me. I don't think a decision should be reached with open questions. Unless, Big Bang means migrating all specs.

With incremental approach, I think the roadmap is much clearer. Any specs can start evolving straight away.

Thanks
Emily


On Sun, Jun 9, 2019 at 12:31 PM Mark Little <markclittle@xxxxxxxxx> wrote:
Whatever we do we should close on a decision soon. Or we could be here still discussing it next year. I said at the start we need to consider as much data as possible to try to make an informed decision and I'm not seeing any new data coming in at this stage.

On Fri, Jun 7, 2019, 13:49 Emmanuel Bernard <ebernard@xxxxxxxxxx> wrote:

Right,

Option 1. you go incremental and if you realise you're screwed, you stop in this mid step can can't do anything. If you realise it works then you have to go through the pain by a thousand cuts.
Option 2. you go big bad and if you realise you're screwed, you stop or get this "fresh platform" with less conversion rate. If you realise it works, you've saved 999 cuts to your users

I also believe that Option 2 has a better chance of moving the ecosystem than Option 1, therefore a better chance of success.

Big Bang FTW.

On 5 Jun 2019, at 21:57, Bill Shannon wrote:

I continue to believe that the success of either approach will depend on whether or not we have an effective binary compatibility solution.  So for me the fine print on my opinion is "assuming we have a good enough binary compatibility solution".

If we start out with the incremental approach and find out that it hurts too much, then what do we do?  We can't go back.  We have to keep moving forward no matter what.  Even if it means inflicting pain at each release.  So why not get it all over with at once.

Either way, I suspect many developers will skip these early releases of Jakarta EE until these issues settle out.

Kevin Sutter wrote on 6/5/19 11:47 AM:
+1, John.  We can start incrementally and move to big bang later.  We can't do the reverse.


---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:        John Clingan <jclingan@xxxxxxxxxx>
To:        jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:        06/05/2019 12:55 PM
Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Sent by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx



I’ve been pretty quiet up to this point, following the discussion. Early on was I was for “big bang” for various reasons already outlined in other comments. What I find increasingly concerning, the more I think about it, we are guessing/making assumptions as to the impact of a decision.

 “We don’t know what we don’t know”, IMHO. Making a big-bang change is a big step that could have unforeseen consequences to the ecosystem and the user base. We are a small group discussing the namespace issue that is trying to represent a developer base of probably 1M managing potentially millions deployed apps based on these specs. A more conservative approach would be to do an incremental update, measure the impact and learn some things along the way, and then decide if further incremental steps are required or if we can simply move the remainder.

On Jun 5, 2019, at 9:20 AM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

Oracle agrees that Big Bang is best.

Steve Millidge (Payara) wrote on 6/5/19 9:12 AM:
Just to add Payara favours a big bang approach as described in  https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/namespace/proposal-01-bigbang.adocwe believe a majority of APIs need to evolve and therefore a majority of apis will eventually move to the Jakarta namespace so may as well do it now.
 
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx<jakartaee-platform-dev-bounces@xxxxxxxxxxx>On Behalf Of Scott Stark
Sent: 05 June 2019 16:59
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

 

There has been no decision and there continues to be uncertainty as to the best approach. Vendors seem to favor an incremental approach as there is a belief that it eases backward compatibility stories. Developers seem to favor getting the move over with. I think the current plan is to talk about a plan toward a decision on the upcoming June 12 community call.

On Jun 5, 2019, at 4:19 AM, reza_rahman <reza_rahman@xxxxxxxxx> wrote:

 

Has a definitive decision on this been reached already? If not, when will it be reached? If a decision has been reached, can the community have visibility into how each of the stakeholders voted on this issue and why?

 

I looked at the recent meeting minutes and it is very unclear to me if a vote was held and what the rationale from each decision maker was. In particular I would personally like to understand how community input was weighted.

 

I am still hoping we can all celebrate together soon with the right forward looking and community focused decision being made by stakeholders.

 

Reza Rahman
Principal Program Manager
Java on Azure

 

Please note that views here are my own as an individual community member and do not represent the views of my employer.

 


Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

 

-------- Original message --------
From: David Blevins <dblevins@xxxxxxxxxxxxx>
Date: 5/6/19 7:23 PM (GMT-05:00)
Subject: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

 


[Contents of this email represent discussions of the Jakarta EE Specification Committee over the last several meetings.  The statements here have been reviewed by and represent the voice of the Jakarta EE Specification Committee]

 


As announced in the Update on Jakarta EE Rights to Java Trademarks[1] post on Friday, future modification of the javaxnamespace will not be allowed.  While this is not what was envisioned when Jakarta EE started, in many ways this in our best interest as the modification of javaxwould always have involved long-term legal and trademark restrictions.

 


To evolve Jakarta EE, we must transition to a new namespace. The primary decisions we need to make as a community and industry are how and when. Given all delays and desires on everyone’s part to move forward as fast as possible, we would like to have this discussion openly as a community and conclude in one month. It is the hope that in one month a clear consensus emerges and can be presented to the Specification Committee for final approval.

 


In an effort to bootstrap the conversation, the Specification Committee has prepared two proposals for how we might move into the new namespace. These should be considered a starting point, more proposals are welcome. No final decisions have been made at this stage.

 


The guiding principle for Jakarta EE.next will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.

 


Other proposals should incorporate the following considerations and goals:

 

  • The new namespace will be jakarta.*
  • APIs moved to the jakarta namespace maintain class names and method signatures compatible with equivalent class names and method signatures in the javax.* namespace.
  • Even a small maintenance change to an API would require a javaxto jakartachange of that entire specification. Examples include:
    • Adding a value to an enum
    • Overriding/adding a method signature
    • Adding default methods in interfaces
    • Compensating for Java language changes
  • Binary compatibility for existing applications in the javaxnamespace is an agreed goal by the majority of existing vendors in the Jakarta EE Working Group and would be a priority in their products. However, there is a strong desire not to deter new implementers of the jakartanamespace from entering the ecosystem by requiring they also implement an equivalent javaxlegacy API.
  • There is no intention to change Jakarta EE 8 goals or timeline.
  • Community discussion on how to transition to the jakartanamespace will conclude Sunday, June 9th, 2019.
 
It is envisioned binary compatibility can be achieved and offered by implementations via tooling that performs bytecode modification at either build-time, deploy-time or runtime. While there are open questions and considerations in this area, the primary goal of the discussion that must conclude is how do we move forward with future modifications to the APIs themselves.
Proposal 1: Big-bang Jakarta EE 9, Jakarta EE 10 New Features
The heart of this proposal is to do a one-time move of API source from the javaxnamespace to the jakartanamespace with the primary goal of not prolonging industry cost and pain associated with the transition.

 


Were we to take this path, a compelling approach would be to do the namespace rename and immediately release this as Jakarta EE 9. Additional modifications would be put into a Jakarta EE 10 which can be developed in parallel, without further delays.

 

  • Some or all Jakarta EE APIs under javaxwould move immediately into jakartaas-is.
  • Any packages not moved from javaxto jakartacould be included in Jakarta EE, but would be foreverfrozen and never move to the jakartanamespace.
  • Jakarta EE 9 would be refocused as quick, stepping-stone release, identical to Jakarta EE 8 with the exception of the javaxto jakartanamespace change and immediately released.
  • Jakarta EE 10 would become the new release name for what we imagined as Jakarta EE.next with only minor impact on timeline.
  • Work on Jakarta EE 10 could start immediately after rename is completed in the GitHub source and need not wait for the Jakarta EE 9 release to actually ship.
Pros:
  • One-time coordination and cost to the industry, including; conversion tools, users, enterprises, cloud vendors, IDE creators, platform vendors, trainers and book authors.
  • Easily understood rule: everything Jakarta EE 8 and before is javax, Jakarta EE 9 and after is jakarta
  • Consistent with the javaxto jakartaMaven groupId change.
  • Highest degree of flexibility and freedom of action, post-change.
  • Industry would have the opportunity to begin digesting the namespace change far in advance of any major new APIs or feature changes.
Cons:
  • Largest upfront cost for everyone.
  • Specifications that may never be updated would still likely be moved.
  • Decision to not move a specification is permanent and therefore requires high confidence.
Decisions:
  • Which specifications, if any, would we opt not to move?
  • Would we take the opportunity to prune specifications from Jakarta EE 9?
  • Do we change the language level in Jakarta EE 9 to Java SE 11 or delay that to Jakarta EE 10?
 
Proposal 2: Incremental Change in Jakarta EE 9 and beyond
Evolve API source from javaxto the jakartanamespace over time on an as-needed basis.  The most active specifications would immediately move in Jakarta EE 9.  Every Jakarta EE release, starting with version 10 and beyond may involve some javaxto jakartanamespace transition.

 

  • The most active APIs would immediately move from javaxto jakarta
  • APIs not changed or determined by the community to be unlikely to change would stay in javax
  • Jakarta EE 9 would be a mix of javaxand jakartapackaged APIs
  • If a change was needed to a javaxAPI post Jakarta EE 9 for any reason, that API would transition fromjavaxto jakarta.
  • Jakarta EE 10 would be a mix of javaxand jakartapackaged APIs, but a different mix than Jakarta EE 9.
  • At some point down the road, Jakarta EE xx, it may be decided that the migration from javaxto jakartais “done” and the final APIs are moved.
Pros:
  • Cheaper up front cost and reduced immediate noise.
  • No need to move specifications unless there is an immediately visible benefit.
  • Potential for less impact from API change overall.
Cons:
  • Prolonged coordination, cost and complexity to industry affecting conversion tools, users, enterprises, cloud vendors, IDE creators, platform vendors, trainers and book authors.
  • Use of restricted javaxnamespace prolonged.
  • Frustration of “always changing” packages may deter application developers and become a permanent perception of the brand.
  • Difficulty in remembering/knowing which Jakarta EE release an API was moved. “Is Connector javaxorjakartain Jakarta EE 11?”
  • Difficulty in keeping the industry in sync.
  • New implementations may find themselves having to deal with the javaxto jakartatransition, unable to avoid legacy costs and therefore decide not to enter the space.
  • Transitive dependencies to other specifications may make incremental change difficult or impossible.
  • Restrictions on what Java SE implementation can be used for certification
Decisions:
  • Do we start small or start large?
  • Which APIs would immediately need to be changed?
Out of Scope
The following are very important community discussions, but do not require a decision in the time-frame allotted:

 

  • Roadmap or release date for any Jakarta EE.next that would contain new features
  • List of specifications that may be deprecated, pruned or removed from Jakarta EE.next, if any
  • Specification text around backwards compatibility requirements, if any
  • What profiles should be defined
 
However, depending on the path chosen, some of these topics may require immediate resolution before the chosen path can be executed.

[1] https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/


--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852

 

 

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

 



_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev




_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


--
Thanks
Emily
=================
Emily Jiang
ejiang@xxxxxxxxxx
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top