Date: Fri, 29 Mar 2024 12:41:49 +0000 (UTC) Message-ID: <1253729314.1349.1711716109975@34fc92c9345b> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1348_1608345545.1711716109975" ------=_Part_1348_1608345545.1711716109975 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
OpenJDK 8 is a long-term stable release = of OpenJDK. Our primary goal is to maintain it, fixing significant bugs and= especially security problems as we go along. The "first, do no harm" princ= iple applies: we must not break things.
In general we'll use the process in https://openjdk.java.net/projects/jdk-updates/app= roval.html.
All fixes that significantly improve stability, = security or performance and do not change behavioural compatibility [1]will= be considered for jdk8u. To use the language of the JDK 6 project, by defa= ult such fixes are assumed to be applicable to jdk8u, especially if having = "soaked" in later JDK releases for a time without incident. By "significant= " I mean any bug that affects runtime behaviour in a way that either produc= es incorrect results, poor performance, or crashes the VM, especially TCK f= ailures. Failures that are due solely to bizarre or unreasonable combinatio= ns of -XX: command-line parameters probably don't reach the bar of signific= ance, and fixing them will carry a non-zero risk of breaking something, so = we should err on the size of caution. For now it's mostly "bug fixes only".=
Build failures on all platforms, including 32-bi= t ones, are assumed to be applicable. Also, there is a good deal of C++ cod= e with Undefined Behaviour in HotSpot, and such bugs tend to cause failures= with more recent C++ compilers. While all UB fixes may be applied to jdk8u= , they should be submitted to the current jdk development tree first.
Occasionally we might have to make changes which= raise compatibility issues. We will liaise with the Compatibility & Sp= ecification Review (CSR) Group.
We have two active trees, = http://hg.openjdk.java.net/jdk8u/jdk8u and http:/= /hg.openjdk.java.net/jdk8u/jdk8u-dev. jdk8u-dev is always open to all c= ontributors, and that's where everyone should push their patches after main= tainer approval. Patches pushed to jdk8u-dev will be copied to jdk8u at reg= ular intervals. When the time comes for an update release, jdk8u will be cl= osed for testing and stabilization. From that point onward only critical bu= g fixes may be applied to jdk8u, at the discretion of the maintainers.
To request maintainer approval for a backport, t= ag your entry in the bug database with "jdk8u-fix-request"= . A maintainer will reply by either tagging the bug entry with "jdk= 8u-fix-yes" or "jdk8u-fix-no".
Once a quarter, we will snapshot the jdk8u tree = and prepare a Critical Patch Update (CPU) release. Once the snapshot has be= en taken the engineers working on the CPU will work in the dark, sharing th= e patches with only the OpenJDK Vulnerability Group. Any patches not commit= ted to jdk8u at the time of the snapshot will probably have to wait for a l= ater release. [I don't propose to make any non-CPU releases: one release a = quarter should be quite enough for jdk8u. However, if an urgent problem ari= ses we might need to make an intermediate release.]
Having said all of that, there is considerable c= ustomer demand for backports of features from later OpenJDK releases. I don= 't intend to forbid such backports, but strict rules will apply. Features w= hich apply to ports in jdk8u must have the property that they can be disabl= ed altogether by the use of a command-line switch. This switch should turn = the feature into a NOP, so that it does not affect the rest of the system i= n any way. Reviewers should ensure that every hunk in such a changeset is g= uarded by an if (Feature_enabled) statement or something similar. This will= also allow Feature_enabled to be made a compile-time constant, and if set = to false this will allow images to be created without the feature.
With regard to the likely feature backports, the= re are several possibilities, in particular the Java Flight Recorder (JFR).= There is a tree http://hg.openjdk.java.net= /jdk8u/jdk8u-jfr-incubator/ for this work. Patches to this tree must be= approved in the usual way, with an RFR email to the jdk8u-dev mailing list= .
[1] https://blogs.oracle.com/darcy/kinds-of-compatibility= :-source,-binary,-and-behavioral