[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

Nathan,

>ÂWhat if we just keep the javax packages as they are and leave them alone, still fully part of Jakarta with each subsequent release? Full compatibility would be maintained. Enhancements could instead be made by parallel specs that introduce individual interfaces under jakarta.*, but only as needed.ÂÂ

I can hardly believe that one would not touch the javax.* classes ever in the future! Some of the parallel specs would need to introduce changes which are then not possible.
And renaming the packages at that point means that the renaming is spread out over many releases and many years. A sure recipe for the majority of the user base to abandon Java. (and not Jakarta EE only as this impact the whole Java ecosystem as pointed out by David)

Rudy

On Tue, 7 May 2019 at 23:57, Nathan Rauh <nathan.rauh@xxxxxxxxxx> wrote:
I'll start by pointing out that these are some of my own thoughts and do not represent any position on the part of my employer.

One of the really valuable parts of Java EE as a standard is the wide array of pluggable third party implementations that are available. I worry that if we put out a breaking spec change like package renames (you can't implement both interface variants under a single implementation class due to details like spec-defined concrete exception classes), that a number of third-party implementations will simply never update to jakarta, and applications will be torn between their dependencies vs taking advantage of improvements in other specs at newer levels. Many applications will stay behind as well, make attempts to mix different jakarta.* and javax.* technologies, or move away from Java altogether. Some providers/applications/vendors which have a desire to support both javax and jakarta will overcome the breaking changes, but will do so at the cost of increased footprint.

There is another option that should at least be considered. What if we just keep the javax packages as they are and leave them alone, still fully part of Jakarta with each subsequent release? Full compatibility would be maintained. ÂEnhancements could instead be made by parallel specs that introduce individual interfaces under jakarta.*, but only as needed. Completely new specs would of course be written under jakarta.*. Sure, there is some inconvenience here (extra imports for users, maybe a need for creative interface design in places, probably some unwanted limitations on changes that can be made). However, that may be a small price to pay to avoid all of the churn, confusion and trouble that would otherwise arise from having duplicate implementations per package name, existing probably indefinitely for as many of the third-party providers of resource adapters, JMS providers, JPA providers, JSON-P/B providers... and so on, as are willing to provide a jakarta.* variant.





From: Â Â Â Âreza_rahman <reza_rahman@xxxxxxxxx>
To: Â Â Â Âjakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: Â Â Â Â05/07/2019 04:15 PM
Subject: Â Â Â ÂRe: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Sent by: Â Â Â Âjakartaee-platform-dev-bounces@xxxxxxxxxxx




This is a really great perspective. I totally agree.

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

-------- Original message --------
From: David Blevins <dblevins@xxxxxxxxxxxxx>
Date: 5/8/19 4:27 AM (GMT+08:00)
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the  jakarta namespace

> On May 7, 2019, at 12:09 PM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:
>
> It's been a while since I was on the user side of the fence but it's hard for me to imagine companies would want to migrate to Jakarta EE 9 just for a namespace change from javax. to jakarta. Â (I think someone else made this point but I agree).

There's a key point we all need to acknowledge -- the primary consumer of a fast-release, namespace-only Jakarta EE 9 will not be end users (large customers). It's more likely to be libraries, third party tools and cloud platforms.

If we look at the changes between Java 8 and 11, we ultimately have this experience:

- Major Java language change

- Time for bytecode libraries like ASM to update their bytecode parsers

- Time for component libraries like Hibernate to update their ASM dependencies

- Time for framework implementations like TomEE, Wildfly, Spring to use the latest components

- Users now get to use full stack platforms

The result is a Java language version can take 2-3 years to reach some people before they can really use it.


Ultimately a quickly released namespace-only change is going to be a total yawn for most developers, but it will allow the rest of the industry to start paving the way so that when new features do show up, they roll right into the developers lap.

Things that need "paving" include:

- components themselves (Hibernate, MyFaces, etc)
- libraries and tools written on top of them (Primefaces, Jolokia, etc)
- server implementations (TomEE, Payara, GlassFish, Wildfly, OpenLiberty, etc)
- IDEs (Eclipse, Intellij, Netbeans, etc.)
- Cloud platforms (Microsoft, Amazon, Google, etc.)
- Monitoring tools (AppDynamics, NewRelic, Elastic APM, etc)

All the above have dependencies on each other which complicates things.

If we released a namespace-only changed in say November 2019, it would likely be June 2020 before the above roads are half-way "paved".

If we put the namespace change in with a set of new features, it would be a situation where the rest of the industry is having to catch up while consumers are breathing down their back, potentially complaining about bad tool support and how "everything is broken."

In many ways it's a huge advantage that a namespace-only release done very quickly would be a big yawn to most developers. Our ecosystem can be absorbing the namespace change while developers are happily distracted with the fun of creating new features.


-David

_______________________________________________
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