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.
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx> Date:
04:15 PM Subject:
[jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace Sent
This is a really great perspective. I
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
If we look at the changes between Java 8 and 11, we ultimately have this
- 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.