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

Wow!  This never really occurred to me but if you did a big bang than 3rd parties would need a lot of time to make the adjustments and having only a namespace to contend with is probably much less of a burdon. Thanks for pointing that out its a perspective I had not thought about.

On Tue, May 7, 2019 at 3:27 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
> 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


--

Back to the top