| Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace |
Reza, as I've indicated to you before on this topic, please give names and positions if possible or have them come and voice their opinions directly otherwise it's hard to determine the context of their input.You mean like the customers you’ve talked to in your very next message (no flame intended, just pointing out the irony)
There are many different positions in EE and all of them are valid.
_______________________________________________Below is my position as a user of Java EE.Our mission, should we choose to accept it, is to keep the platform relevant and let it have a future.Given what I’ve read on this list any future starts with jakarta.*. And given the impossibility of migrating spec by spec, due to the intermingledness of the APIs, migrating all APIs is easier for folks that adopt jakarta as the future than doing it piecemeal. Even though some parts might not evolve beyond the package rename.If someone wants to stay on javax they can pay their vendor to keep supporting their Java EE 8 server. I sympathize with folks that don’t have source for parts of their applications but they are not being stranded by us going to the future: they were already stranded. Should the whole industry be kept hostage by unnamed customers or can we (and they) take this opportunity to shed the parts that hold us back?As a named user of Java EE technology, not a representative of my whole company (just the part with ~2M lines of Java EE code in the education sector, you’re free to look me up on LinkedIn), I and my team support a Big Bang, get everything migrated, prune later, don’t conflate adding Microprofile stuff now and get it done sooner than later approach.The amount of work that lies before all platform builders is staggering, so getting a bunch of alfa releases with the renamed packages out would be awesome and show how much work it really is. Then we all can focus on marketing the sh*t out of the new reality, like “I migrated all my systems to Jakarta EE and it only took 1 month” blog articles. I know I will write one.From there the rest of the ecosystem can start migrating to the new reality and work on byte code stuff to aid migrations of stuck, old and left behind libraries. For instance Apache Wicket can’t migrate until there’s a jakarta.servlet available (and a Jetty/tomcat/glass fish/wildfly to run it in)Kind regards,Martijn DashorstThanks,Mark.On Thu, Jun 6, 2019, 11:12 Reza Rahman <reza_rahman@xxxxxxxxx> wrote:To be honest I am trying my best to avoid an inevitably long and convoluted debate (perhaps somewhat emotionally charged too?) on what to do with MicroProfile now. My list is from the perspective of what a server-side developer would like to see from the core ecosystem platform in terms of maintenance.
Aside from listening to what the folks in the community are saying at a high level, I had a little bit of time (mostly in the evenings) to have longer conversations with some more senior end users around this. The emerging pattern is that people are concerned about Java EE ecosystem fragmentation at the very core, significant brand confusion for newcomers as well as a concern for how the same set of key stakeholders would staff/manage two separate endeavors without weakening both.
That said, a clear pattern I have also seen is that people are more concerned about moving forward Java EE and views on MicroProfile are far softer. For that reason I believe just issuing a statement of alignment without doing much in the near term is sufficient. The key issue is properly prioritizing moving forward Jakarta EE including the re-packaging. Java EE has been under-funded long enough now and it has made everyone's life more difficult. More of the same is likely to make things worse, not better.
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.
P.S.: The list is quite old sadly. Agreed on not moving forward with Open Tracing just yet because of the recent flux. I do actually pay attention to the MicroProfile emails even if I do not often chime in you see :-).
On 6/5/2019 10:35 PM, Alasdair Nottingham wrote:
#Off Topic, butMicroProfile has already speced some of those things so I would hope that we wouldn’t respecify just for the sake of it.
I wouldn’t bother with adding Open Tracing to anything given it is imminently to be replaced with Open Telemetry.
Alasdair
On Jun 5, 2019, at 4:53 PM, Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
I am very much in agreement with the Payara view that most Java EE APIs need to evolve under Jakarta EE for the entire ecosystem (including MicroProfile) to avoid the impression of being stagnant and irrelevant. The reality is that Java EE truly is foundational (both in terms of perception and technical reality) to the entire ecosystem and needs to be kept healthy, especially now that it can move forward in a vendor neutral fashion.
I had already provided my own list of changes that I have had in mind for a while now. I neglected to put those in priority order. Perhaps it helps to do that now:
* Servlet -> Reactive support* JPA -> Reactive support, various long pending enhancements* JAX-RS -> CDI alignment, various long pending enhancements, NIO support, Open API support, Open Tracing support
* Security -> Many important pending enhancements, most important of which is JWT support* Concurrency -> Java SE alignment, adding replacements to EJB functionality* JMS -> CDI based message listeners, AMPQ support, Kafka compatibility, bootstrap API* JSON-B -> JSON schema support
* JSON-P -> JSON schema support* JSF -> Cleanup and cruft removal* JavaMail -> Java SE alignment, higher level JMS 2 style usability API
* Batch -> Adding Java configuration support, various enhancements* WebSocket -> Java SE alignment
* EJB -> Java SE alignment
I think others - particularly end users - should chime in with their own views of how they would like to see Java EE APIs evolve under Jakarta EE if this is really a critical issue to determine right now.
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.
On 6/5/2019 4:22 PM, Steve Millidge (Payara) wrote:
I’m not aware of any list. The linked document is Arjan’s view of what he wants to see. I’m sure others would have other ideas. I for one would want to see evolution of CDI, JBatch, JPA and JMS and maybe even EJB which weren’t on the list.Now that APIs have been moved to the Eclipse Foundation whether an api evolves or not is up to the open source project and the corresponding community. However I firmly believe that for all the mainstream heavily used Java EE 8 apis there is a desire out there to see them evolve.Are you really suggesting that after all this time that we actually don’t want to change the apis that we’ve just spent two years moving to the Eclipse Foundation?SteveFrom: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of John Clingan
Sent: 05 June 2019 20:54
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespaceBTW, I should mention that my comment was general in nature and not targeted specifically at Bill’s comment. I just wanted to insert my thought somewhere and that seemed as good a place as any :-)@Steve, you mentioned "we believe a majority of APIs need to evolve”. Does a list exist of which APIs plan to evolve and in what timeframe? I think the only list I’ve seen is here: https://www.eclipse.org/community/eclipse_newsletter/2019/february/Jakarta_EE_9.php
On Jun 5, 2019, at 11:47 AM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:+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 namespaceThere 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 RahmanPrincipal Program ManagerJava on AzurePlease 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 thejavaxnamespace 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:o Adding a value to an enumo Overriding/adding a method signatureo Adding default methods in interfaceso 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·<span style="font-style: normal; font-variant-caps: normal; font-weight: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New_______________________________________________
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