| Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace |
(Speaking as an experienced platform dev, not on behalf of my employer)
Regarding
"any position that states Jakarta EE is legacy and we should focus on something else is
potentially disastrous for everyone here.
Our detractors will take this opportunity to tell people to move to their platform
while we are "still trying to figure it out"."
I recognize the serious of this topic.
For such important topics I sometimes use the thinking tool referred to here:
https://awealthofcommonsense.com/2013/09/10th-man-rule-world-war-z/
With this "10th man" hat on:
<10thman>
What would it look like if we took our development dollars and stepped off
the mode of operation that has worked over the past decades? Would we choose to
invest our money by evolving such a huge codebase?
For MicroProfile we are trying to do the same thing that worked before
- just a bit quicker. How fast did we really execute, and with our
collectively vast resources how much adoption
from customers did we get compared to single vendor/library/framework innovations?
What is the telemetry on this?
What are the core reasons that are still needed for having large 'formations'
of associated spec/jar versions.
Problems like@ https://twitter.com/alonso_Isidoro/status/1125366214908358656
"It is not possible to use Kafka-streams and apache spark in a joint project due
to the incompatibility of the Jackson-core library.
Spark uses 2.6.7.1 and Kafka-streams uses 2.9.8."
-> Could this sort of problem be attacked with JPMS?
-> Is this sort of problem less important with single service Microservices?
Vendor lock in (and thus loss of bargaining power on software licenses?)
-> Is this less of a concern to customers when their server software is free
and portability to the 'cost' is achieved via containers?
Do we all need to eat a copy of https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma
and wake up and realize that in the future the OODA loop that is needed to compete
is dipping under the iteration time of large cross group collaborations?
What if we invested in
A - maintaining the fantastic platform we currently have with great service
B - if the revenue is going to come from support and hosting, and new app/functions packaged as separate microservice processes, building
that platforms rival as an evolving best-of-breed curation of defacto leading technologies from any source
</10thman>
Only by coming at this problem
from the other side too,
can we understand fully why it is not
the best way to deliver value for our customers with the assets we have and we are not just doing
'more of the same' as it is what we are comfortable with - that path leads to being out evolved
and a revenue/value 'half-life'.
I love the enterprise Java space and I want it to really thrive.
Gordon.
Gordon Hutchison
IBM Systems Middleware
Websphere Application Server Development
IBM Hursley Lab, UK.
gordon_hutchison@xxxxxxxxxx
From: Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 09/05/2019 12:16
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
Um. Either my email was not clear or something got lost in translation.
I never suggested abandoning the Java EE code base, just the opposite. As for MicroProfile that could easily co-exist with Jakarta EE as a sanctioned Profile. No one would need to change anything.
On Wed, May 8, 2019 at 3:03 PM reza_rahman <reza_rahman@xxxxxxxxx> wrote:
Thank you Richard for chiming in. The objective evidence that I have seen aligns with the idea of creating at least one new profile focused on microservices.
It is not like the idea of just discountinuing with Jakarta EE and focusing on MicroProfile is all that unexpected. Most of us that have been closely watching the MicroProfile personas have seen this coming for months.
That hypothesis deserves an attempt at validation so I did test it to the best of my abilities. The peoblem is that it resonates with as few as 5-10% of the community. It is not just the Twitter poll I am talking about here. I have been talking about this with the folks I trust the most - all of whom are real world Java EE users - for a while now. As many as 60% want MicroProfile folded into Jakarta EE ASAP - with the introduction of a Jakarta EE incubator status that relaxes procedural and transparency rigours temporarily. This is actually the 100% view with the folks I know as opposed to the folks I have polled.
As Ryan has tried to tell you already, any position that states Jakarta EE is legacy and we should focus on something else is potentially disastrous for everyone here. Our detractors will take this opportunity to tell people to move to their platform while we are "still trying to figure it out".
This is especially true for Servlet. What we should be doing instead is creating an alternative set of additional APIs within Servlet that has reactive features. The minority that actually needs such features can opt in to those APIs while still sticking with their same Servlet containers instead of moving to something else. There is a good possibility that something will not be "vertx" but something no one here is aligned with.
Please choose wisely. What comforts me is that the working group is based on simple majority rather than consensus. I am still hopeful sanity will prevail after of initial kneejerk overreacton.
Being handed a monkey wrench by a bunch of overzealous lawyers is not nice. I get it. You guys are smart enough to handle it. Do not hit auto destruct on things that pay your salaries in favor of something new that may or may not.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
Date: 5/8/19 10:55 PM (GMT+08:00)
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Like many of you, I have been in this industry for decades now (25 years and counting) and I cannot help but believe that entirely new, unexpected ways of doing Enterprise Computing will emerge in the decades to come, and each will challenge whatever is the Jakarta EE platform is at the time.
tl;dr (aka The skinny)
The answer to the ever-evolving EE is Profiles. Do not define Jakarta EE as one monolithic platform that continues to grow. Instead, define it as a small core, Java SE and maybe something else, around which a plethora of profiles can be defined all of which work well with the core and therefore each other.
The long version
The Jakarta EE platform, whatever it is at any given time, must be flexible enough to allow end-users to adopt innovations and drop old technologies with very little modification to existing systems. Accommodating all the changes to come is impossible when the "platform" concept claims the mind-share. You can't define an entire platform and expect it to remain, in its entirety, relevant forever.
I think the only answer to this dilemma is the concept of a Profile - or at least what I believe are profiles. A profile is to me, a set of APIs that have been gathered together and used to accomplish some domain-specific objective. The Web profile, while not a pure profile in the sense I'm talking about, is one example. It allowed vendors more flexibility as well as end-users.
A better way forward might be to think of Jakarta EE as many things rather than just one monolithic thing. As long as there is a core, and in my mind that is at least Java SE, that remains stable, Jakarta EE can be whatever it needs to be. That means it can be something new, but it can also be something old or some mix of both.
Take the current Java EE platform. It's actually composed of many different technologies including EJB, Servlets/JSPs, JNDI, JMS, concurrency, CDI, etc. The platform ensures that they work well together, It is the glue. The same is true of a Profile, but in terms of perception, a Profile is far more composable as well as ephemeral than a Platform.
Now, think of Jakarta EE not as a platform in the sense that Java EE is a platform, but as a collection of optional profiles. As long as the Profiles always work with the core, you can use any combination of those Profiles you want. For example, if all you want is JMS and MDBs you should be able to buy a Jakarta EE platform with those two profiles and nothing else. Another example, what if you want JSF, JDO and CDI and nothing else.
If we think of Jakarta EE as one single entangled platform, we will never be free of the conundrum of advancing the platform without leaving folks behind. If, however, we develop every Profile so that its composable with a core and therefore any other Profile we start to see a platform that can evolve, be standardized, and remain backward compatible. If you are using an older version of JSP or EJB or whatever, you should always be able to combine that older profile with new profiles to create a platform that makes sense to your organization at any given time. As new profiles are introduced you should be able to add them to an existing system without having to do an upgrade of other aspects of your platform. The platform is whatever you need it to be. More precisely the Platform is an umbrella for a range of Profiles that are guaranteed to work together no matter what the combination.
The way to handle Java EE is to consider it a Profile rather than a platform. It's a big profile, no doubt, but a profile none the less. Call it Jakarta EE Classic if "Legacy" is a marketing issue. Now define a core for Jakarta EE based on Java SE and perhaps something else that will not remain stable for at least 20 years and you can start adding new profiles to the system that can work independently, with other new profiles, or in concert with the existing Classic (Java EE ) profile.
On Wed, May 8, 2019 at 8:00 AM Mark Little <markclittle@xxxxxxxxx> wrote:
This is good input though I don't think anywhere near enough to actually argue that the specifications need to change, especially when we hear from spec leads that they haven't had much (any?) requests to evolve quite a few of these specifications over the past few years and in fact that evolving some of them may be better done through starting entirely new specifications. Take transactions, for instance: JTA is fine for its use cases but I wouldn't want to evolve that for weak consistency transaction models or to incorporate true nested transaction semantics because that's just far too much effort to ensure backwards compatibility. Far better to create a new spec which focusses on those use cases.
Let me try to be clearer too: I'm not suggesting specifications shouldn't be evolved. I'm putting a case for where they could be evolved which isn't necessarily Jakarta EE.
I think I saw someone suggest that we create a "legacy" profile with Jakarta EE (let's call it Java EE8 for this example) where the existing javax code would reside, and a new profile (let's call it Cloud Native) where new efforts happen. I think that could work if, say, MicroProfile became the basis of that Cloud Native profile and the communities come together behind it. I've said this a number of times but will repeat, but one of my biggest concerns is fracturing of the efforts going forward.
Mark.
On Wed, May 8, 2019 at 3:03 AM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
I completely agree with the perspective that a majority of Java EE APIs - especially the ones moving forward - definitely need further evolving. Just from the top of my head, I can mention the following:
* WebSocket -> Java SE alignment
* JSON-B -> JSON schema support
* JSON-P -> JSON schema support
* Servlet -> Reactive support
* JSF -> Cleanup and cruft removal
* Batch -> Adding Java configuration support, various enhancements
* Concurrency -> Java SE alignment, adding replacements to EJB functionality
* EJB -> Java SE alignment
* JPA -> Reactive support, various long pending enhancements
* JMS -> CDI based message listeners, AMPQ support, Kafka compatibility, bootstrap API
* JavaMail -> Java SE alignment, higher level JMS 2 style usability API
* JAX-RS -> CDI alignment, various long pending enhancements, NIO support
* Security -> Many important pending enhancements, most important of which is JWT support
Frankly I could go on. It is an amazingly short-sighted and improbable proposition that the millions of developers of these heavily used APIs do not need for them to evolve further in order to serve the ecosystem. Not evolving these is a recipe for getting into a hopeless fragmentation of proprietary and incompatible half-baked extensions.
On 5/7/2019 9:53 PM, Steve Millidge (Payara) wrote:
OK fair point.
Therefore the fundamental question is not “How and When” but What will evolve?
So maybe the first step to answering the “what” is to go through each Java EE spec and give it a rating as to whether it will likely evolve in the future?
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Mark Little
Sent: 07 May 2019 13:18
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Our starting assumptions are clearly not the same.
On Tue, 7 May 2019 at 07:23, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
The problem is, if you assume that the majority of Jakarta EE apis have a future and therefore need to evolve, then the namespace change has to occur. You are therefore already in a cluster fsck.
Big Bang or incremental is not actually an irreversible decision.
If you start with the strategic goal that you are moving everything then it is possible to row back from that a little tactically at the individual spec level and platform level based on new knowledge as the process continues.
If you start with the strategic goal that the impact of migrating each individual api needs to be individually assessed before making a decision then you are likely heading into analysis paralysis.
Steve
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Mark Little
Sent: 07 May 2019 12:05
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
As Greg said in an earlier response, we shouldn't underestimate the effort this Big Bang will take and everyone involved in either the development of a Java EE application server, a component of one(s) or someone leading one of the Jakarta EE specifications, should be requested to go and figure out the answer. What seems simple at the high level could become a complete cluster fcuk when examined in detail and given what the UK is still going through with Brexit (yeah, I know!) I'd rather we made a decision based on all of the data so no one is surprised the day after the agreement is made and work has to start. We've spent 18+ months on Jakarta EE so far and adding a few more weeks to a deadline isn't going to represent much of an extension to that but could help us all in the end.
Mark.
On Tue, May 7, 2019 at 6:48 AM David Heffelfinger <dheffelfinger@xxxxxxxxx> wrote:
I like the first proposal ("Big Bang"), I would propose we move everything, leaving some APIs under javax because they are unlikely to change unnecessarily ties our hands, in case we do need to change something in them in the future.
My 2 cents.
David
On Mon, May 6, 2019 at 7:23 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
[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 javax namespace 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 javax would 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 javax to jakarta change 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 javax namespace 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 jakarta namespace from entering the ecosystem by requiring they also implement an equivalent javax legacy API.
- There is no intention to change Jakarta EE 8 goals or timeline.
- Community discussion on how to transition to the jakarta namespace 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 javax namespace to the jakarta namespace 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.
Pros:
- Some or all Jakarta EE APIs under javax would move immediately into jakarta as-is.
- Any packages not moved from javax to jakarta could be included in Jakarta EE, but would be forever frozen and never move to the jakarta namespace.
- Jakarta EE 9 would be refocused as quick, stepping-stone release, identical to Jakarta EE 8 with the exception of the javax to jakarta namespace 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.
Cons:
- 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 javax to jakarta Maven 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.
Decisions:
- 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.
- 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 javax to the jakarta namespace 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 javax to jakarta namespace transition.
Pros:
- The most active APIs would immediately move from javax to 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 javax and jakarta packaged APIs
- If a change was needed to a javax API post Jakarta EE 9 for any reason, that API would transition from javax to jakarta.
- Jakarta EE 10 would be a mix of javax and jakarta packaged 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 javax to jakarta is “done” and the final APIs are moved.
Cons:
- 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.
Decisions:
- 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 javax namespace 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 javax or jakarta in Jakarta EE 11?”
- Difficulty in keeping the industry in sync.
- New implementations may find themselves having to deal with the javax to jakarta transition, 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
Out of Scope
- Do we start small or start large?
- Which APIs would immediately need to be changed?
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
--
http://ensode.net - A Guide to Java, Linux and Other Technology Topics
My Books: https://www.packtpub.com/books/info/authors/david-r-heffelfinger
My Video Training: http://www.packtpub.com/java-ee-development-with-netbeans-7/video
Follow me on Twitter: https://twitter.com/ensode
_______________________________________________
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
--
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.tomitribe.com/_______________________________________________
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
--
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.tomitribe.com/_______________________________________________
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
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