From gnu.andrew at redhat.com Wed Nov 1 15:37:46 2023 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 1 Nov 2023 15:37:46 +0000 Subject: OpenJDK 8u402-b01 EA Released Message-ID: I've made available an early access source bundle for 8u402, based on the tag jdk8u402-b01: https://openjdk-sources.osci.io/openjdk8/openjdk8u402-b01-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u402-b01-ea.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint: CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 38e40d98f34be9bed6cf7340f2b5f15388cbcc1fbed23bfd0485203d4797ef02 openjdk8u402-b01-ea.tar.xz 8af5369448059b8298465617d038121471b1fc7aa1c322b9eb1ebe231a32283f openjdk8u402-b01-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u402-b01-ea.sha256 The tarball was built on RHEL 6 (x86, x86_64) and RHEL 7 (aarch64, ppc, ppc64, ppc64le, s390x, x86, x86_64) Changes in 8u402-b01: - JDK-6528710: sRGB-ColorSpace to sRGB-ColorSpace Conversion - JDK-8029995: accept yes/no for boolean krb5.conf settings - JDK-8159156: [TESTBUG] ReserveMemory test is not useful on Aix. - JDK-8206179: com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java fails with Committed virtual memory size illegal value - JDK-8207404: MulticastSocket tests failing on AIX - JDK-8212677: X11 default visual support for IM status window on VNC - JDK-8239365: ProcessBuilder test modifications for AIX execution - JDK-8271838: AmazonCA.java interop test fails - JDK-8285398: Cache the results of constraint checks - JDK-8285696: AlgorithmConstraints:permits not throwing IllegalArgumentException when 'alg' is null - JDK-8307837: [8u] Check step in GHA should also print errors - JDK-8309088: security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java fails - JDK-8311813: C1: Uninitialized PhiResolver::_loop field - JDK-8312535: MidiSystem.getSoundbank() throws unexpected SecurityException - JDK-8315280: Bump update version of OpenJDK: 8u402 - JDK-8315506: C99 compatibility issue in LinuxNativeDispatcher Notes on individual issues: =========================== JDK-8029995: accept yes/no for boolean krb5.conf settings ========================================================= The krb5.conf configuration file now also accepts "yes" and "no", as alternatives to the existing "true" and "false" support, when using settings that take boolean values. Thanks, -- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks Available on Libera Chat & OFTC IRC networks as gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From andrew at openjdk.org Thu Nov 2 20:12:20 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 2 Nov 2023 20:12:20 GMT Subject: [jdk8u-dev] RFR: 8305329: [8u] Unify test libraries into single test library - step 1 [v2] In-Reply-To: References: <-myNqW_fw3D6SHLG0l05BA4m1w6zFs9TvCgvHSrAzzk=.222f6ecc-c89b-4d56-99d9-c66fda765078@github.com> Message-ID: On Tue, 15 Aug 2023 18:35:33 GMT, Zdenek Zambersky wrote: > I have removed lib classes, which do not compile on jdk 8 (and ones depending on them). Retested -> OK. This looks good. All seem to have been added by the JFR backport. While some are unique and only used by that (`LingeredApp.java`, `LingeredAppWithDeadlock.java`, `ModuleInfoMaker.java`), the rest seem to be duplicated by (presumably working) versions in the hotspot and jdk libraries. ~~~ $ find -name RedefineClassHelper.java ./hotspot/test/testlibrary/RedefineClassHelper.java ./jdk/test/lib/RedefineClassHelper.java $ find -name CompilerUtils.java ./jdk/test/lib/jdk/test/lib/compiler/CompilerUtils.java ./jdk/test/lib/testlibrary/CompilerUtils.java $ find -name InMemoryJavaCompiler.java ./hotspot/test/testlibrary/com/oracle/java/testlibrary/InMemoryJavaCompiler.java ./jdk/test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java ./jdk/test/lib/testlibrary/jdk/testlibrary/InMemoryJavaCompiler.java $ find -name JarUtils.java ./jdk/test/lib/jdk/test/lib/util/JarUtils.java ./jdk/test/lib/testlibrary/jdk/testlibrary/JarUtils.java $ find -name SecurityTools.java ./jdk/test/lib/jdk/test/lib/SecurityTools.java ./jdk/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java ~~~ ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/294#issuecomment-1791470098 From andrew at openjdk.org Thu Nov 2 20:12:21 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 2 Nov 2023 20:12:21 GMT Subject: [jdk8u-dev] RFR: 8305329: [8u] Unify test libraries into single test library - step 1 In-Reply-To: References: <-myNqW_fw3D6SHLG0l05BA4m1w6zFs9TvCgvHSrAzzk=.222f6ecc-c89b-4d56-99d9-c66fda765078@github.com> Message-ID: On Mon, 14 Aug 2023 14:35:32 GMT, Zdenek Zambersky wrote: > > I think we should also probably have a step 4 to actually move the tests. That will then solve the backporting problem where tests keep being introduced in the wrong location. > > Even though, it would be good for backporting, I have so far excluded tests themselfs from move, as there are some additional difficulties with that. While changing test library location can be done more or less transparently, in case of tests there are some complications: > > * It would be more invasive change needing changes to build system (makefiles) > > * It would break existing CI testing (would require changes), in cases, where jtreg is being called directly, rater than through main makefile, (e.g. Adoptium aqa-tests, see: [openjdk.mk](https://github.com/adoptium/aqa-tests/blob/07cac1895144ecb63a2ad03c3214a52fb108cfbc/openjdk/openjdk.mk#L122) [playlist.xml](https://github.com/adoptium/aqa-tests/blob/07cac1895144ecb63a2ad03c3214a52fb108cfbc/openjdk/playlist.xml#L717).) I know what you mean, and it is what has put me off doing this earlier. We can see how things look once the library work is done, but I think it would actually help remove a lot of special casing for 8u long term. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/294#issuecomment-1791471409 From duke at openjdk.org Fri Nov 3 12:15:22 2023 From: duke at openjdk.org (duke) Date: Fri, 3 Nov 2023 12:15:22 GMT Subject: [jdk8u-dev] Withdrawn: 8176509: Use pandoc for converting build readme to html In-Reply-To: <-b_sIr0DdNgucwSKVckSqwjg0ChhDmEuf2e6YtHjXUs=.baa26a5c-fcc2-4523-ae18-bfaea88da7d8@github.com> References: <-b_sIr0DdNgucwSKVckSqwjg0ChhDmEuf2e6YtHjXUs=.baa26a5c-fcc2-4523-ae18-bfaea88da7d8@github.com> Message-ID: On Thu, 7 Sep 2023 20:09:14 GMT, Zdenek Zambersky wrote: > This backport switches to pandoc for coversion of building readme to html. It also does some style/formating changes/fixes to building readme, which is moved to new location and also removes redundant information in other Readme files. > > Backport is not clear. Code for coversion to html had to be modified to work with JDK8 build system. Change set (patch) for building readme mostly applied automatically, but some parts had to be done by hand due to few differences. > > Unlike in original change set, this backport moves `README-builds.{md,html}` files directly to `doc/building.{md,html}` and not to intermediate location `common/doc/building.{md,html}`. (additional move was done in jdk10 as part of [JDK-8187443](https://bugs.openjdk.org/browse/JDK-8187443)) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/370 From stuefe at openjdk.org Sat Nov 4 06:31:32 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 4 Nov 2023 06:31:32 GMT Subject: [jdk8u-dev] RFR: JDK-8319405: [s390] [jdk8] Increase javac default stack size for s390x zero Message-ID: This is a JDK8 - only patch to fix failing TCK tests for javac on s390. s390x, by default, needs a lot of stack space for C++ frames since the s390x ABI requires a 160-byte register save area per frame. That affects JDK 8 in particular since we run Zero, and the C++ interpreter builds up C-frames for Java frames; furthermore, it affects javac since it recurses a lot. This causes several javac TCK tests to fail with SOE (stmt33002mxxx). To pass TCK, the default stack size of javac should be increased for s390 on JDK 8. Testing: - manually tested on s390 to see if the issue was resolved, which it was. - manually tested on x64 to check that nothing changed - GHAs ------------- Commit messages: - JDK-8319405-s390-jdk8-Increase-javac-default-stack-size-for-s390x-zero Changes: https://git.openjdk.org/jdk8u-dev/pull/385/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=385&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319405 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/385.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/385/head:pull/385 PR: https://git.openjdk.org/jdk8u-dev/pull/385 From jianyesun at openjdk.org Sun Nov 5 07:04:29 2023 From: jianyesun at openjdk.org (Sun Jianye) Date: Sun, 5 Nov 2023 07:04:29 GMT Subject: [jdk8u-dev] RFR: 6899049: G1: Clean up code in ptrQueue.[ch]pp and ptrQueue.inline.hpp [v5] In-Reply-To: References: Message-ID: <60YEvFpRPRfJiJW1J5A_OeVACp8hc-OCeXdemoJ0Na4=.1a1734d2-f28c-4ccb-a74d-ea96f31853af@github.com> > Hi all, > > This pull request contains a backport of commit [b256989eb34a32c8f03be448c0645baeb5192a01](https://github.com/openjdk/jdk11u-dev/commit/b256989eb34a32c8f03be448c0645baeb5192a01) from the [openjdk/jdk11u-dev](https://github.com/openjdk/jdk11u-dev) repository. > > As reported by issue : https://bugs.openjdk.org/browse/JDK-8316278 . We found the indexing method of PtrQueue's buf is not correct when converting an integer of type size_t to type int, then calling the method PtrQueue::byte_index_to_index . > The key problem is this way of using: > > size_t i=0; _buf[byte_index_to_index((int)i)] = NULL; > > The variable i of size_t type cannot be converted directly to an int type . Other than that, the return value of the function byte_index_to_index is the index of the array _buf, and it should be non-negative. So it should be a type of size_t. > Currently we have found 2 issues related to this problem, https://bugs.openjdk.org/browse/JDK-8308169 and https://bugs.openjdk.org/browse/JDK-8303961. They are all triggered by a special size number of buf, like '-XX:G1UpdateBufferSize=512M' or '-XX:G1SATBBufferSize=500m' > We also added a test case. > Please review this PR. Thanks. Sun Jianye has updated the pull request incrementally with one additional commit since the last revision: fix white space mismatch ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/374/files - new: https://git.openjdk.org/jdk8u-dev/pull/374/files/4486486f..9646d613 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=374&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=374&range=03-04 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/374.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/374/head:pull/374 PR: https://git.openjdk.org/jdk8u-dev/pull/374 From jianyesun at openjdk.org Sun Nov 5 07:08:20 2023 From: jianyesun at openjdk.org (Sun Jianye) Date: Sun, 5 Nov 2023 07:08:20 GMT Subject: [jdk8u-dev] RFR: 6899049: G1: Clean up code in ptrQueue.[ch]pp and ptrQueue.inline.hpp [v4] In-Reply-To: References: <9ZRGfkLAHdEXMJ-bmZRo0wLUJ-9XhSMB-xwFhYw5wMM=.1b8dd889-10b5-4804-8a67-a548c951defc@github.com> Message-ID: On Thu, 19 Oct 2023 21:22:46 GMT, Paul Hohensee wrote: > White space mismatch in dirtyCardQueue.cpp, lines 209 and 210. dirtyCardQueue.hpp ine 72 also doesn't match, but Andrew allowed it so I will too. Other than that, lgtm. Sorry, something interrupted me. I fix it as you suggested, thank you very much. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/374#issuecomment-1793656998 From zzambers at openjdk.org Mon Nov 6 13:08:26 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 6 Nov 2023 13:08:26 GMT Subject: [jdk8u-dev] RFR: 8305329: [8u] Unify test libraries into single test library - step 1 [v2] In-Reply-To: References: <-myNqW_fw3D6SHLG0l05BA4m1w6zFs9TvCgvHSrAzzk=.222f6ecc-c89b-4d56-99d9-c66fda765078@github.com> Message-ID: On Tue, 15 Aug 2023 13:32:02 GMT, Zdenek Zambersky wrote: >> I would like to start effort to unify test libraries in openjdk 8 into one unified library. This is first step of that effort, which moves newest copy of jdk test library (added with jfr backport) from `jdk/test/lib` to `test/lib`. For more details please continue reading. >> >> **Problem:** >> Test libraries in jdk8 are a bit messy. >> There are currently 3 different test libraries: >> - hotspot testlibrary - placed in [hotspot/test/testlibrary](https://github.com/openjdk/jdk8u-dev/tree/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary), (pkgs `com.oracle.java.testlibrary`, `sun.hotspot...` ), includes testlibrary tests in [hotspot/test/testlibrary_tests](https://github.com/openjdk/jdk8u-dev/tree/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary_tests) >> - jdk testlibrary (old) - placed in [jdk/test/lib/testlibrary](https://github.com/openjdk/jdk8u-dev/tree/master/jdk/test/lib/testlibrary), (pkgs `jdk.testlibrary`, `com.oracle.testlibrary.jsr292`) >> - jdk test lib - placed directly in [jdk/test/lib](https://github.com/openjdk/jdk8u-dev/tree/master/jdk/test/lib), was added with [jfr backport](https://github.com/openjdk/jdk8u-dev/commit/df7e09043392d5952d522a28702c6e5ec3e8492e), (pkgs `jdk.test.lib` `sun.hotspot...`) >> >> Many test library classes exist in multiple different copies (using different pkgs). Few examples: >> - Platform.java - 3 copies ([hs](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/com/oracle/java/testlibrary/Platform.java), [jdk (old)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/jdk/test/lib/Platform.java)) >> - OutputAnalyzer.java - 3 copies ([hs](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java), [jdk (old)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/jdk/test/lib/process/OutputAnalyzer.java)) >> - WhiteBox.java - 2 copies ([hotspot](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/whitebox/sun/hotspot/WhiteBox.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/sun/hotspot/WhiteBox.j... > > Zdenek Zambersky has updated the pull request incrementally with one additional commit since the last revision: > > Removed lib classes, which do not compile on JDK8 Seems like this PR will need to get updated (rebased), due to changes introduced by: https://github.com/openjdk/jdk8u-dev/pull/347 ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/294#issuecomment-1794785055 From zzambers at openjdk.org Mon Nov 6 15:42:11 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 6 Nov 2023 15:42:11 GMT Subject: [jdk8u-dev] RFR: 8305329: [8u] Unify test libraries into single test library - step 1 [v3] In-Reply-To: <-myNqW_fw3D6SHLG0l05BA4m1w6zFs9TvCgvHSrAzzk=.222f6ecc-c89b-4d56-99d9-c66fda765078@github.com> References: <-myNqW_fw3D6SHLG0l05BA4m1w6zFs9TvCgvHSrAzzk=.222f6ecc-c89b-4d56-99d9-c66fda765078@github.com> Message-ID: > I would like to start effort to unify test libraries in openjdk 8 into one unified library. This is first step of that effort, which moves newest copy of jdk test library (added with jfr backport) from `jdk/test/lib` to `test/lib`. For more details please continue reading. > > **Problem:** > Test libraries in jdk8 are a bit messy. > There are currently 3 different test libraries: > - hotspot testlibrary - placed in [hotspot/test/testlibrary](https://github.com/openjdk/jdk8u-dev/tree/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary), (pkgs `com.oracle.java.testlibrary`, `sun.hotspot...` ), includes testlibrary tests in [hotspot/test/testlibrary_tests](https://github.com/openjdk/jdk8u-dev/tree/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary_tests) > - jdk testlibrary (old) - placed in [jdk/test/lib/testlibrary](https://github.com/openjdk/jdk8u-dev/tree/master/jdk/test/lib/testlibrary), (pkgs `jdk.testlibrary`, `com.oracle.testlibrary.jsr292`) > - jdk test lib - placed directly in [jdk/test/lib](https://github.com/openjdk/jdk8u-dev/tree/master/jdk/test/lib), was added with [jfr backport](https://github.com/openjdk/jdk8u-dev/commit/df7e09043392d5952d522a28702c6e5ec3e8492e), (pkgs `jdk.test.lib` `sun.hotspot...`) > > Many test library classes exist in multiple different copies (using different pkgs). Few examples: > - Platform.java - 3 copies ([hs](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/com/oracle/java/testlibrary/Platform.java), [jdk (old)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/jdk/test/lib/Platform.java)) > - OutputAnalyzer.java - 3 copies ([hs](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java), [jdk (old)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/jdk/test/lib/process/OutputAnalyzer.java)) > - WhiteBox.java - 2 copies ([hotspot](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/whitebox/sun/hotspot/WhiteBox.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/sun/hotspot/WhiteBox.java)) > > Few additional obse... Zdenek Zambersky has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Fixed library tag of additional tests after rebase - Removed lib classes, which do not compile on JDK8 - Moved test lib ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/294/files - new: https://git.openjdk.org/jdk8u-dev/pull/294/files/14666aa2..5f384666 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=294&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=294&range=01-02 Stats: 900987 lines in 455 files changed: 897061 ins; 2244 del; 1682 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/294.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/294/head:pull/294 PR: https://git.openjdk.org/jdk8u-dev/pull/294 From zzambers at openjdk.org Mon Nov 6 15:55:30 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 6 Nov 2023 15:55:30 GMT Subject: [jdk8u-dev] RFR: 8305329: [8u] Unify test libraries into single test library - step 1 [v3] In-Reply-To: References: <-myNqW_fw3D6SHLG0l05BA4m1w6zFs9TvCgvHSrAzzk=.222f6ecc-c89b-4d56-99d9-c66fda765078@github.com> Message-ID: On Mon, 6 Nov 2023 15:42:11 GMT, Zdenek Zambersky wrote: >> I would like to start effort to unify test libraries in openjdk 8 into one unified library. This is first step of that effort, which moves newest copy of jdk test library (added with jfr backport) from `jdk/test/lib` to `test/lib`. For more details please continue reading. >> >> **Problem:** >> Test libraries in jdk8 are a bit messy. >> There are currently 3 different test libraries: >> - hotspot testlibrary - placed in [hotspot/test/testlibrary](https://github.com/openjdk/jdk8u-dev/tree/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary), (pkgs `com.oracle.java.testlibrary`, `sun.hotspot...` ), includes testlibrary tests in [hotspot/test/testlibrary_tests](https://github.com/openjdk/jdk8u-dev/tree/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary_tests) >> - jdk testlibrary (old) - placed in [jdk/test/lib/testlibrary](https://github.com/openjdk/jdk8u-dev/tree/master/jdk/test/lib/testlibrary), (pkgs `jdk.testlibrary`, `com.oracle.testlibrary.jsr292`) >> - jdk test lib - placed directly in [jdk/test/lib](https://github.com/openjdk/jdk8u-dev/tree/master/jdk/test/lib), was added with [jfr backport](https://github.com/openjdk/jdk8u-dev/commit/df7e09043392d5952d522a28702c6e5ec3e8492e), (pkgs `jdk.test.lib` `sun.hotspot...`) >> >> Many test library classes exist in multiple different copies (using different pkgs). Few examples: >> - Platform.java - 3 copies ([hs](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/com/oracle/java/testlibrary/Platform.java), [jdk (old)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/jdk/test/lib/Platform.java)) >> - OutputAnalyzer.java - 3 copies ([hs](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java), [jdk (old)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/jdk/test/lib/process/OutputAnalyzer.java)) >> - WhiteBox.java - 2 copies ([hotspot](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/whitebox/sun/hotspot/WhiteBox.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/sun/hotspot/WhiteBox.j... > > Zdenek Zambersky has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Fixed library tag of additional tests after rebase > - Removed lib classes, which do not compile on JDK8 > - Moved test lib I have rebased changes on current master to fix conflict as shown by GH. (Bot does not like rebasing, but I find it less evil and more readable, than merging in master.) Rebase using `git rebase master` worked out of box, no manual interaction was needed. I verified that renamed [NetworkConfiguration.java](https://github.com/zzambers/jdk8u-dev/blob/jtreg-lib/test/lib/jdk/test/lib/NetworkConfiguration.java) contains changes by [JDK-8207404 backport](https://github.com/openjdk/jdk8u-dev/pull/347). There is only small change on top fixing `@library` tag in affected tests. I have found no other issues. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/294#issuecomment-1795197636 From phh at openjdk.org Tue Nov 7 19:04:26 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 7 Nov 2023 19:04:26 GMT Subject: [jdk8u-dev] RFR: JDK-8319405: [s390] [jdk8] Increase javac default stack size for s390x zero In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 14:49:24 GMT, Thomas Stuefe wrote: > This is a JDK8 - only patch to fix failing TCK tests for javac on s390. > > s390x, by default, needs a lot of stack space for C++ frames since the s390x ABI requires a 160-byte register save area per frame. That affects JDK 8 in particular since we run Zero, and the C++ interpreter builds up C-frames for Java frames; furthermore, it affects javac since it recurses a lot. > > This causes several javac TCK tests to fail with SOE (stmt33002mxxx). > > To pass TCK, the default stack size of javac should be increased for s390 on JDK 8. > > Testing: > > - manually tested on s390 to see if the issue was resolved, which it was. > - manually tested on x64 to check that nothing changed > - GHAs Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/385#pullrequestreview-1718487540 From phh at openjdk.org Tue Nov 7 19:05:01 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 7 Nov 2023 19:05:01 GMT Subject: [jdk8u-dev] RFR: 6899049: G1: Clean up code in ptrQueue.[ch]pp and ptrQueue.inline.hpp [v5] In-Reply-To: <60YEvFpRPRfJiJW1J5A_OeVACp8hc-OCeXdemoJ0Na4=.1a1734d2-f28c-4ccb-a74d-ea96f31853af@github.com> References: <60YEvFpRPRfJiJW1J5A_OeVACp8hc-OCeXdemoJ0Na4=.1a1734d2-f28c-4ccb-a74d-ea96f31853af@github.com> Message-ID: On Sun, 5 Nov 2023 07:04:29 GMT, Sun Jianye wrote: >> Hi all, >> >> This pull request contains a backport of commit [b256989eb34a32c8f03be448c0645baeb5192a01](https://github.com/openjdk/jdk11u-dev/commit/b256989eb34a32c8f03be448c0645baeb5192a01) from the [openjdk/jdk11u-dev](https://github.com/openjdk/jdk11u-dev) repository. >> >> As reported by issue : https://bugs.openjdk.org/browse/JDK-8316278 . We found the indexing method of PtrQueue's buf is not correct when converting an integer of type size_t to type int, then calling the method PtrQueue::byte_index_to_index . >> The key problem is this way of using: >> >> size_t i=0; _buf[byte_index_to_index((int)i)] = NULL; >> >> The variable i of size_t type cannot be converted directly to an int type . Other than that, the return value of the function byte_index_to_index is the index of the array _buf, and it should be non-negative. So it should be a type of size_t. >> Currently we have found 2 issues related to this problem, https://bugs.openjdk.org/browse/JDK-8308169 and https://bugs.openjdk.org/browse/JDK-8303961. They are all triggered by a special size number of buf, like '-XX:G1UpdateBufferSize=512M' or '-XX:G1SATBBufferSize=500m' >> We also added a test case. >> Please review this PR. Thanks. > > Sun Jianye has updated the pull request incrementally with one additional commit since the last revision: > > fix white space mismatch linux-x86 looks to have a couple of tier1 test failures. The windows-x64 failure looks like an infrastructure issue. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/374#issuecomment-1799575812 From andrew at openjdk.org Wed Nov 8 00:48:12 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 8 Nov 2023 00:48:12 GMT Subject: [jdk8u-dev] RFR: 8305329: [8u] Unify test libraries into single test library - step 1 [v3] In-Reply-To: References: <-myNqW_fw3D6SHLG0l05BA4m1w6zFs9TvCgvHSrAzzk=.222f6ecc-c89b-4d56-99d9-c66fda765078@github.com> Message-ID: On Mon, 6 Nov 2023 15:42:11 GMT, Zdenek Zambersky wrote: >> I would like to start effort to unify test libraries in openjdk 8 into one unified library. This is first step of that effort, which moves newest copy of jdk test library (added with jfr backport) from `jdk/test/lib` to `test/lib`. For more details please continue reading. >> >> **Problem:** >> Test libraries in jdk8 are a bit messy. >> There are currently 3 different test libraries: >> - hotspot testlibrary - placed in [hotspot/test/testlibrary](https://github.com/openjdk/jdk8u-dev/tree/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary), (pkgs `com.oracle.java.testlibrary`, `sun.hotspot...` ), includes testlibrary tests in [hotspot/test/testlibrary_tests](https://github.com/openjdk/jdk8u-dev/tree/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary_tests) >> - jdk testlibrary (old) - placed in [jdk/test/lib/testlibrary](https://github.com/openjdk/jdk8u-dev/tree/master/jdk/test/lib/testlibrary), (pkgs `jdk.testlibrary`, `com.oracle.testlibrary.jsr292`) >> - jdk test lib - placed directly in [jdk/test/lib](https://github.com/openjdk/jdk8u-dev/tree/master/jdk/test/lib), was added with [jfr backport](https://github.com/openjdk/jdk8u-dev/commit/df7e09043392d5952d522a28702c6e5ec3e8492e), (pkgs `jdk.test.lib` `sun.hotspot...`) >> >> Many test library classes exist in multiple different copies (using different pkgs). Few examples: >> - Platform.java - 3 copies ([hs](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/com/oracle/java/testlibrary/Platform.java), [jdk (old)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/jdk/test/lib/Platform.java)) >> - OutputAnalyzer.java - 3 copies ([hs](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java), [jdk (old)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/jdk/test/lib/process/OutputAnalyzer.java)) >> - WhiteBox.java - 2 copies ([hotspot](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/whitebox/sun/hotspot/WhiteBox.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/sun/hotspot/WhiteBox.j... > > Zdenek Zambersky has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Fixed library tag of additional tests after rebase > - Removed lib classes, which do not compile on JDK8 > - Moved test lib Yes, I agree a rebase makes sense here. The bot comment makes sense to encourage people to respond to review comments with further commits, but not really with merges. Worst of all is with dependent pull requests, where merging the two identical change requests would be more dangerous than just rebasing and having `git` just recognise and drop the duplicate. Of course, that duplicate is only created because the bot itself does a rebase... The additional changes look fine to me. Let's get this in. ------------- Marked as reviewed by andrew (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/294#pullrequestreview-1719100649 From sgehwolf at openjdk.org Wed Nov 8 10:04:06 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Nov 2023 10:04:06 GMT Subject: [jdk8u-dev] RFR: JDK-8319405: [s390] [jdk8] Increase javac default stack size for s390x zero In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 14:49:24 GMT, Thomas Stuefe wrote: > This is a JDK8 - only patch to fix failing TCK tests for javac on s390. > > s390x, by default, needs a lot of stack space for C++ frames since the s390x ABI requires a 160-byte register save area per frame. That affects JDK 8 in particular since we run Zero, and the C++ interpreter builds up C-frames for Java frames; furthermore, it affects javac since it recurses a lot. > > This causes several javac TCK tests to fail with SOE (stmt33002mxxx). > > To pass TCK, the default stack size of javac should be increased for s390 on JDK 8. > > Testing: > > - manually tested on s390 to see if the issue was resolved, which it was. > - manually tested on x64 to check that nothing changed > - GHAs Looks good. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/385#pullrequestreview-1719870544 From stuefe at openjdk.org Wed Nov 8 11:10:12 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 8 Nov 2023 11:10:12 GMT Subject: [jdk8u-dev] RFR: JDK-8319405: [s390] [jdk8] Increase javac default stack size for s390x zero In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 10:01:25 GMT, Severin Gehwolf wrote: >> This is a JDK8 - only patch to fix failing TCK tests for javac on s390. >> >> s390x, by default, needs a lot of stack space for C++ frames since the s390x ABI requires a 160-byte register save area per frame. That affects JDK 8 in particular since we run Zero, and the C++ interpreter builds up C-frames for Java frames; furthermore, it affects javac since it recurses a lot. >> >> This causes several javac TCK tests to fail with SOE (stmt33002mxxx). >> >> To pass TCK, the default stack size of javac should be increased for s390 on JDK 8. >> >> Testing: >> >> - manually tested on s390 to see if the issue was resolved, which it was. >> - manually tested on x64 to check that nothing changed >> - GHAs > > Looks good. Thanks @jerboaa ! ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/385#issuecomment-1801659963 From stuefe at openjdk.org Wed Nov 8 11:10:13 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 8 Nov 2023 11:10:13 GMT Subject: [jdk8u-dev] Integrated: JDK-8319405: [s390] [jdk8] Increase javac default stack size for s390x zero In-Reply-To: References: Message-ID: <5VrnKd6A0kJliRcMUIuyzjHOtYBNmnXv7Yu_ew3PxaM=.1181d695-b47b-4394-95eb-f7173e47e03f@github.com> On Fri, 3 Nov 2023 14:49:24 GMT, Thomas Stuefe wrote: > This is a JDK8 - only patch to fix failing TCK tests for javac on s390. > > s390x, by default, needs a lot of stack space for C++ frames since the s390x ABI requires a 160-byte register save area per frame. That affects JDK 8 in particular since we run Zero, and the C++ interpreter builds up C-frames for Java frames; furthermore, it affects javac since it recurses a lot. > > This causes several javac TCK tests to fail with SOE (stmt33002mxxx). > > To pass TCK, the default stack size of javac should be increased for s390 on JDK 8. > > Testing: > > - manually tested on s390 to see if the issue was resolved, which it was. > - manually tested on x64 to check that nothing changed > - GHAs This pull request has now been integrated. Changeset: dd43bdd6 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk8u-dev/commit/dd43bdd6c4fae298d401222ddfaf848b0d458aa3 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod 8319405: [s390] [jdk8] Increase javac default stack size for s390x zero Reviewed-by: phh, sgehwolf ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/385 From zzambers at openjdk.org Wed Nov 8 15:58:19 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Wed, 8 Nov 2023 15:58:19 GMT Subject: [jdk8u-dev] RFR: 8305329: [8u] Unify test libraries into single test library - step 1 In-Reply-To: References: <-myNqW_fw3D6SHLG0l05BA4m1w6zFs9TvCgvHSrAzzk=.222f6ecc-c89b-4d56-99d9-c66fda765078@github.com> Message-ID: On Thu, 2 Nov 2023 20:10:13 GMT, Andrew John Hughes wrote: >>> I think we should also probably have a step 4 to actually move the tests. That will then solve the backporting problem where tests keep being introduced in the wrong location. >> >> Even though, it would be good for backporting, I have so far excluded tests themselfs from move, as there are some additional difficulties with that. While changing test library location can be done more or less transparently, in case of tests there are some complications: >> - It would be more invasive change needing changes to build system (makefiles) >> - It would break existing CI testing (would require changes), in cases, where jtreg is being called directly, rater than through main makefile, (e.g. Adoptium aqa-tests, see: [openjdk.mk](https://github.com/adoptium/aqa-tests/blob/07cac1895144ecb63a2ad03c3214a52fb108cfbc/openjdk/openjdk.mk#L122) [playlist.xml](https://github.com/adoptium/aqa-tests/blob/07cac1895144ecb63a2ad03c3214a52fb108cfbc/openjdk/playlist.xml#L717).) > >> > I think we should also probably have a step 4 to actually move the tests. That will then solve the backporting problem where tests keep being introduced in the wrong location. >> >> Even though, it would be good for backporting, I have so far excluded tests themselfs from move, as there are some additional difficulties with that. While changing test library location can be done more or less transparently, in case of tests there are some complications: >> >> * It would be more invasive change needing changes to build system (makefiles) >> >> * It would break existing CI testing (would require changes), in cases, where jtreg is being called directly, rater than through main makefile, (e.g. Adoptium aqa-tests, see: [openjdk.mk](https://github.com/adoptium/aqa-tests/blob/07cac1895144ecb63a2ad03c3214a52fb108cfbc/openjdk/openjdk.mk#L122) [playlist.xml](https://github.com/adoptium/aqa-tests/blob/07cac1895144ecb63a2ad03c3214a52fb108cfbc/openjdk/playlist.xml#L717).) > > I know what you mean, and it is what has put me off doing this earlier. We can see how things look once the library work is done, but I think it would actually help remove a lot of special casing for 8u long term. @gnu-andrew thank you ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/294#issuecomment-1802179474 From duke at openjdk.org Fri Nov 10 08:50:45 2023 From: duke at openjdk.org (yaqsun) Date: Fri, 10 Nov 2023 08:50:45 GMT Subject: [jdk8u-dev] RFR: 8198321: javax/swing/JEditorPane/5076514/bug5076514.java fails Message-ID: I backport this for parity with 8u271. Low risk, only test changes. And test have been locally verified to pass. ------------- Commit messages: - update Copyright - Backport cc3756b342a367d3d29a31a18bdcc2fa4797bdcf Changes: https://git.openjdk.org/jdk8u-dev/pull/386/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=386&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8198321 Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/386.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/386/head:pull/386 PR: https://git.openjdk.org/jdk8u-dev/pull/386 From andrew at openjdk.org Sat Nov 11 14:35:04 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Sat, 11 Nov 2023 14:35:04 GMT Subject: [jdk8u-dev] RFR: 8317291: Missing null check for nmethod::is_native_method() In-Reply-To: References: Message-ID: <1bIQfSrbUjSm2Yg1OZRae08cK-k-AlgrY9av8Z1v0CY=.b323b075-7f4b-4724-b372-311fd574ed35@github.com> On Fri, 29 Sep 2023 04:15:09 GMT, KIRIYAMA Takuya wrote: > I added null check to nmethod::is_native_method() and is_java_method(). > I verified that the JVM crash problem no longer occurs by this fix. > I don't attach the test for this fix beause I could reproduce this problem only with debug build. > > Would anyone review this fix, pelase? Looks like a sensible cherry-pick from that big changeset to me. Approved for 8u. ------------- Marked as reviewed by andrew (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/379#pullrequestreview-1726072283 From andrew at openjdk.org Sat Nov 11 15:12:01 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Sat, 11 Nov 2023 15:12:01 GMT Subject: [jdk8u-dev] RFR: 8021961: setAlwaysOnTop doesn't behave correctly in Linux/Solaris under certain scenarios In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 09:28:53 GMT, Taizo Kurashige wrote: > Hi, > > This is a backoport of JDK-8021961: setAlwaysOnTop doesn't behave correctly in Linux/Solaris under certain scenarios > > Original patch does not apply cleanly to 8u, bacause "parent" is declared at XWindowPeer.java#1652 in 8u. > So I deleted that declaration. > > There is a related Issue: JDK-8222323, and I submit the corresponding PR. Testing was done after applying this related patch. > Testing: jdk_awt on RHEL7, GHA testing > > Thanks. It looks like the `parent` line was added to 8u for the backport of JDK-8187803, as it wasn't present due to this change (JDK-8021961) being absent. So replacing it with the earlier declaration in 8021961 seems correct. ------------- Marked as reviewed by andrew (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/377#pullrequestreview-1726076064 From andrew at openjdk.org Sat Nov 11 15:28:04 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Sat, 11 Nov 2023 15:28:04 GMT Subject: [jdk8u-dev] RFR: 8176509: Use pandoc for converting build readme to html In-Reply-To: <-b_sIr0DdNgucwSKVckSqwjg0ChhDmEuf2e6YtHjXUs=.baa26a5c-fcc2-4523-ae18-bfaea88da7d8@github.com> References: <-b_sIr0DdNgucwSKVckSqwjg0ChhDmEuf2e6YtHjXUs=.baa26a5c-fcc2-4523-ae18-bfaea88da7d8@github.com> Message-ID: On Thu, 7 Sep 2023 20:09:14 GMT, Zdenek Zambersky wrote: > This backport switches to pandoc for coversion of building readme to html. It also does some style/formating changes/fixes to building readme, which is moved to new location and also removes redundant information in other Readme files. > > Backport is not clear. Code for coversion to html had to be modified to work with JDK8 build system. Change set (patch) for building readme mostly applied automatically, but some parts had to be done by hand due to few differences. > > Unlike in original change set, this backport moves `README-builds.{md,html}` files directly to `doc/building.{md,html}` and not to intermediate location `common/doc/building.{md,html}`. (additional move was done in jdk10 as part of [JDK-8187443](https://bugs.openjdk.org/browse/JDK-8187443)) Looks good to me. 8u build requirements seem to have been retained as is and I think moving the file to the final place here is the right thing to do. ------------- Marked as reviewed by andrew (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/370#pullrequestreview-1726077834 From duke at openjdk.org Mon Nov 13 14:34:11 2023 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Mon, 13 Nov 2023 14:34:11 GMT Subject: [jdk8u-dev] Integrated: 8317291: Missing null check for nmethod::is_native_method() In-Reply-To: References: Message-ID: On Fri, 29 Sep 2023 04:15:09 GMT, KIRIYAMA Takuya wrote: > I added null check to nmethod::is_native_method() and is_java_method(). > I verified that the JVM crash problem no longer occurs by this fix. > I don't attach the test for this fix beause I could reproduce this problem only with debug build. > > Would anyone review this fix, pelase? This pull request has now been integrated. Changeset: 0e7ebcb9 Author: kiriyama Committer: Andrew John Hughes URL: https://git.openjdk.org/jdk8u-dev/commit/0e7ebcb9a56536bab60917d7be0da87458af7d3e Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8317291: Missing null check for nmethod::is_native_method() Reviewed-by: phh, andrew ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/379 From zzambers at openjdk.org Mon Nov 13 17:11:07 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 13 Nov 2023 17:11:07 GMT Subject: [jdk8u-dev] RFR: 8176509: Use pandoc for converting build readme to html In-Reply-To: References: <-b_sIr0DdNgucwSKVckSqwjg0ChhDmEuf2e6YtHjXUs=.baa26a5c-fcc2-4523-ae18-bfaea88da7d8@github.com> Message-ID: <01kUiNSLqOdIym1MMbnadTTcD_mhhhpi75KmK0_MCm0=.487e2a77-b938-4853-bd90-c884be2a8c74@github.com> On Sat, 11 Nov 2023 15:25:47 GMT, Andrew John Hughes wrote: > Looks good to me. 8u build requirements seem to have been retained as is and I think moving the file to the final place here is the right thing to do. Yy, pandoc should be optional, it builds without it in GHA. Unfortunately there is little additional noise in generated-configure concerning `--runstatedir` option, even though, I have used same version of autofonf, as was used before (2.69). It boils down to whether autoconf is ran on distro which has [specific backport](https://bugzilla.redhat.com/show_bug.cgi?id=1831941#c6). (Not present on rhel-8 I used) But I don't think this affects OpenJDK in any way. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/370#issuecomment-1808603662 From zzambers at openjdk.org Mon Nov 13 19:30:37 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 13 Nov 2023 19:30:37 GMT Subject: [jdk8u-dev] Integrated: 8305329: [8u] Unify test libraries into single test library - step 1 In-Reply-To: <-myNqW_fw3D6SHLG0l05BA4m1w6zFs9TvCgvHSrAzzk=.222f6ecc-c89b-4d56-99d9-c66fda765078@github.com> References: <-myNqW_fw3D6SHLG0l05BA4m1w6zFs9TvCgvHSrAzzk=.222f6ecc-c89b-4d56-99d9-c66fda765078@github.com> Message-ID: On Thu, 30 Mar 2023 21:12:59 GMT, Zdenek Zambersky wrote: > I would like to start effort to unify test libraries in openjdk 8 into one unified library. This is first step of that effort, which moves newest copy of jdk test library (added with jfr backport) from `jdk/test/lib` to `test/lib`. For more details please continue reading. > > **Problem:** > Test libraries in jdk8 are a bit messy. > There are currently 3 different test libraries: > - hotspot testlibrary - placed in [hotspot/test/testlibrary](https://github.com/openjdk/jdk8u-dev/tree/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary), (pkgs `com.oracle.java.testlibrary`, `sun.hotspot...` ), includes testlibrary tests in [hotspot/test/testlibrary_tests](https://github.com/openjdk/jdk8u-dev/tree/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary_tests) > - jdk testlibrary (old) - placed in [jdk/test/lib/testlibrary](https://github.com/openjdk/jdk8u-dev/tree/master/jdk/test/lib/testlibrary), (pkgs `jdk.testlibrary`, `com.oracle.testlibrary.jsr292`) > - jdk test lib - placed directly in [jdk/test/lib](https://github.com/openjdk/jdk8u-dev/tree/master/jdk/test/lib), was added with [jfr backport](https://github.com/openjdk/jdk8u-dev/commit/df7e09043392d5952d522a28702c6e5ec3e8492e), (pkgs `jdk.test.lib` `sun.hotspot...`) > > Many test library classes exist in multiple different copies (using different pkgs). Few examples: > - Platform.java - 3 copies ([hs](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/com/oracle/java/testlibrary/Platform.java), [jdk (old)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/jdk/test/lib/Platform.java)) > - OutputAnalyzer.java - 3 copies ([hs](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java), [jdk (old)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/jdk/test/lib/process/OutputAnalyzer.java)) > - WhiteBox.java - 2 copies ([hotspot](https://github.com/openjdk/jdk8u-dev/blob/89aeae16e85ddfbd581cb86d0b0480b1e2d50e99/hotspot/test/testlibrary/whitebox/sun/hotspot/WhiteBox.java), [jdk (jfr)](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/test/lib/sun/hotspot/WhiteBox.java)) > > Few additional obse... This pull request has now been integrated. Changeset: eace2d73 Author: Zdenek Zambersky URL: https://git.openjdk.org/jdk8u-dev/commit/eace2d732133accd3be9e95a9e75aee0fc1938f8 Stats: 1926 lines in 611 files changed: 8 ins; 1449 del; 469 mod 8305329: [8u] Unify test libraries into single test library - step 1 Reviewed-by: andrew ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/294 From andrew at openjdk.org Mon Nov 13 22:30:38 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Mon, 13 Nov 2023 22:30:38 GMT Subject: [jdk8u-dev] RFR: 8312489: Increase jdk.jar.maxSignatureFileSize default which is too low for JARs such as WhiteSource/Mend unified agent jar In-Reply-To: <7-xmb7wngXD3-DyOHNB9A0smkImvsSH2bj8SVpFSciw=.9a32be38-efdc-44ca-bdfa-af0cf111335c@github.com> References: <7-xmb7wngXD3-DyOHNB9A0smkImvsSH2bj8SVpFSciw=.9a32be38-efdc-44ca-bdfa-af0cf111335c@github.com> Message-ID: On Wed, 11 Oct 2023 00:57:35 GMT, Andrew John Hughes wrote: > The security fix, JDK-8300596, introduced a maximum size for signature-related files in JAR files, via the `jdk.jar.maxSignatureFileSize` property. The default value of 8MB has since proven to be too low for some JARs in general use. This change doubles it to 16MB, while still being much lower than the previous `MAX_ARRAY_SIZE` value of `Integer.MAX_VALUE - 8` > > This pull request contains a backport of commit [e47a84f2](https://github.com/openjdk/jdk/commit/e47a84f23dd2608c6f5748093eefe301fb5bf750) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. After path shuffling, the `SignatureFileVerifier.java` changes had to be applied manually due to the lack of `GetIntegerAction.privilegedGetProperty` in 8u. The actual changes are the same as for 11u+. Comparing the two patches: > > ~~~ > +@@ -855,16 +855,16 @@ public class SignatureFileVerifier { > * the maximum allowed number of bytes for the signature-related files > * in a JAR file. > */ > -- Integer tmp = GetIntegerAction.privilegedGetProperty( > -- "jdk.jar.maxSignatureFileSize", 8000000); > -+ int tmp = GetIntegerAction.privilegedGetProperty( > -+ "jdk.jar.maxSignatureFileSize", 16000000); > +- Integer tmp = AccessController.doPrivileged(new GetIntegerAction( > +- "jdk.jar.maxSignatureFileSize", 8000000)); > ++ int tmp = AccessController.doPrivileged(new GetIntegerAction( > ++ "jdk.jar.maxSignatureFileSize", 16000000)); > if (tmp < 0 || tmp > MAX_ARRAY_SIZE) { > if (debug != null) { > - debug.println("Default signature file size 8000000 bytes " + > ~~~ > > The commit being backported was authored by Hai-May Chao on 31 Jul 2023 and was reviewed by Sean Mullan and Matthias Baesken. Keep open please. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/381#issuecomment-1809236303 From andrew at openjdk.org Mon Nov 13 22:56:34 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Mon, 13 Nov 2023 22:56:34 GMT Subject: [jdk8u-dev] RFR: 8176509: Use pandoc for converting build readme to html In-Reply-To: <01kUiNSLqOdIym1MMbnadTTcD_mhhhpi75KmK0_MCm0=.487e2a77-b938-4853-bd90-c884be2a8c74@github.com> References: <-b_sIr0DdNgucwSKVckSqwjg0ChhDmEuf2e6YtHjXUs=.baa26a5c-fcc2-4523-ae18-bfaea88da7d8@github.com> <01kUiNSLqOdIym1MMbnadTTcD_mhhhpi75KmK0_MCm0=.487e2a77-b938-4853-bd90-c884be2a8c74@github.com> Message-ID: On Mon, 13 Nov 2023 17:08:19 GMT, Zdenek Zambersky wrote: > > Looks good to me. 8u build requirements seem to have been retained as is and I think moving the file to the final place here is the right thing to do. > > Yy, pandoc should be optional, it builds without it in GHA. > > Unfortunately there is little additional noise in `generated-configure.sh`'s diff concerning `--runstatedir` option, even though, I have used same version of autofonf, as was used before (2.69). It boils down to whether autoconf is ran on distro which has [specific backport](https://bugzilla.redhat.com/show_bug.cgi?id=1831941#c6). (Not present on rhel-8 I used) But I don't think this affects OpenJDK in any way. No, it shouldn't and one can always regenerate configure if it is an issue. I'm in two minds about whether it is finally time to backport [JDK-8195689](https://bugs.openjdk.org/browse/JDK-8195689) to 8u and get rid of this once and for all. It is the only JDK to have this baggage (it is removed in 11u and up) and I think it causes more problems than it solves, but then I've never been a fan of bundling generated files to begin with. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/370#issuecomment-1809262968 From duke at openjdk.org Tue Nov 14 07:18:28 2023 From: duke at openjdk.org (ktakakuri) Date: Tue, 14 Nov 2023 07:18:28 GMT Subject: [jdk8u-dev] RFR: 8160974: [TESTBUG] Mark more headful tests with @key headful. [v2] In-Reply-To: References: Message-ID: <-lKgBddwKX6-yG5rv8PNuy73SQQ_0ctmc0KfRtgQy2c=.af4d4ea7-40f6-4f0c-b1d9-9b8adf4ca86b@github.com> > This is a backport of JDK-8160974: [TESTBUG] Mark more headful tests with @key headful. > > This patch has already been applied to OracleJDK8. > As noted in the Bug Issue comments, some tests do not exist in 8u. ktakakuri has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into 8160974 - Backport e52b963d0cdc49e2048757eae2e4b10bb279f296 ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/383/files - new: https://git.openjdk.org/jdk8u-dev/pull/383/files/8983a17a..7fb82b04 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=383&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=383&range=00-01 Stats: 4927 lines in 673 files changed: 2003 ins; 2267 del; 657 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/383.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/383/head:pull/383 PR: https://git.openjdk.org/jdk8u-dev/pull/383 From zzambers at openjdk.org Tue Nov 14 11:41:44 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Tue, 14 Nov 2023 11:41:44 GMT Subject: [jdk8u-dev] RFR: 8176509: Use pandoc for converting build readme to html In-Reply-To: References: <-b_sIr0DdNgucwSKVckSqwjg0ChhDmEuf2e6YtHjXUs=.baa26a5c-fcc2-4523-ae18-bfaea88da7d8@github.com> <01kUiNSLqOdIym1MMbnadTTcD_mhhhpi75KmK0_MCm0=.487e2a77-b938-4853-bd90-c884be2a8c74@github.com> Message-ID: On Mon, 13 Nov 2023 22:53:32 GMT, Andrew John Hughes wrote: >>> Looks good to me. 8u build requirements seem to have been retained as is and I think moving the file to the final place here is the right thing to do. >> >> Yy, pandoc should be optional, it builds without it in GHA. >> >> Unfortunately there is little additional noise in `generated-configure.sh`'s diff concerning `--runstatedir` option, even though, I have used same version of autofonf, as was used before (2.69). It boils down to whether autoconf is ran on distro which has [specific backport](https://bugzilla.redhat.com/show_bug.cgi?id=1831941#c6). (Not present on rhel-8 I used) But I don't think this affects OpenJDK in any way. > >> > Looks good to me. 8u build requirements seem to have been retained as is and I think moving the file to the final place here is the right thing to do. >> >> Yy, pandoc should be optional, it builds without it in GHA. >> >> Unfortunately there is little additional noise in `generated-configure.sh`'s diff concerning `--runstatedir` option, even though, I have used same version of autofonf, as was used before (2.69). It boils down to whether autoconf is ran on distro which has [specific backport](https://bugzilla.redhat.com/show_bug.cgi?id=1831941#c6). (Not present on rhel-8 I used) But I don't think this affects OpenJDK in any way. > > No, it shouldn't and one can always regenerate configure if it is an issue. I'm in two minds about whether it is finally time to backport [JDK-8195689](https://bugs.openjdk.org/browse/JDK-8195689) to 8u and get rid of this once and for all. It is the only JDK to have this baggage (it is removed in 11u and up) and I think it causes more problems than it solves, but then I've never been a fan of bundling generated files to begin with. @gnu-andrew thanks ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/370#issuecomment-1810042504 From zzambers at openjdk.org Tue Nov 14 11:41:46 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Tue, 14 Nov 2023 11:41:46 GMT Subject: [jdk8u-dev] Integrated: 8176509: Use pandoc for converting build readme to html In-Reply-To: <-b_sIr0DdNgucwSKVckSqwjg0ChhDmEuf2e6YtHjXUs=.baa26a5c-fcc2-4523-ae18-bfaea88da7d8@github.com> References: <-b_sIr0DdNgucwSKVckSqwjg0ChhDmEuf2e6YtHjXUs=.baa26a5c-fcc2-4523-ae18-bfaea88da7d8@github.com> Message-ID: On Thu, 7 Sep 2023 20:09:14 GMT, Zdenek Zambersky wrote: > This backport switches to pandoc for coversion of building readme to html. It also does some style/formating changes/fixes to building readme, which is moved to new location and also removes redundant information in other Readme files. > > Backport is not clear. Code for coversion to html had to be modified to work with JDK8 build system. Change set (patch) for building readme mostly applied automatically, but some parts had to be done by hand due to few differences. > > Unlike in original change set, this backport moves `README-builds.{md,html}` files directly to `doc/building.{md,html}` and not to intermediate location `common/doc/building.{md,html}`. (additional move was done in jdk10 as part of [JDK-8187443](https://bugs.openjdk.org/browse/JDK-8187443)) This pull request has now been integrated. Changeset: 10a653e5 Author: Zdenek Zambersky URL: https://git.openjdk.org/jdk8u-dev/commit/10a653e5c3c07a1c823b12d295c86dc91201661c Stats: 5004 lines in 16 files changed: 2140 ins; 2854 del; 10 mod 8176509: Use pandoc for converting build readme to html Reviewed-by: andrew Backport-of: 9d0bd1b495012de5de1c62f65f14c4de36aef056 ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/370 From sgehwolf at openjdk.org Wed Nov 15 19:55:43 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 15 Nov 2023 19:55:43 GMT Subject: [jdk8u-dev] RFR: 8312489: Increase jdk.jar.maxSignatureFileSize default which is too low for JARs such as WhiteSource/Mend unified agent jar In-Reply-To: <7-xmb7wngXD3-DyOHNB9A0smkImvsSH2bj8SVpFSciw=.9a32be38-efdc-44ca-bdfa-af0cf111335c@github.com> References: <7-xmb7wngXD3-DyOHNB9A0smkImvsSH2bj8SVpFSciw=.9a32be38-efdc-44ca-bdfa-af0cf111335c@github.com> Message-ID: On Wed, 11 Oct 2023 00:57:35 GMT, Andrew John Hughes wrote: > The security fix, JDK-8300596, introduced a maximum size for signature-related files in JAR files, via the `jdk.jar.maxSignatureFileSize` property. The default value of 8MB has since proven to be too low for some JARs in general use. This change doubles it to 16MB, while still being much lower than the previous `MAX_ARRAY_SIZE` value of `Integer.MAX_VALUE - 8` > > This pull request contains a backport of commit [e47a84f2](https://github.com/openjdk/jdk/commit/e47a84f23dd2608c6f5748093eefe301fb5bf750) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. After path shuffling, the `SignatureFileVerifier.java` changes had to be applied manually due to the lack of `GetIntegerAction.privilegedGetProperty` in 8u. The actual changes are the same as for 11u+. Comparing the two patches: > > ~~~ > +@@ -855,16 +855,16 @@ public class SignatureFileVerifier { > * the maximum allowed number of bytes for the signature-related files > * in a JAR file. > */ > -- Integer tmp = GetIntegerAction.privilegedGetProperty( > -- "jdk.jar.maxSignatureFileSize", 8000000); > -+ int tmp = GetIntegerAction.privilegedGetProperty( > -+ "jdk.jar.maxSignatureFileSize", 16000000); > +- Integer tmp = AccessController.doPrivileged(new GetIntegerAction( > +- "jdk.jar.maxSignatureFileSize", 8000000)); > ++ int tmp = AccessController.doPrivileged(new GetIntegerAction( > ++ "jdk.jar.maxSignatureFileSize", 16000000)); > if (tmp < 0 || tmp > MAX_ARRAY_SIZE) { > if (debug != null) { > - debug.println("Default signature file size 8000000 bytes " + > ~~~ > > The commit being backported was authored by Hai-May Chao on 31 Jul 2023 and was reviewed by Sean Mullan and Matthias Baesken. Looks fine to me. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/381#pullrequestreview-1732834386 From andrew at openjdk.org Mon Nov 20 18:18:26 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Mon, 20 Nov 2023 18:18:26 GMT Subject: [jdk8u-dev] RFR: 8281096: Flags introduced by configure script are not passed to ADLC build In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 03:58:10 GMT, Andrew John Hughes wrote: > The 8u configure script defines compiler flags in `EXTRA_CFLAGS`, `EXTRA_LDFLAGS` and `EXTRA_ASFLAGS`. Some are added by configure tests, while others are taken directly from corresponding options passed by the user. > > 8u still use the legacy HotSpot build system which is not fully integrated with the autoconf system. Variables defined by configure thus have to be explicitly passed down to the separate HotSpot build. > > ADLC is a tool used at build-time and so the flags it uses don't impact on the end product. So, for a long time, it has been ignoring these flags defined by configure and using just its own minimal set. > > However, with newer compilers, this means that the code is compiled to a newer version of the C++ standard, as the default has changed in GCC 6 and later (see [JDK-8151841](https://bugs.openjdk.org/browse/JDK-8151841)). With the latest versions of GCC (11 and 12), this actually leads to build failures due to the use of 'register' (GCC 11) and the way comments are used (GCC 12) in the code. > > We should fix the ADLC build to use the same flags as the rest of the build. The impact should be negligible, given the same flags are already used in the code that is actually shipped. > > This does not affect 9+ where HotSpot's build system has been replaced with full integration in the autoconf system. > > With this change, 8u can be built with GCC 11 on GNU/Linux. I'd appreciate testing on other platforms, particularly those not covered by GHA (Solaris, AIX - @adamfarley, @sxa & @deepa181 who have provided previous fixes for these platforms) @deepa181 thanks for the feedback. It's good to know it doesn't break AIX. @tstuefe good catch. I need to find out why `LFLAGS` is missing on Solaris (assuming at the moment it's not used generally) and also check why it seemed to be failing on cross-compiles (we don't use them ourselves so that is untested prior to this) ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/357#issuecomment-1819577208 From andrew at openjdk.org Wed Nov 22 06:05:26 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 22 Nov 2023 06:05:26 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests Message-ID: This backport brings in `jtreg.SkippedException` which is used by JDK-8308592 (and likely other potential future backports as well). It is a test-only change which allows a skipped test to be correctly reported to jtreg, rather than it appearing like a successful run. The actual code changes to the HotSpot tests to use `SkippedException` were mostly clean. The main manual adaptations involved the placement of `import` statements (8u also doesn't have 8132919: 'Put compiler tests in packages') and copyright headers. Most tests also needed to have the library location `/test/lib` added. This is because the HotSpot tests are currently still using the HotSpot test library, not the top-level library. @zzambers work on this should eventually remove the need to reference both libraries. I've included with this change a number of follow-on changes which were necessary to make the changed tests pass. I don't know how the original version of 8208655 was committed as is, because it contains a number of typos and missing import statements which cause tests to fail. The follow-up changes are: * 8023735 backport. This change introduces the code which is altered by 8208655 to use `SkippedException`. The fix is simple enough to just backport with this change and fix the test in the process. It applied cleanly other than the `@ignore` line which has been replaced in 8u by a `ProblemList.txt` addition which is removed by this backport instead. * Addition of `vm.debug`; this is cherry-picked from 8155219: "[TESTBUG] Rewrite compiler/ciReplay/TestVM.sh in java" which first introduced it in later JDKs. The implementation needs to be adapted to work around the absence of `jdk.debug` (JDK-8139986). Using `java.vm.version` matches what happens in the `Platform.java` test library code. * 8208701: first fix for typos in 8208655 as committed. Some changes had to be manually applied due to context differences but otherwise a clean backport. * 8208706: fixes a missing `import` line in `ConstantGettersTransitionsTest.java`, which was applied manually due to differing context. * 8213410 backport which is necessary as 8208655 removes a number of checks altogether, replacing them with `@requires` statements. This is why we need `vm.debug` above and also this change due to the removed 32-bit check in `runtime/CompressedOops/CompressedClassPointers.java` * For consistency, the debug build check in `TestLargePageUseForAuxMemory.java` was replaced with vm.debug. In 11u, this is removed through the enhancement [JDK-8152491](https://bugs.openjdk.org/browse/JDK-8152491): "Convert TracePageSizes to use UL" Absent tests were omitted. Some may be worth a later backport and should ideally use `SkippedException` in backporting. * `test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java` - 8059625: JEP-197 JDK-8043304: Test task: DTrace- tests for segmented codecache feature * `test/compiler/intrinsics/base64/TestBase64.java` - 8205528: Base64 encoding algorithm using AVX512 instructions * `test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java` - 8136421: JEP 243: Java-Level JVM Compiler Interface * `test/runtime/libadimalloc.solaris.sparc/Testlibadimalloc.java` -- 8141445: Use of Solaris/SPARC M7 libadimalloc.so can generate unknown signal in hs_err file * `test/runtime/signal/SigTestDriver.java` -- JDK-8200126 Open source VM runtime signal tests (needs dep JDK-8072842) * `test/serviceability/jvmti/NotifyFramePop/NotifyFramePopTest.java` -- 8187289: NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled * `test/serviceability/sa/ClhsdbCDSCore.java` -- 8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS * `test/serviceability/sa/ClhsdbCDSJstackPrintAll.java` -- 8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS * `test/serviceability/sa/ClhsdbInspect.java` -- 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands * `test/serviceability/sa/ClhsdbJdis.java` -- 8193124: SA: Testcases for clhsdb jdis and findpc commands * `test/serviceability/sa/ClhsdbLongConstant.java` -- 8190198: SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands * `test/serviceability/sa/ClhsdbPrintAs.java` -- 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands * `test/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java` -- 8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC * `test/serviceability/sa/ClhsdbScanOops.java` -- 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands * `test/serviceability/sa/DeadlockDetectionTest.java` -- 8086134: Deadlock detection fails to attach to core file * `test/serviceability/sa/TestJmapCore.java` -- 8203491: [TESTBUG] Port heapdump tests into java * `test/vmTestbase/gc/g1/unloading/UnloadingTest.java` -- 8199370: [TESTBUG] Open source vm testbase GC tests * `test/vmTestbase/nsk/jdi/AttachingConnector/attach/attach004/TestDriver.java` -- 8199382: [TESTBUG] Open source VM testbase JDI tests * `test/vmTestbase/nsk/monitoring/stress/thread/strace001.java` -- 8199375: [TESTBUG] Open source vm testbase monitoring tests The following two are present, but in much older versions in different locations: * `test/compiler/codegen/aes/TestAESMain.java` -> `./test/compiler/7184394/TestAESMain.java 8207153: Some intrinsic tests take long time to run` * `test/compiler/codegen/aes/TestCipherBlockChainingEncrypt.java` -> `./test/compiler/8209951/TestCipherBlockChainingEncrypt.java` 8219513: compiler/codegen/aes/TestCipherBlockChainingEncrypt.java timeout on Solaris-sparc ------------- Commit messages: - 8213410: UseCompressedOops requirement check fails fails on 32-bit system - 8208706: compiler/tiered/ConstantGettersTransitionsTest.java fails to compile - 8208701: Fix for JDK-8208655 causes test failures in CI tier1 - Support vm.debug - 8023735: [TESTBUG] runtime/XCheckJniJsig/XCheckJSig.java fails on MacOS X - Backport 17b730d7edf7be91ee841180ea6a59b26c0c567a Changes: https://git.openjdk.org/jdk8u-dev/pull/387/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=387&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8208655 Stats: 266 lines in 32 files changed: 114 ins; 85 del; 67 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/387.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/387/head:pull/387 PR: https://git.openjdk.org/jdk8u-dev/pull/387 From andrew at openjdk.org Wed Nov 22 22:44:20 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 22 Nov 2023 22:44:20 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 05:59:32 GMT, Andrew John Hughes wrote: > This backport brings in `jtreg.SkippedException` which is used by JDK-8308592 (and likely other potential future backports as well). It is a test-only change which allows a skipped test to be correctly reported to jtreg, rather than it appearing like a successful run. > > The actual code changes to the HotSpot tests to use `SkippedException` were mostly clean. The main manual adaptations involved the placement of `import` statements (8u also doesn't have 8132919: 'Put compiler tests in packages') and copyright headers. Most tests also needed to have the library location `/test/lib` added. This is because the HotSpot tests are currently still using the HotSpot test library, not the top-level library. @zzambers work on this should eventually remove the need to reference both libraries. > > I've included with this change a number of follow-on changes which were necessary to make the changed tests pass. I don't know how the original version of 8208655 was committed as is, because it contains a number of typos and missing import statements which cause tests to fail. The follow-up changes are: > > * 8023735 backport. This change introduces the code which is altered by 8208655 to use `SkippedException`. The fix is simple enough to just backport with this change and fix the test in the process. It applied cleanly other than the `@ignore` line which has been replaced in 8u by a `ProblemList.txt` addition which is removed by this backport instead. > * Addition of `vm.debug`; this is cherry-picked from 8155219: "[TESTBUG] Rewrite compiler/ciReplay/TestVM.sh in java" which first introduced it in later JDKs. The implementation needs to be adapted to work around the absence of `jdk.debug` (JDK-8139986). Using `java.vm.version` matches what happens in the `Platform.java` test library code. > * 8208701: first fix for typos in 8208655 as committed. Some changes had to be manually applied due to context differences but otherwise a clean backport. > * 8208706: fixes a missing `import` line in `ConstantGettersTransitionsTest.java`, which was applied manually due to differing context. > * 8213410 backport which is necessary as 8208655 removes a number of checks altogether, replacing them with `@requires` statements. This is why we need `vm.debug` above and also this change due to the removed 32-bit check in `runtime/CompressedOops/CompressedClassPointers.java` > * For consistency, the debug build check in `TestLargePageUseForAuxMemory.java` was replaced with vm.debug. In 11u, this is removed t... Setting `requiredVersion` seems to have broken `test.Empty`, used by the four failing tests. Looking into the fix now. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/387#issuecomment-1823594654 From duke at openjdk.org Thu Nov 23 15:18:27 2023 From: duke at openjdk.org (duke) Date: Thu, 23 Nov 2023 15:18:27 GMT Subject: [jdk8u-dev] Withdrawn: 8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 09:39:50 GMT, Taizo Kurashige wrote: > Hi, > > This is a backport of JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" > > Original patch does not apply cleanly to JDK-8021961 applied code, because the fix uses "StringBuffer.isEmpty()" published in JDK15. I fixed the test so as not to use "StringBuffer.isEmpty()". > > Testing: jdk_awt on RHEL7, GHA testing > > Thanks. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/378 From andrew at openjdk.org Fri Nov 24 05:21:33 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 05:21:33 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: References: Message-ID: > This backport brings in `jtreg.SkippedException` which is used by JDK-8308592 (and likely other potential future backports as well). It is a test-only change which allows a skipped test to be correctly reported to jtreg, rather than it appearing like a successful run. > > The actual code changes to the HotSpot tests to use `SkippedException` were mostly clean. The main manual adaptations involved the placement of `import` statements (8u also doesn't have 8132919: 'Put compiler tests in packages') and copyright headers. Most tests also needed to have the library location `/test/lib` added. This is because the HotSpot tests are currently still using the HotSpot test library, not the top-level library. @zzambers work on this should eventually remove the need to reference both libraries. > > I've included with this change a number of follow-on changes which were necessary to make the changed tests pass. I don't know how the original version of 8208655 was committed as is, because it contains a number of typos and missing import statements which cause tests to fail. The follow-up changes are: > > * 8023735 backport. This change introduces the code which is altered by 8208655 to use `SkippedException`. The fix is simple enough to just backport with this change and fix the test in the process. It applied cleanly other than the `@ignore` line which has been replaced in 8u by a `ProblemList.txt` addition which is removed by this backport instead. > * Addition of `vm.debug`; this is cherry-picked from 8155219: "[TESTBUG] Rewrite compiler/ciReplay/TestVM.sh in java" which first introduced it in later JDKs. The implementation needs to be adapted to work around the absence of `jdk.debug` (JDK-8139986). Using `java.vm.version` matches what happens in the `Platform.java` test library code. > * 8208701: first fix for typos in 8208655 as committed. Some changes had to be manually applied due to context differences but otherwise a clean backport. > * 8208706: fixes a missing `import` line in `ConstantGettersTransitionsTest.java`, which was applied manually due to differing context. > * 8213410 backport which is necessary as 8208655 removes a number of checks altogether, replacing them with `@requires` statements. This is why we need `vm.debug` above and also this change due to the removed 32-bit check in `runtime/CompressedOops/CompressedClassPointers.java` > * For consistency, the debug build check in `TestLargePageUseForAuxMemory.java` was replaced with vm.debug. In 11u, this is removed t... Andrew John Hughes has updated the pull request incrementally with three additional commits since the last revision: - 8183503: Update hotspot tests to allow for unique test classes directory - 8186095: upgrade to jtreg 4.2 b08 - 8129355: [TESTBUG] runtime FragmentMetaspaceSimple.java fails with java.lang.ClassNotFoundException: test.Empty ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/387/files - new: https://git.openjdk.org/jdk8u-dev/pull/387/files/dee3121f..2608b80d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=387&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=387&range=00-01 Stats: 93 lines in 3 files changed: 80 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/387.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/387/head:pull/387 PR: https://git.openjdk.org/jdk8u-dev/pull/387 From andrew at openjdk.org Fri Nov 24 05:27:12 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 05:27:12 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 05:21:33 GMT, Andrew John Hughes wrote: >> This backport brings in `jtreg.SkippedException` which is used by JDK-8308592 (and likely other potential future backports as well). It is a test-only change which allows a skipped test to be correctly reported to jtreg, rather than it appearing like a successful run. >> >> The actual code changes to the HotSpot tests to use `SkippedException` were mostly clean. The main manual adaptations involved the placement of `import` statements (8u also doesn't have 8132919: 'Put compiler tests in packages') and copyright headers. Most tests also needed to have the library location `/test/lib` added. This is because the HotSpot tests are currently still using the HotSpot test library, not the top-level library. @zzambers work on this should eventually remove the need to reference both libraries. >> >> I've included with this change a number of follow-on changes which were necessary to make the changed tests pass. I don't know how the original version of 8208655 was committed as is, because it contains a number of typos and missing import statements which cause tests to fail. The follow-up changes are: >> >> * 8023735 backport. This change introduces the code which is altered by 8208655 to use `SkippedException`. The fix is simple enough to just backport with this change and fix the test in the process. It applied cleanly other than the `@ignore` line which has been replaced in 8u by a `ProblemList.txt` addition which is removed by this backport instead. >> * Addition of `vm.debug`; this is cherry-picked from 8155219: "[TESTBUG] Rewrite compiler/ciReplay/TestVM.sh in java" which first introduced it in later JDKs. The implementation needs to be adapted to work around the absence of `jdk.debug` (JDK-8139986). Using `java.vm.version` matches what happens in the `Platform.java` test library code. >> * 8208701: first fix for typos in 8208655 as committed. Some changes had to be manually applied due to context differences but otherwise a clean backport. >> * 8208706: fixes a missing `import` line in `ConstantGettersTransitionsTest.java`, which was applied manually due to differing context. >> * 8213410 backport which is necessary as 8208655 removes a number of checks altogether, replacing them with `@requires` statements. This is why we need `vm.debug` above and also this change due to the removed 32-bit check in `runtime/CompressedOops/CompressedClassPointers.java` >> * For consistency, the debug build check in `TestLargePageUseForAuxMemory.java` was replaced with vm.debug. I... > > Andrew John Hughes has updated the pull request incrementally with three additional commits since the last revision: > > - 8183503: Update hotspot tests to allow for unique test classes directory > - 8186095: upgrade to jtreg 4.2 b08 > - 8129355: [TESTBUG] runtime FragmentMetaspaceSimple.java fails with java.lang.ClassNotFoundException: test.Empty 8129355 was a clean backport and a pre-requisite for 8186095 8186095 was a clean backport for the test file. The version bump to `TEST.ROOT` was omitted as we already introduced this in the main patch. 8183503 was a clean backport for the library file we needed to update, `hotspot/test/runtime/testlibrary/ClassUnloadCommon.java`. `hotspot/test/runtime/logging/ClassLoadUnloadTest.java` does not exist in 8u (no Unified Logging from 8079408). The `hotspot/test/compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java` change is essentially a reversion of the change from JDK-8132919: "Put compiler tests in packages" which creates a path from the fully qualified class name. We don't have this in 8u so, while we use the more flexible version from 8183503 that doesn't hardcode the class name, the code is essentially unchanged. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/387#issuecomment-1825163046 From andrew at openjdk.org Fri Nov 24 05:27:12 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 05:27:12 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 05:23:23 GMT, Andrew John Hughes wrote: >> Andrew John Hughes has updated the pull request incrementally with three additional commits since the last revision: >> >> - 8183503: Update hotspot tests to allow for unique test classes directory >> - 8186095: upgrade to jtreg 4.2 b08 >> - 8129355: [TESTBUG] runtime FragmentMetaspaceSimple.java fails with java.lang.ClassNotFoundException: test.Empty > > 8129355 was a clean backport and a pre-requisite for 8186095 > 8186095 was a clean backport for the test file. The version bump to `TEST.ROOT` was omitted as we already introduced this in the main patch. > 8183503 was a clean backport for the library file we needed to update, `hotspot/test/runtime/testlibrary/ClassUnloadCommon.java`. `hotspot/test/runtime/logging/ClassLoadUnloadTest.java` does not exist in 8u (no Unified Logging from 8079408). The `hotspot/test/compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java` change is essentially a reversion of the change from JDK-8132919: "Put compiler tests in packages" which creates a path from the fully qualified class name. We don't have this in 8u so, while we use the more flexible version from 8183503 that doesn't hardcode the class name, the code is essentially unchanged. > @gnu-andrew The issue `8129355` was not found in the `JDK` project - make sure you have entered it correctly. As there were validation problems, no additional issues will be added to the list of solved issues. This is correct, but the bug is private for some reason. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/387#issuecomment-1825163909 From andrew at openjdk.org Fri Nov 24 07:17:21 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 07:17:21 GMT Subject: [jdk8u-dev] RFR: 8297955: LDAP CertStore should use LdapName and not String for DNs Message-ID: [JDK-8308592](https://bugs.openjdk.org/browse/JDK-8308592): "Framework for CA interoperability testing" merges the Actalis test into a single test which handles multiple CAs. Before we can backport that, we thus need to fix the Actalis test by backporting [JDK-8297955](https://bugs.openjdk.org/browse/JDK-8297955) which also fixes [8224768](https://bugs.openjdk.org/browse/JDK-8224768) The backport is mostly clean. The code changes apply cleanly once applied to `LDAPCertStore.java` rather than `LDAPCertStoreImpl.java` which doesn't exist in 8u (a refactoring in [JDK-8038084](https://bugs.openjdk.org/browse/JDK-8038084): "CertStore needs a way to add new CertStore types"). The unused `getName()` method needed to be removed as `name` is no longer a `String`. The `ProblemList.txt` change had to be manually added as did the copyright header change to `LDAPCertStore.java`. The Actalis test passes after this backport. All other CA results match those on an unpatched build (GoogleCA currently seems to be broken on all 8u builds I had to hand) ------------- Depends on: https://git.openjdk.org/jdk8u-dev/pull/387 Commit messages: - Backport 7f1047edba68cfe2fa2660030cb3dd1abad49e4f Changes: https://git.openjdk.org/jdk8u-dev/pull/388/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=388&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297955 Stats: 299 lines in 3 files changed: 56 ins; 88 del; 155 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/388.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/388/head:pull/388 PR: https://git.openjdk.org/jdk8u-dev/pull/388 From andrew at openjdk.org Fri Nov 24 07:26:33 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 07:26:33 GMT Subject: [jdk8u-dev] RFR: 8312126: NullPointerException in CertStore.getCRLs after 8297955 Message-ID: <-58cu-nBHMzhzyvO-YuvaER1drfZvYcWEGeojP-Pvjg=.1262d53a-3375-4bd7-a706-dc07264a2713@github.com> Hi all, This pull request contains a backport of commit [3c743cfe](https://github.com/openjdk/jdk/commit/3c743cfea00692d0b938cb1cbde936084eecf369) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Sean Mullan on 15 Sep 2023 and was reviewed by Weijun Wang. It was backported to 17u on 2023-11-10 and [a PR is open for 11u](https://github.com/openjdk/jdk11u-dev/pull/2299). It is a simple fix and clean backport for a regression introduced by [JDK-8297955](https://bugs.openjdk.org/browse/JDK-8297955) which was backported in [PR 388](https://github.com/openjdk/jdk8u-dev/pull/388). The new code in JDK-8297955 failed to catch a null IssuerName, allowing a NullPointerException to be thrown instead of the specified CertStoreException. Thanks. ------------- Depends on: https://git.openjdk.org/jdk8u-dev/pull/388 Commit messages: - Backport 3c743cfea00692d0b938cb1cbde936084eecf369 Changes: https://git.openjdk.org/jdk8u-dev/pull/389/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=389&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312126 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/389.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/389/head:pull/389 PR: https://git.openjdk.org/jdk8u-dev/pull/389 From stuefe at openjdk.org Fri Nov 24 07:53:17 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 24 Nov 2023 07:53:17 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: References: Message-ID: <3XlvVjADcLM9XcSCLny9ZoIuOMd2p6nCBbSKrH0jGcs=.8325d7c7-b865-42ff-9874-d33c0503e2f9@github.com> On Fri, 24 Nov 2023 05:21:33 GMT, Andrew John Hughes wrote: >> This backport brings in `jtreg.SkippedException` which is used by JDK-8308592 (and likely other potential future backports as well). It is a test-only change which allows a skipped test to be correctly reported to jtreg, rather than it appearing like a successful run. >> >> The actual code changes to the HotSpot tests to use `SkippedException` were mostly clean. The main manual adaptations involved the placement of `import` statements (8u also doesn't have 8132919: 'Put compiler tests in packages') and copyright headers. Most tests also needed to have the library location `/test/lib` added. This is because the HotSpot tests are currently still using the HotSpot test library, not the top-level library. @zzambers work on this should eventually remove the need to reference both libraries. >> >> I've included with this change a number of follow-on changes which were necessary to make the changed tests pass. I don't know how the original version of 8208655 was committed as is, because it contains a number of typos and missing import statements which cause tests to fail. The follow-up changes are: >> >> * 8023735 backport. This change introduces the code which is altered by 8208655 to use `SkippedException`. The fix is simple enough to just backport with this change and fix the test in the process. It applied cleanly other than the `@ignore` line which has been replaced in 8u by a `ProblemList.txt` addition which is removed by this backport instead. >> * Addition of `vm.debug`; this is cherry-picked from 8155219: "[TESTBUG] Rewrite compiler/ciReplay/TestVM.sh in java" which first introduced it in later JDKs. The implementation needs to be adapted to work around the absence of `jdk.debug` (JDK-8139986). Using `java.vm.version` matches what happens in the `Platform.java` test library code. >> * 8208701: first fix for typos in 8208655 as committed. Some changes had to be manually applied due to context differences but otherwise a clean backport. >> * 8208706: fixes a missing `import` line in `ConstantGettersTransitionsTest.java`, which was applied manually due to differing context. >> * 8213410 backport which is necessary as 8208655 removes a number of checks altogether, replacing them with `@requires` statements. This is why we need `vm.debug` above and also this change due to the removed 32-bit check in `runtime/CompressedOops/CompressedClassPointers.java` >> * For consistency, the debug build check in `TestLargePageUseForAuxMemory.java` was replaced with vm.debug. I... > > Andrew John Hughes has updated the pull request incrementally with three additional commits since the last revision: > > - 8183503: Update hotspot tests to allow for unique test classes directory > - 8186095: upgrade to jtreg 4.2 b08 > - 8129355: [TESTBUG] runtime FragmentMetaspaceSimple.java fails with java.lang.ClassNotFoundException: test.Empty Looked through the tests, mainly with an eye for required/skipped replacements of existing manual test exclusion. Also looked a the libjsig test a bit more closely. I did not directly compare all patches against the new one (now I understand why you maintainers dislike compound patches so much). hotspot/test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java line 28: > 26: * @bug 8004924 > 27: * @summary Checks that jmap -heap contains the flag CompressedClassSpaceSize > 28: * @requires vm.bits == 64 Not sure about this. The flag itself exists also on 32-bit, so the test should work there; it is pointless though since the flag is never used. hotspot/test/gc/metaspace/TestMetaspaceMemoryPool.java line 33: > 31: * @summary Tests that a MemoryPoolMXBeans is created for metaspace and that a > 32: * MemoryManagerMXBean is created. > 33: * @requires vm.bits == 64 Why? We have metaspace also on 32-bit, just no class space. ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/387#pullrequestreview-1747447134 PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/387#discussion_r1404033873 PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/387#discussion_r1404032827 From andrew at openjdk.org Fri Nov 24 08:36:45 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 08:36:45 GMT Subject: [jdk8u-dev] RFR: 8308592: Framework for CA interoperability testing Message-ID: Hi all, This pull request contains a backport of commit [da57d2a1](https://github.com/openjdk/jdk/commit/da57d2a1eb409ddc64117865c7d24ed518421cab) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Rajan Halade on 19 Sep 2023 and was reviewed by Sean Mullan. It was backported to 17u on 2023-09-28 and 11u on 2023-10-11 It reworks the certificate tests to use test portals rather than having to maintain copies of the certificates in the OpenJDK repository and so should reduce the maintenance cost of these tests going forward. The fix has already been backported to 21u and Oracle-17u. There were conflicts in the removals of `ActalisCA.java`, `BuypassCA.java`, `LetsEncryptCA.java` and `QuoVadisCA.java`, due to changes not in 8u. For the first of these, we backported JDK-8297955 (see #388) as it also contains a code change. As the other three are only test changes, we assumed these bugs to be resolved by the replacement of the individual tests with `CAInterop.java`. The `ValidatePathWithURL.java` class had to be modified slightly to work with the 8u `cacerts`. These changes were based on the existing `ValidatePathWithParams.java`. All tests pass with the exception of the OCSP case of `certignarootca`. This fails with `Caused by: java.security.cert.CertPathValidatorException: Certificate does not specify OCSP responder`. While not ideal, I don't think this is an issue with the testing backport so I'd suggest we look into this and fix it later, while getting this in so that pending certificate updates can go in. It seems to be 8u specific (the case passed on 11u). The CRL case does pass as does `CertignaCA.java` (not sure why there are two tests for this one). ------------- Depends on: https://git.openjdk.org/jdk8u-dev/pull/389 Commit messages: - Backport c4faab66933b5977a466f28c31cba9fc099c8fb4 Changes: https://git.openjdk.org/jdk8u-dev/pull/390/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=390&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308592 Stats: 6503 lines in 18 files changed: 1012 ins; 5491 del; 0 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/390.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/390/head:pull/390 PR: https://git.openjdk.org/jdk8u-dev/pull/390 From andrew at openjdk.org Fri Nov 24 08:36:46 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 08:36:46 GMT Subject: [jdk8u-dev] RFR: 8308592: Framework for CA interoperability testing In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 08:24:59 GMT, Andrew John Hughes wrote: > Hi all, > > This pull request contains a backport of commit [da57d2a1](https://github.com/openjdk/jdk/commit/da57d2a1eb409ddc64117865c7d24ed518421cab) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Rajan Halade on 19 Sep 2023 and was reviewed by Sean Mullan. It was backported to 17u on 2023-09-28 and 11u on 2023-10-11 > > It reworks the certificate tests to use test portals rather than having to maintain copies of the certificates in the OpenJDK repository and so should reduce the maintenance cost of these tests going forward. The fix has already been backported to 21u and Oracle-17u. > > There were conflicts in the removals of `ActalisCA.java`, `BuypassCA.java`, `LetsEncryptCA.java` and `QuoVadisCA.java`, due to changes not in 8u. For the first of these, we backported JDK-8297955 (see #388) as it also contains a code change. As the other three are only test changes, we assumed these bugs to be resolved by the replacement of the individual tests with `CAInterop.java`. > > The `ValidatePathWithURL.java` class had to be modified slightly to work with the 8u `cacerts`. These changes were based on the existing `ValidatePathWithParams.java`. > > All tests pass with the exception of the OCSP case of `certignarootca`. This fails with `Caused by: java.security.cert.CertPathValidatorException: Certificate does not specify OCSP responder`. While not ideal, I don't think this is an issue with the testing backport so I'd suggest we look into this and fix it later, while getting this in so that pending certificate updates can go in. It seems to be 8u specific (the case passed on 11u). The CRL case does pass as does `CertignaCA.java` (not sure why there are two tests for this one). ~~~ Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#actalisauthenticationrootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass3ca FAILED: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#certignarootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodoeccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodorsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcaec1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcag4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsigneccrootcar4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsignrootcar6 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#godaddyrootg2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootecccar3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootecccar4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#letsencryptisrgx1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#microsoftecc2017 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#microsoftrsa2017 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca2g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca3g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrooteccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrootevrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrootrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#starfieldrootg2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#twcaglobalrootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#usertrusteccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#usertrustrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CertignaCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/DTrustCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/HaricaCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java Test results: passed: 36; failed: 1 ~~~ ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/390#issuecomment-1825311821 From andrew at openjdk.org Fri Nov 24 08:42:15 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 08:42:15 GMT Subject: [jdk8u-dev] RFR: 8297955: LDAP CertStore should use LdapName and not String for DNs In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 07:10:49 GMT, Andrew John Hughes wrote: > [JDK-8308592](https://bugs.openjdk.org/browse/JDK-8308592): "Framework for CA interoperability testing" merges the Actalis test into a single test which handles multiple CAs. Before we can backport that, we thus need to fix the Actalis test by backporting [JDK-8297955](https://bugs.openjdk.org/browse/JDK-8297955) which also fixes [8224768](https://bugs.openjdk.org/browse/JDK-8224768) > > The backport is mostly clean. The code changes apply cleanly once applied to `LDAPCertStore.java` rather than `LDAPCertStoreImpl.java` which doesn't exist in 8u (a refactoring in [JDK-8038084](https://bugs.openjdk.org/browse/JDK-8038084): "CertStore needs a way to add new CertStore types"). The unused `getName()` method needed to be removed as `name` is no longer a `String`. The `ProblemList.txt` change had to be manually added as did the copyright header change to `LDAPCertStore.java`. > > The Actalis test passes after this backport. All other CA results match those on an unpatched build (GoogleCA currently seems to be broken on all 8u builds I had to hand) HotSpot failure looks like a sporadic GC test failure and unrelated to a JDK code change. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/388#issuecomment-1825317663 From sgehwolf at openjdk.org Fri Nov 24 13:47:13 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 24 Nov 2023 13:47:13 GMT Subject: [jdk8u-dev] RFR: 8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 09:39:50 GMT, Taizo Kurashige wrote: > Hi, > > This is a backport of JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" > > Original patch does not apply cleanly to JDK-8021961 applied code, because the fix uses "StringBuffer.isEmpty()" published in JDK15. I fixed the test so as not to use "StringBuffer.isEmpty()". > > Testing: jdk_awt on RHEL7, GHA testing > > Thanks. Seems OK. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/378#pullrequestreview-1747977409 From sgehwolf at openjdk.org Fri Nov 24 14:32:15 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 24 Nov 2023 14:32:15 GMT Subject: [jdk8u-dev] RFR: 8160974: [TESTBUG] Mark more headful tests with @key headful. [v2] In-Reply-To: <-lKgBddwKX6-yG5rv8PNuy73SQQ_0ctmc0KfRtgQy2c=.af4d4ea7-40f6-4f0c-b1d9-9b8adf4ca86b@github.com> References: <-lKgBddwKX6-yG5rv8PNuy73SQQ_0ctmc0KfRtgQy2c=.af4d4ea7-40f6-4f0c-b1d9-9b8adf4ca86b@github.com> Message-ID: On Tue, 14 Nov 2023 07:18:28 GMT, ktakakuri wrote: >> This is a backport of JDK-8160974: [TESTBUG] Mark more headful tests with @key headful. >> >> This patch has already been applied to OracleJDK8. >> As noted in the Bug Issue comments, some tests do not exist in 8u. > > ktakakuri has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8160974 > - Backport e52b963d0cdc49e2048757eae2e4b10bb279f296 There are test failures. See GHA. E.g.: Error: Test clashes with another test with a similar name: /home/runner/work/jdk8u-dev/jdk8u-dev/jdk/test/java/awt/Focus/MouseClickRequestFocusRaceTest/MouseClickRequestFocusRaceTest.java /home/runner/work/jdk8u-dev/jdk8u-dev/jdk/test/java/awt/Focus/MouseClickRequestFocusRaceTest/MouseClickRequestFocusRaceTest.html Please fix. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/383#issuecomment-1825753297 From andrew at openjdk.org Fri Nov 24 14:47:16 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 14:47:16 GMT Subject: [jdk8u-dev] Integrated: 8312489: Increase jdk.jar.maxSignatureFileSize default which is too low for JARs such as WhiteSource/Mend unified agent jar In-Reply-To: <7-xmb7wngXD3-DyOHNB9A0smkImvsSH2bj8SVpFSciw=.9a32be38-efdc-44ca-bdfa-af0cf111335c@github.com> References: <7-xmb7wngXD3-DyOHNB9A0smkImvsSH2bj8SVpFSciw=.9a32be38-efdc-44ca-bdfa-af0cf111335c@github.com> Message-ID: On Wed, 11 Oct 2023 00:57:35 GMT, Andrew John Hughes wrote: > The security fix, JDK-8300596, introduced a maximum size for signature-related files in JAR files, via the `jdk.jar.maxSignatureFileSize` property. The default value of 8MB has since proven to be too low for some JARs in general use. This change doubles it to 16MB, while still being much lower than the previous `MAX_ARRAY_SIZE` value of `Integer.MAX_VALUE - 8` > > This pull request contains a backport of commit [e47a84f2](https://github.com/openjdk/jdk/commit/e47a84f23dd2608c6f5748093eefe301fb5bf750) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. After path shuffling, the `SignatureFileVerifier.java` changes had to be applied manually due to the lack of `GetIntegerAction.privilegedGetProperty` in 8u. The actual changes are the same as for 11u+. Comparing the two patches: > > ~~~ > +@@ -855,16 +855,16 @@ public class SignatureFileVerifier { > * the maximum allowed number of bytes for the signature-related files > * in a JAR file. > */ > -- Integer tmp = GetIntegerAction.privilegedGetProperty( > -- "jdk.jar.maxSignatureFileSize", 8000000); > -+ int tmp = GetIntegerAction.privilegedGetProperty( > -+ "jdk.jar.maxSignatureFileSize", 16000000); > +- Integer tmp = AccessController.doPrivileged(new GetIntegerAction( > +- "jdk.jar.maxSignatureFileSize", 8000000)); > ++ int tmp = AccessController.doPrivileged(new GetIntegerAction( > ++ "jdk.jar.maxSignatureFileSize", 16000000)); > if (tmp < 0 || tmp > MAX_ARRAY_SIZE) { > if (debug != null) { > - debug.println("Default signature file size 8000000 bytes " + > ~~~ > > The commit being backported was authored by Hai-May Chao on 31 Jul 2023 and was reviewed by Sean Mullan and Matthias Baesken. This pull request has now been integrated. Changeset: b372b4b5 Author: Andrew John Hughes URL: https://git.openjdk.org/jdk8u-dev/commit/b372b4b502cb07eb3477c8ba1fbc8393b1bd56ff Stats: 9 lines in 2 files changed: 2 ins; 0 del; 7 mod 8312489: Increase jdk.jar.maxSignatureFileSize default which is too low for JARs such as WhiteSource/Mend unified agent jar Reviewed-by: sgehwolf Backport-of: e47a84f23dd2608c6f5748093eefe301fb5bf750 ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/381 From sgehwolf at openjdk.org Fri Nov 24 14:49:14 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 24 Nov 2023 14:49:14 GMT Subject: [jdk8u-dev] RFR: 8297955: LDAP CertStore should use LdapName and not String for DNs In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 07:10:49 GMT, Andrew John Hughes wrote: > [JDK-8308592](https://bugs.openjdk.org/browse/JDK-8308592): "Framework for CA interoperability testing" merges the Actalis test into a single test which handles multiple CAs. Before we can backport that, we thus need to fix the Actalis test by backporting [JDK-8297955](https://bugs.openjdk.org/browse/JDK-8297955) which also fixes [8224768](https://bugs.openjdk.org/browse/JDK-8224768) > > The backport is mostly clean. The code changes apply cleanly once applied to `LDAPCertStore.java` rather than `LDAPCertStoreImpl.java` which doesn't exist in 8u (a refactoring in [JDK-8038084](https://bugs.openjdk.org/browse/JDK-8038084): "CertStore needs a way to add new CertStore types"). The unused `getName()` method needed to be removed as `name` is no longer a `String`. The `ProblemList.txt` change had to be manually added as did the copyright header change to `LDAPCertStore.java`. > > The Actalis test passes after this backport. All other CA results match those on an unpatched build (GoogleCA currently seems to be broken on all 8u builds I had to hand) This looks OK. `getName()` got removed in later JDKs, by JDK-8224729. This patch is fine, though. No need to drag in that additional dependency. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/388#pullrequestreview-1748071509 From andrew at openjdk.org Fri Nov 24 14:52:15 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 14:52:15 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: <3XlvVjADcLM9XcSCLny9ZoIuOMd2p6nCBbSKrH0jGcs=.8325d7c7-b865-42ff-9874-d33c0503e2f9@github.com> References: <3XlvVjADcLM9XcSCLny9ZoIuOMd2p6nCBbSKrH0jGcs=.8325d7c7-b865-42ff-9874-d33c0503e2f9@github.com> Message-ID: On Fri, 24 Nov 2023 07:50:30 GMT, Thomas Stuefe wrote: > Looked through the tests, mainly with an eye for required/skipped replacements of existing manual test exclusion. Also looked a the libjsig test a bit more closely. I did not directly compare all patches against the new one (now I understand why you maintainers dislike compound patches so much). Yes, this is why I at least kept the individual backports to separate commits, so a 1-to-1 comparison can still be performed while this change doesn't break any tests. I could split it into about half a dozen separate PRs but I'm not sure there's much advantage (plus we already have a dependency chain of four to get to #390) and the first change would result in several test failures being introduced. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/387#issuecomment-1825777531 From sgehwolf at openjdk.org Fri Nov 24 15:07:16 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 24 Nov 2023 15:07:16 GMT Subject: [jdk8u-dev] RFR: 8312126: NullPointerException in CertStore.getCRLs after 8297955 In-Reply-To: <-58cu-nBHMzhzyvO-YuvaER1drfZvYcWEGeojP-Pvjg=.1262d53a-3375-4bd7-a706-dc07264a2713@github.com> References: <-58cu-nBHMzhzyvO-YuvaER1drfZvYcWEGeojP-Pvjg=.1262d53a-3375-4bd7-a706-dc07264a2713@github.com> Message-ID: <4mphRo_96ZuNH204qIPEO6xPKI4fMVRznnchnyZoR3U=.37cd81ca-08c7-4ad7-b19d-56cd0060a09e@github.com> On Fri, 24 Nov 2023 07:21:24 GMT, Andrew John Hughes wrote: > Hi all, > > This pull request contains a backport of commit [3c743cfe](https://github.com/openjdk/jdk/commit/3c743cfea00692d0b938cb1cbde936084eecf369) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Sean Mullan on 15 Sep 2023 and was reviewed by Weijun Wang. It was backported to 17u on 2023-11-10 and [a PR is open for 11u](https://github.com/openjdk/jdk11u-dev/pull/2299). > > It is a simple fix and clean backport for a regression introduced by [JDK-8297955](https://bugs.openjdk.org/browse/JDK-8297955) which was backported in [PR 388](https://github.com/openjdk/jdk8u-dev/pull/388). The new code in JDK-8297955 failed to catch a null IssuerName, allowing a NullPointerException to be thrown instead of the specified CertStoreException. > > Thanks. OK. GHA test failure on 32 bit Linux seems unrelated: `gc/6581734/Test6581734.java` (timeout). ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/389#pullrequestreview-1748098746 PR Comment: https://git.openjdk.org/jdk8u-dev/pull/389#issuecomment-1825793260 From andrew at openjdk.org Fri Nov 24 15:17:17 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 15:17:17 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: <3XlvVjADcLM9XcSCLny9ZoIuOMd2p6nCBbSKrH0jGcs=.8325d7c7-b865-42ff-9874-d33c0503e2f9@github.com> References: <3XlvVjADcLM9XcSCLny9ZoIuOMd2p6nCBbSKrH0jGcs=.8325d7c7-b865-42ff-9874-d33c0503e2f9@github.com> Message-ID: On Fri, 24 Nov 2023 07:44:00 GMT, Thomas Stuefe wrote: >> Andrew John Hughes has updated the pull request incrementally with three additional commits since the last revision: >> >> - 8183503: Update hotspot tests to allow for unique test classes directory >> - 8186095: upgrade to jtreg 4.2 b08 >> - 8129355: [TESTBUG] runtime FragmentMetaspaceSimple.java fails with java.lang.ClassNotFoundException: test.Empty > > hotspot/test/gc/metaspace/TestMetaspaceMemoryPool.java line 33: > >> 31: * @summary Tests that a MemoryPoolMXBeans is created for metaspace and that a >> 32: * MemoryManagerMXBean is created. >> 33: * @requires vm.bits == 64 > > Why? We have metaspace also on 32-bit, just no class space. This and the other test you commented on are https://bugs.openjdk.org/browse/JDK-8213410 The change was backported for the alteration to `runtime/CompressedOops/CompressedClassPointers.java` which would otherwise have its code-based 64-bit check removed by 8208655 and not replaced. Both of the other tests have this restriction up to trunk as well. I think the history comes from adding `vm.opt.final.UseCompressedOops` in [JDK-8204167](https://bugs.openjdk.org/browse/JDK-8204167) which causes the error shown in 8213410, even though the actual run would work without compressed oops thanks to `-XX:+IgnoreUnrecognizedVMOptions`. `TestMetaspaceMemoryPool` even still includes a `if (Platform.is64bit())` and `if (InputArguments.contains("-XX:+UseCompressedOops"))` in the `main` method which enforce the same restrictions. I did look at backporting JDK-8204167 as well, but `vm.opt.final.UseCompressedOops` returned `null` for me even on x86_64. Maybe some test infrastructure or HotSpot change we are missing. I don't see any issue with backporting the whole patch, given the exclusions are also there in 11+. If there is a case for running these on 32-bit, the restriction should probably be dropped in trunk and backported down for consistency. ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/387#discussion_r1404455272 From andrew at openjdk.org Fri Nov 24 15:19:18 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 15:19:18 GMT Subject: [jdk8u-dev] RFR: 8297955: LDAP CertStore should use LdapName and not String for DNs In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 14:46:15 GMT, Severin Gehwolf wrote: > This looks OK. `getName()` got removed in later JDKs, by JDK-8224729. This patch is fine, though. No need to drag in that additional dependency. Thanks. I'd assumed it was part of the big refactoring in [JDK-8038084](https://bugs.openjdk.org/browse/JDK-8038084) - and it's definitely a no for that one - but it seems it survived a bit longer and 8224729 was also backported for the 11 backport of this. I agree just removing `getName` is enough and we don't need to add more dependencies with that change. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/388#issuecomment-1825809567 From stuefe at openjdk.org Fri Nov 24 15:33:15 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 24 Nov 2023 15:33:15 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: References: Message-ID: <3YRVElyMk7r-cNwmuznbXPU3cBdK4njoIG0QmnAkU_Y=.54deb988-f54b-490b-8d03-0e93713771fd@github.com> On Fri, 24 Nov 2023 05:21:33 GMT, Andrew John Hughes wrote: >> This backport brings in `jtreg.SkippedException` which is used by JDK-8308592 (and likely other potential future backports as well). It is a test-only change which allows a skipped test to be correctly reported to jtreg, rather than it appearing like a successful run. >> >> The actual code changes to the HotSpot tests to use `SkippedException` were mostly clean. The main manual adaptations involved the placement of `import` statements (8u also doesn't have 8132919: 'Put compiler tests in packages') and copyright headers. Most tests also needed to have the library location `/test/lib` added. This is because the HotSpot tests are currently still using the HotSpot test library, not the top-level library. @zzambers work on this should eventually remove the need to reference both libraries. >> >> I've included with this change a number of follow-on changes which were necessary to make the changed tests pass. I don't know how the original version of 8208655 was committed as is, because it contains a number of typos and missing import statements which cause tests to fail. The follow-up changes are: >> >> * 8023735 backport. This change introduces the code which is altered by 8208655 to use `SkippedException`. The fix is simple enough to just backport with this change and fix the test in the process. It applied cleanly other than the `@ignore` line which has been replaced in 8u by a `ProblemList.txt` addition which is removed by this backport instead. >> * Addition of `vm.debug`; this is cherry-picked from 8155219: "[TESTBUG] Rewrite compiler/ciReplay/TestVM.sh in java" which first introduced it in later JDKs. The implementation needs to be adapted to work around the absence of `jdk.debug` (JDK-8139986). Using `java.vm.version` matches what happens in the `Platform.java` test library code. >> * 8208701: first fix for typos in 8208655 as committed. Some changes had to be manually applied due to context differences but otherwise a clean backport. >> * 8208706: fixes a missing `import` line in `ConstantGettersTransitionsTest.java`, which was applied manually due to differing context. >> * 8213410 backport which is necessary as 8208655 removes a number of checks altogether, replacing them with `@requires` statements. This is why we need `vm.debug` above and also this change due to the removed 32-bit check in `runtime/CompressedOops/CompressedClassPointers.java` >> * For consistency, the debug build check in `TestLargePageUseForAuxMemory.java` was replaced with vm.debug. I... > > Andrew John Hughes has updated the pull request incrementally with three additional commits since the last revision: > > - 8183503: Update hotspot tests to allow for unique test classes directory > - 8186095: upgrade to jtreg 4.2 b08 > - 8129355: [TESTBUG] runtime FragmentMetaspaceSimple.java fails with java.lang.ClassNotFoundException: test.Empty Good. Argh, again I forgot to mention that I am not an official jdk8 R eviewer. ------------- Marked as reviewed by stuefe (Committer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/387#pullrequestreview-1748133442 PR Comment: https://git.openjdk.org/jdk8u-dev/pull/387#issuecomment-1825825771 From stuefe at openjdk.org Fri Nov 24 15:33:18 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 24 Nov 2023 15:33:18 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: References: <3XlvVjADcLM9XcSCLny9ZoIuOMd2p6nCBbSKrH0jGcs=.8325d7c7-b865-42ff-9874-d33c0503e2f9@github.com> Message-ID: On Fri, 24 Nov 2023 15:14:04 GMT, Andrew John Hughes wrote: >> hotspot/test/gc/metaspace/TestMetaspaceMemoryPool.java line 33: >> >>> 31: * @summary Tests that a MemoryPoolMXBeans is created for metaspace and that a >>> 32: * MemoryManagerMXBean is created. >>> 33: * @requires vm.bits == 64 >> >> Why? We have metaspace also on 32-bit, just no class space. > > This and the other test you commented on are https://bugs.openjdk.org/browse/JDK-8213410 > The change was backported for the alteration to `runtime/CompressedOops/CompressedClassPointers.java` which would otherwise have its code-based 64-bit check removed by 8208655 and not replaced. > > Both of the other tests have this restriction up to trunk as well. I think the history comes from adding `vm.opt.final.UseCompressedOops` in [JDK-8204167](https://bugs.openjdk.org/browse/JDK-8204167) which causes the error shown in 8213410, even though the actual run would work without compressed oops thanks to `-XX:+IgnoreUnrecognizedVMOptions`. `TestMetaspaceMemoryPool` even still includes a `if (Platform.is64bit())` and `if (InputArguments.contains("-XX:+UseCompressedOops"))` in the `main` method which enforce the same restrictions. > > I did look at backporting JDK-8204167 as well, but `vm.opt.final.UseCompressedOops` returned `null` for me even on x86_64. Maybe some test infrastructure or HotSpot change we are missing. > > I don't see any issue with backporting the whole patch, given the exclusions are also there in 11+. If there is a case for running these on 32-bit, the restriction should probably be dropped in trunk and backported down for consistency. Okay, that makes sense. Thanks for clarifying. I looked at test/hotspot/jtreg/gc/metaspace/TestMetaspaceMemoryPool.java more closely. That test could be run for 32-bit as well, but its not worth fixing. ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/387#discussion_r1404469585 From andrew at openjdk.org Fri Nov 24 15:42:14 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 15:42:14 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: <3YRVElyMk7r-cNwmuznbXPU3cBdK4njoIG0QmnAkU_Y=.54deb988-f54b-490b-8d03-0e93713771fd@github.com> References: <3YRVElyMk7r-cNwmuznbXPU3cBdK4njoIG0QmnAkU_Y=.54deb988-f54b-490b-8d03-0e93713771fd@github.com> Message-ID: <4Uxs3Jegg8vB__3IkseTv0qSn1NNqLdjnRwwci2aEic=.aa6bfab9-92dd-4b25-9098-1dc3cae51b0c@github.com> On Fri, 24 Nov 2023 15:30:49 GMT, Thomas Stuefe wrote: > Argh, again I forgot to mention that I am not an official jdk8 R eviewer. Feedback still very welcome and @jerboaa can use your comments in his formal approval. If you'd like me to start a vote to make you an 8u reviewer, let me know. Anyone who is a Reviewer in updates & trunk, but not in 8u, seems like a bug to me and more to do with timing than any lack of technical qualification. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/387#issuecomment-1825835660 From stuefe at openjdk.org Fri Nov 24 16:52:16 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 24 Nov 2023 16:52:16 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: <4Uxs3Jegg8vB__3IkseTv0qSn1NNqLdjnRwwci2aEic=.aa6bfab9-92dd-4b25-9098-1dc3cae51b0c@github.com> References: <3YRVElyMk7r-cNwmuznbXPU3cBdK4njoIG0QmnAkU_Y=.54deb988-f54b-490b-8d03-0e93713771fd@github.com> <4Uxs3Jegg8vB__3IkseTv0qSn1NNqLdjnRwwci2aEic=.aa6bfab9-92dd-4b25-9098-1dc3cae51b0c@github.com> Message-ID: <-Z8A8QhNaFHIHGnUqPRE5a31jHVPhJyqg8RC3vAHtyw=.85ab958a-5601-4429-b240-faafb0806bda@github.com> On Fri, 24 Nov 2023 15:39:52 GMT, Andrew John Hughes wrote: > > Argh, again I forgot to mention that I am not an official jdk8 R eviewer. > > Feedback still very welcome and @jerboaa can use your comments in his formal approval. If you'd like me to start a vote to make you an 8u reviewer, let me know. Sure, go ahead (but no pressure, this is not urgent). ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/387#issuecomment-1825913132 From sgehwolf at openjdk.org Fri Nov 24 18:40:16 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 24 Nov 2023 18:40:16 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: References: Message-ID: <1p0gG-Aj7FWjSXWhoZm6uENijnCcgcGhE9MOx3dwV7s=.dccf4afb-1904-43a3-9c8f-0a0a7eaae8d0@github.com> On Fri, 24 Nov 2023 05:21:33 GMT, Andrew John Hughes wrote: >> This backport brings in `jtreg.SkippedException` which is used by JDK-8308592 (and likely other potential future backports as well). It is a test-only change which allows a skipped test to be correctly reported to jtreg, rather than it appearing like a successful run. >> >> The actual code changes to the HotSpot tests to use `SkippedException` were mostly clean. The main manual adaptations involved the placement of `import` statements (8u also doesn't have 8132919: 'Put compiler tests in packages') and copyright headers. Most tests also needed to have the library location `/test/lib` added. This is because the HotSpot tests are currently still using the HotSpot test library, not the top-level library. @zzambers work on this should eventually remove the need to reference both libraries. >> >> I've included with this change a number of follow-on changes which were necessary to make the changed tests pass. I don't know how the original version of 8208655 was committed as is, because it contains a number of typos and missing import statements which cause tests to fail. The follow-up changes are: >> >> * 8023735 backport. This change introduces the code which is altered by 8208655 to use `SkippedException`. The fix is simple enough to just backport with this change and fix the test in the process. It applied cleanly other than the `@ignore` line which has been replaced in 8u by a `ProblemList.txt` addition which is removed by this backport instead. >> * Addition of `vm.debug`; this is cherry-picked from 8155219: "[TESTBUG] Rewrite compiler/ciReplay/TestVM.sh in java" which first introduced it in later JDKs. The implementation needs to be adapted to work around the absence of `jdk.debug` (JDK-8139986). Using `java.vm.version` matches what happens in the `Platform.java` test library code. >> * 8208701: first fix for typos in 8208655 as committed. Some changes had to be manually applied due to context differences but otherwise a clean backport. >> * 8208706: fixes a missing `import` line in `ConstantGettersTransitionsTest.java`, which was applied manually due to differing context. >> * 8213410 backport which is necessary as 8208655 removes a number of checks altogether, replacing them with `@requires` statements. This is why we need `vm.debug` above and also this change due to the removed 32-bit check in `runtime/CompressedOops/CompressedClassPointers.java` >> * For consistency, the debug build check in `TestLargePageUseForAuxMemory.java` was replaced with vm.debug. I... > > Andrew John Hughes has updated the pull request incrementally with three additional commits since the last revision: > > - 8183503: Update hotspot tests to allow for unique test classes directory > - 8186095: upgrade to jtreg 4.2 b08 > - 8129355: [TESTBUG] runtime FragmentMetaspaceSimple.java fails with java.lang.ClassNotFoundException: test.Empty This is a large change. If it wasn't only in the testing area, then this would be hard to argue to get in. GHA looks OK. Thumbs up. test/lib/jtreg/SkippedException.java line 27: > 25: > 26: /** > 27: * {@code SkippedException} is an exception treaded by jtreg as an indication typo `treated`. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/387#pullrequestreview-1748320729 PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/387#discussion_r1404583902 From andrew at openjdk.org Fri Nov 24 21:14:12 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 21:14:12 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: <1p0gG-Aj7FWjSXWhoZm6uENijnCcgcGhE9MOx3dwV7s=.dccf4afb-1904-43a3-9c8f-0a0a7eaae8d0@github.com> References: <1p0gG-Aj7FWjSXWhoZm6uENijnCcgcGhE9MOx3dwV7s=.dccf4afb-1904-43a3-9c8f-0a0a7eaae8d0@github.com> Message-ID: On Fri, 24 Nov 2023 18:30:31 GMT, Severin Gehwolf wrote: >> Andrew John Hughes has updated the pull request incrementally with three additional commits since the last revision: >> >> - 8183503: Update hotspot tests to allow for unique test classes directory >> - 8186095: upgrade to jtreg 4.2 b08 >> - 8129355: [TESTBUG] runtime FragmentMetaspaceSimple.java fails with java.lang.ClassNotFoundException: test.Empty > > test/lib/jtreg/SkippedException.java line 27: > >> 25: >> 26: /** >> 27: * {@code SkippedException} is an exception treaded by jtreg as an indication > > typo `treated`. https://bugs.openjdk.org/browse/JDK-8209740 :-) I can follow up with that change and 8267751: "(test) jtreg.SkippedException has no serial VersionUID" but they are not that critical ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/387#discussion_r1404644534 From andrew at openjdk.org Fri Nov 24 21:23:12 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 24 Nov 2023 21:23:12 GMT Subject: [jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2] In-Reply-To: <1p0gG-Aj7FWjSXWhoZm6uENijnCcgcGhE9MOx3dwV7s=.dccf4afb-1904-43a3-9c8f-0a0a7eaae8d0@github.com> References: <1p0gG-Aj7FWjSXWhoZm6uENijnCcgcGhE9MOx3dwV7s=.dccf4afb-1904-43a3-9c8f-0a0a7eaae8d0@github.com> Message-ID: On Fri, 24 Nov 2023 18:37:26 GMT, Severin Gehwolf wrote: > This is a large change. If it wasn't only in the testing area, then this would be hard to argue to get in. GHA looks OK. Thumbs up. If it wasn't only in the testing area, I wouldn't submit this kind of change for a backport. Making such changes to the codebase is a risk to stability. But, on the other hand, *not* improving the test suite where we can is also a risk to stability. To me, the two (sources and tests) are quite different things that happen to share the same repository. In GNU Classpath, we actually used to have the test suite as a separate independent repository, which I think was a better approach. Yes, it's harder to make sure things in there work appropriately on each JDK version, but it means each version is using the latest tests and would cut down on a huge amount of backporting work. 8u's version of the test suite is still quite immature compared with where trunk is now, so it's not a surprise that there are backports like this. Note also that this is not one change, but seven. I could have filed them all as separate PRs but, as I said to Thomas, it doesn't really make sense. I don't know how 8208655 was accepted in the state it's in, because it has a whole host of things like typos and missing import statements that are fixed in subsequent changes, but should have been caught by running the tests before commit (that's how I found them and then the fixes). So I think what we have here is much closer to how 8208655 should have been to begin with. Thanks both of you for the reviews. I know it's not easy on larger changes. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/387#issuecomment-1826090851 From gnu.andrew at redhat.com Sat Nov 25 17:05:55 2023 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 25 Nov 2023 17:05:55 +0000 Subject: [RAMPDOWN] 8u402 now in Rampdown Stage Message-ID: 8u402 is in rampdown for release in January 2024. jdk8u-dev is CLOSED for commits until https://bugs.openjdk.org/browse/JDK-8320713 is integrated to begin the 8u412 release cycle. For critical fixes (i.e. regressions or urgent fixes like tzdata updates) for 8u402, please file a PR against https://github.com/openjdk/jdk8u and use jdk8u-critical-request to obtain approval to push. Thanks, -- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks Available on Libera Chat & OFTC IRC networks as gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From andrew at openjdk.org Sat Nov 25 17:16:35 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Sat, 25 Nov 2023 17:16:35 GMT Subject: [jdk8u-dev] RFR: 8320713: Bump update version of OpenJDK: 8u412 Message-ID: Rampdown for 8u392 [has begun](https://mail.openjdk.org/pipermail/jdk8u-dev/2023-November/017686.html). 8u-dev needs to transition to 8u412. ------------- Commit messages: - 8320713: Bump update version of OpenJDK: 8u412 Changes: https://git.openjdk.org/jdk8u-dev/pull/391/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=391&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320713 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/391.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/391/head:pull/391 PR: https://git.openjdk.org/jdk8u-dev/pull/391 From phh at openjdk.org Sun Nov 26 19:59:33 2023 From: phh at openjdk.org (Paul Hohensee) Date: Sun, 26 Nov 2023 19:59:33 GMT Subject: [jdk8u-dev] RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM Message-ID: <_ZWKxcgZzaoqb9iLlIsSoceyd-fiHhdHOpVmTsbRNI0=.99ae0e62-e9b2-4ef0-a6fe-15faa3e3c9cd@github.com> I'd like to backport the definition and implementation of com.sun.management.ThreadMXBean.getTotalThreadAllocatedBytes to 8u. The backport CSR is [JDK-8320375](https://bugs.openjdk.org/browse/JDK-8320375). A follow-up bugfix backport of [JDK-8313081](https://bugs.openjdk.org/browse/JDK-8313081) will be done following this backport. The combined backports have been in production at Amazon for two months with no issues. The backport uses the reserved6 slot in jmm.h in order to preserve binary compatibility with 11u. Per current policy, there is no update to JMM_VERSION in jmm.h and the new method is marked @since 8u412 Aside from file relocation and context differences, relative to the 11u backport the MonitoringSupport_lock definition macro changes, and the reserved1 rather than reserved6 jmm slot is used. SMR doesn't exist in 8u, so jmm_GetTotalThreadAllocated bytes attempts to lock Threads_lock instead, and if the Threads_lock is already locked, the previous return value is returned. HotSpotThreadImpl.java doesn't exist in 8u, so the hunk associated with it is dropped. ------------- Commit messages: - 8304074: make @since 8u412 - Merge branch 'master' into backport-8304074 - Merge branch 'master' into backport-8304074 - Backport 3eced01f9efe2567a07b63343f8559683a2d0517 Changes: https://git.openjdk.org/jdk8u-dev/pull/392/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=392&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304074 Stats: 294 lines in 13 files changed: 212 ins; 45 del; 37 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/392.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/392/head:pull/392 PR: https://git.openjdk.org/jdk8u-dev/pull/392 From phh at openjdk.org Sun Nov 26 20:24:18 2023 From: phh at openjdk.org (Paul Hohensee) Date: Sun, 26 Nov 2023 20:24:18 GMT Subject: [jdk8u-dev] RFR: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074 Message-ID: <6WTexvrkW8zsKxZQ4rUZZQ212Mow__tiYrMyVLyjgWc=.5e9cf95f-7b42-43b8-a5c7-e112244fd3c8@github.com> Follow-on bug fix for [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) backport. Unclean backport from 11u, see https://github.com/openjdk/jdk11u-dev/pull/2287. Other than file location and context, the lock definition macro changed between 8 and 11, so the definition of MonitoringSupport_lock is different. ------------- Depends on: https://git.openjdk.org/jdk8u-dev/pull/392 Commit messages: - Merge branch 'backport-8304074' into backport-8313081 - Merge branch 'backport-8304074' into backport-8313081 - Backport a9d21c61fb12a11e18c6bb8aa903e5a8e42473f1 Changes: https://git.openjdk.org/jdk8u-dev/pull/393/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=393&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313081 Stats: 17 lines in 3 files changed: 12 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/393.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/393/head:pull/393 PR: https://git.openjdk.org/jdk8u-dev/pull/393 From duke at openjdk.org Mon Nov 27 09:18:18 2023 From: duke at openjdk.org (Taizo Kurashige) Date: Mon, 27 Nov 2023 09:18:18 GMT Subject: [jdk8u-dev] RFR: 8021961: setAlwaysOnTop doesn't behave correctly in Linux/Solaris under certain scenarios In-Reply-To: References: Message-ID: On Sat, 11 Nov 2023 15:09:28 GMT, Andrew John Hughes wrote: >> Hi, >> >> This is a backoport of JDK-8021961: setAlwaysOnTop doesn't behave correctly in Linux/Solaris under certain scenarios >> >> Original patch does not apply cleanly to 8u, bacause "parent" is declared at XWindowPeer.java#1652 in 8u. >> So I deleted that declaration. >> >> There is a related Issue: JDK-8222323, and I submit the corresponding PR. Testing was done after applying this related patch. >> Testing: jdk_awt on RHEL7, GHA testing >> >> Thanks. > > It looks like the `parent` line was added to 8u for the backport of JDK-8187803, as it wasn't present due to this change (JDK-8021961) being absent. So replacing it with the earlier declaration in 8021961 seems correct. @gnu-andrew Thank you for your reviewing. I asked my colleague to add jdk8u-fix-request label. So please check it. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/377#issuecomment-1827436737 From sgehwolf at openjdk.org Mon Nov 27 10:10:16 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 27 Nov 2023 10:10:16 GMT Subject: [jdk8u-dev] RFR: 8320713: Bump update version of OpenJDK: 8u412 In-Reply-To: References: Message-ID: On Sat, 25 Nov 2023 17:11:20 GMT, Andrew John Hughes wrote: > Rampdown for 8u392 [has begun](https://mail.openjdk.org/pipermail/jdk8u-dev/2023-November/017686.html). 8u-dev needs to transition to 8u412. Marked as reviewed by sgehwolf (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/391#pullrequestreview-1750069058 From sgehwolf at openjdk.org Mon Nov 27 10:41:18 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 27 Nov 2023 10:41:18 GMT Subject: [jdk8u-dev] RFR: 8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 09:39:50 GMT, Taizo Kurashige wrote: > Hi, > > This is a backport of JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" > > Original patch does not apply cleanly to JDK-8021961 applied code, because the fix uses "StringBuffer.isEmpty()" published in JDK15. I fixed the test so as not to use "StringBuffer.isEmpty()". > > Testing: jdk_awt on RHEL7, GHA testing > > Thanks. Please ask for approval of the bug using the `/approval` [SKARA command](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/approval) so that the dependency and this one can get approved together. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/378#issuecomment-1827575109 From gnu.andrew at redhat.com Mon Nov 27 14:47:33 2023 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 27 Nov 2023 14:47:33 +0000 Subject: CFV: New OpenJDK 8u Reviewer: Thomas Stuefe Message-ID: I hereby nominate Thomas Stuefe [0] for the role of OpenJDK 8u Reviewer. Thomas already has reviewership in OpenJDK 9 and later and a wealth of OpenJDK experience [1] [2] [3] [4]. Thus, his lack of reviewer status on OpenJDK 8 Updates seems more a simple case of when he started contributing to OpenJDK - as the same status is conferred on to new JDK releases, but not retrospectively to older ones - than a lack of sufficient technical qualification. Votes are due by 15h00 UTC on the 11th of December, 2023. Only current OpenJDK 8u Reviewers [5] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [6]. [0] https://openjdk.java.net/census#stuefe [1] https://github.com/openjdk/jdk/commits?author=tstuefe [2] https://github.com/openjdk/jdk17u/commits?author=tstuefe [3] https://github.com/openjdk/jdk11u/commits?author=tstuefe [4] https://github.com/openjdk/jdk8u/commits?author=tstuefe [3] http://openjdk.java.net/census#jdk8u [4] http://openjdk.java.net/bylaws#three-vote-consensus Thanks, -- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks Available on Libera Chat & OFTC IRC networks as gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From sgehwolf at redhat.com Mon Nov 27 15:37:33 2023 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 27 Nov 2023 16:37:33 +0100 Subject: CFV: New OpenJDK 8u Reviewer: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes On Mon, 2023-11-27 at 14:47 +0000, Andrew Hughes wrote: > I hereby nominate Thomas Stuefe [0] for the role of OpenJDK 8u > Reviewer. From vladimir.kozlov at oracle.com Mon Nov 27 16:41:58 2023 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Nov 2023 08:41:58 -0800 Subject: CFV: New OpenJDK 8u Reviewer: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes Thanks, Vladimir K On 11/27/23 6:47 AM, Andrew Hughes wrote: > I hereby nominate Thomas Stuefe [0] for the role of OpenJDK 8u Reviewer. > > Thomas already has reviewership in OpenJDK 9 and later and a wealth of > OpenJDK experience [1] [2] [3] [4]. Thus, his lack of reviewer status > on OpenJDK 8 Updates seems more a simple case of when he started > contributing to OpenJDK - as the same status is conferred on to new > JDK releases, but not retrospectively to older ones - than a lack of > sufficient technical qualification. > > Votes are due by 15h00 UTC on the 11th of December, 2023. > > Only current OpenJDK 8u Reviewers [5] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [6]. > > [0] https://openjdk.java.net/census#stuefe > [1] https://github.com/openjdk/jdk/commits?author=tstuefe > [2] https://github.com/openjdk/jdk17u/commits?author=tstuefe > [3] https://github.com/openjdk/jdk11u/commits?author=tstuefe > [4] https://github.com/openjdk/jdk8u/commits?author=tstuefe > [3] http://openjdk.java.net/census#jdk8u > [4] http://openjdk.java.net/bylaws#three-vote-consensus > > Thanks, From dhanalla at microsoft.com Mon Nov 27 16:47:11 2023 From: dhanalla at microsoft.com (Dhamoder Nalla) Date: Mon, 27 Nov 2023 16:47:11 +0000 Subject: Backport of JDK-8293562 to JDK8 In-Reply-To: References: Message-ID: Hi All, I'm a member of the Java Engineering Group at Microsoft, currently working on a TLS 1.3 issue for one of our customers using JDK8. This issue aligns with JDK-8293562. This customer is currently not able to upgrade their JDK version, so I'm interested in understanding if there are any concerns about backporting this bug (JDK-8293562) fix to JDK8 (or if this is already in progress by someone). Thanks, Dhamoder. -------------- next part -------------- An HTML attachment was scrubbed... URL: From neugens at redhat.com Mon Nov 27 17:06:25 2023 From: neugens at redhat.com (Mario Torre) Date: Mon, 27 Nov 2023 18:06:25 +0100 Subject: CFV: New OpenJDK 8u Reviewer: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: Yes, Cheers, Mario On Mon, Nov 27, 2023 at 3:54?PM Andrew Hughes wrote: > > I hereby nominate Thomas Stuefe [0] for the role of OpenJDK 8u Reviewer. > > Thomas already has reviewership in OpenJDK 9 and later and a wealth of > OpenJDK experience [1] [2] [3] [4]. Thus, his lack of reviewer status > on OpenJDK 8 Updates seems more a simple case of when he started > contributing to OpenJDK - as the same status is conferred on to new > JDK releases, but not retrospectively to older ones - than a lack of > sufficient technical qualification. > > Votes are due by 15h00 UTC on the 11th of December, 2023. > > Only current OpenJDK 8u Reviewers [5] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [6]. > > [0] https://openjdk.java.net/census#stuefe > [1] https://github.com/openjdk/jdk/commits?author=tstuefe > [2] https://github.com/openjdk/jdk17u/commits?author=tstuefe > [3] https://github.com/openjdk/jdk11u/commits?author=tstuefe > [4] https://github.com/openjdk/jdk8u/commits?author=tstuefe > [3] http://openjdk.java.net/census#jdk8u > [4] http://openjdk.java.net/bylaws#three-vote-consensus > > Thanks, > -- > Andrew :) > Pronouns: he / him or they / them > Principal Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > Please contact via e-mail, not proprietary chat networks > Available on Libera Chat & OFTC IRC networks as gnu_andrew -- Mario Torre Manager, Software Engineering, Red Hat OpenJDK, Java Champion https://keybase.io/neugens 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 Mastodon: https://mastodon.social/@MarioTorre Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243, Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross From andrew at openjdk.org Mon Nov 27 17:37:16 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Mon, 27 Nov 2023 17:37:16 GMT Subject: [jdk8u-dev] Integrated: 8320713: Bump update version of OpenJDK: 8u412 In-Reply-To: References: Message-ID: On Sat, 25 Nov 2023 17:11:20 GMT, Andrew John Hughes wrote: > Rampdown for 8u392 [has begun](https://mail.openjdk.org/pipermail/jdk8u-dev/2023-November/017686.html). 8u-dev needs to transition to 8u412. This pull request has now been integrated. Changeset: 0464401c Author: Andrew John Hughes URL: https://git.openjdk.org/jdk8u-dev/commit/0464401cc5d8e4ce52e7e32a82b631d5ba9db310 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8320713: Bump update version of OpenJDK: 8u412 Reviewed-by: sgehwolf ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/391 From zzambers at openjdk.org Mon Nov 27 17:38:41 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 27 Nov 2023 17:38:41 GMT Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README Message-ID: This backport adds `.md` extension to README. It also changes formulations a bit and adds some hyperlinks. Backport is not clean because there were small intermediate changes to README by (changesets not applicable to JDK8): - [JDK-8187444](https://bugs.openjdk.org/browse/JDK-8187444) - [JDK-8205956](https://bugs.openjdk.org/browse/JDK-8205956) (Git however considers this rewrite anyway.) ------------- Commit messages: - Backport 4fbe635b21e3aba14dba760168a2f8965c7b29f5 Changes: https://git.openjdk.org/jdk8u-dev/pull/394/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=394&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8251551 Stats: 21 lines in 2 files changed: 11 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/394.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/394/head:pull/394 PR: https://git.openjdk.org/jdk8u-dev/pull/394 From yan at azul.com Mon Nov 27 18:28:50 2023 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 27 Nov 2023 22:28:50 +0400 Subject: CFV: New OpenJDK 8u Reviewer: Thomas Stuefe In-Reply-To: References: Message-ID: <7d7e527f-9faa-42f7-8921-17ad5b8ff722@azul.com> Vote: yes --yan On 27.11.2023 18:47, Andrew Hughes wrote: > I hereby nominate Thomas Stuefe [0] for the role of OpenJDK 8u Reviewer. > From shipilev at amazon.de Mon Nov 27 19:36:03 2023 From: shipilev at amazon.de (Aleksey Shipilev) Date: Mon, 27 Nov 2023 20:36:03 +0100 Subject: CFV: New OpenJDK 8u Reviewer: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes On 27.11.23 15:47, Andrew Hughes wrote: > I hereby nominate Thomas Stuefe [0] for the role of OpenJDK 8u Reviewer. Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 From sgehwolf at openjdk.org Mon Nov 27 19:43:13 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 27 Nov 2023 19:43:13 GMT Subject: [jdk8u-dev] RFR: 8308592: Framework for CA interoperability testing In-Reply-To: References: Message-ID: <5fKpSvCCHW93aPdYFGFRCBrQn2IQncxal_V8rMvPytU=.591e9987-724b-46bc-abbb-303dd7268d71@github.com> On Fri, 24 Nov 2023 08:24:59 GMT, Andrew John Hughes wrote: > Hi all, > > This pull request contains a backport of commit [da57d2a1](https://github.com/openjdk/jdk/commit/da57d2a1eb409ddc64117865c7d24ed518421cab) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Rajan Halade on 19 Sep 2023 and was reviewed by Sean Mullan. It was backported to 17u on 2023-09-28 and 11u on 2023-10-11 > > It reworks the certificate tests to use test portals rather than having to maintain copies of the certificates in the OpenJDK repository and so should reduce the maintenance cost of these tests going forward. The fix has already been backported to 21u and Oracle-17u. > > There were conflicts in the removals of `ActalisCA.java`, `BuypassCA.java`, `LetsEncryptCA.java` and `QuoVadisCA.java`, due to changes not in 8u. For the first of these, we backported JDK-8297955 (see #388) as it also contains a code change. As the other three are only test changes, we assumed these bugs to be resolved by the replacement of the individual tests with `CAInterop.java`. > > The `ValidatePathWithURL.java` class had to be modified slightly to work with the 8u `cacerts`. These changes were based on the existing `ValidatePathWithParams.java`. > > All tests pass with the exception of the OCSP case of `certignarootca`. This fails with `Caused by: java.security.cert.CertPathValidatorException: Certificate does not specify OCSP responder`. While not ideal, I don't think this is an issue with the testing backport so I'd suggest we look into this and fix it later, while getting this in so that pending certificate updates can go in. It seems to be 8u specific (the case passed on 11u). The CRL case does pass as does `CertignaCA.java` (not sure why there are two tests for this one). This looks good. The reason why `certignarootca` test fails is the different defaults for `jdk.tls.client.enableStatusRequestExtension` between JDK 11 and JDK 8 in `SSLContextImpl.java`. The former has it set to `true` the latter to `false` as per the TLS 1.3 backport to 8. Without it the `ClientHello` won't have the `status_request` extension, which is required for the test to pass. I suggest to set this to `true` in the affected test only (or set it to true globally in `CAInterop.java`). Either way I'd include this in this backport. ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/390#pullrequestreview-1751221660 From duke at openjdk.org Mon Nov 27 19:50:16 2023 From: duke at openjdk.org (duke) Date: Mon, 27 Nov 2023 19:50:16 GMT Subject: [jdk8u-dev] Withdrawn: 8315757: [8u] Add cacerts JTREG tests to GHA tier1 test set In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 13:50:09 GMT, Severin Gehwolf wrote: > Simple GHA only change to add cacert tests to the tier1 test set. Please review. > > Testing: > - [x] GHA (which shows a failure in tier1 now, `VerifyCACerts.java` fails due to JDK-8295894; being worked on in jdk8u repo) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/368 From phh at openjdk.org Mon Nov 27 23:46:13 2023 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 27 Nov 2023 23:46:13 GMT Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 17:33:22 GMT, Zdenek Zambersky wrote: > This backport adds `.md` extension to README. It also changes formulations a bit and adds some hyperlinks. Backport is not clean because there were small intermediate changes to README by (changesets not applicable to JDK8): > - [JDK-8187444](https://bugs.openjdk.org/browse/JDK-8187444) > - [JDK-8205956](https://bugs.openjdk.org/browse/JDK-8205956) > > (Git however considers this rewrite anyway.) Looks like a clean backport from 11u. GHA test failure appears unrelated (this PR doesn't affect GC). ------------- Marked as reviewed by phh (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/394#pullrequestreview-1751626744 From andrew at openjdk.org Tue Nov 28 03:20:19 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 03:20:19 GMT Subject: [jdk8u-dev] Integrated: 8208655: use JTreg skipped status in hotspot tests In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 05:59:32 GMT, Andrew John Hughes wrote: > This backport brings in `jtreg.SkippedException` which is used by JDK-8308592 (and likely other potential future backports as well). It is a test-only change which allows a skipped test to be correctly reported to jtreg, rather than it appearing like a successful run. > > The actual code changes to the HotSpot tests to use `SkippedException` were mostly clean. The main manual adaptations involved the placement of `import` statements (8u also doesn't have 8132919: 'Put compiler tests in packages') and copyright headers. Most tests also needed to have the library location `/test/lib` added. This is because the HotSpot tests are currently still using the HotSpot test library, not the top-level library. @zzambers work on this should eventually remove the need to reference both libraries. > > I've included with this change a number of follow-on changes which were necessary to make the changed tests pass. I don't know how the original version of 8208655 was committed as is, because it contains a number of typos and missing import statements which cause tests to fail. The follow-up changes are: > > * 8023735 backport. This change introduces the code which is altered by 8208655 to use `SkippedException`. The fix is simple enough to just backport with this change and fix the test in the process. It applied cleanly other than the `@ignore` line which has been replaced in 8u by a `ProblemList.txt` addition which is removed by this backport instead. > * Addition of `vm.debug`; this is cherry-picked from 8155219: "[TESTBUG] Rewrite compiler/ciReplay/TestVM.sh in java" which first introduced it in later JDKs. The implementation needs to be adapted to work around the absence of `jdk.debug` (JDK-8139986). Using `java.vm.version` matches what happens in the `Platform.java` test library code. > * 8208701: first fix for typos in 8208655 as committed. Some changes had to be manually applied due to context differences but otherwise a clean backport. > * 8208706: fixes a missing `import` line in `ConstantGettersTransitionsTest.java`, which was applied manually due to differing context. > * 8213410 backport which is necessary as 8208655 removes a number of checks altogether, replacing them with `@requires` statements. This is why we need `vm.debug` above and also this change due to the removed 32-bit check in `runtime/CompressedOops/CompressedClassPointers.java` > * For consistency, the debug build check in `TestLargePageUseForAuxMemory.java` was replaced with vm.debug. In 11u, this is removed t... This pull request has now been integrated. Changeset: 3b9c787e Author: Andrew John Hughes URL: https://git.openjdk.org/jdk8u-dev/commit/3b9c787e3c8ec3f89bf041d37c0b2d1484a2ada0 Stats: 359 lines in 35 files changed: 194 ins; 88 del; 77 mod 8208655: use JTreg skipped status in hotspot tests 8023735: [TESTBUG][macosx] runtime/XCheckJniJsig/XCheckJSig.java fails on MacOS X 8208701: Fix for JDK-8208655 causes test failures in CI tier1 8208706: compiler/tiered/ConstantGettersTransitionsTest.java fails to compile 8186095: upgrade to jtreg 4.2 b08 8183503: Update hotspot tests to allow for unique test classes directory 8213410: UseCompressedOops requirement check fails fails on 32-bit system Reviewed-by: stuefe, sgehwolf Backport-of: 17b730d7edf7be91ee841180ea6a59b26c0c567a ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/387 From andrew at openjdk.org Tue Nov 28 03:25:32 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 03:25:32 GMT Subject: [jdk8u-dev] RFR: 8297955: LDAP CertStore should use LdapName and not String for DNs [v2] In-Reply-To: References: Message-ID: > [JDK-8308592](https://bugs.openjdk.org/browse/JDK-8308592): "Framework for CA interoperability testing" merges the Actalis test into a single test which handles multiple CAs. Before we can backport that, we thus need to fix the Actalis test by backporting [JDK-8297955](https://bugs.openjdk.org/browse/JDK-8297955) which also fixes [8224768](https://bugs.openjdk.org/browse/JDK-8224768) > > The backport is mostly clean. The code changes apply cleanly once applied to `LDAPCertStore.java` rather than `LDAPCertStoreImpl.java` which doesn't exist in 8u (a refactoring in [JDK-8038084](https://bugs.openjdk.org/browse/JDK-8038084): "CertStore needs a way to add new CertStore types"). The unused `getName()` method needed to be removed as `name` is no longer a `String`. The `ProblemList.txt` change had to be manually added as did the copyright header change to `LDAPCertStore.java`. > > The Actalis test passes after this backport. All other CA results match those on an unpatched build (GoogleCA currently seems to be broken on all 8u builds I had to hand) Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/388/files - new: https://git.openjdk.org/jdk8u-dev/pull/388/files/9fea5694..9fea5694 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=388&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=388&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/388.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/388/head:pull/388 PR: https://git.openjdk.org/jdk8u-dev/pull/388 From andrew at openjdk.org Tue Nov 28 03:34:23 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 03:34:23 GMT Subject: [jdk8u-dev] RFR: 8297955: LDAP CertStore should use LdapName and not String for DNs [v3] In-Reply-To: References: Message-ID: > [JDK-8308592](https://bugs.openjdk.org/browse/JDK-8308592): "Framework for CA interoperability testing" merges the Actalis test into a single test which handles multiple CAs. Before we can backport that, we thus need to fix the Actalis test by backporting [JDK-8297955](https://bugs.openjdk.org/browse/JDK-8297955) which also fixes [8224768](https://bugs.openjdk.org/browse/JDK-8224768) > > The backport is mostly clean. The code changes apply cleanly once applied to `LDAPCertStore.java` rather than `LDAPCertStoreImpl.java` which doesn't exist in 8u (a refactoring in [JDK-8038084](https://bugs.openjdk.org/browse/JDK-8038084): "CertStore needs a way to add new CertStore types"). The unused `getName()` method needed to be removed as `name` is no longer a `String`. The `ProblemList.txt` change had to be manually added as did the copyright header change to `LDAPCertStore.java`. > > The Actalis test passes after this backport. All other CA results match those on an unpatched build (GoogleCA currently seems to be broken on all 8u builds I had to hand) Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Backport 7f1047edba68cfe2fa2660030cb3dd1abad49e4f ------------- Changes: https://git.openjdk.org/jdk8u-dev/pull/388/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=388&range=02 Stats: 299 lines in 3 files changed: 56 ins; 88 del; 155 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/388.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/388/head:pull/388 PR: https://git.openjdk.org/jdk8u-dev/pull/388 From andrew at openjdk.org Tue Nov 28 03:34:24 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 03:34:24 GMT Subject: [jdk8u-dev] Integrated: 8297955: LDAP CertStore should use LdapName and not String for DNs In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 07:10:49 GMT, Andrew John Hughes wrote: > [JDK-8308592](https://bugs.openjdk.org/browse/JDK-8308592): "Framework for CA interoperability testing" merges the Actalis test into a single test which handles multiple CAs. Before we can backport that, we thus need to fix the Actalis test by backporting [JDK-8297955](https://bugs.openjdk.org/browse/JDK-8297955) which also fixes [8224768](https://bugs.openjdk.org/browse/JDK-8224768) > > The backport is mostly clean. The code changes apply cleanly once applied to `LDAPCertStore.java` rather than `LDAPCertStoreImpl.java` which doesn't exist in 8u (a refactoring in [JDK-8038084](https://bugs.openjdk.org/browse/JDK-8038084): "CertStore needs a way to add new CertStore types"). The unused `getName()` method needed to be removed as `name` is no longer a `String`. The `ProblemList.txt` change had to be manually added as did the copyright header change to `LDAPCertStore.java`. > > The Actalis test passes after this backport. All other CA results match those on an unpatched build (GoogleCA currently seems to be broken on all 8u builds I had to hand) This pull request has now been integrated. Changeset: b2655a72 Author: Andrew John Hughes URL: https://git.openjdk.org/jdk8u-dev/commit/b2655a72590ef27304c38638554bc25bda9793bc Stats: 299 lines in 3 files changed: 56 ins; 88 del; 155 mod 8297955: LDAP CertStore should use LdapName and not String for DNs 8224768: Test ActalisCA.java fails Reviewed-by: sgehwolf Backport-of: 7f1047edba68cfe2fa2660030cb3dd1abad49e4f ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/388 From andrew at openjdk.org Tue Nov 28 03:34:31 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 03:34:31 GMT Subject: [jdk8u-dev] RFR: 8312126: NullPointerException in CertStore.getCRLs after 8297955 [v2] In-Reply-To: <-58cu-nBHMzhzyvO-YuvaER1drfZvYcWEGeojP-Pvjg=.1262d53a-3375-4bd7-a706-dc07264a2713@github.com> References: <-58cu-nBHMzhzyvO-YuvaER1drfZvYcWEGeojP-Pvjg=.1262d53a-3375-4bd7-a706-dc07264a2713@github.com> Message-ID: > Hi all, > > This pull request contains a backport of commit [3c743cfe](https://github.com/openjdk/jdk/commit/3c743cfea00692d0b938cb1cbde936084eecf369) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Sean Mullan on 15 Sep 2023 and was reviewed by Weijun Wang. It was backported to 17u on 2023-11-10 and [a PR is open for 11u](https://github.com/openjdk/jdk11u-dev/pull/2299). > > It is a simple fix and clean backport for a regression introduced by [JDK-8297955](https://bugs.openjdk.org/browse/JDK-8297955) which was backported in [PR 388](https://github.com/openjdk/jdk8u-dev/pull/388). The new code in JDK-8297955 failed to catch a null IssuerName, allowing a NullPointerException to be thrown instead of the specified CertStoreException. > > Thanks. Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/389/files - new: https://git.openjdk.org/jdk8u-dev/pull/389/files/69299277..69299277 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=389&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=389&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/389.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/389/head:pull/389 PR: https://git.openjdk.org/jdk8u-dev/pull/389 From serb at openjdk.org Tue Nov 28 04:22:23 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 28 Nov 2023 04:22:23 GMT Subject: [jdk8u-dev] RFR: 8301310: The SendRawSysexMessage test may cause a JVM crash Message-ID: <-YbOn_cUf3QNL2RrekxKnXh8IvdZuTdI-Lz7YXmUYRs=.42795677-64b8-45ca-838c-ae63efa6f56d@github.com> Hi all, This pull request contains a backport of commit [d725b73d](https://github.com/openjdk/jdk/commit/d725b73df01ae4478dfaabc47c48cd7231d91afa) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Alec Su on 14 Nov 2023 and was reviewed by Sergey Bylokhov. Thanks! ------------- Commit messages: - Backport d725b73df01ae4478dfaabc47c48cd7231d91afa Changes: https://git.openjdk.org/jdk8u-dev/pull/395/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=395&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301310 Stats: 19 lines in 2 files changed: 13 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/395.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/395/head:pull/395 PR: https://git.openjdk.org/jdk8u-dev/pull/395 From sgehwolf at openjdk.org Tue Nov 28 09:48:26 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 09:48:26 GMT Subject: [jdk8u-dev] RFR: 8315757: [8u] Add cacerts JTREG tests to GHA tier1 test set [v4] In-Reply-To: References: Message-ID: On Thu, 21 Sep 2023 07:47:06 GMT, Severin Gehwolf wrote: >> Simple GHA only change to add cacert tests to the tier1 test set. Please review. >> >> Testing: >> - [x] GHA (which shows a failure in tier1 now, `VerifyCACerts.java` fails due to JDK-8295894; being worked on in jdk8u repo) > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8315757-tier1-gha > - Move to jdk_security_infra and add to tier1 > - 8315757: [8u] Add cacerts JTREG tests to GHA tier1 test set This could work again once #390 is in. Waiting for that to happen first. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/368#issuecomment-1829453923 From zzambers at openjdk.org Tue Nov 28 10:40:23 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Tue, 28 Nov 2023 10:40:23 GMT Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 17:33:22 GMT, Zdenek Zambersky wrote: > This backport adds `.md` extension to README. It also changes formulations a bit and adds some hyperlinks. Backport is not clean because there were small intermediate changes to README by (changesets not applicable to JDK8): > - [JDK-8187444](https://bugs.openjdk.org/browse/JDK-8187444) > - [JDK-8205956](https://bugs.openjdk.org/browse/JDK-8205956) > > (Git however considers this rewrite anyway.) thanks ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/394#issuecomment-1829546243 From zzambers at openjdk.org Tue Nov 28 10:40:24 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Tue, 28 Nov 2023 10:40:24 GMT Subject: [jdk8u-dev] Integrated: 8251551: Use .md filename extension for README In-Reply-To: References: Message-ID: <1_4ABcQxNqB_4d22hZsv5H6_9NgAbqBP8H9qSczUVxE=.b0e02fb0-427d-4ee7-9511-b32efdda48a4@github.com> On Mon, 27 Nov 2023 17:33:22 GMT, Zdenek Zambersky wrote: > This backport adds `.md` extension to README. It also changes formulations a bit and adds some hyperlinks. Backport is not clean because there were small intermediate changes to README by (changesets not applicable to JDK8): > - [JDK-8187444](https://bugs.openjdk.org/browse/JDK-8187444) > - [JDK-8205956](https://bugs.openjdk.org/browse/JDK-8205956) > > (Git however considers this rewrite anyway.) This pull request has now been integrated. Changeset: 2f81fb4b Author: Zdenek Zambersky URL: https://git.openjdk.org/jdk8u-dev/commit/2f81fb4b586097e5cb3e139e2131dd7a5b6312a5 Stats: 21 lines in 2 files changed: 11 ins; 10 del; 0 mod 8251551: Use .md filename extension for README Reviewed-by: phh Backport-of: 4fbe635b21e3aba14dba760168a2f8965c7b29f5 ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/394 From duke at openjdk.org Tue Nov 28 12:39:48 2023 From: duke at openjdk.org (ktakakuri) Date: Tue, 28 Nov 2023 12:39:48 GMT Subject: [jdk8u-dev] RFR: 8059847: complement JDK-8055286 and JDK-8056964 changes Message-ID: Hi all, This is a backport of JDK-8059847: complement JDK-8055286 and JDK-8056964 changes JDK-8055286 and JDK-8056964 are already backported to JDK8, but this patch is not. For this reason, CompileCommand=option does not support flags of type double, as reported. So this patch should be applied. The original patch is applied cleanly. Testing: hotspot_tier1 including the test which come with this patch. Thank you. ------------- Commit messages: - Backport e210688db98357ab66718958d75b9970d4750fd2 Changes: https://git.openjdk.org/jdk8u-dev/pull/396/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=396&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8059847 Stats: 251 lines in 4 files changed: 247 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/396.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/396/head:pull/396 PR: https://git.openjdk.org/jdk8u-dev/pull/396 From sgehwolf at openjdk.org Tue Nov 28 13:26:20 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 13:26:20 GMT Subject: [jdk8u-dev] RFR: 8059847: complement JDK-8055286 and JDK-8056964 changes In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 12:33:12 GMT, ktakakuri wrote: > Hi all, > > This is a backport of JDK-8059847: complement JDK-8055286 and JDK-8056964 changes > > JDK-8055286 and JDK-8056964 are already backported to JDK8, but this patch is not. For this reason, CompileCommand=option does not support flags of type double, as reported. So this patch should be applied. > > The original patch is applied cleanly. > > Testing: hotspot_tier1 including the test which come with this patch. > > Thank you. Please explain why this backport is needed? It's a P5 enhancement and it's unclear why it's needed now in the current stage of the lifecycle of OpenJDK 8. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/396#issuecomment-1829831904 From andrew at openjdk.org Tue Nov 28 14:46:05 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 14:46:05 GMT Subject: [jdk8u-dev] RFR: 8312126: NullPointerException in CertStore.getCRLs after 8297955 [v3] In-Reply-To: <-58cu-nBHMzhzyvO-YuvaER1drfZvYcWEGeojP-Pvjg=.1262d53a-3375-4bd7-a706-dc07264a2713@github.com> References: <-58cu-nBHMzhzyvO-YuvaER1drfZvYcWEGeojP-Pvjg=.1262d53a-3375-4bd7-a706-dc07264a2713@github.com> Message-ID: > Hi all, > > This pull request contains a backport of commit [3c743cfe](https://github.com/openjdk/jdk/commit/3c743cfea00692d0b938cb1cbde936084eecf369) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Sean Mullan on 15 Sep 2023 and was reviewed by Weijun Wang. It was backported to 17u on 2023-11-10 and [a PR is open for 11u](https://github.com/openjdk/jdk11u-dev/pull/2299). > > It is a simple fix and clean backport for a regression introduced by [JDK-8297955](https://bugs.openjdk.org/browse/JDK-8297955) which was backported in [PR 388](https://github.com/openjdk/jdk8u-dev/pull/388). The new code in JDK-8297955 failed to catch a null IssuerName, allowing a NullPointerException to be thrown instead of the specified CertStoreException. > > Thanks. Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Backport 3c743cfea00692d0b938cb1cbde936084eecf369 ------------- Changes: https://git.openjdk.org/jdk8u-dev/pull/389/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=389&range=02 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/389.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/389/head:pull/389 PR: https://git.openjdk.org/jdk8u-dev/pull/389 From andrew at openjdk.org Tue Nov 28 14:46:07 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 14:46:07 GMT Subject: [jdk8u-dev] Integrated: 8312126: NullPointerException in CertStore.getCRLs after 8297955 In-Reply-To: <-58cu-nBHMzhzyvO-YuvaER1drfZvYcWEGeojP-Pvjg=.1262d53a-3375-4bd7-a706-dc07264a2713@github.com> References: <-58cu-nBHMzhzyvO-YuvaER1drfZvYcWEGeojP-Pvjg=.1262d53a-3375-4bd7-a706-dc07264a2713@github.com> Message-ID: On Fri, 24 Nov 2023 07:21:24 GMT, Andrew John Hughes wrote: > Hi all, > > This pull request contains a backport of commit [3c743cfe](https://github.com/openjdk/jdk/commit/3c743cfea00692d0b938cb1cbde936084eecf369) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Sean Mullan on 15 Sep 2023 and was reviewed by Weijun Wang. It was backported to 17u on 2023-11-10 and [a PR is open for 11u](https://github.com/openjdk/jdk11u-dev/pull/2299). > > It is a simple fix and clean backport for a regression introduced by [JDK-8297955](https://bugs.openjdk.org/browse/JDK-8297955) which was backported in [PR 388](https://github.com/openjdk/jdk8u-dev/pull/388). The new code in JDK-8297955 failed to catch a null IssuerName, allowing a NullPointerException to be thrown instead of the specified CertStoreException. > > Thanks. This pull request has now been integrated. Changeset: a226a47d Author: Andrew John Hughes URL: https://git.openjdk.org/jdk8u-dev/commit/a226a47d4367145583cd3821e96397ac1170f6d0 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8312126: NullPointerException in CertStore.getCRLs after 8297955 Reviewed-by: sgehwolf Backport-of: 3c743cfea00692d0b938cb1cbde936084eecf369 ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/389 From andrew at openjdk.org Tue Nov 28 14:47:23 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 14:47:23 GMT Subject: [jdk8u-dev] RFR: 8308592: Framework for CA interoperability testing [v2] In-Reply-To: References: Message-ID: > Hi all, > > This pull request contains a backport of commit [da57d2a1](https://github.com/openjdk/jdk/commit/da57d2a1eb409ddc64117865c7d24ed518421cab) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Rajan Halade on 19 Sep 2023 and was reviewed by Sean Mullan. It was backported to 17u on 2023-09-28 and 11u on 2023-10-11 > > It reworks the certificate tests to use test portals rather than having to maintain copies of the certificates in the OpenJDK repository and so should reduce the maintenance cost of these tests going forward. The fix has already been backported to 21u and Oracle-17u. > > There were conflicts in the removals of `ActalisCA.java`, `BuypassCA.java`, `LetsEncryptCA.java` and `QuoVadisCA.java`, due to changes not in 8u. For the first of these, we backported JDK-8297955 (see #388) as it also contains a code change. As the other three are only test changes, we assumed these bugs to be resolved by the replacement of the individual tests with `CAInterop.java`. > > The `ValidatePathWithURL.java` class had to be modified slightly to work with the 8u `cacerts`. These changes were based on the existing `ValidatePathWithParams.java`. > > All tests pass with the exception of the OCSP case of `certignarootca`. This fails with `Caused by: java.security.cert.CertPathValidatorException: Certificate does not specify OCSP responder`. While not ideal, I don't think this is an issue with the testing backport so I'd suggest we look into this and fix it later, while getting this in so that pending certificate updates can go in. It seems to be 8u specific (the case passed on 11u). The CRL case does pass as does `CertignaCA.java` (not sure why there are two tests for this one). Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/390/files - new: https://git.openjdk.org/jdk8u-dev/pull/390/files/0dc8bad2..0dc8bad2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=390&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=390&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/390.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/390/head:pull/390 PR: https://git.openjdk.org/jdk8u-dev/pull/390 From andrew at openjdk.org Tue Nov 28 15:04:00 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 15:04:00 GMT Subject: [jdk8u-dev] RFR: 8308592: Framework for CA interoperability testing [v3] In-Reply-To: References: Message-ID: > Hi all, > > This pull request contains a backport of commit [da57d2a1](https://github.com/openjdk/jdk/commit/da57d2a1eb409ddc64117865c7d24ed518421cab) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Rajan Halade on 19 Sep 2023 and was reviewed by Sean Mullan. It was backported to 17u on 2023-09-28 and 11u on 2023-10-11 > > It reworks the certificate tests to use test portals rather than having to maintain copies of the certificates in the OpenJDK repository and so should reduce the maintenance cost of these tests going forward. The fix has already been backported to 21u and Oracle-17u. > > There were conflicts in the removals of `ActalisCA.java`, `BuypassCA.java`, `LetsEncryptCA.java` and `QuoVadisCA.java`, due to changes not in 8u. For the first of these, we backported JDK-8297955 (see #388) as it also contains a code change. As the other three are only test changes, we assumed these bugs to be resolved by the replacement of the individual tests with `CAInterop.java`. > > The `ValidatePathWithURL.java` class had to be modified slightly to work with the 8u `cacerts`. These changes were based on the existing `ValidatePathWithParams.java`. > > All tests pass with the exception of the OCSP case of `certignarootca`. This fails with `Caused by: java.security.cert.CertPathValidatorException: Certificate does not specify OCSP responder`. While not ideal, I don't think this is an issue with the testing backport so I'd suggest we look into this and fix it later, while getting this in so that pending certificate updates can go in. It seems to be 8u specific (the case passed on 11u). The CRL case does pass as does `CertignaCA.java` (not sure why there are two tests for this one). Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Backport c4faab66933b5977a466f28c31cba9fc099c8fb4 ------------- Changes: https://git.openjdk.org/jdk8u-dev/pull/390/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=390&range=02 Stats: 6503 lines in 18 files changed: 1012 ins; 5491 del; 0 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/390.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/390/head:pull/390 PR: https://git.openjdk.org/jdk8u-dev/pull/390 From andrew at openjdk.org Tue Nov 28 15:12:49 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 15:12:49 GMT Subject: [jdk8u-dev] RFR: 8308592: Framework for CA interoperability testing [v4] In-Reply-To: References: Message-ID: > Hi all, > > This pull request contains a backport of commit [da57d2a1](https://github.com/openjdk/jdk/commit/da57d2a1eb409ddc64117865c7d24ed518421cab) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Rajan Halade on 19 Sep 2023 and was reviewed by Sean Mullan. It was backported to 17u on 2023-09-28 and 11u on 2023-10-11 > > It reworks the certificate tests to use test portals rather than having to maintain copies of the certificates in the OpenJDK repository and so should reduce the maintenance cost of these tests going forward. The fix has already been backported to 21u and Oracle-17u. > > There were conflicts in the removals of `ActalisCA.java`, `BuypassCA.java`, `LetsEncryptCA.java` and `QuoVadisCA.java`, due to changes not in 8u. For the first of these, we backported JDK-8297955 (see #388) as it also contains a code change. As the other three are only test changes, we assumed these bugs to be resolved by the replacement of the individual tests with `CAInterop.java`. > > The `ValidatePathWithURL.java` class had to be modified slightly to work with the 8u `cacerts`. These changes were based on the existing `ValidatePathWithParams.java`. > > All tests pass with the exception of the OCSP case of `certignarootca`. This fails with `Caused by: java.security.cert.CertPathValidatorException: Certificate does not specify OCSP responder`. While not ideal, I don't think this is an issue with the testing backport so I'd suggest we look into this and fix it later, while getting this in so that pending certificate updates can go in. It seems to be 8u specific (the case passed on 11u). The CRL case does pass as does `CertignaCA.java` (not sure why there are two tests for this one). Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision: Explicitly enable stapling, which is disabled by default in the 8u backport of TLS 1.3 ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/390/files - new: https://git.openjdk.org/jdk8u-dev/pull/390/files/04ae02cb..1c96da7e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=390&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=390&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/390.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/390/head:pull/390 PR: https://git.openjdk.org/jdk8u-dev/pull/390 From andrew at openjdk.org Tue Nov 28 15:12:51 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 15:12:51 GMT Subject: [jdk8u-dev] RFR: 8308592: Framework for CA interoperability testing [v2] In-Reply-To: <5fKpSvCCHW93aPdYFGFRCBrQn2IQncxal_V8rMvPytU=.591e9987-724b-46bc-abbb-303dd7268d71@github.com> References: <5fKpSvCCHW93aPdYFGFRCBrQn2IQncxal_V8rMvPytU=.591e9987-724b-46bc-abbb-303dd7268d71@github.com> Message-ID: <6JvpUP-0mOCFml7cIGNQhNoBVt_DTBUFGz_HEWGgIt4=.456a8b5b-0943-4561-bf8a-87fecfd0656e@github.com> On Mon, 27 Nov 2023 19:40:13 GMT, Severin Gehwolf wrote: > This looks good. The reason why `certignarootca` test fails is the different defaults for `jdk.tls.client.enableStatusRequestExtension` between JDK 11 and JDK 8 in `SSLContextImpl.java`. The former has it set to `true` the latter to `false` as per the TLS 1.3 backport to 8. Without it the `ClientHello` won't have the `status_request` extension, which is required for the test to pass. > > I suggest to set this to `true` in the affected test only (or set it to true globally in `CAInterop.java`). Either way I'd include this in this backport. Good catch. Looks like all tests pass with this enabled in `ValidatePathWithURL.java` ~~~ Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#actalisauthenticationrootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass3ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#certignarootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodoeccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodorsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcaec1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcag4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsigneccrootcar4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsignrootcar6 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#godaddyrootg2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootecccar3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootecccar4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#letsencryptisrgx1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#microsoftecc2017 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#microsoftrsa2017 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca2g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca3g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrooteccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrootevrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrootrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#starfieldrootg2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#twcaglobalrootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#usertrusteccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#usertrustrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CertignaCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/DTrustCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/HaricaCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java Test results: passed: 37 ~~~ ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/390#issuecomment-1830038927 From andrew at openjdk.org Tue Nov 28 15:13:22 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 15:13:22 GMT Subject: [jdk8u-dev] RFR: 8315757: [8u] Add cacerts JTREG tests to GHA tier1 test set [v4] In-Reply-To: References: Message-ID: On Thu, 21 Sep 2023 07:47:06 GMT, Severin Gehwolf wrote: >> Simple GHA only change to add cacert tests to the tier1 test set. Please review. >> >> Testing: >> - [x] GHA (which shows a failure in tier1 now, `VerifyCACerts.java` fails due to JDK-8295894; being worked on in jdk8u repo) > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8315757-tier1-gha > - Move to jdk_security_infra and add to tier1 > - 8315757: [8u] Add cacerts JTREG tests to GHA tier1 test set All tests pass now with #390, so if you make this PR depend on that, it should now pass. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/368#issuecomment-1830042067 From andrew at openjdk.org Tue Nov 28 15:15:10 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 28 Nov 2023 15:15:10 GMT Subject: [jdk8u-dev] RFR: 8308592: Framework for CA interoperability testing [v2] In-Reply-To: <6JvpUP-0mOCFml7cIGNQhNoBVt_DTBUFGz_HEWGgIt4=.456a8b5b-0943-4561-bf8a-87fecfd0656e@github.com> References: <5fKpSvCCHW93aPdYFGFRCBrQn2IQncxal_V8rMvPytU=.591e9987-724b-46bc-abbb-303dd7268d71@github.com> <6JvpUP-0mOCFml7cIGNQhNoBVt_DTBUFGz_HEWGgIt4=.456a8b5b-0943-4561-bf8a-87fecfd0656e@github.com> Message-ID: On Tue, 28 Nov 2023 15:09:10 GMT, Andrew John Hughes wrote: >> This looks good. The reason why `certignarootca` test fails is the different defaults for `jdk.tls.client.enableStatusRequestExtension` between JDK 11 and JDK 8 in `SSLContextImpl.java`. The former has it set to `true` the latter to `false` as per the TLS 1.3 backport to 8. Without it the `ClientHello` won't have the `status_request` extension, which is required for the test to pass. >> >> I suggest to set this to `true` in the affected test only (or set it to true globally in `CAInterop.java`). Either way I'd include this in this backport. > >> This looks good. The reason why `certignarootca` test fails is the different defaults for `jdk.tls.client.enableStatusRequestExtension` between JDK 11 and JDK 8 in `SSLContextImpl.java`. The former has it set to `true` the latter to `false` as per the TLS 1.3 backport to 8. Without it the `ClientHello` won't have the `status_request` extension, which is required for the test to pass. >> >> I suggest to set this to `true` in the affected test only (or set it to true globally in `CAInterop.java`). Either way I'd include this in this backport. > > Good catch. Looks like all tests pass with this enabled in `ValidatePathWithURL.java` > ~~~ > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#actalisauthenticationrootca > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca1 > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca2 > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca3 > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca4 > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass2ca > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass3ca > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#certignarootca > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodoeccca > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodorsaca > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcaec1 > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcag4 > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsigneccrootcar4 > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsignrootcar6 > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#godaddyrootg2ca > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar1 > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar2 > Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInt... > @gnu-andrew Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See [OpenJDK Developers? Guide](https://openjdk.org/guide/#working-with-pull-requests) for more information. Yeah, I'm not going to merge over half a dozen commits manually, bot, when Git is smart enough to match them against the ones you pushed to 8u-dev and just drop them. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/390#issuecomment-1830045506 From sgehwolf at openjdk.org Tue Nov 28 15:53:12 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 15:53:12 GMT Subject: [jdk8u-dev] RFR: 8308592: Framework for CA interoperability testing [v4] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 15:12:49 GMT, Andrew John Hughes wrote: >> Hi all, >> >> This pull request contains a backport of commit [da57d2a1](https://github.com/openjdk/jdk/commit/da57d2a1eb409ddc64117865c7d24ed518421cab) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Rajan Halade on 19 Sep 2023 and was reviewed by Sean Mullan. It was backported to 17u on 2023-09-28 and 11u on 2023-10-11 >> >> It reworks the certificate tests to use test portals rather than having to maintain copies of the certificates in the OpenJDK repository and so should reduce the maintenance cost of these tests going forward. The fix has already been backported to 21u and Oracle-17u. >> >> There were conflicts in the removals of `ActalisCA.java`, `BuypassCA.java`, `LetsEncryptCA.java` and `QuoVadisCA.java`, due to changes not in 8u. For the first of these, we backported JDK-8297955 (see #388) as it also contains a code change. As the other three are only test changes, we assumed these bugs to be resolved by the replacement of the individual tests with `CAInterop.java`. >> >> The `ValidatePathWithURL.java` class had to be modified slightly to work with the 8u `cacerts`. These changes were based on the existing `ValidatePathWithParams.java`. >> >> All tests pass with the exception of the OCSP case of `certignarootca`. This fails with `Caused by: java.security.cert.CertPathValidatorException: Certificate does not specify OCSP responder`. While not ideal, I don't think this is an issue with the testing backport so I'd suggest we look into this and fix it later, while getting this in so that pending certificate updates can go in. It seems to be 8u specific (the case passed on 11u). The CRL case does pass as does `CertignaCA.java` (not sure why there are two tests for this one). > > Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision: > > Explicitly enable stapling, which is disabled by default in the 8u backport of TLS 1.3 LGTM. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/390#pullrequestreview-1753259750 From sgehwolf at openjdk.org Tue Nov 28 16:24:36 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 16:24:36 GMT Subject: [jdk8u-dev] RFR: 8317373: Add Telia Root CA v2 Message-ID: Backport of a mandatory cacert root addition. JDK 11u patch applies clean modulo path changes. Please review. Testing: - [ ] GHA (still running). - [x] `jdk/test/sun/security/lib/cacerts` and `jdk/test/security/infra/java/security/cert/CertPathValidator` jtreg tests (including the new one). All pass. ------------- Depends on: https://git.openjdk.org/jdk8u-dev/pull/390 Commit messages: - Backport d3ebb4a155be8ed93e79b6b58c645e861ec30267 Changes: https://git.openjdk.org/jdk8u-dev/pull/397/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=397&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317373 Stats: 58 lines in 3 files changed: 55 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/397.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/397/head:pull/397 PR: https://git.openjdk.org/jdk8u-dev/pull/397 From sgehwolf at openjdk.org Tue Nov 28 16:24:36 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 16:24:36 GMT Subject: [jdk8u-dev] RFR: 8317373: Add Telia Root CA v2 In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 16:18:12 GMT, Severin Gehwolf wrote: > Backport of a mandatory cacert root addition. JDK 11u patch applies clean modulo path changes. Please review. > > Testing: > - [ ] GHA (still running). > - [x] `jdk/test/sun/security/lib/cacerts` and `jdk/test/security/infra/java/security/cert/CertPathValidator` jtreg tests (including the new one). All pass. Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#actalisauthenticationrootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass3ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#certignarootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodoeccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodorsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcaec1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcag4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsigneccrootcar4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsignrootcar6 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#godaddyrootg2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootecccar3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootecccar4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#letsencryptisrgx1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#microsoftecc2017 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#microsoftrsa2017 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca2g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca3g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrooteccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrootevrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrootrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#starfieldrootg2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliarootcav2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#twcaglobalrootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#usertrusteccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#usertrustrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CertignaCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/DTrustCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/HaricaCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java Passed: sun/security/lib/cacerts/VerifyCACerts.java Test results: passed: 39 ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/397#issuecomment-1830216073 From sgehwolf at openjdk.org Tue Nov 28 16:32:46 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 16:32:46 GMT Subject: [jdk8u-dev] RFR: 8315757: [8u] Add cacerts JTREG tests to GHA tier1 test set [v5] In-Reply-To: References: Message-ID: <0Y191MAA1YvnvXInqG9Po2gkEAHPFXNHXpBeCddrOSM=.251e07f0-7a52-4097-8e80-4fabec989a6c@github.com> > Simple GHA only change to add cacert tests to the tier1 test set. Please review. > > Testing: > - [ ] GHA (still running). It should be clean after #390. Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Move to jdk_security_infra and add to tier1 - 8315757: [8u] Add cacerts JTREG tests to GHA tier1 test set ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/368/files - new: https://git.openjdk.org/jdk8u-dev/pull/368/files/3bcf7e23..e0584c3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=368&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=368&range=03-04 Stats: 16292 lines in 766 files changed: 5032 ins; 10291 del; 969 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/368.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/368/head:pull/368 PR: https://git.openjdk.org/jdk8u-dev/pull/368 From sgehwolf at openjdk.org Tue Nov 28 16:32:46 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 16:32:46 GMT Subject: [jdk8u-dev] RFR: 8315757: [8u] Add cacerts JTREG tests to GHA tier1 test set [v4] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 15:10:48 GMT, Andrew John Hughes wrote: > All tests pass now with #390, so if you make this PR depend on that, it should now pass. Done. Let's see how it goes in terms of GHA. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/368#issuecomment-1830249323 From simonis at openjdk.org Tue Nov 28 17:20:32 2023 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 28 Nov 2023 17:20:32 GMT Subject: [jdk8u-dev] RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM In-Reply-To: <_ZWKxcgZzaoqb9iLlIsSoceyd-fiHhdHOpVmTsbRNI0=.99ae0e62-e9b2-4ef0-a6fe-15faa3e3c9cd@github.com> References: <_ZWKxcgZzaoqb9iLlIsSoceyd-fiHhdHOpVmTsbRNI0=.99ae0e62-e9b2-4ef0-a6fe-15faa3e3c9cd@github.com> Message-ID: On Sun, 26 Nov 2023 19:54:02 GMT, Paul Hohensee wrote: > I'd like to backport the definition and implementation of com.sun.management.ThreadMXBean.getTotalThreadAllocatedBytes to 8u. The backport CSR is [JDK-8320375](https://bugs.openjdk.org/browse/JDK-8320375). A follow-up bugfix backport of [JDK-8313081](https://bugs.openjdk.org/browse/JDK-8313081) will be done following this backport. The combined backports have been in production at Amazon for two months with no issues. The backport uses the reserved1 slot in jmm.h in order to preserve binary compatibility with 8u. Per current policy, there is no update to JMM_VERSION in jmm.h and the new method is marked > > @since 8u412 > > Aside from file relocation and context differences, relative to the 11u backport the MonitoringSupport_lock definition macro changes, and the reserved1 rather than reserved6 jmm slot is used. SMR doesn't exist in 8u, so jmm_GetTotalThreadAllocated bytes attempts to lock Threads_lock instead, and if the Threads_lock is already locked, the previous return value is returned. HotSpotThreadImpl.java doesn't exist in 8u, so the hunk associated with it is dropped. I didn't read the PR comment carefully (my fault :) so here's my list of changes with regards to the corresponding jdk11 change set (see https://github.com/openjdk/jdk11u-dev/pull/2286). I'll provide them here in the hope to simplify the review for others: - in jdk8 we have two `jmm.h` files, one in `jdk/src/share/javavm/export/jmm.h` and one in `hotspot/src/share/vm/services/jmm.h`. The changes to both files are the same. - There's no `HotSpotThreadImpl.java` so the function added in the base class `ThreadImpl.java` has to be public in jdk8u. - there is no `jdk/make/mapfiles/libmanagement/mapfile-vers` in `jdk11u` and later. - there's no `JavaThreadIteratorWithHandle`/`ThreadsListHandle` in jdk8 that's why we have to use the `Threads_lock` while iterating over the threads. It's also the reason why parts of the comments in `jmm_GetTotalThreadAllocatedMemory()` became obsolete and have been removed. @phohensee, is my assumption correct that you also use this already in production within Amazon and haven't seen any negative impact (particularly not due to the usage of the `Threads_lock` in `jmm_GetTotalThreadAllocatedMemory()` ? jdk/make/mapfiles/libmanagement/mapfile-vers line 92: > 90: Java_sun_management_ThreadImpl_getThreadAllocatedMemory0; > 91: Java_sun_management_ThreadImpl_getThreadAllocatedMemory1; > 92: Java_sun_management_ThreadImpl_getTotalThreadAllocatedMemory; All the other entries are indented by a TAB plus four spaces. This is not ideal, but please use the same scheme to get the same indentation independently of the TAB size. ------------- Changes requested by simonis (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/392#pullrequestreview-1753408107 PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/392#discussion_r1408084868 From simonis at openjdk.org Tue Nov 28 17:22:34 2023 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 28 Nov 2023 17:22:34 GMT Subject: [jdk8u-dev] RFR: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074 In-Reply-To: <6WTexvrkW8zsKxZQ4rUZZQ212Mow__tiYrMyVLyjgWc=.5e9cf95f-7b42-43b8-a5c7-e112244fd3c8@github.com> References: <6WTexvrkW8zsKxZQ4rUZZQ212Mow__tiYrMyVLyjgWc=.5e9cf95f-7b42-43b8-a5c7-e112244fd3c8@github.com> Message-ID: On Sun, 26 Nov 2023 20:18:53 GMT, Paul Hohensee wrote: > Follow-on bug fix for [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) backport. Unclean backport from 11u, see https://github.com/openjdk/jdk11u-dev/pull/2287. Other than file location and context, the lock definition macro changed between 8 and 11, so the definition of MonitoringSupport_lock is different. Trivial fix. Looks good. ------------- Marked as reviewed by simonis (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/393#pullrequestreview-1753468074 From sgehwolf at openjdk.org Tue Nov 28 18:57:18 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 18:57:18 GMT Subject: [jdk8u-dev] RFR: 8317373: Add Telia Root CA v2 In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 16:18:12 GMT, Severin Gehwolf wrote: > Backport of a mandatory cacert root addition. JDK 11u patch applies clean modulo path changes. Please review. > > Testing: > - [ ] GHA (still running). > - [x] `jdk/test/sun/security/lib/cacerts` and `jdk/test/security/infra/java/security/cert/CertPathValidator` jtreg tests (including the new one). All pass. The windows x64 build failure looks suspicous. It doesn't fail in #390 which this PR is based on and doesn't really change anything related to the build failure. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/397#issuecomment-1830486655 From sgehwolf at openjdk.org Tue Nov 28 18:58:44 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 18:58:44 GMT Subject: [jdk8u-dev] RFR: 8317374: Add Let's Encrypt ISRG Root X2 Message-ID: Backport so as to add the Let's Encrypt ISRG Root X2 CA. Applies clean after path shuffeling. Please review! Testing: - [ ] GHA (still running) - [x] `jdk/test/security/infra/java/security/cert/CertPathValidator` and `jdk/test/sun/security/lib/cacerts` jtreg tests. ------------- Depends on: https://git.openjdk.org/jdk8u-dev/pull/397 Commit messages: - Backport e6f46a43268808d0cbbb3bb93c73aa8e4cbfad83 Changes: https://git.openjdk.org/jdk8u-dev/pull/398/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=398&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317374 Stats: 39 lines in 3 files changed: 35 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/398.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/398/head:pull/398 PR: https://git.openjdk.org/jdk8u-dev/pull/398 From sgehwolf at openjdk.org Tue Nov 28 18:58:44 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 18:58:44 GMT Subject: [jdk8u-dev] RFR: 8317374: Add Let's Encrypt ISRG Root X2 In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 18:50:55 GMT, Severin Gehwolf wrote: > Backport so as to add the Let's Encrypt ISRG Root X2 CA. Applies clean after path shuffeling. Please review! > > Testing: > - [ ] GHA (still running) > - [x] `jdk/test/security/infra/java/security/cert/CertPathValidator` and `jdk/test/sun/security/lib/cacerts` jtreg tests. Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#actalisauthenticationrootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass3ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#certignarootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodoeccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodorsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcaec1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcag4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsigneccrootcar4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsignrootcar6 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#godaddyrootg2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootecccar3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootecccar4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#letsencryptisrgx1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#letsencryptisrgx2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#microsoftecc2017 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#microsoftrsa2017 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca2g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca3g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrooteccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrootevrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrootrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#starfieldrootg2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliarootcav2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#twcaglobalrootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#usertrusteccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#usertrustrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CertignaCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/DTrustCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/HaricaCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java Passed: sun/security/lib/cacerts/VerifyCACerts.java Test results: passed: 40 ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/398#issuecomment-1830488415 From phh at openjdk.org Tue Nov 28 19:15:15 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 28 Nov 2023 19:15:15 GMT Subject: [jdk8u-dev] RFR: 8021961: setAlwaysOnTop doesn't behave correctly in Linux/Solaris under certain scenarios In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 09:28:53 GMT, Taizo Kurashige wrote: > Hi, > > This is a backoport of JDK-8021961: setAlwaysOnTop doesn't behave correctly in Linux/Solaris under certain scenarios > > Original patch does not apply cleanly to 8u, bacause "parent" is declared at XWindowPeer.java#1652 in 8u. > So I deleted that declaration. > > There is a related Issue: JDK-8222323, and I submit the corresponding PR. Testing was done after applying this related patch. > Testing: jdk_awt on RHEL7, GHA testing > > Thanks. This PR has been approved, please add /integrate. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/377#issuecomment-1830514649 From phh at openjdk.org Tue Nov 28 19:16:17 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 28 Nov 2023 19:16:17 GMT Subject: [jdk8u-dev] RFR: 8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 09:39:50 GMT, Taizo Kurashige wrote: > Hi, > > This is a backport of JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" > > Original patch does not apply cleanly to JDK-8021961 applied code, because the fix uses "StringBuffer.isEmpty()" published in JDK15. I fixed the test so as not to use "StringBuffer.isEmpty()". > > Testing: jdk_awt on RHEL7, GHA testing > > Thanks. This PR has been approved, please add /integrate. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/378#issuecomment-1830515277 From sgehwolf at openjdk.org Tue Nov 28 19:19:14 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 19:19:14 GMT Subject: [jdk8u-dev] RFR: 8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:13:28 GMT, Paul Hohensee wrote: > This PR has been approved, please add /integrate. This needs https://github.com/openjdk/jdk8u-dev/pull/377 first. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/378#issuecomment-1830519401 From sgehwolf at openjdk.org Tue Nov 28 19:20:42 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 19:20:42 GMT Subject: [jdk8u-dev] RFR: 8318759: Add four DigiCert root certificates Message-ID: Backport for adding 4 new digicert root certificates. Patch applies clean modulo path shuffeling. Testing: - [ ] GHA (still running) - [x] jdk/test/security/infra/java/security/cert/CertPathValidator and jdk/test/sun/security/lib/cacerts jtreg tests. Including new ones. All 43 tests pass. ------------- Depends on: https://git.openjdk.org/jdk8u-dev/pull/398 Commit messages: - Backport 0ea58048f9b4cdaaa0470b2bcc03913fb3939453 Changes: https://git.openjdk.org/jdk8u-dev/pull/399/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=399&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318759 Stats: 459 lines in 7 files changed: 456 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/399.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/399/head:pull/399 PR: https://git.openjdk.org/jdk8u-dev/pull/399 From sgehwolf at openjdk.org Tue Nov 28 19:20:42 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 19:20:42 GMT Subject: [jdk8u-dev] RFR: 8318759: Add four DigiCert root certificates In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:12:25 GMT, Severin Gehwolf wrote: > Backport for adding 4 new digicert root certificates. Patch applies clean modulo path shuffeling. > > Testing: > - [ ] GHA (still running) > - [x] jdk/test/security/infra/java/security/cert/CertPathValidator and jdk/test/sun/security/lib/cacerts jtreg tests. Including new ones. All 43 tests pass. Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#actalisauthenticationrootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass3ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#certignarootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodoeccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodorsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#digicerttlseccrootg5 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#digicerttlsrsarootg5 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcaec1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcag4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsigneccrootcar4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsignrootcar6 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#godaddyrootg2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootecccar3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootecccar4 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#letsencryptisrgx1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#letsencryptisrgx2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#microsoftecc2017 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#microsoftrsa2017 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca1g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca2g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#quovadisrootca3g3 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrooteccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrootevrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrootrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#starfieldrootg2ca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliarootcav2 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1 Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#twcaglobalrootca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#usertrusteccca Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#usertrustrsaca Passed: security/infra/java/security/cert/CertPathValidator/certification/CertignaCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/DigicertCSRootG5.java Passed: security/infra/java/security/cert/CertPathValidator/certification/DTrustCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/HaricaCA.java Passed: security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java Passed: sun/security/lib/cacerts/VerifyCACerts.java Test results: passed: 43 ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/399#issuecomment-1830515593 From gnu.andrew at redhat.com Tue Nov 28 20:11:45 2023 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 28 Nov 2023 20:11:45 +0000 Subject: CFV: New OpenJDK 8u Reviewer: Thomas Stuefe In-Reply-To: References: Message-ID: On 14:47 Mon 27 Nov , Andrew Hughes wrote: > I hereby nominate Thomas Stuefe [0] for the role of OpenJDK 8u Reviewer. > > Thomas already has reviewership in OpenJDK 9 and later and a wealth of > OpenJDK experience [1] [2] [3] [4]. Thus, his lack of reviewer status > on OpenJDK 8 Updates seems more a simple case of when he started > contributing to OpenJDK - as the same status is conferred on to new > JDK releases, but not retrospectively to older ones - than a lack of > sufficient technical qualification. > > Votes are due by 15h00 UTC on the 11th of December, 2023. > > Only current OpenJDK 8u Reviewers [5] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [6]. > > [0] https://openjdk.java.net/census#stuefe > [1] https://github.com/openjdk/jdk/commits?author=tstuefe > [2] https://github.com/openjdk/jdk17u/commits?author=tstuefe > [3] https://github.com/openjdk/jdk11u/commits?author=tstuefe > [4] https://github.com/openjdk/jdk8u/commits?author=tstuefe > [3] http://openjdk.java.net/census#jdk8u > [4] http://openjdk.java.net/bylaws#three-vote-consensus > > Thanks, > -- > Andrew :) > Pronouns: he / him or they / them > Principal Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > Please contact via e-mail, not proprietary chat networks > Available on Libera Chat & OFTC IRC networks as gnu_andrew Vote: Yes -- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks Available on Libera Chat & OFTC IRC networks as gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From gnu.andrew at redhat.com Tue Nov 28 20:22:00 2023 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 28 Nov 2023 20:22:00 +0000 Subject: Backport of JDK-8293562 to JDK8 In-Reply-To: References: Message-ID: On 16:47 Mon 27 Nov , Dhamoder Nalla wrote: > Hi All, > > I'm a member of the Java Engineering Group at Microsoft, currently working on a TLS 1.3 issue for one of our customers using JDK8. This issue aligns with JDK-8293562. > This customer is currently not able to upgrade their JDK version, so I'm interested in understanding if there are any concerns about backporting this bug (JDK-8293562) fix to JDK8 (or if this is already in progress by someone). > > Thanks, > Dhamoder. > > It's difficult to give a definitive answer without seeing what the backport would actually look like, how it may need to be modified for 8u and if any other backports are needed as well. What I would say is that the TLS 1.3 support in 8u was recently backported from 11u, so it is already code that is newer than most of 8u and similar to what it is in 11u. Given we already made a backport of such a significant enhancement, I would say that bug fixes for it have a lower bar than other changes elsewhere in the 8u code base. The change also has a test case which is always a plus. I'm not aware of any work on 8u already, though this ticket saw a lot of interest when backporting to 11u with two competing PRs. I would say do the backport and propose a PR, but be aware that the end result of that process could be that we decide not to go ahead, as some changes are deemed too risky to 8u stability. Hope that helps, -- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks Available on Libera Chat & OFTC IRC networks as gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From gnu.andrew at redhat.com Tue Nov 28 20:23:11 2023 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 28 Nov 2023 20:23:11 +0000 Subject: [RAMPDOWN] 8u402 now in Rampdown Stage In-Reply-To: References: Message-ID: On 17:05 Sat 25 Nov , Andrew Hughes wrote: > 8u402 is in rampdown for release in January 2024. > > jdk8u-dev is CLOSED for commits until > https://bugs.openjdk.org/browse/JDK-8320713 is integrated to begin the > 8u412 release cycle. > > For critical fixes (i.e. regressions or urgent fixes like tzdata > updates) for 8u402, please file a PR against > https://github.com/openjdk/jdk8u and use jdk8u-critical-request to > obtain approval to push. > > Thanks, > -- > Andrew :) > Pronouns: he / him or they / them > Principal Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > Please contact via e-mail, not proprietary chat networks > Available on Libera Chat & OFTC IRC networks as gnu_andrew 8u-dev is now open for commits to 8u412. Thanks, -- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks Available on Libera Chat & OFTC IRC networks as gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From phh at openjdk.org Tue Nov 28 22:52:13 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 28 Nov 2023 22:52:13 GMT Subject: [jdk8u-dev] RFR: 8317374: Add Let's Encrypt ISRG Root X2 In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 18:50:55 GMT, Severin Gehwolf wrote: > Backport so as to add the Let's Encrypt ISRG Root X2 CA. Applies clean after path shuffeling. Please review! > > Testing: > - [ ] GHA (still running) > - [x] `jdk/test/security/infra/java/security/cert/CertPathValidator` and `jdk/test/sun/security/lib/cacerts` jtreg tests. Marked as reviewed by phh (Reviewer). linux-x86 failure appears unrelated. ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/398#pullrequestreview-1754089893 PR Comment: https://git.openjdk.org/jdk8u-dev/pull/398#issuecomment-1830882520 From phh at openjdk.org Tue Nov 28 22:55:12 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 28 Nov 2023 22:55:12 GMT Subject: [jdk8u-dev] RFR: 8317373: Add Telia Root CA v2 In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 16:18:12 GMT, Severin Gehwolf wrote: > Backport of a mandatory cacert root addition. JDK 11u patch applies clean modulo path changes. Please review. > > Testing: > - [ ] GHA (still running). > - [x] `jdk/test/sun/security/lib/cacerts` and `jdk/test/security/infra/java/security/cert/CertPathValidator` jtreg tests (including the new one). All pass. Marked as reviewed by phh (Reviewer). windows-x64 failure appears to be an infrastructure issue. ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/397#pullrequestreview-1754091945 PR Comment: https://git.openjdk.org/jdk8u-dev/pull/397#issuecomment-1830885512 From phh at openjdk.org Tue Nov 28 23:06:12 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 28 Nov 2023 23:06:12 GMT Subject: [jdk8u-dev] RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM In-Reply-To: <_ZWKxcgZzaoqb9iLlIsSoceyd-fiHhdHOpVmTsbRNI0=.99ae0e62-e9b2-4ef0-a6fe-15faa3e3c9cd@github.com> References: <_ZWKxcgZzaoqb9iLlIsSoceyd-fiHhdHOpVmTsbRNI0=.99ae0e62-e9b2-4ef0-a6fe-15faa3e3c9cd@github.com> Message-ID: On Sun, 26 Nov 2023 19:54:02 GMT, Paul Hohensee wrote: > I'd like to backport the definition and implementation of com.sun.management.ThreadMXBean.getTotalThreadAllocatedBytes to 8u. The backport CSR is [JDK-8320375](https://bugs.openjdk.org/browse/JDK-8320375). A follow-up bugfix backport of [JDK-8313081](https://bugs.openjdk.org/browse/JDK-8313081) will be done following this backport. The combined backports have been in production at Amazon for two months with no issues. The backport uses the reserved1 slot in jmm.h in order to preserve binary compatibility with 8u. Per current policy, there is no update to JMM_VERSION in jmm.h and the new method is marked > > @since 8u412 > > Aside from file relocation and context differences, relative to the 11u backport the MonitoringSupport_lock definition macro changes, and the reserved1 rather than reserved6 jmm slot is used. SMR doesn't exist in 8u, so jmm_GetTotalThreadAllocated bytes attempts to lock Threads_lock instead, and if the Threads_lock is already locked, the previous return value is returned. HotSpotThreadImpl.java doesn't exist in 8u, so the hunk associated with it is dropped. linux-x86 test failure is unrelated and has appeared in multiple PRs. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/392#issuecomment-1830897906 From phh at openjdk.org Tue Nov 28 23:14:29 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 28 Nov 2023 23:14:29 GMT Subject: [jdk8u-dev] RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v2] In-Reply-To: <_ZWKxcgZzaoqb9iLlIsSoceyd-fiHhdHOpVmTsbRNI0=.99ae0e62-e9b2-4ef0-a6fe-15faa3e3c9cd@github.com> References: <_ZWKxcgZzaoqb9iLlIsSoceyd-fiHhdHOpVmTsbRNI0=.99ae0e62-e9b2-4ef0-a6fe-15faa3e3c9cd@github.com> Message-ID: > I'd like to backport the definition and implementation of com.sun.management.ThreadMXBean.getTotalThreadAllocatedBytes to 8u. The backport CSR is [JDK-8320375](https://bugs.openjdk.org/browse/JDK-8320375). A follow-up bugfix backport of [JDK-8313081](https://bugs.openjdk.org/browse/JDK-8313081) will be done following this backport. The combined backports have been in production at Amazon for two months with no issues. The backport uses the reserved1 slot in jmm.h in order to preserve binary compatibility with 8u. Per current policy, there is no update to JMM_VERSION in jmm.h and the new method is marked > > @since 8u412 > > Aside from file relocation and context differences, relative to the 11u backport the MonitoringSupport_lock definition macro changes, and the reserved1 rather than reserved6 jmm slot is used. SMR doesn't exist in 8u, so jmm_GetTotalThreadAllocated bytes attempts to lock Threads_lock instead, and if the Threads_lock is already locked, the previous return value is returned. HotSpotThreadImpl.java doesn't exist in 8u, so the hunk associated with it is dropped. Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: 8304074: whitespace fix ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/392/files - new: https://git.openjdk.org/jdk8u-dev/pull/392/files/50dc3e3b..137de84e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=392&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=392&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/392.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/392/head:pull/392 PR: https://git.openjdk.org/jdk8u-dev/pull/392 From phh at openjdk.org Tue Nov 28 23:14:34 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 28 Nov 2023 23:14:34 GMT Subject: [jdk8u-dev] RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v2] In-Reply-To: References: <_ZWKxcgZzaoqb9iLlIsSoceyd-fiHhdHOpVmTsbRNI0=.99ae0e62-e9b2-4ef0-a6fe-15faa3e3c9cd@github.com> Message-ID: <1SmHlqUFn0kaVA4em_gTQ9Ui5dMdtI0tXZn6EP-3KfY=.6563ca59-56b9-4058-8b05-482a9cc4f265@github.com> On Tue, 28 Nov 2023 16:53:23 GMT, Volker Simonis wrote: >> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: >> >> 8304074: whitespace fix > > jdk/make/mapfiles/libmanagement/mapfile-vers line 92: > >> 90: Java_sun_management_ThreadImpl_getThreadAllocatedMemory0; >> 91: Java_sun_management_ThreadImpl_getThreadAllocatedMemory1; >> 92: Java_sun_management_ThreadImpl_getTotalThreadAllocatedMemory; > > All the other entries are indented by a TAB plus four spaces. This is not ideal, but please use the same scheme to get the same indentation independently of the TAB size. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/392#discussion_r1408525503 From phh at openjdk.org Tue Nov 28 23:14:31 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 28 Nov 2023 23:14:31 GMT Subject: [jdk8u-dev] RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM In-Reply-To: <_ZWKxcgZzaoqb9iLlIsSoceyd-fiHhdHOpVmTsbRNI0=.99ae0e62-e9b2-4ef0-a6fe-15faa3e3c9cd@github.com> References: <_ZWKxcgZzaoqb9iLlIsSoceyd-fiHhdHOpVmTsbRNI0=.99ae0e62-e9b2-4ef0-a6fe-15faa3e3c9cd@github.com> Message-ID: On Sun, 26 Nov 2023 19:54:02 GMT, Paul Hohensee wrote: > I'd like to backport the definition and implementation of com.sun.management.ThreadMXBean.getTotalThreadAllocatedBytes to 8u. The backport CSR is [JDK-8320375](https://bugs.openjdk.org/browse/JDK-8320375). A follow-up bugfix backport of [JDK-8313081](https://bugs.openjdk.org/browse/JDK-8313081) will be done following this backport. The combined backports have been in production at Amazon for two months with no issues. The backport uses the reserved1 slot in jmm.h in order to preserve binary compatibility with 8u. Per current policy, there is no update to JMM_VERSION in jmm.h and the new method is marked > > @since 8u412 > > Aside from file relocation and context differences, relative to the 11u backport the MonitoringSupport_lock definition macro changes, and the reserved1 rather than reserved6 jmm slot is used. SMR doesn't exist in 8u, so jmm_GetTotalThreadAllocated bytes attempts to lock Threads_lock instead, and if the Threads_lock is already locked, the previous return value is returned. HotSpotThreadImpl.java doesn't exist in 8u, so the hunk associated with it is dropped. Thanks for the quick review, Volker! Re your comments: Yes, there are two jmm.h files with identical changes. I missed pointing that out. HotSpotThreadImpl.java was mentioned in the PR comment. Yes, there is no jdk/make/mapfiles/libmanagement/mapfile-vers in jdk11u and later. I missed pointing that out too. Lack of SMR was mentioned in the PR comment. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/392#issuecomment-1830904535 From christoph.langer at sap.com Wed Nov 29 10:56:46 2023 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 29 Nov 2023 10:56:46 +0000 Subject: CFV: New OpenJDK 8u Reviewer: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of Andrew Hughes > Sent: Montag, 27. November 2023 15:48 > To: jdk8u-dev at openjdk.org > Subject: CFV: New OpenJDK 8u Reviewer: Thomas Stuefe > > I hereby nominate Thomas Stuefe [0] for the role of OpenJDK 8u Reviewer. > > Thomas already has reviewership in OpenJDK 9 and later and a wealth of > OpenJDK experience [1] [2] [3] [4]. Thus, his lack of reviewer status on OpenJDK > 8 Updates seems more a simple case of when he started contributing to > OpenJDK - as the same status is conferred on to new JDK releases, but not > retrospectively to older ones - than a lack of sufficient technical qualification. > > Votes are due by 15h00 UTC on the 11th of December, 2023. > > Only current OpenJDK 8u Reviewers [5] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [6]. > > [0] https://openjdk.java.net/census#stuefe > [1] https://github.com/openjdk/jdk/commits?author=tstuefe > [2] https://github.com/openjdk/jdk17u/commits?author=tstuefe > [3] https://github.com/openjdk/jdk11u/commits?author=tstuefe > [4] https://github.com/openjdk/jdk8u/commits?author=tstuefe > [3] http://openjdk.java.net/census#jdk8u > [4] http://openjdk.java.net/bylaws#three-vote-consensus > > Thanks, > -- > Andrew :) > Pronouns: he / him or they / them > Principal Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = > 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > Please contact via e-mail, not proprietary chat networks Available on Libera > Chat & OFTC IRC networks as gnu_andrew From duke at openjdk.org Wed Nov 29 10:59:25 2023 From: duke at openjdk.org (ktakakuri) Date: Wed, 29 Nov 2023 10:59:25 GMT Subject: [jdk8u-dev] RFR: 8320964: sun/tools/native2ascii/Native2AsciiTests.sh fails on Japanese Message-ID: <5cvLYA6PgVxQXmRRBXLPdNv4E9zi-zqqq1IL3nU_3mw=.49d05d7d-a4b8-473b-a9e8-59018d95b2c8@github.com> I would like to fix this issue because the test dose not work as intended. Could someone please review it? ------------- Commit messages: - Fix Native2AsciiTests.sh Changes: https://git.openjdk.org/jdk8u-dev/pull/400/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=400&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320964 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/400.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/400/head:pull/400 PR: https://git.openjdk.org/jdk8u-dev/pull/400 From simonis at openjdk.org Wed Nov 29 13:35:14 2023 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 29 Nov 2023 13:35:14 GMT Subject: [jdk8u-dev] RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v2] In-Reply-To: References: <_ZWKxcgZzaoqb9iLlIsSoceyd-fiHhdHOpVmTsbRNI0=.99ae0e62-e9b2-4ef0-a6fe-15faa3e3c9cd@github.com> Message-ID: <1gFro4rT3rfrcAtMclCjoqKU8YBboSxvZC_90_5MlqA=.240be822-a72f-4ec5-9169-7d212fdaf3ca@github.com> On Tue, 28 Nov 2023 23:14:29 GMT, Paul Hohensee wrote: >> I'd like to backport the definition and implementation of com.sun.management.ThreadMXBean.getTotalThreadAllocatedBytes to 8u. The backport CSR is [JDK-8320375](https://bugs.openjdk.org/browse/JDK-8320375). A follow-up bugfix backport of [JDK-8313081](https://bugs.openjdk.org/browse/JDK-8313081) will be done following this backport. The combined backports have been in production at Amazon for two months with no issues. The backport uses the reserved1 slot in jmm.h in order to preserve binary compatibility with 8u. Per current policy, there is no update to JMM_VERSION in jmm.h and the new method is marked >> >> @since 8u412 >> >> Aside from file relocation and context differences, relative to the 11u backport the MonitoringSupport_lock definition macro changes, and the reserved1 rather than reserved6 jmm slot is used. SMR doesn't exist in 8u, so jmm_GetTotalThreadAllocated bytes attempts to lock Threads_lock instead, and if the Threads_lock is already locked, the previous return value is returned. HotSpotThreadImpl.java doesn't exist in 8u, so the hunk associated with it is dropped. > > Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: > > 8304074: whitespace fix Thanks for the addition information Paul. Looks good now. ------------- Marked as reviewed by simonis (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/392#pullrequestreview-1755275315 From duke at openjdk.org Wed Nov 29 13:58:24 2023 From: duke at openjdk.org (Taizo Kurashige) Date: Wed, 29 Nov 2023 13:58:24 GMT Subject: [jdk8u-dev] Integrated: 8021961: setAlwaysOnTop doesn't behave correctly in Linux/Solaris under certain scenarios In-Reply-To: References: Message-ID: <_Qb3G5h_QI9CG1Ul_Zn4NIC8S3DH6ZfBVSSqLQqCPXk=.48e4408f-4c1e-4f7d-8304-347d61c2cf65@github.com> On Thu, 28 Sep 2023 09:28:53 GMT, Taizo Kurashige wrote: > Hi, > > This is a backoport of JDK-8021961: setAlwaysOnTop doesn't behave correctly in Linux/Solaris under certain scenarios > > Original patch does not apply cleanly to 8u, bacause "parent" is declared at XWindowPeer.java#1652 in 8u. > So I deleted that declaration. > > There is a related Issue: JDK-8222323, and I submit the corresponding PR. Testing was done after applying this related patch. > Testing: jdk_awt on RHEL7, GHA testing > > Thanks. This pull request has now been integrated. Changeset: 8cf7c968 Author: Taizo Kurashige Committer: Paul Hohensee URL: https://git.openjdk.org/jdk8u-dev/commit/8cf7c96813c7f26ee922a2db44a8b5cc97324985 Stats: 204 lines in 2 files changed: 193 ins; 4 del; 7 mod 8021961: setAlwaysOnTop doesn't behave correctly in Linux/Solaris under certain scenarios Reviewed-by: andrew Backport-of: 09a7c4bc4624dd39ab5500c394c1e298a43a711a ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/377 From duke at openjdk.org Wed Nov 29 14:00:40 2023 From: duke at openjdk.org (Taizo Kurashige) Date: Wed, 29 Nov 2023 14:00:40 GMT Subject: [jdk8u-dev] RFR: 8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" [v2] In-Reply-To: References: Message-ID: <1vMv0JhaBhTFSRXErtWKTUTS56rN8I_rUldErtgOcAI=.fa91176c-47b5-4f5a-90ce-7069bb598169@github.com> > Hi, > > This is a backport of JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" > > Original patch does not apply cleanly to JDK-8021961 applied code, because the fix uses "StringBuffer.isEmpty()" published in JDK15. I fixed the test so as not to use "StringBuffer.isEmpty()". > > Testing: jdk_awt on RHEL7, GHA testing > > Thanks. Taizo Kurashige has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/378/files - new: https://git.openjdk.org/jdk8u-dev/pull/378/files/ce74df4e..ce74df4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=378&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=378&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/378.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/378/head:pull/378 PR: https://git.openjdk.org/jdk8u-dev/pull/378 From duke at openjdk.org Wed Nov 29 15:15:22 2023 From: duke at openjdk.org (Taizo Kurashige) Date: Wed, 29 Nov 2023 15:15:22 GMT Subject: [jdk8u-dev] Integrated: 8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 09:39:50 GMT, Taizo Kurashige wrote: > Hi, > > This is a backport of JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" > > Original patch does not apply cleanly to JDK-8021961 applied code, because the fix uses "StringBuffer.isEmpty()" published in JDK15. I fixed the test so as not to use "StringBuffer.isEmpty()". > > Testing: jdk_awt on RHEL7, GHA testing > > Thanks. This pull request has now been integrated. Changeset: b05e6799 Author: Taizo Kurashige Committer: Paul Hohensee URL: https://git.openjdk.org/jdk8u-dev/commit/b05e6799d30a7e5e5b88f12914cd3d0f88aab729 Stats: 224 lines in 1 file changed: 128 ins; 32 del; 64 mod 8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" Reviewed-by: sgehwolf Backport-of: 837928ba7955dbfd4a9c966209c3469c0fb5e195 ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/378 From hohensee at amazon.com Wed Nov 29 17:27:03 2023 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 29 Nov 2023 17:27:03 +0000 Subject: CFV: New OpenJDK 8u Reviewer: Thomas Stuefe Message-ID: <33D1112B-4892-4256-BA34-79CFD31CAAF9@amazon.com> Vote: yes ?On 11/27/23, 6:48 AM, "jdk8u-dev on behalf of Andrew Hughes" on behalf of gnu.andrew at redhat.com > wrote: I hereby nominate Thomas Stuefe [0] for the role of OpenJDK 8u Reviewer. Thomas already has reviewership in OpenJDK 9 and later and a wealth of OpenJDK experience [1] [2] [3] [4]. Thus, his lack of reviewer status on OpenJDK 8 Updates seems more a simple case of when he started contributing to OpenJDK - as the same status is conferred on to new JDK releases, but not retrospectively to older ones - than a lack of sufficient technical qualification. Votes are due by 15h00 UTC on the 11th of December, 2023. Only current OpenJDK 8u Reviewers [5] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [6]. [0] https://openjdk.java.net/census#stuefe [1] https://github.com/openjdk/jdk/commits?author=tstuefe [2] https://github.com/openjdk/jdk17u/commits?author=tstuefe [3] https://github.com/openjdk/jdk11u/commits?author=tstuefe [4] https://github.com/openjdk/jdk8u/commits?author=tstuefe [3] http://openjdk.java.net/census#jdk8u [4] http://openjdk.java.net/bylaws#three-vote-consensus Thanks, -- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com ) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks Available on Libera Chat & OFTC IRC networks as gnu_andrew From phh at openjdk.org Wed Nov 29 17:28:24 2023 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 29 Nov 2023 17:28:24 GMT Subject: [jdk8u-dev] RFR: 8320964: sun/tools/native2ascii/Native2AsciiTests.sh fails on Japanese In-Reply-To: <5cvLYA6PgVxQXmRRBXLPdNv4E9zi-zqqq1IL3nU_3mw=.49d05d7d-a4b8-473b-a9e8-59018d95b2c8@github.com> References: <5cvLYA6PgVxQXmRRBXLPdNv4E9zi-zqqq1IL3nU_3mw=.49d05d7d-a4b8-473b-a9e8-59018d95b2c8@github.com> Message-ID: <60VledOelbHO0N6U57BuaJBSlmwnjU0QNamwITAGxGc=.3167b310-d33a-4232-9079-152f4a9d31c2@github.com> On Wed, 29 Nov 2023 10:55:17 GMT, ktakakuri wrote: > I would like to fix this issue because the test dose not work as intended. > Could someone please review it? Marked as reviewed by phh (Reviewer). linux-x86 failure seems unrelated, but please have a look at the windows-x64 failure. ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/400#pullrequestreview-1755838937 PR Comment: https://git.openjdk.org/jdk8u-dev/pull/400#issuecomment-1832383844 From phh at openjdk.org Wed Nov 29 17:33:26 2023 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 29 Nov 2023 17:33:26 GMT Subject: [jdk8u-dev] RFR: 8318759: Add four DigiCert root certificates In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:12:25 GMT, Severin Gehwolf wrote: > Backport for adding 4 new digicert root certificates. Patch applies clean modulo path shuffeling. > > Testing: > - [ ] GHA (still running) > - [x] jdk/test/security/infra/java/security/cert/CertPathValidator and jdk/test/sun/security/lib/cacerts jtreg tests. Including new ones. All 43 tests pass. Marked as reviewed by phh (Reviewer). linux-x86 test failure appears unrelated. ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/399#pullrequestreview-1755850462 PR Comment: https://git.openjdk.org/jdk8u-dev/pull/399#issuecomment-1832392561 From duke at openjdk.org Thu Nov 30 02:43:16 2023 From: duke at openjdk.org (yaqsun) Date: Thu, 30 Nov 2023 02:43:16 GMT Subject: [jdk8u-dev] RFR: 8198321: javax/swing/JEditorPane/5076514/bug5076514.java fails In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 07:50:03 GMT, yaqsun wrote: > I backport this for parity with 8u271. > Low risk, only test changes. Apply clean except for test path and Problemlist.txt. And test have been locally verified to pass. Hi all, Please review my pr. Thank you. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/386#issuecomment-1833015992 From sgehwolf at openjdk.org Thu Nov 30 16:18:40 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 30 Nov 2023 16:18:40 GMT Subject: [jdk8u-dev] RFR: 8308592: Framework for CA interoperability testing [v2] In-Reply-To: References: <5fKpSvCCHW93aPdYFGFRCBrQn2IQncxal_V8rMvPytU=.591e9987-724b-46bc-abbb-303dd7268d71@github.com> <6JvpUP-0mOCFml7cIGNQhNoBVt_DTBUFGz_HEWGgIt4=.456a8b5b-0943-4561-bf8a-87fecfd0656e@github.com> Message-ID: On Tue, 28 Nov 2023 15:12:40 GMT, Andrew John Hughes wrote: >>> This looks good. The reason why `certignarootca` test fails is the different defaults for `jdk.tls.client.enableStatusRequestExtension` between JDK 11 and JDK 8 in `SSLContextImpl.java`. The former has it set to `true` the latter to `false` as per the TLS 1.3 backport to 8. Without it the `ClientHello` won't have the `status_request` extension, which is required for the test to pass. >>> >>> I suggest to set this to `true` in the affected test only (or set it to true globally in `CAInterop.java`). Either way I'd include this in this backport. >> >> Good catch. Looks like all tests pass with this enabled in `ValidatePathWithURL.java` >> ~~~ >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#actalisauthenticationrootca >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca1 >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca2 >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca3 >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#amazonrootca4 >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass2ca >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#buypassclass3ca >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#certignarootca >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodoeccca >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#comodorsaca >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcaec1 >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#entrustrootcag4 >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsigneccrootcar4 >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#globalsignrootcar6 >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#godaddyrootg2ca >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar1 >> Passed: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#gtsrootcar2 >> Passed: security/infra/java/securi... > >> @gnu-andrew Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See [OpenJDK Developers? Guide](https://openjdk.org/guide/#working-with-pull-requests) for more information. > > Yeah, I'm not going to merge over half a dozen commits manually, bot, when Git is smart enough to match them against the ones you pushed to 8u-dev and just drop them. @gnu-andrew Could you please integrate this? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/390#issuecomment-1834087234 From volker.simonis at gmail.com Thu Nov 30 17:05:00 2023 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 30 Nov 2023 18:05:00 +0100 Subject: CFV: New OpenJDK 8u Reviewer: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes On Mon, Nov 27, 2023 at 4:53?PM Andrew Hughes wrote: > > I hereby nominate Thomas Stuefe [0] for the role of OpenJDK 8u Reviewer. > > Thomas already has reviewership in OpenJDK 9 and later and a wealth of > OpenJDK experience [1] [2] [3] [4]. Thus, his lack of reviewer status > on OpenJDK 8 Updates seems more a simple case of when he started > contributing to OpenJDK - as the same status is conferred on to new > JDK releases, but not retrospectively to older ones - than a lack of > sufficient technical qualification. > > Votes are due by 15h00 UTC on the 11th of December, 2023. > > Only current OpenJDK 8u Reviewers [5] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [6]. > > [0] https://openjdk.java.net/census#stuefe > [1] https://github.com/openjdk/jdk/commits?author=tstuefe > [2] https://github.com/openjdk/jdk17u/commits?author=tstuefe > [3] https://github.com/openjdk/jdk11u/commits?author=tstuefe > [4] https://github.com/openjdk/jdk8u/commits?author=tstuefe > [3] http://openjdk.java.net/census#jdk8u > [4] http://openjdk.java.net/bylaws#three-vote-consensus > > Thanks, > -- > Andrew :) > Pronouns: he / him or they / them > Principal Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > Please contact via e-mail, not proprietary chat networks > Available on Libera Chat & OFTC IRC networks as gnu_andrew