[SRU] Please provide openjdk-21 for focal, jammy and lunar

The attachment "adjust-bootjdk.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Jtreg test results:
Jammy

FAILED: sun/security/pkcs11/KeyStore/CertChainRemoval.java
https://bugs.openjdk.org/browse/JDK-8309214 (needs backport to 21 - requested)

Armhf: FAILED: java/io/File/GetXSpace.java
Runner issue (needs quarantine)
ARMHF: FAILED: serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java
https://bugs.openjdk.org/browse/JDK-8303168
Bad test, need to update quarantine patch
ARMF: FAILED: compiler/vectorization/runner/MultipleLoopsTest.java
Bad test, need to update quarantine patch

Armhf: FAILED: java/lang/ScopedValue/StressStackOverflow.java
https://bugs.openjdk.org/browse/JDK-8308609 (resolved in October patch)

S390x: FAILED: runtime/NMT/VirtualAllocCommitMerge.java
https://bugs.openjdk.org/browse/JDK-8309698 (in progress)

Focal:

FAILED: sun/security/pkcs11/KeyStore/CertChainRemoval.java
https://bugs.openjdk.org/browse/JDK-8309214 (needs backport to 21 - requested)

ARMHF: FAILED: serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java
https://bugs.openjdk.org/browse/JDK-8303168
Bad test, need to update quarantine patch

ARMHF: FAILED: compiler/vectorization/runner/MultipleLoopsTest.java
compiler.vectorization.runner.MultipleLoopsTest.reductionLoopWithAnotherReductionInput: Method is not compiled after 30s.
Intermittent runner timeout issue

Armhf: FAILED: java/lang/ScopedValue/StressStackOverflow.java
https://bugs.openjdk.org/browse/JDK-8308609 (resolved in October patch)

FAILED: runtime/NMT/VirtualAllocCommitMerge.java
https://bugs.openjdk.org/browse/JDK-8309698

Note: symlink /etc/localtime is being removed on purge by the package dependency
Note: Following files are left on system:
  /etc/timezone not owned
  /usr/local/share/fonts/ not owned
  /usr/local/share/fonts/.uuid not owned
  /usr/share/fonts/ owned by: fonts-dejavu-core
  /usr/share/fonts/.uuid not owned
  /usr/share/fonts/truetype/ owned by: fonts-dejavu-core
  /usr/share/fonts/truetype/.uuid not owned
  /usr/share/fonts/truetype/dejavu/ owned by: fonts-dejavu-core
  /usr/share/fonts/truetype/dejavu/.uuid not owned

Note: following files are left on system:
  /etc/timezone not owned
  /usr/local/share/fonts/ not owned
  /usr/local/share/fonts/.uuid not owned
  /usr/share/fonts/ owned by: fonts-dejavu-core
  /usr/share/fonts/.uuid not owned
  /usr/share/fonts/truetype/ owned by: fonts-dejavu-core
  /usr/share/fonts/truetype/.uuid not owned
  /usr/share/fonts/truetype/dejavu/ owned by: fonts-dejavu-core
  /usr/share/fonts/truetype/dejavu/.uuid not owned

Note: added block-proposed-jammy and block-proposed-focal tags for the bootstrap upload

Bootstrap build for Focal

Bootstrap build for Jammy

GA build for Focal

GA build for Jammy

In my opinion it should be backported also to Ubuntu 23.04, this is even a prerequisite for the backport to jammy and focal (see https://wiki.ubuntu.com/UbuntuBackports#Preparing_the_Backported_Package:~:text=so%20that%20version%202.x.y%20is%20usable%20in%20bionic%2C%20you%20must%20first%20backport%20that%20version%20to%20focal%2C%20so%20that%20upgrades%20from%20bionic%2Bbackport%20to%20focal%2Bbackports%20are%20covered)

Status changed to 'Confirmed' because the bug affects multiple users.

Lunar is currently building in PPA, I will update the bug with installation and jtreg test results after it finishes.

GA build for Lunar

Hi Vladimir,

I'm not particularly comfortable with disabling a whole range of tests for the toolchain in our stable releases. Have you looked into porting the testsuite onto the older GTest? It's probably not trivial, but who knows? ;)

Lunar JTREG test:

FAILED: sun/security/pkcs11/KeyStore/CertChainRemoval.java
https://bugs.openjdk.org/browse/JDK-8309214 (needs backport to 21 - requested)

Armhf: FAILED: java/io/File/GetXSpace.java
Runner issue, need to update quarantine patch
ARMHF: FAILED: serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java
https://bugs.openjdk.org/browse/JDK-8303168
Bad test, need to update quarantine patch
Armhf: FAILED: java/lang/ScopedValue/StressStackOverflow.java
https://bugs.openjdk.org/browse/JDK-8308609 (resolved in October patch)

S390x: FAILED: runtime/NMT/VirtualAllocCommitMerge.java
https://bugs.openjdk.org/browse/JDK-8309698 (in progress)

PPC64EL: FAILED: serviceability/attach/AttachNegativePidTest.java
execStatus=Failed. Execution failed\: `main' threw exception\: java.lang.NoClassDefFoundError\: jdk/test/lib/Utils
This appears to be a jtreg7 classpath issue, but a lot of other tests should've failed if it was the case: LP: #2037587 (Invalid).
The test passed with 1000 repetitions in ppc64el vm.

Hi Simon,
Yes, I did look into it - the issue is compile errors with TEST_F() macros:
----
/<<PKGBUILDDIR>>/test/hotspot/gtest/classfile/test_AltHashing.cpp:139:24: error: 'halfsiphash_test_ByteArray' has not been declared
  139 | TEST_F(AltHashingTest, halfsiphash_test_ByteArray) {
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/test/hotspot/gtest/classfile/test_AltHashing.cpp:139:1: error: ISO C++ forbids declaration of 'TEST_F' with no type [-fpermissive]
  139 | TEST_F(AltHashingTest, halfsiphash_test_ByteArray) {
      | ^~~~~~
/<<PKGBUILDDIR>>/test/hotspot/gtest/classfile/test_AltHashing.cpp:139:50: error: cannot declare parameter to be of abstract type 'AltHashingTest'
  139 | TEST_F(AltHashingTest, halfsiphash_test_ByteArray) {
      | ^
/<<PKGBUILDDIR>>/test/hotspot/gtest/classfile/test_AltHashing.cpp:30:7: note: because the following virtual functions are pure within 'AltHashingTest':
   30 | class AltHashingTest : public ::testing::Test {
      | ^~~~~~~~~~~~~~
In file included from /usr/src/googletest/googlemock/include/gmock/internal/gmock-internal-utils.h:47,
                 from /usr/src/googletest/googlemock/include/gmock/gmock-actions.h:145,
                 from /usr/src/googletest/googlemock/include/gmock/gmock.h:59,
                 from /<<PKGBUILDDIR>>/test/hotspot/gtest/unittest.hpp:52,
                 from /<<PKGBUILDDIR>>/test/hotspot/gtest/classfile/test_AltHashing.cpp:28:
/usr/src/googletest/googletest/include/gtest/gtest.h:494:16: note: 'virtual void testing::Test::TestBody()'
  494 | virtual void TestBody() = 0;

-----
that only happens with 1.11. Earlier (focal) and later (lunar) versions are not affected. Looks like a combination of toolchain/gtest that are not compatible[1].

I believe going forward we will bundle google test and will not have this problem.

Note: this is a common problem for openjdk-17 and up.
Note: since I am testing jammy against ppa anyway (due to missing jtreg7 backport), I have google test 1.13 to the ppa, I will update jammy test results once rebuild it done

[1] https://mail.openjdk.org/pipermail/hotspot-dev/2021-April/050965.html

JDK focal to jammy upgrade (success). Requires -security updates.

JDK jammy to lunar upgrade (success). Requires -security updates.

Lunar piuparts test.

Note:
 0m46.6s INFO: Warning: Package purging left files on system:
  /usr/share/icons/ owned by: humanity-icon-theme, ubuntu-mono, openjdk-21-jre:amd64, hicolor-icon-theme, adwaita-icon-theme
  /usr/share/icons/Humanity-Dark/ owned by: humanity-icon-theme
  /usr/share/icons/Humanity-Dark/icon-theme.cache not owned
  /usr/share/icons/Humanity/ owned by: humanity-icon-theme
  /usr/share/icons/Humanity/icon-theme.cache not owned

Removed jammy test results, pending rebuild with google test enabled.

Updated jammy jtreg test logs

Disclaimer: I'm not familiar with java packaging

I'm looking at the SRU policy for openjdk-N updates: https://wiki.ubuntu.com/OpenJDK-Updates

It says:
"At most two OpenJDK short term support versions can be found in an Ubuntu LTS release."

Looking at jammy, there we seem to have versions 11 and 17 which are LTS releases, but also 8, 18 and 19. And now you want to introduce 21 for jammy. What happens to 8, 18 and 19? The policy also says:

"We want to ship the short term support OpenJDK version to get those exposed to users and developers, but want to drop them again when they become unsupported. "

Does that mean we should remove the unsupported versions?

> Jtreg tests should be disabled for the package due to the large number of packages that need to be
> upgraded in order to port jtreg7 [1]. This should be handled as a separate issue.

What is jtreg, what is it used for, what breaks if we don't ship it, and won't disabling the tests just paper over the problem? What do you mean by "handled as a separate issue", are you planning on fixing it somehow?

Is java21 useful without a working jtreg? Won't users be expecting java 21 to just work, but ours will have this defficiency?

> Does that mean we should remove the unsupported versions?

The unsupported versions are required for bootstrapping the next version, e.g. openjdk-19 is required to build openjdk-20, and openjdk-20 is required for building openjdk-21.
If we have openjdk-21 in the archive, then technically we do not need openjdk-19, since if we ever publish openjdk-21 containing a critical bug that does not allow to build a fix, we still can rely on openjdk20.

Thank you for looking into it! I should put together some wiki page on openjdk packaging.

> What is jtreg, what is it used for
This is a regression test harness for openjdk[1] and is used to validate that openjdk works correctly.

> what breaks if we don't ship it
Not shipping jtreg suite forces users to download it outside the archive to validate the openjdk.

> and won't disabling the tests just paper over the problem?
The tests were run in the ppa to ensure that there were no new problems introduced.

>What do you mean by "handled as a separate issue", are you planning on fixing it somehow?
Yes, there is a number of a new packages that needs to be added to focal and jammy[2].

>Is java21 useful without a working jtreg? Won't users be expecting java 21 to just work, but ours will have this defficiency?
Yes. jtreg is not needed to have a working openjdk. This is similar to disabling autopkgtests and executing them manually.

[1] https://github.com/openjdk/jtreg
[2] https://launchpad.net/~vpa1977/+archive/ubuntu/openjdk-21-jtreg7

> Does that mean we should remove the unsupported versions?

Just to re-iterate one of Andreas' questions that I don't think has been answered yet: if this is accepted, jammy will have openjdk versions 8, 11 (LTS), 17 (LTS), 18, 19, 20, and 21. I note that 18 will be dropped on mantic (though not 19?). Should we be considering removal of (at least) 18 from earlier releases too, or is removal from an active release too disruptive?

The policy (kindly linked by Andreas above) states "At most two OpenJDK short term support versions" in an Ubuntu LTS release. Should we be considering revising that policy? As a follow-up to that: 18 and 19 didn't make it back to focal -- why should 20 and 21, given the SRU policy also states "A new OpenJDK short term support version has to be upload[ed] to [...] *the most recent* Ubuntu LTS release" (emphasis added)? Or in other words, we seem to be at least bending policy here; if there's a good reason for us to be doing so, should we be revising the policy?

>Just to re-iterate one of Andreas' questions that I don't think has been answered yet: if this is accepted, jammy will have openjdk versions 8, 11 (LTS), 17 (LTS), 18, 19, 20, and 21. I note that 18 will be dropped on mantic (though not 19?). Should we be considering removal of (at least) 18 from earlier releases too, or is removal from an active release too disruptive?

HI, just to clear up some misunderstanding here, 21 is a LTS release (see [Impact]) and the poilicy specifically targets short term (6 month support) releases.

The list of jamy versions is 8 (LTS), 11 (LTS), 17(LTS), 18, 19, 20 and 21(LTS).

18, 19 and 20 can be dropped as they are out of support and do not get security updates. 21 (LTS) is bootstrapped from 17 (LTS) with 21~35ea build.