[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
- From: reza_rahman <reza_rahman@xxxxxxxxx>
- Date: Wed, 08 May 2019 05:14:46 +0800
- Delivered-to: email@example.com
- Importance: normal
- Savedfromemail: firstname.lastname@example.org
This is a really great perspective. I totally agree.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
> On May 7, 2019, at 12:09 PM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:
-------- 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
> 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.
jakartaee-platform-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit