|
I too find it very hard to believe a majority of Java EE
specifications would not need to evolve. If nothing else, they
need to absorb innovations from Java SE. Indeed we are barely done
even adopting the changes from Java SE 8 across most Java EE
specifications!
On 5/8/2019 2:04 PM, Rudy De Busscher
wrote:
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
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
_______________________________________________
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
|
