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.”
No comments:
Post a Comment