OpenJDK Updates Project Builds

[Andrew Dinn]

On 16/04/2019 18:31, Dalibor Topic wrote:
> Fwiw, the functional equivalence between Oracle JDK and OpenJDK only
> started with JDK 11, and holds only for as long as Oracle maintains a
> particular update series (i.e. at least six months).
> 
> Once Oracle stops participating, other developers still developing the
> updates in OpenJDK may and typically will make their own, often
> different decisions about the timing, scope and suitability of features,
> enhancements and bug fixes to include in the 'OpenJDK updates' source
> code going forward, so functional equivalence should not be expected.

Just to be clear, can I take it that you are only talking about
difference between Oracle's proprietary JDK11u releases and the common
feature set used in all subsequent OpenJDK JDK11u update releases? Ditto
for JDK8u?

I ask that because your comment comes across to me as suggesting that
the different JDK11u release providers (Oracle excluded) are in some
danger of providing different feature sets in their releases of jdk11u.
I have to disagree. I have seen, and expect to continue to see, every
intention of avoiding such a state of disarray and disunity on the part
of all the providers still involved in working on JDK11u (Oracle being
exempt from that group).

> Historically, once Oracle stops participating in the development of an
> update release in OpenJDK, it tends to quickly become different from the
> Oracle JDK releases.

It is, of course, Oracle's legitimate choice to introduce such a
divergence for their proprietary builds. I think it is unfortunate they
would make such a choice rather than work with those still involved in
JDK11u to ensure consistency in all releases.

> There are multiple reasons for that:
> 
> * OpenJDK 8u source code is available under an open source license, so
> changes are possible and should be expected. Different organizations
> will prioritize different changes and work on different schedules.

Yet, it seems to me that all the organizations still involved in the
JDK8u project (Oracle exempted) are striving to avoid differences in
their OpenJDK releases and, where differences exist for historical
reasons, to upstream a common feature set into the open repos for all to
use. This seems to me to be the biggest priority that is driving the
jdk8u project, after back-porting security updates (naturally).

> * Considering that feature and bug fix differences already exist between
> various downstream builds of OpenJDK 8u outside of Oracle, and some of
> them contain dozens or more additional changes for various reasons, it's
> not really possible for them not to be different from Oracle JDK
> releases or from each other.

That may or may not be an accurate account of why any difference might
still be present. However, in my eyes at least, it does not justify the
rather blithe way in which you comtemplate and excuse Oracle introducing
/extra/ differences into new proprietary releases. Java is supposed to
be about write once run anywhere. By pursuing its own development path
in private, proprietary releases I feel that Oracle is prejudicing that
very important goal.

> * Different organizations may care about different sets of platforms and
> functionality. At Oracle, the set of supported platforms for Oracle JDK
> 8 is documented at
> https://www.oracle.com/technetwork/java/javase/certconfig-2095354.html .
> 
> The set of actively supported platforms within OpenJDK 8u may overlap in
> some ways, miss other platforms available in Oracle JDK, but on the
> other hand also add additional ones, depending on what the current
> configuration of contributors is at any given time.

Indeed Oracle has chosen only to address a subset of available platforms
and also configurations. As an example of the latter, Oracle, quite
legitimately, has chosen not to build the Shenandoah GC into their
releases. Given that Oracle's engineers had no part to play in creating,
and very little in maintaining, Shenandoah it is understandable that
they might wish to avoid incurring the liability of supporting that
capability in their releases. However, unfortunate as that is I still
suggest there is a difference in kind between that omission and the
action of /creating/ divergent behaviour on the same platform for the
same configuration and selected feature set.

> * Different organizations may make different technological evolution
> choices.

Indeed. Yet, the important point is that those currently involved in the
jdk8u and jdk11u projects are working to minimize the effect of such
choices on users. Of course, in all cases the TCK ensures a very large
degree of compatibility between Oracle's Java releases and the
corresponding OpenJDK releases so we are only talking about minor
discrepancies here. However, the continuing OpenJDK JKD11u and JDK8u
projects are certainly taking even such minor discrepancies very seriously.

> For example, a non-trivial part of the effort around updates is keeping
> HotSpot in great shape from one release to next. If an organization's
> focus is on reducing the amount of work they spend on backporting
> changes from later releases it might be appealing for them to move to
> later versions of HotSpot, adjusting the code in the process to work
> within the context of the Java SE 8 specification and users'
> expectations (such as handling removed VM flags, for example).

> On the other hand, if their priority is to provide a stable HotSpot
> platform with similar behavioral characteristics between releases,
> they'll try to minimize the amount of changes.

The cost of backporting is one reason why all those currently involved
the JDK11u and JDK8u projects have been working together on the latest
releases to ensure we all use common patches for any backports. To me
your presentation of the case belies that, suggesting that there is
disunity and competition here when in fact there is co-operation and
pooling of both resources and gains -- for us and for our users.

n.b. I don't claim to speak here on behalf of all those still involved
in the JDK11u or JDK8u projects, nor even on behalf of Red Hat. This is
just my personal response to things I found to ring false in your post.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander