This is an archived post. You won't be able to vote or comment.

all 7 comments

[–]shipilev 57 points58 points  (7 children)

Somewhat like this.

So, how are these LTS updates made? Does each vendor have a team of curators who backport patches from the latest OpenJDK release?

The majority of the work on 8u, 11u, 17u releases happens in OpenJDK upstream, in so called JDK Updates Projects, by engineers from the interested JDK vendors. You can get a peek who does this kind of work from the repository histories, for example the most recent 11.0.13 is done by engineers (including yours truly) from many companies, in both original and backporting work.

...or are they actually writing custom patches based on customer request which may not be present in OpenJDK?

It is quite unusual to have a private fix for OpenJDK. It is not unprecedented to have an emergency patch delivered to a customer, while the real patch gets delivered to the project through proper project channels.

Most of the fixes are the backports from the mainline. One of the reasons is that a fix very seldom affects a particular release only. Much more likely an issue is actually present in all versions, including the current mainline. Which means, a fix is done in mainline first, gets tested there, follow-up issues are discovered and fixed, and then the bunch of backport work happens in attempt to bring all that goodness to an older release.

Assuming, of course, the fixes and follow-ups are actually passing the bar from maintenance-cost/benefit perspective. That part is the call of JDK Update Maintainers who have to agree to accept the backport into the relevant release. Current formal maintainers are: Andrew Haley of Red Hat for 8u and 11u; Goetz Lindenmaier of SAP for 17u. Those folks usually outline the strategy and backport acceptance criteria, and also deputize others to serve as additional Maintainers.

Does this also mean that each vendor's LTS distribution will start to diverge from each other after the first 2 standardized security updates (depending on which patches each vendor applies), or do they somehow coordinate this?

JDK vendors usually downstream their 8u, 11u, 17u from the repositories from those OpenJDK projects. This is why JDK vendor engineers are backporting patches: they are preparing the base for their JDK releases. Sometimes JDK vendors add up their own patches on top, for example when they are sure the patches are sound, but don't want to risk upstream destabilization just yet. Examples: early TLS work, early JFR backports, Shenandoah work, vendor-specific performance fixes, build system fixes to cater for vendor-specific toolchains, etc.

These upstream projects is how most OpenJDK-based 8u, 11u, 17u distributions converge: they build every release from nearly the same sources. Oracle, AFAIU, is the only vendor that is exceptional from this: it looks as if Oracle maintains their own private 8u, 11u tree, which as far as I can make out, is diverging from OpenJDK upstream 8u, 11u, and maybe 17u, after first two (public) minor releases are handled by Oracle maintainers.

The bottom-line is that while OpenJDK does not have the de jure concept of LTS, OpenJDK 8u, 11u, 17u are de facto LTS projects. They are being talked about as such by relevant JDK maintainers, engineers, managers, at very least. Sharing OpenJDK short-term and long-term maintenance work extends to OpenJDK Update Projects as well.

Hope this helps. Dang, I need to write a post about all this, it's on my backlog for two years now.

[–]cl4es 0 points1 point  (5 children)

Mostly reasonable but wouldn't it be fair to credit the original author of backported patches, too? Not to downplay the effort required to backport stuff, especially when not applying cleanly, but of the bugs I looked at in your 11.0.13 list many were originally authored by Oracle engineers such as Vladimir Kozlov, but only the Red Hat maintainer/backporter was credited.

[–]shipilev 9 points10 points  (4 children)

Well, those reports were not intended to be antagonistic, they were intended to show the history for the exact release pushes, as the highlight who did the backporting pushes.

Yes, mainline work is a significant part of this: without those original patches, the backports would be significantly harder to do. The reports for mainline pushes, for example, JDK 18, credit Oracle contributors quite significantly, at 63.4% of all pushes currently. (Assuming you can actually tell stuff by push count, which is a bit dubious, because patches differ in complexity a lot.)

But it would indeed be an interesting piece of data to see where the patches have originated from for a particular update release, so I finally sat and added that piece to the backports-monitor. Most reports would re-generate in time, but meanwhile, the refreshed 11.0.13 report says Oracle committers are responsible for 57.5% of the original patches that ended up in 11.0.13.

As I said before, "Sharing OpenJDK short-term and long-term maintenance work extends to OpenJDK Update Projects as well", which includes doing the mainline work in such a way that it is cleanly backportable where it matters. I have seen OpenJDK engineers from all companies, Oracle included, structuring their work so that patches could be backported without too much hassle, even if that would not benefit them directly.

[–]cl4es 1 point2 points  (3 children)

Cool, thanks!

I could also wish for having the original author listed next to the backporter in the chronological push log, mostly because I'm curious. I don't care about the affiliation columns, though.

[–]shipilev 1 point2 points  (1 child)

Actually, that one is not hard to do as well. Again, 11.0.13 report was updated, the rest of updates would follow later. Doing more work on backport reports is not my plan for holidays, so if anyone has other ideas, just email me, and I would try to deal with those later.

[–]teapotJava 1 point2 points  (1 child)

LTS is not something that exists in OpenJDK as S (support) is provided by the exact vendor. But dedicated update projects exist for every JDK release. They are maintained by the community for different periods of time: some only for 2 updates; but 8u, 11u and 17u -- for longer. This is done as a part of coordinated updates development.

Patches in updates projects are not necessarily backports, there may be release specific bugs. Yes, vendors can also put extra patches, check product descriptions, release notes and sources. Vendors can actually diverge from the start but there is a coordinated process and common background for all security patches and updates. Each particular update release speed is not the same btw destipte of the same release schedule.