OpenJDK Updates Project Builds

[Dalibor Topic]

On 15.04.2019 16:19, Severin Gehwolf wrote:

 >> I hope this will improve in the future. Maybe 8u212 from Oracle
 >> will release April 16 in GMT. I concern that the build might be
 >> different from your builds. Do you have any idea?
 >
 > We are trying to match Oracle JDK with our OpenJDK releases as much
 > as possible.

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.

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.

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.

* 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.

* 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.

For example, as OpenJFX contributors have moved on to newer releases 
decoupled from the JDK, there are no OpenJDK contributors left willing 
to maintain OpenJFX 8 further. Relying on OpenJDK 8 updates as a runtime 
for JavaFX applications could therefore become a challenge going forward.

* Different organizations may make different technological evolution 
choices.

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.

Those two approaches are obviously mutually exclusive.

cheers,
dalibor topic


-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | D-22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment