Best practices for OpenJDK 8 updates

[Andrew Haley]

Best practices for OpenJDK 8 updates
====================================

Where we are
------------

OpenJDK 8 is a mature project, well into its middle age. As time
passes, OpenJDK 8 inevitably diverges from mainline OpenJDK
development, and back-porting patches becomes increasingly
difficult. However, we expect to continue to maintain it in some form
for years to come.

Also, back-porting patches becomes not only difficult but increasingly
risky: subsystems are redesigned, and the assumptions on which a patch
to mainline was based are less likely to apply to OpenJDK 8. It may
not be apparent to a back-porting engineer that a patch is
inappropriate.

People still using OpenJDK 8 deserve, above all else, to know that it
will continue to work for their application. Guaranteeing this for
certain is beyond the state of the art, not least because some Java
code makes assumptions that are not guaranteed by the Java
Specification. Nonetheless, we try to keep everything working.

So, the question arises: what patches are appropriate for back-porting
to OpenJDK 8u, and how should that back-porting be done?

[OpenJDK 11 is not yet at this stage in its life cycle, but it will be
before very long.]

What kinds of patches should be back-ported?
--------------------------------------------

Bug fixes may be back-ported if they fix a significant customer-
visible bug. So, a bug that caused an incorrect result to be returned
from a standard method would generally be accepted. However, a bug
that could only have an effect if the user specified arcane -XX:
options on the Java command line probably wouldn't be. Most bugs are
somewhat in between these extremes, so it's necessary to make
judgment calls; it was ever thus.

We must also consider the complexity of the patch to be back-ported.
A thousand-line patch for a minor bug that is unlikely to cause
problems in real-world use is unlikely to be accepted. It is always
appropriate for an engineer working on back-ports to decide that a
patch is too risky.

Bug fixes for parity with Oracle's proprietary releases are generally
acceptable because our users look at a release version number and
expect it to behave in much the same way that the Oracle release of
the same number does. However, even then we should look long and hard
at marginal cases that, for example, touch sensitive parts of HotSpot.

New features should not generally be back-ported to 8u, except where
it is necessary to adapt OpenJDK to new computing environments. For
example, new crypto algorithms might qualify, as might ports to new
hardware or operating systems. These are necessary for JDK 8u to
remain relevant.

Having said that, in some rare cases we might decide that a feature
back-port is sufficiently important to our target audience that we'll
do it anyway.  Such decisions must be discussed in the public list in
order to achieve a broad consensus, and must be signed off by the
Project Lead.

More testing is always good. Additional tests and improvements to the
test infrastructure are welcome, as long as they don't require
significant changes to the project being tested.

Security backports should almost always be accepted.

What form should back-ported patches take?
------------------------------------------

In general, back-ported patches should be minimal. This reduces the
amount of churn in the source code, itself a very important
consideration.

This guideline has some consequences. If a patch to be back-ported
depends on some earlier patches applied to mainline (as is
increasingly likely as time passes) it is not appropriate to pull in
the earlier patches as dependencies unless those patches also fix a
significant bug, or are certain to be needed by several other patches
for significant bugs. It is almost always better to re-work a patch in
order to reduce its complexity, even if that causes it to diverge from
mainline. It may sometimes be appropriate to work around the problem
in an entirely different way, if that reduces the complexity (and
risk) of the patch.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671