I'm going the other way. I started off thinking that incremental and taking the opportunity to prune and renew would be best....
But in consideration, I feel that renaming + pruning + renewing is just too big a step for non trivial deployments to make in one step. Moreover, just because we change the name space for not absolve is from the responsibility of backwards binary compatibility, no matter how much pruning and renewing is desirable.
So now I favour a big bang in EE9. We will continue to need to support EE8, first in existing container versions, then in binary compatibility modes, and also in byte code and source code translation tools. We have to to that regardless.
Then in EE9, we can continue to refine, enhance our even revolutionise our services. Sure we will have the detritus of decades in the namespace, but we need that anyway for binary compatibility translation targets the moment we do any non trivial change or clarification to the API. The namespace is infinite, so if we want to renew, there is space for new APIs along side deprecated old APIs.
What Big Bang gives us is to avoid the dilemma of not making a needed change to an API because that would trigger the incremental rename.
However, I don't think incremental would be that bad either, because I expect many APIs are in need of changes that will trigger a rename anyway... So EE9 will be a large bang no matter what.
Maybe we should have a third option of large bang. In EE9 rename all APIs that are changing our likely to need to change in the short to mid term. Leave unchanged only those APIs for which there is no prospect of a triggering change in the next few years. This may be a vanishing small subset?
Tl;dr; I don't think it matters much either way, but I lean towards a large to big bang.
Cheers
I may be imagining
this but while the early community reactions seemed more in favour of a
BB approach, I'm hearing increasing acceptance (some of it reluctant) in
Incremental being a less worse option than Big Bang. As one of the container-providers
Ryan mentions (Liberty in my case), I'm confident we can make either approach
technically work with backward compatibility for older apps in the future
alongside new packages for new versions of the specs. But emotionally,
for the health of a hugely well-deployed enterprise Java platform as well
as newer technologies that already extend it outside the javax names (like
MicpoProfile), breaking packages that don't need to be broken may look
like vandalism to some.
I doubt anyone
believes we will ever have a complete community consensus on the better
way forward so we'll have to make do with a discernible preference when
it emerges. At this point in time this might be BB but I suspect it is
trending towards Incremental. While its true that Incremental could end
up being seen as "death by 1000 cuts", projects like MicroProfile
have made a pretty decent success (as mentioned in another thread by Emily)
of building new value on top of existing specs (for example the MP REST
Client) without changing the underlying spec. That approach only goes so
far but it demonstrates perfectly well that app devs have no problem including
both javax and (for example) micropropfile packages in what is essentially
an extension to a single technology. Certainly, if there is a swing of
preference from BB to Incremental, we can't come back from BB.
Jakarta EE 9 needs
to prune stuff we don't expect to take forward and removal is not an issue.
But when we consider what is left, if it could just work (because we didn't
break javax) then I'd rather defend that to a Jakarta EE project member
than explain to a customer who has a ton of critical apps why they needn't
worry about the additional bytecode modification (or whatever BB-mitigating
strategy is taken) being applied to all their apps.
Regards,
Ian
From:
Ryan
Cuprak <rcuprak@xxxxxxxxx>
To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:
17/05/2019
20:40
Subject:
Re:
[jakartaee-platform-dev] Support for the Incremental approach to Jakarta
EE package renaming
Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
While tooling can rename packages,
the bigger problem is the third part libraries which an application depends
upon. For example, say I am using version 3 of a hypothetical JSF component
framework. The application has been in mostly maintenance for years. The
Big Bang approach is taken by the community. A business change comes in
and the application needs to run on Jakarta EE 9. Now the application will
be confronted with one of at least two scenarios:
1. JSF library may no longer be
supported and there be no hope of getting it ported to Jakarta EE 9. (Maybe
better ways of implementing the application but they may not be business
justifiable).
2. JSF library may have switched
to supporting Jakarta EE 9 with the rename, however, the library has evolved
and isn’t backwards compatible. Parts of the application need to be rewritten
and re-tested.
I picked on JSF because in years past
I have discovered that not keeping up with third party JSF library releases
can cause problems. For going from Java EE 6 to 7 on one project required
an upgrade of a library due to an incompatibility with EE 7. This simple
upgrade required changes to every page in the application. RARs for things
like ActiveMQ might also cause a problem (I believe they still aren’t
supporting stuff added in EE 7?).
Personally I like the big bang approach
but I think there needs to be a transition longer transition period for
all the implementations to catch-up. I am also concerned that right now
everyone is trying to get past Java SE 8 (to 11, 12, etc.) so this is the
wrong time for a big bang change. Some applications might be forced to
upgrade to Jakarta EE 9 because Java licensing and support issues - say
the application container needs to be upgraded to run on Java 11 because
8 is so far out of support. Third party library from EE 8 doesn’t run
on Java SE 12 but the newest version that runs on Java 13 has all the package
names renamed.
The thing I’d like to hear, what do
the container implementors think? How long will it take for WildFly, Liberty,
Websphere, Payara, WebLogic, TomEE, etc. to support Jakarta and have backward
compatibility for legacy applications? How long will it take IceFaces,
PrimeFaces, etc. to make the transition? How long will it take Arquillian
and its suite to catch-up?
-Ryan
On May 17, 2019, at 2:45 PM, Rudy De
Busscher <rdebusscher@xxxxxxxxx>
wrote:
Hi BJ,
I do
not agree with your conclusion. With the help of some tooling, the renaming
can be done swiftly and existing programs will run on Jakarta EE 9.
What
is true, is the fact that the Big Bang has no technical value. But with
an incremental approach, developers will need to adapt their application
with each release of Jakarta EE. Because a few specs will be changed in
Jakarta EE 9, a few more in Jakarta EE 10, and so on.
And when
specs are using still the old package name, is the community then prepared
to change the package name for a small improvement? Or will the end result
be; "nah leave it as it is, we will use a workaround." And thus
not having any real investment in it anymore?
Also
important to consider is the fact that this package name change is much
larger than just Jakarta EE. Will a developer, after he already went over
the application and changed some package names two times, do it for a third
time? Or will he just choose another language? The chosen approach will
affect the complete Java and JVM ecosystem!
Rudy
On Fri, 17 May 2019 at 20:12, Kevin Sutter
<kwsutter@xxxxxxxxx>
wrote:
Thanks, BJ, fir your excellent insights.
Definitely some things to consider as we go forward.
-- Kevin
On Fri, May 17, 2019, 12:16 BJ Hargrave
<hargrave@xxxxxxxxxx>
wrote:
I have posted my thoughts
at https://blog.hargrave.io/2019/05/jakarta-ee-and-package-renaming.html
and include a copy of the post below.
======
Eclipse Jakarta EE
has been placed in the position that it may not evolve the enterprise APIs
under their existing package names. That is, the package names starting
with `java` or `javax`. See Update
on Jakarta EE Rights to Java Trademarks
for the background on how we arrived at this state.
So this means that
after Jakarta EE 8 (which is API identical to Java EE 8 from which it descends),
whenever an API in Jakarta EE is to be updated for a new specification
version, the package names used by the API must be renamed away from `java`
or `javax`. (Note: some other things will also need to be renamed such
as system property names, property file names, and XML schema namespaces
if those things start with `java` or `javax`. For example, the property
file `META-INF/services/javax.persistence.PersistenceProvider`.) But this
also means that if an API does not need to be changed, then it is free
to remain in its current package names. Only a change to the signature
of a package, that is, adding or removing types in the package or adding
or removing members in the existing types in the package, will require
a name change to the package.
There has been much
discussion on the Jakarta EE mail lists and in blogs about what to do given
the above constraint and David Blevins has kindly summed up the two main
choices being discussed by the Jakarta EE Specification Committee: https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html.
In a nutshell, the
two main choices are (1) “Big Bang” and (2) Incremental. Big Bang says:
Let’s rename all the packages in all the Jakarta EE specifications all
at once for the Jakarta EE release after Jakarta EE 8. Incremental says:
Let’s rename packages only when necessary such as when, in the normal
course of specification innovation, a Jakarta EE specification project
wants to update its API.
I would like to argue
that Jakarta EE should chose the Incremental option.
Big Bang has no technical
value and large, up-front community costs.
The names of the packages
are of little technical value in and of themselves. They just need to be
unique and descriptive to programmers. In source code, developers almost
never see the package names. They are generally in `import` statements
at the top of the source file and most IDEs kindly collapse the view of
the import statements so they are not “in the way” of the developer.
So, a developer will generally not really know or care if the Jakarta EE
API being used in the source code is a mix of package names starting with
`java` or `javax`, unchanged since Jakarta EE 8, and updated API with package
names starting with `jakarta`. That is, there is little mental cost to
such a mixture. The Jakarta EE 8 API are already spread across many, many
package names and developers can easily deal with this. That some will
start with `java` or `javax` and some with `jakarta` is largely irrelevant
to a developer. The developer mostly works with type and member names which
are not subject to the package rename problem.
But once source code
is compiled into class files, packaged into artifacts, and distributed
to repositories, the package names are baked in to the artifacts and play
an important role in interoperation between artifacts: binary compatibility.
Modern Java applications generally include many 3rd party open
source artifacts from public repositories such as Maven Central and there
are many such artifacts in Maven Central which use the current package
names. If Jakarta EE 9 were to rename all packages, then the corpus of
existing artifacts is no longer usable in Jakarta EE 9 and later. At least
not without some technical “magic” in builds, deployments, and/or runtimes
to attempt to rename package references on-the-fly. Such magic may be incomplete
and will break jar signatures and will complicate builds and tool chains.
It will not be transparent.
Jakarta EE must minimize
the inflection point/blast radius on the Java community caused by the undesired
constraint to rename packages if they are changed. The larger the inflection
point, the more reason you give to developers to consider alternatives
to Jakarta EE and to Java in general. The Incremental approach minimizes
the inflection point providing an evolutionary approach to the package
naming changes rather than the revolutionary approach of the Big Bang.
Some Jakarta EE specification
may never be updated. They have long been stable in the Java EE world and
will likely remain so in Jakarta EE. So why rename their packages? The
Big Bang proposal even recognizes this by indicating that some specification
will be “frozen” in their current package names. But, of course, there
is the possibility that one day, Jakarta EE will want to update a frozen
specification. And then the package names will need to be changed. The
Incremental approach takes this approach to all Jakarta EE specifications.
Only rename packages when absolutely necessary to minimize the impact on
the Java community.
Renaming packages incrementally,
as needed, does not reduce the freedom of action for Jakarta EE to innovate.
It is just a necessary part of the first innovation of a Jakarta EE specification.
A Big Bang approach
does not remove the need to run existing applications on earlier platform
versions. It increases the burden on customers since they must update
all parts of their application for the complete package renaming when the
need to access a new innovation in a single updated Jakarta EE specification
when none of the other Jakarta EE specifications they use have any new
innovations. Just package renames for no technical reason. It also
puts a large burden on all application server vendors. Rather than having
to update parts of their implementations to support the package name changes
of a Jakarta EE specification when the specification is updated for some
new innovation, they must spend a lot of resources to support both old
and new packages name for the implementations of all Jakarta EE specifications.
There are some arguments
in favor of a Big Bang approach. It “gets the job done” once and for
all and for new specifications and implementations the old `java` or `javax`
package names will fade from collective memories. In addition, the requirement
to use a certified Java SE implementation licensed by Oracle to claim compliance
with Eclipse Jakarta EE evaporates once there are no longer any `java`
or `javax` package names in a Jakarta EE specification. However, these
arguments do not seem sufficient motivation to disrupt the ability of all
existing applications to run on a future Jakarta EE 9 platform.
In general, lazy evaluation
is a good strategy in programming. Don’t do a thing until the thing needs
to be done. We should apply that strategy in Jakarta EE to package renaming
and take the Incremental approach. Finally, I am reminded of Æsop’s fable,
The
Tortoise & the Hare.
“The race is not always to the swift.”
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargrave@xxxxxxxxxx
_______________________________________________
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
_______________________________________________
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