From t.glaser at tarent.de Mon Jul 3 00:15:51 2023 From: t.glaser at tarent.de (Thorsten Glaser) Date: Mon, 3 Jul 2023 02:15:51 +0200 (CEST) Subject: sparc-linux fixes from Debian Message-ID: Hi, you?ll want this, or something that only adds that flag if SUNWcc is actually used: --- a/jdk/make/CompileDemos.gmk +++ b/jdk/make/CompileDemos.gmk @@ -235,10 +235,12 @@ define SetupJVMTIDemo $1_CXXFLAGS := $(CXXFLAGS_JDKLIB) -I$(JDK_TOPDIR)/src/share/demo/jvmti/$1 \ $$(BUILD_DEMO_JVMTI_$1_EXTRA_INC) $3 \ $(CXXFLAGS_DEBUG_SYMBOLS) + ifeq ($(OPENJDK_TARGET_OS), solaris) ifeq ($1-$(OPENJDK_TARGET_CPU_ARCH), waiters-sparc) $1_FILTER := -xregs=no%appl $1_CXXFLAGS := $$(filter-out $$($1_FILTER), $$($1_CXXFLAGS)) endif + endif # Workaround for CFLAGS_JDKLIB containing ',' on solaris. If this is added as 'CFLAGS' to the # eval call below, the comma gets expanded too early. Furthermore, you?ll want something like this; I took this from commit 718f3252f64e4a4da739b1419dc520dd60e3b6dc, not knowing whether it?s correct for Linux. --- a/hotspot/src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp +++ b/hotspot/src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -32,11 +32,21 @@ bool JavaThread::pd_get_top_frame_for_si void* ucontext, bool isInJava) { assert(Thread::current() == this, "caller must be current thread"); + return pd_get_top_frame(fr_addr, ucontext, isInJava, true); +} + +bool JavaThread::pd_get_top_frame_for_profiling(frame* fr_addr, void* ucontext, bool isInJava) { + // get ucontext somehow + return pd_get_top_frame(fr_addr, ucontext, isInJava, false); +} + +bool JavaThread::pd_get_top_frame(frame* fr_addr, + void* ucontext, bool isInJava, bool makeWalkable) { assert(this->is_Java_thread(), "must be JavaThread"); JavaThread* jt = (JavaThread *)this; - if (!isInJava) { + if (!isInJava && makeWalkable) { // make_walkable flushes register windows and grabs last_Java_pc // which can not be done if the ucontext sp matches last_Java_sp // stack walking utilities assume last_Java_pc set if marked flushed --- a/hotspot/src/os_cpu/linux_sparc/vm/thread_linux_sparc.hpp +++ b/hotspot/src/os_cpu/linux_sparc/vm/thread_linux_sparc.hpp @@ -94,6 +94,11 @@ public: bool pd_get_top_frame_for_signal_handler(frame* fr_addr, void* ucontext, bool isInJava); + bool pd_get_top_frame_for_profiling(frame* fr_addr, void* ucontext, bool isInJava); +private: + bool pd_get_top_frame(frame* fr_addr, void* ucontext, bool isInJava); +public: + // These routines are only used on cpu architectures that // have separate register stacks (Itanium). static bool register_stack_overflow() { return false; } bye, //mirabilos -- Infrastrukturexperte ? tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/ Telephon +49 228 54881-393 ? Fax: +49 228 54881-235 HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941 Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg **************************************************** /?\ The UTF-8 Ribbon ??? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ??? HTML eMail! Also, https://www.tarent.de/newsletter ??? header encryption! **************************************************** From andrew at openjdk.org Mon Jul 3 14:10:06 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Mon, 3 Jul 2023 14:10:06 GMT Subject: [jdk8u-dev] RFR: 8200468: Port the native GSS-API bridge to Windows [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 22:19:12 GMT, Alexey Bakhtin wrote: >> Hello, >> I'd like to backport JDK-8200568: port the native GSS-API bridge to Windows to JDK8u >> This is a prerequisite of the JDK-6722928 and JDK-8225687 >> >> The backport is not clean. I have to to make the following changes: >> jdk/make/lib/SecurityLibraries.gmk >> - Patched manually, just removed platform dependency >> >> jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.c >> - Clean merge except for copyright year >> >> jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.h >> - Visual Studio 2010-2012 doesn't provide inttypes.h so provide appropriate definitions the header file >> - Manually updated copyright year >> >> jdk/src/share/classes/sun/security/jgss/GSSManagerImpl.java >> - Manually removed platform OS dependency >> >> jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.c >> - All changes applied manually because of JDK-8238388 already applied >> >> jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.h is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.h >> - All changes applied clean >> >> jdk/test/sun/security/krb5/auto/BasicProc.java >> - Manually added Windows platform dependency code >> >> jdk/test/java/security/testlibrary/Proc.java >> - Manually extended debug output >> >> All related jtreg tests passed successfully on Windows > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year and BasicProc test Thanks. I've added `jdk8u-fix-yes`. It is a little curious that Oracle apparently backported [8225687](https://bugs.openjdk.org/browse/JDK-8225687) to 8u & 11u, but not 6722928, and so there is no CSR in place already. Definitely worth making sure there's plenty of time to allow the CSR to be approved, so thanks for starting on this early in the 8u392 cycle. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/335#issuecomment-1618375269 From duke at openjdk.org Mon Jul 3 14:45:13 2023 From: duke at openjdk.org (duke) Date: Mon, 3 Jul 2023 14:45:13 GMT Subject: [jdk8u-dev] Withdrawn: 8074883: Tab key should move to focused button in a button group In-Reply-To: References: Message-ID: <0xsbymedxSzD4jJj0YzaLlkwFSAgo3YaFuPIDLLuSN4=.b3867a50-dad4-4499-950c-2b8d7041dd4b@github.com> On Fri, 16 Dec 2022 10:30:19 GMT, ktakakuri wrote: > This is a backport of JDK-8074883: Tab key should move to focused button in a button group. > > I would like to backport the patch to OpenJDK8u. > Original patch does not apply cleanly to 8u, because the fix uses a new API published in JDK9. > > * Since RequestFocusController only determines whether or not to set focus, I modified it so that requestFocus/requestFocusInWindow is called by SwingUtilities.invokeLater() and re-set focus and return false. > Without invokeLater(), the focus returns to the first button in case of Cause.ACTIVATION. > > * ToggleButton.getGroupSelection() is defined as a package private method, because it must be called by JCompoennt.focusController. > > * Calling requestFocus()/requestFocusInWindow() will be processed as Cause.UNKNOWN. > ToggleButton.getGroupSelection() returns itself, so no circular call occurs. > > * I moved Component.requestFocusController.acceptRequestFocus because RequestFocusContoroller is not called when Cause.ACTIVATION. > > * Only Swing components replace default RequestFocusController to JComponent.focusController. > The focusController returns true except for Swing, so this change does not affect other components. > > Testing: > build on Windows x86_64 > java/awt, javax/swing and ButtonGroupFocusTest.java on Windows x86_64 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/212 From abakhtin at openjdk.org Mon Jul 3 21:06:06 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Mon, 3 Jul 2023 21:06:06 GMT Subject: [jdk8u-dev] Integrated: 8200468: Port the native GSS-API bridge to Windows In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 06:20:11 GMT, Alexey Bakhtin wrote: > Hello, > I'd like to backport JDK-8200568: port the native GSS-API bridge to Windows to JDK8u > This is a prerequisite of the JDK-6722928 and JDK-8225687 > > The backport is not clean. I have to to make the following changes: > jdk/make/lib/SecurityLibraries.gmk > - Patched manually, just removed platform dependency > > jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.c > - Clean merge except for copyright year > > jdk/src/share/native/sun/security/jgss/wrapper/NativeUtil.h > - Visual Studio 2010-2012 doesn't provide inttypes.h so provide appropriate definitions the header file > - Manually updated copyright year > > jdk/src/share/classes/sun/security/jgss/GSSManagerImpl.java > - Manually removed platform OS dependency > > jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.c > - All changes applied manually because of JDK-8238388 already applied > > jdk/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.h is moved to jdk/src/share/native/sun/security/jgss/wrapper/NativeFunc.h > - All changes applied clean > > jdk/test/sun/security/krb5/auto/BasicProc.java > - Manually added Windows platform dependency code > > jdk/test/java/security/testlibrary/Proc.java > - Manually extended debug output > > All related jtreg tests passed successfully on Windows This pull request has now been integrated. Changeset: 09443845 Author: Alexey Bakhtin URL: https://git.openjdk.org/jdk8u-dev/commit/09443845df2ae520e8a3000f889aecf8d621c52c Stats: 757 lines in 11 files changed: 342 ins; 309 del; 106 mod 8200468: Port the native GSS-API bridge to Windows Reviewed-by: andrew Backport-of: 0b6fbf50d24438117c33fa1a7d3633b792c99983 ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/335 From t.glaser at tarent.de Mon Jul 3 23:27:04 2023 From: t.glaser at tarent.de (Thorsten Glaser) Date: Tue, 4 Jul 2023 01:27:04 +0200 (CEST) Subject: sparc-linux fixes from Debian In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023, Thorsten Glaser wrote: >--- a/hotspot/src/os_cpu/linux_sparc/vm/thread_linux_sparc.hpp >+++ b/hotspot/src/os_cpu/linux_sparc/vm/thread_linux_sparc.hpp >@@ -94,6 +94,11 @@ public: > bool pd_get_top_frame_for_signal_handler(frame* fr_addr, void* ucontext, > bool isInJava); > >+ bool pd_get_top_frame_for_profiling(frame* fr_addr, void* ucontext, bool isInJava); >+private: >+ bool pd_get_top_frame(frame* fr_addr, void* ucontext, bool isInJava); Pasto, this ought to obviously be: ++ bool pd_get_top_frame(frame* fr_addr, void* ucontext, bool isInJava, bool makeWalkable); >+public: >+ > // These routines are only used on cpu architectures that > // have separate register stacks (Itanium). > static bool register_stack_overflow() { return false; } At some point, we?ll have a sparc64 porterbox? bye, //mirabilos -- Infrastrukturexperte ? tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/ Telephon +49 228 54881-393 ? Fax: +49 228 54881-235 HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941 Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg **************************************************** /?\ The UTF-8 Ribbon ??? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ??? HTML eMail! Also, https://www.tarent.de/newsletter ??? header encryption! **************************************************** From gdams at openjdk.org Tue Jul 4 20:31:02 2023 From: gdams at openjdk.org (George Adams) Date: Tue, 4 Jul 2023 20:31:02 GMT Subject: [jdk8u-dev] RFR: 8193017: Import freetype sources into OpenJDK source tree [v4] In-Reply-To: <0GHr4S0HzJRGkbPyQdB79OnrgmqwLE-1XM5oscR8r_Y=.b0329029-5602-4d09-beae-66d273496f29@github.com> References: <0GHr4S0HzJRGkbPyQdB79OnrgmqwLE-1XM5oscR8r_Y=.b0329029-5602-4d09-beae-66d273496f29@github.com> Message-ID: On Wed, 24 May 2023 12:57:28 GMT, George Adams wrote: >> Imports the Freetype source to be consistent with JDK11+ >> >> As discussed in https://github.com/ibmruntimes/openj9-openjdk-jdk8/pull/631 CC @gnu-andrew > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > move libfreetype to correct src directory Please keep this open ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/318#issuecomment-1620710760 From duke at openjdk.org Thu Jul 6 00:21:59 2023 From: duke at openjdk.org (duke) Date: Thu, 6 Jul 2023 00:21:59 GMT Subject: [jdk8u-dev] Withdrawn: 8307837: [8u] Check step in GHA should also print errors In-Reply-To: References: Message-ID: On Wed, 10 May 2023 15:25:28 GMT, Zdenek Zambersky wrote: > Check step currently only prints list of failed tests. It should also print tests, which finished with error (e.g. test ending on timeout). See e.g.: https://github.com/naotoj/jdk8u-dev/actions/runs/4931190096/jobs/8813500528 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/317 From duke at openjdk.org Fri Jul 7 08:50:22 2023 From: duke at openjdk.org (sendaoYan) Date: Fri, 7 Jul 2023 08:50:22 GMT Subject: [jdk8u-dev] RFR: 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException Message-ID: 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException Reviewed-by: Yi Yang ------------- Commit messages: - Backport eccfec498d4062b582282f3b73bba84206a36046 Changes: https://git.openjdk.org/jdk8u-dev/pull/337/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=337&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8219804 Stats: 34 lines in 1 file changed: 24 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/337.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/337/head:pull/337 PR: https://git.openjdk.org/jdk8u-dev/pull/337 From sgehwolf at openjdk.org Fri Jul 7 09:08:02 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 7 Jul 2023 09:08:02 GMT Subject: [jdk8u-dev] RFR: 8309143: [8u] fix archiving inconsistencies in GHA In-Reply-To: References: Message-ID: On Tue, 30 May 2023 22:10:44 GMT, Zdenek Zambersky wrote: > There are few inconsistencies when it comes to packing/unpacking of JDK in GHA. Tar archives are not gzipped despite use `.tar.gz` extension. Zip JDK archives on windows are being extracted by tar. These inconsistencies do not cause failures, but better to fix them. Affects JDK 8 only. OK ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/327#pullrequestreview-1518397852 From sgehwolf at openjdk.org Fri Jul 7 09:21:04 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 7 Jul 2023 09:21:04 GMT Subject: [jdk8u-dev] RFR: 8202952: C2: Unexpected dead nodes after matching In-Reply-To: References: Message-ID: On Fri, 24 Mar 2023 07:57:45 GMT, Dongbo He wrote: > I would like to backport this patch to fix crash during C2 compilation. > > This patch doesn't apply cleanly due to context differences, and > I selected fuzzer tests from Fei Yang because the tests in the original commit cannot be reproduced on JDK8u. > > Performed hotspot jtreg test on linux x86-64 platforms with -Xcomp options, new test fails without product change and passes with it. @sxa Hi! Could you please help with testing this 8u patch on ppc64le when you get a chance? ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/291#issuecomment-1625115885 From sgehwolf at openjdk.org Fri Jul 7 09:30:02 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 7 Jul 2023 09:30:02 GMT Subject: [jdk8u-dev] RFR: 8310026: [8u] make java_lang_String::hash_code consistent across platforms In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 13:02:53 GMT, Zdenek Zambersky wrote: > `java_lang_String::hash_code` produces inconsistent results on different platforms, when `s` is `char*`. This is because on some platforms `char` is signed, while on others unsigned (resulting in `char` to be either zero-extended or sign-extended, when cast to `unsigned int`). This causes 1 tier1 test failure on aarch64. > > Details: > This was discovered by examining one failing test (from tier1) present on aarch64 builds: > `test/serviceability/sa/jmap-hashcode/Test8028623.java` > Test was introduced by [JDK-8028623](https://bugs.openjdk.org/browse/JDK-8028623). However fix done there does not work on aarch64. Code was later fixed (newer jdks) in [hotspot part](https://github.com/openjdk/jdk11u-dev/commit/7af927f9c10923b61f746eb6e566bcda853dd95a) of [JDK-8141132](https://bugs.openjdk.org/browse/JDK-8141132) (JEP 254: Compact Strings). > > Fix: > Fixed by backporting very small portion of JDK-8141132. > > Testing: > tier1 (x86, x86_64, aarch64): OK (tested by GH and in rhel-8 aarch64 VM) @tstuefe @adinn Could you please help with a second review? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/336#issuecomment-1625126951 From adinn at openjdk.org Fri Jul 7 09:44:02 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 7 Jul 2023 09:44:02 GMT Subject: [jdk8u-dev] RFR: 8310026: [8u] make java_lang_String::hash_code consistent across platforms In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 13:02:53 GMT, Zdenek Zambersky wrote: > `java_lang_String::hash_code` produces inconsistent results on different platforms, when `s` is `char*`. This is because on some platforms `char` is signed, while on others unsigned (resulting in `char` to be either zero-extended or sign-extended, when cast to `unsigned int`). This causes 1 tier1 test failure on aarch64. > > Details: > This was discovered by examining one failing test (from tier1) present on aarch64 builds: > `test/serviceability/sa/jmap-hashcode/Test8028623.java` > Test was introduced by [JDK-8028623](https://bugs.openjdk.org/browse/JDK-8028623). However fix done there does not work on aarch64. Code was later fixed (newer jdks) in [hotspot part](https://github.com/openjdk/jdk11u-dev/commit/7af927f9c10923b61f746eb6e566bcda853dd95a) of [JDK-8141132](https://bugs.openjdk.org/browse/JDK-8141132) (JEP 254: Compact Strings). > > Fix: > Fixed by backporting very small portion of JDK-8141132. > > Testing: > tier1 (x86, x86_64, aarch64): OK (tested by GH and in rhel-8 aarch64 VM) Changes look good ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/336#pullrequestreview-1518455690 From shade at openjdk.org Fri Jul 7 09:48:03 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 7 Jul 2023 09:48:03 GMT Subject: [jdk8u-dev] RFR: 8205399: Set node color on pinned HashMap.TreeNode deletion [v2] In-Reply-To: References: Message-ID: > See the issue for details. It reproduces in 8u, which breaks applications that run with `-ea -esa` for extra safety. We have seen at least two in-production bug reports due to this. > > The backport is not clean, because the test should reside in the different folder. > > The verification barfs on discovering the red root, when it also discovers left/right child node is also red. This technically violates one of the basic properties of RB trees: a red node should not have red children. We can always change (sub-)root node color from red to black without violating RB properties, as the path to any descendant node would still have the same number of black nodes. AFAIU, leaving the (sub-)root red and the child red could potentially break something else. This is why I believe this backport is required and safe for 8u. > > Additional testing: > - [x] Linux x86_64, new regression test fails without the patch, passes with it > - [x] Linux x86_64 `jdk_util` > - [x] Linux x86_64 fastdebug `tier1` (some intermittent failures, which look unrelated and present in current master) Aleksey Shipilev 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 JDK-8205399-hashmap-node - Backport 51d0a9e1223f218d10f8761e38cd2dd478607040 ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/325/files - new: https://git.openjdk.org/jdk8u-dev/pull/325/files/78a88f3a..cf1a17d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=325&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=325&range=00-01 Stats: 853 lines in 21 files changed: 389 ins; 317 del; 147 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/325.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/325/head:pull/325 PR: https://git.openjdk.org/jdk8u-dev/pull/325 From shade at openjdk.org Fri Jul 7 13:24:11 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 7 Jul 2023 13:24:11 GMT Subject: [jdk8u-dev] RFR: 8205399: Set node color on pinned HashMap.TreeNode deletion [v2] In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 09:48:03 GMT, Aleksey Shipilev wrote: >> See the issue for details. It reproduces in 8u, which breaks applications that run with `-ea -esa` for extra safety. We have seen at least two in-production bug reports due to this. >> >> The backport is not clean, because the test should reside in the different folder. >> >> The verification barfs on discovering the red root, when it also discovers left/right child node is also red. This technically violates one of the basic properties of RB trees: a red node should not have red children. We can always change (sub-)root node color from red to black without violating RB properties, as the path to any descendant node would still have the same number of black nodes. AFAIU, leaving the (sub-)root red and the child red could potentially break something else. This is why I believe this backport is required and safe for 8u. >> >> Additional testing: >> - [x] Linux x86_64, new regression test fails without the patch, passes with it >> - [x] Linux x86_64 `jdk_util` >> - [x] Linux x86_64 fastdebug `tier1` (some intermittent failures, which look unrelated and present in current master) > > Aleksey Shipilev 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 JDK-8205399-hashmap-node > - Backport 51d0a9e1223f218d10f8761e38cd2dd478607040 Testing is clean, push approval is here. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/325#issuecomment-1625407760 From shade at openjdk.org Fri Jul 7 13:24:13 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 7 Jul 2023 13:24:13 GMT Subject: [jdk8u-dev] Integrated: 8205399: Set node color on pinned HashMap.TreeNode deletion In-Reply-To: References: Message-ID: On Tue, 30 May 2023 08:42:32 GMT, Aleksey Shipilev wrote: > See the issue for details. It reproduces in 8u, which breaks applications that run with `-ea -esa` for extra safety. We have seen at least two in-production bug reports due to this. > > The backport is not clean, because the test should reside in the different folder. > > The verification barfs on discovering the red root, when it also discovers left/right child node is also red. This technically violates one of the basic properties of RB trees: a red node should not have red children. We can always change (sub-)root node color from red to black without violating RB properties, as the path to any descendant node would still have the same number of black nodes. AFAIU, leaving the (sub-)root red and the child red could potentially break something else. This is why I believe this backport is required and safe for 8u. > > Additional testing: > - [x] Linux x86_64, new regression test fails without the patch, passes with it > - [x] Linux x86_64 `jdk_util` > - [x] Linux x86_64 fastdebug `tier1` (some intermittent failures, which look unrelated and present in current master) This pull request has now been integrated. Changeset: a2a68737 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk8u-dev/commit/a2a68737d927e7afa6e5c2d2642d8cb42f9d6be9 Stats: 176 lines in 2 files changed: 175 ins; 0 del; 1 mod 8205399: Set node color on pinned HashMap.TreeNode deletion Backport-of: 51d0a9e1223f218d10f8761e38cd2dd478607040 ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/325 From stuefe at openjdk.org Mon Jul 10 09:09:04 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 10 Jul 2023 09:09:04 GMT Subject: [jdk8u-dev] RFR: 8310026: [8u] make java_lang_String::hash_code consistent across platforms In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 13:02:53 GMT, Zdenek Zambersky wrote: > `java_lang_String::hash_code` produces inconsistent results on different platforms, when `s` is `char*`. This is because on some platforms `char` is signed, while on others unsigned (resulting in `char` to be either zero-extended or sign-extended, when cast to `unsigned int`). This causes 1 tier1 test failure on aarch64. > > Details: > This was discovered by examining one failing test (from tier1) present on aarch64 builds: > `test/serviceability/sa/jmap-hashcode/Test8028623.java` > Test was introduced by [JDK-8028623](https://bugs.openjdk.org/browse/JDK-8028623). However fix done there does not work on aarch64. Code was later fixed (newer jdks) in [hotspot part](https://github.com/openjdk/jdk11u-dev/commit/7af927f9c10923b61f746eb6e566bcda853dd95a) of [JDK-8141132](https://bugs.openjdk.org/browse/JDK-8141132) (JEP 254: Compact Strings). > > Fix: > Fixed by backporting very small portion of JDK-8141132. > > Testing: > tier1 (x86, x86_64, aarch64): OK (tested by GH and in rhel-8 aarch64 VM) hotspot/agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java line 66: > 64: // Emulate the unsigned int in java_lang_String::hash_code > 65: while (len-- > 0) { > 66: h = 31*h + (0xFFL & buf[s]); `Byte.toUnsignedInt()` would be clearer. hotspot/src/share/vm/classfile/javaClasses.hpp line 197: > 195: return h; > 196: } > 197: I don't understand this. According to the comment, both of these functions are to mimic `String.hashCode`. But only the `jchar` variant does, or? Assuming the `jchar` variant gets fed UCS2 and the `jbyte` variant UTF8. Those encodings could be different for the same java string if we have surrogate chars. For example, let string be a single unicode "?" character, aka `U+3041`, which would be encoded as `0x3041` (len 1) with UCS2, `0xE38181` as UTF8. Hash for the first would use the jchar* variant, len=1, and return 0x3041. Hash for the UTF8 variant would get, I assume, a byte array of `0xE3 0x81 0x81` and a len of 3, and return 0x36443 (`(((0xE3 * 0x1F) + 0x81) * 0x1F) + 0x81`). I must be missing something basic here. ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/336#discussion_r1257953806 PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/336#discussion_r1257943896 From adinn at openjdk.org Mon Jul 10 10:06:11 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 10 Jul 2023 10:06:11 GMT Subject: [jdk8u-dev] RFR: 8310026: [8u] make java_lang_String::hash_code consistent across platforms In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 09:06:06 GMT, Thomas Stuefe wrote: >> `java_lang_String::hash_code` produces inconsistent results on different platforms, when `s` is `char*`. This is because on some platforms `char` is signed, while on others unsigned (resulting in `char` to be either zero-extended or sign-extended, when cast to `unsigned int`). This causes 1 tier1 test failure on aarch64. >> >> Details: >> This was discovered by examining one failing test (from tier1) present on aarch64 builds: >> `test/serviceability/sa/jmap-hashcode/Test8028623.java` >> Test was introduced by [JDK-8028623](https://bugs.openjdk.org/browse/JDK-8028623). However fix done there does not work on aarch64. Code was later fixed (newer jdks) in [hotspot part](https://github.com/openjdk/jdk11u-dev/commit/7af927f9c10923b61f746eb6e566bcda853dd95a) of [JDK-8141132](https://bugs.openjdk.org/browse/JDK-8141132) (JEP 254: Compact Strings). >> >> Fix: >> Fixed by backporting very small portion of JDK-8141132. >> >> Testing: >> tier1 (x86, x86_64, aarch64): OK (tested by GH and in rhel-8 aarch64 VM) > > hotspot/agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java line 66: > >> 64: // Emulate the unsigned int in java_lang_String::hash_code >> 65: while (len-- > 0) { >> 66: h = 31*h + (0xFFL & buf[s]); > > `Byte.toUnsignedInt()` would be clearer. yes, but that would also be different to upstream jdk11u ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/336#discussion_r1258017598 From adinn at openjdk.org Mon Jul 10 10:37:11 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 10 Jul 2023 10:37:11 GMT Subject: [jdk8u-dev] RFR: 8310026: [8u] make java_lang_String::hash_code consistent across platforms In-Reply-To: References: Message-ID: <7iz1Ez2abHx_oRAxlX5RYvUP9gF9KzRo8sQHn6V0hhc=.388d970a-b996-48ba-9fbd-7d2b2b1a7fb6@github.com> On Mon, 10 Jul 2023 08:59:35 GMT, Thomas Stuefe wrote: >> `java_lang_String::hash_code` produces inconsistent results on different platforms, when `s` is `char*`. This is because on some platforms `char` is signed, while on others unsigned (resulting in `char` to be either zero-extended or sign-extended, when cast to `unsigned int`). This causes 1 tier1 test failure on aarch64. >> >> Details: >> This was discovered by examining one failing test (from tier1) present on aarch64 builds: >> `test/serviceability/sa/jmap-hashcode/Test8028623.java` >> Test was introduced by [JDK-8028623](https://bugs.openjdk.org/browse/JDK-8028623). However fix done there does not work on aarch64. Code was later fixed (newer jdks) in [hotspot part](https://github.com/openjdk/jdk11u-dev/commit/7af927f9c10923b61f746eb6e566bcda853dd95a) of [JDK-8141132](https://bugs.openjdk.org/browse/JDK-8141132) (JEP 254: Compact Strings). >> >> Fix: >> Fixed by backporting very small portion of JDK-8141132. >> >> Testing: >> tier1 (x86, x86_64, aarch64): OK (tested by GH and in rhel-8 aarch64 VM) > > hotspot/src/share/vm/classfile/javaClasses.hpp line 197: > >> 195: return h; >> 196: } >> 197: > > I don't understand this. According to the comment, both of these functions are to mimic `String.hashCode`. But only the `jchar` variant does, or? > > Assuming the `jchar` variant gets fed UCS2 and the `jbyte` variant UTF8. Those encodings could be different for the same java string if we have surrogate chars. > > For example, let string be a single unicode "?" character, aka `U+3041`, which would be encoded as `0x3041` (len 1) with UCS2, `0xE38181` as UTF8. > > Hash for the first would use the jchar* variant, len=1, and return 0x3041. Hash for the UTF8 variant would get, I assume, a byte array of `0xE3 0x81 0x81` and a len of 3, and return 0x36443 (`(((0xE3 * 0x1F) + 0x81) * 0x1F) + 0x81`). > > I must be missing something basic here. I am not really sure what you are suggesting is a problem here, Thomas. I /think/ the only problem here is that the comment is wrong. You are right that only the `jchar` variant matches `String.hashCode` but I believe only that variant /needs/ to match `String.hashCode`. The `jchar` variant is used by all code operating on Java Strings proper. The `jbyte` variant is only used by the Symbol table and the agent. The problem this is fixing is to do with the disparity between `SymbolTable::hash_symbol` and the agent `HashTable`. That was supposed to have been fixed by JDK-8028623. However, the fix is a hostage to fortune because `SymbolTable::hash_symbol` accepts and passes on to `java_lang_String::hash_code` a value of C type `char*` (which may be signed or unsigned depending on the OS) while the agent `HashTable` code operates on a Java `byte[]` (which is always signed). This means that the template code may or may not sign extend the values melded into the hash causing the `SymbolTable` and agent HashTable` to compute different results. This current fix decouples the definitions of `hash_code(const jchar* s, int len)` and `hash_code(const jbyte* s, int len)` in order to allow the latter to match the redefined behaviour of the agent `HashTable` i.e. it sums individual unsigned 8 byte values in the input rather than unsigned 16 byte values. As far as I can tell it doesn't actually matter what interpretation is placed on the data sitting in field `String.value`, whether it is considered as 8 byte or 16 byte values. What matters here is that they are hashed consistently by whatever code processes the contents. Am I missing something? ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/336#discussion_r1258051917 From zzambers at openjdk.org Mon Jul 10 10:40:10 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 10 Jul 2023 10:40:10 GMT Subject: [jdk8u-dev] RFR: 8310026: [8u] make java_lang_String::hash_code consistent across platforms In-Reply-To: <7iz1Ez2abHx_oRAxlX5RYvUP9gF9KzRo8sQHn6V0hhc=.388d970a-b996-48ba-9fbd-7d2b2b1a7fb6@github.com> References: <7iz1Ez2abHx_oRAxlX5RYvUP9gF9KzRo8sQHn6V0hhc=.388d970a-b996-48ba-9fbd-7d2b2b1a7fb6@github.com> Message-ID: On Mon, 10 Jul 2023 10:32:38 GMT, Andrew Dinn wrote: >> hotspot/src/share/vm/classfile/javaClasses.hpp line 197: >> >>> 195: return h; >>> 196: } >>> 197: >> >> I don't understand this. According to the comment, both of these functions are to mimic `String.hashCode`. But only the `jchar` variant does, or? >> >> Assuming the `jchar` variant gets fed UCS2 and the `jbyte` variant UTF8. Those encodings could be different for the same java string if we have surrogate chars. >> >> For example, let string be a single unicode "?" character, aka `U+3041`, which would be encoded as `0x3041` (len 1) with UCS2, `0xE38181` as UTF8. >> >> Hash for the first would use the jchar* variant, len=1, and return 0x3041. Hash for the UTF8 variant would get, I assume, a byte array of `0xE3 0x81 0x81` and a len of 3, and return 0x36443 (`(((0xE3 * 0x1F) + 0x81) * 0x1F) + 0x81`). >> >> I must be missing something basic here. > > I am not really sure what you are suggesting is a problem here, Thomas. I /think/ the only problem here is that the comment is wrong. You are right that only the `jchar` variant matches `String.hashCode` but I believe only that variant /needs/ to match `String.hashCode`. The `jchar` variant is used by all code operating on Java Strings proper. The `jbyte` variant is only used by the Symbol table and the agent. > > The problem this is fixing is to do with the disparity between `SymbolTable::hash_symbol` and the agent `HashTable`. That was supposed to have been fixed by JDK-8028623. However, the fix is a hostage to fortune because `SymbolTable::hash_symbol` accepts and passes on to `java_lang_String::hash_code` a value of C type `char*` (which may be signed or unsigned depending on the OS) while the agent `HashTable` code operates on a Java `byte[]` (which is always signed). This means that the template code may or may not sign extend the values melded into the hash causing the `SymbolTable` and agent HashTable` to compute different results. > > This current fix decouples the definitions of `hash_code(const jchar* s, int len)` and `hash_code(const jbyte* s, int len)` in order to allow the latter to match the redefined behaviour of the agent `HashTable` i.e. it sums individual unsigned 8 byte values in the input rather than unsigned 16 byte values. > > As far as I can tell it doesn't actually matter what interpretation is placed on the data sitting in field `String.value`, whether it is considered as 8 byte or 16 byte values. What matters here is that they are hashed consistently by whatever code processes the contents. Am I missing something? Few uses of `java_lang_String::hash_code` in JDK8 are following: `jbyte *` varaiant is only used to hash symbols (I don't think this affects code in java): https://github.com/openjdk/jdk8u-dev/blob/a2a68737d927e7afa6e5c2d2642d8cb42f9d6be9/hotspot/src/share/vm/classfile/symbolTable.cpp#L228 other uses dealing with Strings use `jchar *` variant: https://github.com/openjdk/jdk8u-dev/blob/a2a68737d927e7afa6e5c2d2642d8cb42f9d6be9/hotspot/src/share/vm/classfile/javaClasses.cpp#L344 https://github.com/openjdk/jdk8u-dev/blob/a2a68737d927e7afa6e5c2d2642d8cb42f9d6be9/hotspot/src/share/vm/classfile/symbolTable.cpp#L654 https://github.com/openjdk/jdk8u-dev/blob/a2a68737d927e7afa6e5c2d2642d8cb42f9d6be9/hotspot/src/share/vm/gc_implementation/g1/g1StringDedupTable.cpp#L344 In newer JDKs, `jbyte *` variant is also used for compact strings (as zero extended latin1 should be equal to UCS2/UTF-16), e.g.: https://github.com/openjdk/jdk/blob/06a1a15d014f5ca48f62f5f0c8e8682086c4ae0b/src/hotspot/share/classfile/javaClasses.cpp#L522 (but JDK8 does not have compact strings...) ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/336#discussion_r1258056867 From zzambers at openjdk.org Mon Jul 10 11:28:12 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 10 Jul 2023 11:28:12 GMT Subject: [jdk8u-dev] RFR: 8309143: [8u] fix archiving inconsistencies in GHA In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 09:05:28 GMT, Severin Gehwolf wrote: >> There are few inconsistencies when it comes to packing/unpacking of JDK in GHA. Tar archives are not gzipped despite use `.tar.gz` extension. Zip JDK archives on windows are being extracted by tar. These inconsistencies do not cause failures, but better to fix them. Affects JDK 8 only. > > OK @jerboaa thanks ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/327#issuecomment-1628766691 From zzambers at openjdk.org Mon Jul 10 11:28:14 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 10 Jul 2023 11:28:14 GMT Subject: [jdk8u-dev] Integrated: 8309143: [8u] fix archiving inconsistencies in GHA In-Reply-To: References: Message-ID: On Tue, 30 May 2023 22:10:44 GMT, Zdenek Zambersky wrote: > There are few inconsistencies when it comes to packing/unpacking of JDK in GHA. Tar archives are not gzipped despite use `.tar.gz` extension. Zip JDK archives on windows are being extracted by tar. These inconsistencies do not cause failures, but better to fix them. Affects JDK 8 only. This pull request has now been integrated. Changeset: 108003eb Author: Zdenek Zambersky URL: https://git.openjdk.org/jdk8u-dev/commit/108003eb378c7b830119bb7ae41d3a40fcd0809e Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod 8309143: [8u] fix archiving inconsistencies in GHA Reviewed-by: phh, sgehwolf ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/327 From stuefe at openjdk.org Mon Jul 10 11:38:10 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 10 Jul 2023 11:38:10 GMT Subject: [jdk8u-dev] RFR: 8310026: [8u] make java_lang_String::hash_code consistent across platforms In-Reply-To: References: <7iz1Ez2abHx_oRAxlX5RYvUP9gF9KzRo8sQHn6V0hhc=.388d970a-b996-48ba-9fbd-7d2b2b1a7fb6@github.com> Message-ID: <5sj0yoKPhcGZ1ygat8gtyLfiO7L4gbYoo44Vh78MyXw=.86c57605-7502-40ee-842e-a1bdb1aeeb1a@github.com> On Mon, 10 Jul 2023 10:37:19 GMT, Zdenek Zambersky wrote: >> I am not really sure what you are suggesting is a problem here, Thomas. I /think/ the only problem here is that the comment is wrong. You are right that only the `jchar` variant matches `String.hashCode` but I believe only that variant /needs/ to match `String.hashCode`. The `jchar` variant is used by all code operating on Java Strings proper. The `jbyte` variant is only used by the Symbol table and the agent. >> >> The problem this is fixing is to do with the disparity between `SymbolTable::hash_symbol` and the agent `HashTable`. That was supposed to have been fixed by JDK-8028623. However, the fix is a hostage to fortune because `SymbolTable::hash_symbol` accepts and passes on to `java_lang_String::hash_code` a value of C type `char*` (which may be signed or unsigned depending on the OS) while the agent `HashTable` code operates on a Java `byte[]` (which is always signed). This means that the template code may or may not sign extend the values melded into the hash causing the `SymbolTable` and agent HashTable` to compute different results. >> >> This current fix decouples the definitions of `hash_code(const jchar* s, int len)` and `hash_code(const jbyte* s, int len)` in order to allow the latter to match the redefined behaviour of the agent `HashTable` i.e. it sums individual unsigned 8 byte values in the input rather than unsigned 16 byte values. >> >> As far as I can tell it doesn't actually matter what interpretation is placed on the data sitting in field `String.value`, whether it is considered as 8 byte or 16 byte values. What matters here is that they are hashed consistently by whatever code processes the contents. Am I missing something? > > Few uses of `java_lang_String::hash_code` in JDK8 are following: > > `jbyte *` varaiant is only used to hash symbols (I don't think this affects code in java): > https://github.com/openjdk/jdk8u-dev/blob/a2a68737d927e7afa6e5c2d2642d8cb42f9d6be9/hotspot/src/share/vm/classfile/symbolTable.cpp#L228 > > other uses dealing with Strings use `jchar *` variant: > https://github.com/openjdk/jdk8u-dev/blob/a2a68737d927e7afa6e5c2d2642d8cb42f9d6be9/hotspot/src/share/vm/classfile/javaClasses.cpp#L344 > https://github.com/openjdk/jdk8u-dev/blob/a2a68737d927e7afa6e5c2d2642d8cb42f9d6be9/hotspot/src/share/vm/classfile/symbolTable.cpp#L654 > https://github.com/openjdk/jdk8u-dev/blob/a2a68737d927e7afa6e5c2d2642d8cb42f9d6be9/hotspot/src/share/vm/gc_implementation/g1/g1StringDedupTable.cpp#L344 > > > In newer JDKs, `jbyte *` variant is also used for compact strings (as zero extended latin1 should be equal to UCS2/UTF-16), e.g.: > https://github.com/openjdk/jdk/blob/06a1a15d014f5ca48f62f5f0c8e8682086c4ae0b/src/hotspot/share/classfile/javaClasses.cpp#L522 > (but JDK8 does not have compact strings...) > I am not really sure what you are suggesting is a problem here, Thomas. I /think/ the only problem here is that the comment is wrong. You are right that only the `jchar` variant matches `String.hashCode` but I believe only that variant /needs/ to match `String.hashCode`. The `jchar` variant is used by all code operating on Java Strings proper. The `jbyte` variant is only used by the Symbol table and the agent. > > The problem this is fixing is to do with the disparity between `SymbolTable::hash_symbol` and the agent `HashTable`. That was supposed to have been fixed by JDK-8028623. However, the fix is a hostage to fortune because `SymbolTable::hash_symbol` accepts and passes on to `java_lang_String::hash_code` a value of C type `char*` (which may be signed or unsigned depending on the OS) while the agent `HashTable` code operates on a Java `byte[]` (which is always signed). This means that the template code may or may not sign extend the values melded into the hash causing the `SymbolTable` and agent HashTable` to compute different results. > > This current fix decouples the definitions of `hash_code(const jchar* s, int len)` and `hash_code(const jbyte* s, int len)` in order to allow the latter to match the redefined behaviour of the agent `HashTable` i.e. it sums individual unsigned 8 byte values in the input rather than unsigned 16 byte values. > > As far as I can tell it doesn't actually matter what interpretation is placed on the data sitting in field `String.value`, whether it is considered as 8 byte or 16 byte values. What matters here is that they are hashed consistently by whatever code processes the contents. Am I missing something? Thank you, Andrew, for disentangling this. I get it now. The byte variant only has to match its java counterpart in the agent. ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/336#discussion_r1258116487 From stuefe at openjdk.org Mon Jul 10 11:38:09 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 10 Jul 2023 11:38:09 GMT Subject: [jdk8u-dev] RFR: 8310026: [8u] make java_lang_String::hash_code consistent across platforms In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 13:02:53 GMT, Zdenek Zambersky wrote: > `java_lang_String::hash_code` produces inconsistent results on different platforms, when `s` is `char*`. This is because on some platforms `char` is signed, while on others unsigned (resulting in `char` to be either zero-extended or sign-extended, when cast to `unsigned int`). This causes 1 tier1 test failure on aarch64. > > Details: > This was discovered by examining one failing test (from tier1) present on aarch64 builds: > `test/serviceability/sa/jmap-hashcode/Test8028623.java` > Test was introduced by [JDK-8028623](https://bugs.openjdk.org/browse/JDK-8028623). However fix done there does not work on aarch64. Code was later fixed (newer jdks) in [hotspot part](https://github.com/openjdk/jdk11u-dev/commit/7af927f9c10923b61f746eb6e566bcda853dd95a) of [JDK-8141132](https://bugs.openjdk.org/browse/JDK-8141132) (JEP 254: Compact Strings). > > Fix: > Fixed by backporting very small portion of JDK-8141132. > > Testing: > tier1 (x86, x86_64, aarch64): OK (tested by GH and in rhel-8 aarch64 VM) All good, after @adinn explained it to me. ------------- Marked as reviewed by stuefe (Committer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/336#pullrequestreview-1521876289 From zzambers at openjdk.org Mon Jul 10 11:47:10 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 10 Jul 2023 11:47:10 GMT Subject: [jdk8u-dev] RFR: 8310026: [8u] make java_lang_String::hash_code consistent across platforms In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 09:27:37 GMT, Severin Gehwolf wrote: >> `java_lang_String::hash_code` produces inconsistent results on different platforms, when `s` is `char*`. This is because on some platforms `char` is signed, while on others unsigned (resulting in `char` to be either zero-extended or sign-extended, when cast to `unsigned int`). This causes 1 tier1 test failure on aarch64. >> >> Details: >> This was discovered by examining one failing test (from tier1) present on aarch64 builds: >> `test/serviceability/sa/jmap-hashcode/Test8028623.java` >> Test was introduced by [JDK-8028623](https://bugs.openjdk.org/browse/JDK-8028623). However fix done there does not work on aarch64. Code was later fixed (newer jdks) in [hotspot part](https://github.com/openjdk/jdk11u-dev/commit/7af927f9c10923b61f746eb6e566bcda853dd95a) of [JDK-8141132](https://bugs.openjdk.org/browse/JDK-8141132) (JEP 254: Compact Strings). >> >> Fix: >> Fixed by backporting very small portion of JDK-8141132. >> >> Testing: >> tier1 (x86, x86_64, aarch64): OK (tested by GH and in rhel-8 aarch64 VM) > > @tstuefe @adinn Could you please help with a second review? Thanks! @jerboaa @adinn @tstuefe @phohensee thank you ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/336#issuecomment-1628796793 From zzambers at openjdk.org Mon Jul 10 11:47:12 2023 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 10 Jul 2023 11:47:12 GMT Subject: [jdk8u-dev] Integrated: 8310026: [8u] make java_lang_String::hash_code consistent across platforms In-Reply-To: References: Message-ID: <-MboaxDxvGDF5-pj3fbTdKrGne09o1vFoTW0Exa6PTA=.a55d407a-2e62-46c3-9f5d-e4be920510ee@github.com> On Wed, 14 Jun 2023 13:02:53 GMT, Zdenek Zambersky wrote: > `java_lang_String::hash_code` produces inconsistent results on different platforms, when `s` is `char*`. This is because on some platforms `char` is signed, while on others unsigned (resulting in `char` to be either zero-extended or sign-extended, when cast to `unsigned int`). This causes 1 tier1 test failure on aarch64. > > Details: > This was discovered by examining one failing test (from tier1) present on aarch64 builds: > `test/serviceability/sa/jmap-hashcode/Test8028623.java` > Test was introduced by [JDK-8028623](https://bugs.openjdk.org/browse/JDK-8028623). However fix done there does not work on aarch64. Code was later fixed (newer jdks) in [hotspot part](https://github.com/openjdk/jdk11u-dev/commit/7af927f9c10923b61f746eb6e566bcda853dd95a) of [JDK-8141132](https://bugs.openjdk.org/browse/JDK-8141132) (JEP 254: Compact Strings). > > Fix: > Fixed by backporting very small portion of JDK-8141132. > > Testing: > tier1 (x86, x86_64, aarch64): OK (tested by GH and in rhel-8 aarch64 VM) This pull request has now been integrated. Changeset: 15077ad1 Author: Zdenek Zambersky URL: https://git.openjdk.org/jdk8u-dev/commit/15077ad189dc24d7776998f63c2245c3c61ab2bb Stats: 13 lines in 3 files changed: 10 ins; 0 del; 3 mod 8310026: [8u] make java_lang_String::hash_code consistent across platforms Reviewed-by: phh, adinn, stuefe ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/336 From andrew at openjdk.org Wed Jul 12 01:30:14 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 12 Jul 2023 01:30:14 GMT Subject: [jdk8u-dev] RFR: Merge jdk8u:master Message-ID: Bring in jdk8u382-b04 ------------- Commit messages: - Merge jdk8u:master - 8241311: Move some charset mapping tests from closed to open - 8186801: Add regression test to test mapping based charsets (generated at build time) The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk8u-dev/pull/338/files Stats: 887690 lines in 180 files changed: 887689 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/338.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/338/head:pull/338 PR: https://git.openjdk.org/jdk8u-dev/pull/338 From andrew at openjdk.org Wed Jul 12 11:08:18 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 12 Jul 2023 11:08:18 GMT Subject: [jdk8u-dev] Integrated: Merge jdk8u:master In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 01:24:45 GMT, Andrew John Hughes wrote: > Bring in jdk8u382-b04 This pull request has now been integrated. Changeset: e575cb38 Author: Andrew John Hughes URL: https://git.openjdk.org/jdk8u-dev/commit/e575cb38f0ef175d953da19e4413db1926a7ca8f Stats: 887690 lines in 180 files changed: 887689 ins; 0 del; 1 mod Merge ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/338 From andrew at openjdk.org Wed Jul 12 11:26:13 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 12 Jul 2023 11:26:13 GMT Subject: [jdk8u] RFR: 8301119: Support for GB18030-2022 [v3] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 12:58:19 GMT, Andrew John Hughes wrote: >> This is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. >> >> With the preceding test changes in place (#43 and #44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the `SPI.java` generator tool moves into `ExtendedCharsets.java` in the class library, as the file is not auto-generated in 8u. The change to `StandardCharsets.java.template` lands in `AbstractCharsetProvider.java`. >> >> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allows `IS_2000` to be package-private to `sun.nio.cs`, whereas we need to make it public in `sun.nio.cs.ext` so it can be accessed from `sun.nio.cs`. >> >> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to awk. >> >> The only adjustment to `GB18030.java`, other than copyright headers, is to replace the use of `jdk.internal.misc.VM.initLevel` with that of `sun.misc.VM.isBooted`. 8u does not provide as fine-grained access to the initialisation status as 11u, and so may force the use of the 2022 standard until a later stage in the bootup (`BOOTED` is `initLevel() = 4` in 11u). >> >> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u.... > > 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 5c4e744dabcf7785c35168db5d0458ccebfd41e6 Replaced by https://github.com/openjdk/jdk8u-dev/pull/339 ------------- PR Comment: https://git.openjdk.org/jdk8u/pull/45#issuecomment-1632352921 From andrew at openjdk.org Wed Jul 12 11:32:26 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 12 Jul 2023 11:32:26 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 Message-ID: This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are frequent issues in backports, so I used this as an opportunity to introduce a full set of equivalents into the test library. It should now be possible to just rewrite `Set.of` to `Utils.setOf` and `List.of` to `Utils.listOf`. The returned collections are expected to be unmodifiable, not contain `null` and (in the case of sets) not contain duplicates. Simple replacement with a newly constructed `ArrayList` or `HashSet` would not ensure this. While this test does not rely on this, others may, so it seemed worth providing a closer replacement for use in future backports. All `sun.nio.cs` and `java.nio.charset` tests pass with this patch applied. ------------- Commit messages: - Fix for JDK-8310947 and some suggested cleanup - Backport 5c4e744dabcf7785c35168db5d0458ccebfd41e6 Changes: https://git.openjdk.org/jdk8u-dev/pull/339/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=339&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301119 Stats: 1035 lines in 9 files changed: 926 ins; 12 del; 97 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/339.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/339/head:pull/339 PR: https://git.openjdk.org/jdk8u-dev/pull/339 From stuefe at openjdk.org Wed Jul 12 16:58:14 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 12 Jul 2023 16:58:14 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 11:21:53 GMT, Andrew John Hughes wrote: > This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. > > With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. > > In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. > > To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. > > The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. > > With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are frequent issues in backp... Hi Andrew, I looked through the patch, and compared it with 11u, too, looks fine. Minor remarks inline, feel free to ignore the style nits. jdk/src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java line 1189: > 1187: new GetPropertyAction("sun.nio.cs.map")); > 1188: boolean isGB18030_2000 = "2000".equals(AccessController.doPrivileged( > 1189: new GetPropertyAction("jdk.charset.GB18030"))); More user friendly would be to test for "2000" or "2023" and to throw IAE for other values; but since later JDK versions don't do this either this is probably fine. jdk/src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java line 1217: > 1215: "gb18030-2000" > 1216: }); > 1217: } Can you please add this replacement to the comment above listing the changes done in init? jdk/src/share/classes/sun/nio/cs/ext/GB18030.java line 12640: > 12638: int hiByte = 0, loByte = 0; > 12639: currentState = GB18030_DOUBLE_BYTE; > 12640: boolean isGB18030_2000 = ExtendedCharsets.isGB18030_2000(); Here, and in other places: naming these vars IS_2000 would have simplified reviewing (mechanical comparison with 11) jdk/test/lib/testlibrary/jdk/testlibrary/Utils.java line 990: > 988: if (e4 == null) { throw new NullPointerException("e4"); } > 989: if (e5 == null) { throw new NullPointerException("e5"); } > 990: if (e6 == null) { throw new NullPointerException("e6"); } Here, and in other places: Objects.requireNonNull may be shorter. jdk/test/lib/testlibrary/jdk/testlibrary/Utils.java line 1004: > 1002: if (!added) { throw new IllegalArgumentException("duplicate 5"); } > 1003: added = s.add(e6); > 1004: if (!added) { throw new IllegalArgumentException("duplicate 6"); } Could be shortened, but thats up to you (if one does not care for the string, a simple `if (!(s.add(e1) && s.add(e2) && ...` would be sufficient. ------------- Marked as reviewed by stuefe (Committer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/339#pullrequestreview-1526759863 PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/339#discussion_r1261429640 PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/339#discussion_r1261428343 PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/339#discussion_r1261437418 PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/339#discussion_r1261450643 PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/339#discussion_r1261455655 From andrew at openjdk.org Thu Jul 13 00:49:10 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 13 Jul 2023 00:49:10 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 16:25:03 GMT, Thomas Stuefe wrote: >> This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. >> >> With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. >> >> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. >> >> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. >> >> The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. >> >> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are fr... > > jdk/src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java line 1189: > >> 1187: new GetPropertyAction("sun.nio.cs.map")); >> 1188: boolean isGB18030_2000 = "2000".equals(AccessController.doPrivileged( >> 1189: new GetPropertyAction("jdk.charset.GB18030"))); > > More user friendly would be to test for "2000" or "2023" and to throw IAE for other values; but since later JDK versions don't do this either this is probably fine. I agree, but yes this is something that should go into trunk and be backported down. I'm already a little uneasy about fixing 8310947 in 8u first. > jdk/src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java line 1217: > >> 1215: "gb18030-2000" >> 1216: }); >> 1217: } > > Can you please add this replacement to the comment above listing the changes done in init? Good catch. I've updated the comment to document `jdk.charset.GB18030`. ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/339#discussion_r1261854183 PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/339#discussion_r1261853432 From andrew at openjdk.org Thu Jul 13 00:57:09 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 13 Jul 2023 00:57:09 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 In-Reply-To: References: Message-ID: <1NowTA0g7YTge7S1P2J7FljX-_tIRqobhC4TXeLVw6s=.8a5c489d-6752-4271-aadf-37292bc5c567@github.com> On Wed, 12 Jul 2023 16:32:29 GMT, Thomas Stuefe wrote: >> This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. >> >> With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. >> >> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. >> >> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. >> >> The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. >> >> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are fr... > > jdk/src/share/classes/sun/nio/cs/ext/GB18030.java line 12640: > >> 12638: int hiByte = 0, loByte = 0; >> 12639: currentState = GB18030_DOUBLE_BYTE; >> 12640: boolean isGB18030_2000 = ExtendedCharsets.isGB18030_2000(); > > Here, and in other places: naming these vars IS_2000 would have simplified reviewing (mechanical comparison with 11) I think some renaming is intentional as it's a static boolean constant in 11u, but a method and a private instance variable in 8u. I do think the `isGB18032_2000` is odd (presumably to avoid a name conflict with the method), so I will alter that to just `is_2000`. ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/339#discussion_r1261858308 From andrew at openjdk.org Thu Jul 13 01:11:07 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 13 Jul 2023 01:11:07 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 In-Reply-To: <1NowTA0g7YTge7S1P2J7FljX-_tIRqobhC4TXeLVw6s=.8a5c489d-6752-4271-aadf-37292bc5c567@github.com> References: <1NowTA0g7YTge7S1P2J7FljX-_tIRqobhC4TXeLVw6s=.8a5c489d-6752-4271-aadf-37292bc5c567@github.com> Message-ID: On Thu, 13 Jul 2023 00:54:45 GMT, Andrew John Hughes wrote: >> jdk/src/share/classes/sun/nio/cs/ext/GB18030.java line 12640: >> >>> 12638: int hiByte = 0, loByte = 0; >>> 12639: currentState = GB18030_DOUBLE_BYTE; >>> 12640: boolean isGB18030_2000 = ExtendedCharsets.isGB18030_2000(); >> >> Here, and in other places: naming these vars IS_2000 would have simplified reviewing (mechanical comparison with 11) > > I think some renaming is intentional as it's a static boolean constant in 11u, but a method and a private instance variable in 8u. I do think the `isGB18032_2000` is odd (presumably to avoid a name conflict with the method), so I will alter that to just `is_2000`. Went with making that `isGB18030_2000` in the end and the method `IS_2000`. The latter certainly shortens some of the `GB18030.java` changes. ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/339#discussion_r1261864567 From andrew at openjdk.org Thu Jul 13 01:11:09 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 13 Jul 2023 01:11:09 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 In-Reply-To: References: Message-ID: <6EFg1dfGx90-fhurIFoRu8WfcQfbOyGo5P8gmx6yMZY=.86848b00-a024-4cad-b6ed-09c2154497a3@github.com> On Wed, 12 Jul 2023 16:45:19 GMT, Thomas Stuefe wrote: >> This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. >> >> With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. >> >> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. >> >> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. >> >> The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. >> >> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are fr... > > jdk/test/lib/testlibrary/jdk/testlibrary/Utils.java line 990: > >> 988: if (e4 == null) { throw new NullPointerException("e4"); } >> 989: if (e5 == null) { throw new NullPointerException("e5"); } >> 990: if (e6 == null) { throw new NullPointerException("e6"); } > > Here, and in other places: Objects.requireNonNull may be shorter. Completely forgot that method existed! ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/339#discussion_r1261864914 From andrew at openjdk.org Thu Jul 13 01:40:09 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 13 Jul 2023 01:40:09 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 In-Reply-To: References: Message-ID: <5rwVJfMLscCgetStOm3ot0LNkv7u2oximY4POGX3uM4=.00a41007-e4c6-4b62-aa57-a2df1ba1a4f5@github.com> On Wed, 12 Jul 2023 16:50:09 GMT, Thomas Stuefe wrote: >> This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. >> >> With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. >> >> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. >> >> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. >> >> The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. >> >> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are fr... > > jdk/test/lib/testlibrary/jdk/testlibrary/Utils.java line 1004: > >> 1002: if (!added) { throw new IllegalArgumentException("duplicate 5"); } >> 1003: added = s.add(e6); >> 1004: if (!added) { throw new IllegalArgumentException("duplicate 6"); } > > Could be shortened, but thats up to you (if one does not care for the string, a simple `if (!(s.add(e1) && s.add(e2) && ...` would be sufficient. Not sure why I wrote this in such a long-winded way. Maybe there was more to it at one point and I didn't refine it after making further changes :/ Anyway, converted to a single line but kept the message, which can be useful in debugging (this is test output after all) ------------- PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/339#discussion_r1261879714 From andrew at openjdk.org Thu Jul 13 02:43:15 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 13 Jul 2023 02:43:15 GMT Subject: [jdk8u] Withdrawn: 8301119: Support for GB18030-2022 In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 01:39:00 GMT, Andrew John Hughes wrote: > This is being proposed for inclusion in 8u382 during rampdown, so that the changes are in place for when GB18030-2022 enforcement begins in August. It modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. > > With the preceding test changes in place (#43 and #44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the `SPI.java` generator tool moves into `ExtendedCharsets.java` in the class library, as the file is not auto-generated in 8u. The change to `StandardCharsets.java.template` lands in `AbstractCharsetProvider.java`. > > In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allows `IS_2000` to be package-private to `sun.nio.cs`, whereas we need to make it public in `sun.nio.cs.ext` so it can be accessed from `sun.nio.cs`. > > To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to awk. > > The only adjustment to `GB18030.java`, other than copyright headers, is to replace the use of `jdk.internal.misc.VM.initLevel` with that of `sun.misc.VM.isBooted`. 8u does not provide as fine-grained access to the initialisation status as 11u, and so may force the use of the 2022 standard until a later stage in the bootup (`BOOTED` is `initLevel() = 4` in 11u). > > With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Se... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk8u/pull/45 From andrew at openjdk.org Thu Jul 13 02:51:25 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 13 Jul 2023 02:51:25 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 [v2] In-Reply-To: References: Message-ID: <1iklvLm9RMYfT_LdnVCnzRx8cmnQhYodNUY-kqcw_S8=.b8a2edda-a7a6-43f8-9640-30a32abdf9d2@github.com> > This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. > > With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. > > In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. > > To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. > > The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. > > With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are frequent issues in backp... Andrew John Hughes has updated the pull request incrementally with two additional commits since the last revision: - Simplify the code in the new test utility methods - Document jdk.charset.GB18030 initialisation and simplify variable naming. ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/339/files - new: https://git.openjdk.org/jdk8u-dev/pull/339/files/dd4dccf6..f1418909 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=339&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=339&range=00-01 Stats: 260 lines in 3 files changed: 5 ins; 55 del; 200 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/339.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/339/head:pull/339 PR: https://git.openjdk.org/jdk8u-dev/pull/339 From andrew at openjdk.org Thu Jul 13 02:51:25 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 13 Jul 2023 02:51:25 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 11:21:53 GMT, Andrew John Hughes wrote: > This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. > > With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. > > In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. > > To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. > > The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. > > With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are frequent issues in backp... Thanks for the quick review. I wasn't expecting you to be able to find time today. I've made adjustments as discussed above. Tests pass as before. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/339#issuecomment-1633463828 From andrew at openjdk.org Thu Jul 13 02:54:12 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 13 Jul 2023 02:54:12 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 [v3] In-Reply-To: References: Message-ID: > This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. > > With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. > > In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. > > To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. > > The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. > > With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are frequent issues in backp... Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision: One more Objects.requireNotNull use ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/339/files - new: https://git.openjdk.org/jdk8u-dev/pull/339/files/f1418909..fb26e78e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=339&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=339&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/339.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/339/head:pull/339 PR: https://git.openjdk.org/jdk8u-dev/pull/339 From stuefe at openjdk.org Thu Jul 13 05:05:09 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 13 Jul 2023 05:05:09 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 [v3] In-Reply-To: References: Message-ID: <1bckaQ8_nwn-hNYtolZTBfJas0GABAnF6j5ZobRYqV8=.aeb592ce-3745-4f4f-b974-0b46fa59a623@github.com> On Thu, 13 Jul 2023 02:54:12 GMT, Andrew John Hughes wrote: >> This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. >> >> With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. >> >> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. >> >> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. >> >> The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. >> >> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are fr... > > Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision: > > One more Objects.requireNotNull use Still good. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/339#issuecomment-1633549323 From abakhtin at openjdk.org Thu Jul 13 06:24:24 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Thu, 13 Jul 2023 06:24:24 GMT Subject: [jdk8u-dev] RFR: 6722928: Provide a default native GSS-API library on Windows Message-ID: Please review the backport of sspi bridge to JDK8 The backport is based on the JDK11 version and is almost clean. The copyright years are updated manually: - NativeFunc.h already has a newer copyright year - SunNativeProvider.java updated manually The main difference is a build script for sspi_bridge. It is located in SecurityLibraries.gmk No regressions on the sun/security/krb5 tests (Windows and Linux platforms) ------------- Commit messages: - Backport 475996adc2aaa7af920f2e9711d0ace2ddd2430e Changes: https://git.openjdk.org/jdk8u-dev/pull/340/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=340&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6722928 Stats: 1720 lines in 8 files changed: 1612 ins; 14 del; 94 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/340.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/340/head:pull/340 PR: https://git.openjdk.org/jdk8u-dev/pull/340 From sgehwolf at openjdk.org Thu Jul 13 08:43:13 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 13 Jul 2023 08:43:13 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 [v3] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 02:54:12 GMT, Andrew John Hughes wrote: >> This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. >> >> With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. >> >> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. >> >> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. >> >> The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. >> >> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are fr... > > Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision: > > One more Objects.requireNotNull use Looks fine to me. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/339#pullrequestreview-1527917697 From andrew at openjdk.org Thu Jul 13 15:48:14 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 13 Jul 2023 15:48:14 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 [v3] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 02:54:12 GMT, Andrew John Hughes wrote: >> This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. >> >> With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. >> >> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. >> >> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. >> >> The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. >> >> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are fr... > > Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision: > > One more Objects.requireNotNull use Thanks both. Flagged for approval with `jdk8u-fix-request`. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/339#issuecomment-1634482315 From andrew at openjdk.org Thu Jul 13 16:36:13 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 13 Jul 2023 16:36:13 GMT Subject: [jdk8u-dev] RFR: 8301119: Support for GB18030-2022 [v3] In-Reply-To: References: Message-ID: <3C0kA2yveARtYuxMqRpVcG2Pc44Efj2xj3fZlD-9Qlg=.7ad00031-9ab7-4242-87ed-8f239bc4a735@github.com> On Thu, 13 Jul 2023 02:54:12 GMT, Andrew John Hughes wrote: >> This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. >> >> With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. >> >> In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. >> >> To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. >> >> The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. >> >> With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are fr... > > Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision: > > One more Objects.requireNotNull use I see `jdk8u-fix-yes`. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/339#issuecomment-1634547740 From andrew at openjdk.org Thu Jul 13 16:36:14 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 13 Jul 2023 16:36:14 GMT Subject: [jdk8u-dev] Integrated: 8301119: Support for GB18030-2022 In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 11:21:53 GMT, Andrew John Hughes wrote: > This patch modifies GB18030 to handle both the 2000 and the 2022 variant. The 2000 variant is available by setting `-Djdk.charset.GB18030=2000`. This PR replaces https://github.com/openjdk/jdk8u/pull/45. > > With the preceding test changes in place (https://github.com/openjdk/jdk8u/pull/43 and https://github.com/openjdk/jdk8u/pull/44), the changes needed for this are fairly minimal. The biggest divergence from 11u is in the character set providers. The changes in the `make` directory are not needed as 8u never moved to using a template for GB18030 in the first place (the 11u changes revert it back to being source-based). The change in the SPI.java generator tool moves into ExtendedCharsets.java in the class library, as the file is not auto-generated in 8u. Following additional work by @jerboaa, the alias is now set to `2022` initially, and then replaced in the `init()` method if `jdk.charset.GB18030` is `2000`. > > In 8u, the standard charsets are generated from a text file by a shell script, while the extended charsets are handled by a standard class. 11u moves GB18030 from extended to standard. I experimented with this in 8u, but it seemed more problematic than just keeping it in the extended set. The only reason I can see for moving it in 11u is it allowed `IS_2000` to be package-private to sun.nio.cs. This is resolved by @jerboaa's changes which modify `aliasMap` appropriately on creation, and so allow the use of a package-private method `isGB18030_2000` in `ExtendedCharsets` instead. > > To use the 11u solution would mean major rewrites to the shell script or bringing over the whole change in how the standard charset provider is generated from 11u, which I think, along with moving the package the character set is in, is too risky and unnecessary for this change. The generation changes are necessary because the GB18030 character set needs to provide a different alias, depending on whether it is the 2000 or 2002 variant. The `genCharsetProvider.sh` would need the alterations we have added to `ExtendedCharsets.java` to handle this, but converted to `awk`. I did experiment with this, but saw test failures. > > The only adjustment to the `GB18030.java` changes is copyright headers and the removal of `IS_2000` as mentioned above. > > With the tests, the adjustments are just due to differing bug IDs, the absence of `@modules` and the use of constructs (`var`) and library calls (`Set.of`) that don't exist in 8u. The `List.of` and `Set.of` calls are frequent issues in backp... This pull request has now been integrated. Changeset: 4dc1305c Author: Andrew John Hughes URL: https://git.openjdk.org/jdk8u-dev/commit/4dc1305cafe7913b194e9a8ebc01c49e6dc14a6d Stats: 991 lines in 9 files changed: 876 ins; 12 del; 103 mod 8301119: Support for GB18030-2022 8310947: gb18030-2000 not selectable with LANG=zh_CN.GB18030 after JDK-8301119 Co-authored-by: Severin Gehwolf Reviewed-by: stuefe, sgehwolf Backport-of: 5c4e744dabcf7785c35168db5d0458ccebfd41e6 ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/339 From sgehwolf at openjdk.org Fri Jul 14 10:23:14 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 14 Jul 2023 10:23:14 GMT Subject: [jdk8u-dev] RFR: 8308788: [8u] Remove duplicate HaricaCA.java test In-Reply-To: References: Message-ID: On Fri, 26 May 2023 09:35:16 GMT, Severin Gehwolf wrote: > Could I get a review of this trivial patch please? It only removes a file which is present elsewhere. > > Removes file: > > jdk/test/jdk/security/infra/java/security/cert/CertPathValidator/certification/HaricaCA.java > > ... as the same file is present where other CA tests live: > > jdk/test/security/infra/java/security/cert/CertPathValidator/certification/HaricaCA.java > > > See the bug for details. Thoughts? Please don't close this, bot. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/322#issuecomment-1635643919 From sgehwolf at openjdk.org Fri Jul 14 10:25:08 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 14 Jul 2023 10:25:08 GMT Subject: [jdk8u-dev] RFR: 8287663: Add a regression test for JDK-8287073 In-Reply-To: References: Message-ID: On Fri, 26 May 2023 14:44:12 GMT, Severin Gehwolf wrote: > Simple low risk backport for a regression check of https://bugs.openjdk.org/browse/JDK-8287073 (forthcoming). The only changes were (other than context changes due to `optResult.equals(Optional.empty()` vs `optResult.isEmpty()` differences): > > - Bug line in test. Fixed manually > - `Files.writeString()` => `Files.write()` changes in test. > > Testing: > - [x] New regression test fails without the product fix of JDK-8287073, passes with it. > - [x] Linux container tests on x86_64 and cg1 Please keep open. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/323#issuecomment-1635646222 From sgehwolf at openjdk.org Fri Jul 14 10:25:12 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 14 Jul 2023 10:25:12 GMT Subject: [jdk8u-dev] RFR: 8287073: NPE from CgroupV2Subsystem.getInstance() In-Reply-To: References: Message-ID: <7DRS8MYUOOY2BPyaJoKImp0YEvR_CmLoahY_NH3bKZg=.bab26104-9ba6-4eae-80ce-54bbd95a4d1c@github.com> On Fri, 26 May 2023 14:46:38 GMT, Severin Gehwolf wrote: > Simple low-risk backport avoiding a potential NPE on some cgroups v2 systems. Patch applies clean after path unshuffeling. > > Testing: > - [x] Container tests on Linux x86_64. Pass. > - [x] Regression test from #323 Please keep open. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/324#issuecomment-1635645596 From phh at openjdk.org Mon Jul 17 22:59:06 2023 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 17 Jul 2023 22:59:06 GMT Subject: [jdk8u-dev] RFR: 6722928: Provide a default native GSS-API library on Windows In-Reply-To: References: Message-ID: <2GV9cjFd6JVAly_GABKDjSHzhH72-B4PgfZJbo3raD8=.64dccf60-8e23-44be-b211-32884ba02996@github.com> On Thu, 13 Jul 2023 06:18:34 GMT, Alexey Bakhtin wrote: > Please review the backport of sspi bridge to JDK8 > > The backport is based on the JDK11 version and is almost clean. > The copyright years are updated manually: > - NativeFunc.h already has a newer copyright year > - SunNativeProvider.java updated manually > The main difference is a build script for sspi_bridge. It is located in SecurityLibraries.gmk > > No regressions on the sun/security/krb5 tests (Windows and Linux platforms) Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/340#pullrequestreview-1533817386 From duke at openjdk.org Tue Jul 18 13:01:32 2023 From: duke at openjdk.org (Tobias Gesellchen) Date: Tue, 18 Jul 2023 13:01:32 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to Message-ID: See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. ------------- Commit messages: - 8214046: [macosx] Undecorated Frame does not Iconify when set to Changes: https://git.openjdk.org/jdk8u-dev/pull/341/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=341&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8214046 Stats: 13 lines in 2 files changed: 9 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/341.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/341/head:pull/341 PR: https://git.openjdk.org/jdk8u-dev/pull/341 From duke at openjdk.org Tue Jul 18 13:01:33 2023 From: duke at openjdk.org (Tobias Gesellchen) Date: Tue, 18 Jul 2023 13:01:33 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: <3Q9PLjyQnBQjN16NmyQxIjkkOOHOGgKbej0QfPsyl8w=.c24d8125-784e-43d8-bf46-b4b19437363f@github.com> On Fri, 14 Jul 2023 19:36:56 GMT, Tobias Gesellchen wrote: > See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. Hey @openjdk bot: I would prefer to _not_ change the source branch like you suggested in https://github.com/openjdk/jdk8u-dev/pull/341#issuecomment-1636332591, I hope that's ok for you. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1636344031 From serb at openjdk.org Tue Jul 18 13:01:33 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 18 Jul 2023 13:01:33 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 19:36:56 GMT, Tobias Gesellchen wrote: > See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. I suggest to delete all the "added code" which are not part of the initial patch (mostly changes of the empty spaces). That will simplify a process a bit. lets wait when the "oca oca-verify" will be removed. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1636469279 PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1638611614 From duke at openjdk.org Tue Jul 18 13:01:33 2023 From: duke at openjdk.org (Tobias Gesellchen) Date: Tue, 18 Jul 2023 13:01:33 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 21:35:58 GMT, Sergey Bylokhov wrote: >> See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. > > I suggest to delete all the "added code" which are not part of the initial patch (mostly changes of the empty spaces). That will simplify a process a bit. @mrserb thanks for the quick feedback. I have removed the whitespace only changes. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1636857520 From phh at openjdk.org Tue Jul 18 13:22:11 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 18 Jul 2023 13:22:11 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 19:36:56 GMT, Tobias Gesellchen wrote: > See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. Also, please enable pre-submit testing on your repo. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1640216538 From duke at openjdk.org Tue Jul 18 16:29:11 2023 From: duke at openjdk.org (Tobias Gesellchen) Date: Tue, 18 Jul 2023 16:29:11 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 19:36:56 GMT, Tobias Gesellchen wrote: > See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. The pre-submit workflow has been enabled, and passed. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1640549600 From andrew at openjdk.org Wed Jul 19 01:18:49 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 19 Jul 2023 01:18:49 GMT Subject: [jdk8u-dev] RFR: Merge jdk8u:master Message-ID: Merge jdk8u382-b05 ------------- Commit messages: - Merge jdk8u382-b05 - 8305312: Enhanced path handling - 8304468: Better array usages - 8300596: Enhance Jar Signature validation - 8298676: Enhanced Look and Feel - 8301119: Support for GB18030-2022 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk8u-dev/pull/343/files Stats: 86 lines in 7 files changed: 63 ins; 10 del; 13 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/343.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/343/head:pull/343 PR: https://git.openjdk.org/jdk8u-dev/pull/343 From duke at openjdk.org Wed Jul 19 02:28:45 2023 From: duke at openjdk.org (sendaoYan) Date: Wed, 19 Jul 2023 02:28:45 GMT Subject: [jdk8u-dev] RFR: 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException In-Reply-To: References: Message-ID: <33ELykeopaPZO8c1KEr2H2SgzEaM29U3egu3JFaBJgE=.5c1c0be2-0883-4611-85e5-748f96bbbed5@github.com> On Fri, 7 Jul 2023 08:43:34 GMT, sendaoYan wrote: > 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException > > Reviewed-by: Yi Yang Please don't close this, bot. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/337#issuecomment-1641287517 From andrew at openjdk.org Wed Jul 19 11:57:25 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 19 Jul 2023 11:57:25 GMT Subject: [jdk8u-dev] RFR: Merge jdk8u:master [v2] In-Reply-To: References: Message-ID: > Merge jdk8u382-b05 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. The pull request contains 10 additional commits since the last revision: - Merge jdk8u382-b05 - 8301119: Support for GB18030-2022 8310947: gb18030-2000 not selectable with LANG=zh_CN.GB18030 after JDK-8301119 Co-authored-by: Severin Gehwolf Reviewed-by: stuefe, sgehwolf Backport-of: 5c4e744dabcf7785c35168db5d0458ccebfd41e6 - Merge - 8310026: [8u] make java_lang_String::hash_code consistent across platforms Reviewed-by: phh, adinn, stuefe - 8309143: [8u] fix archiving inconsistencies in GHA Reviewed-by: phh, sgehwolf - 8205399: Set node color on pinned HashMap.TreeNode deletion Backport-of: 51d0a9e1223f218d10f8761e38cd2dd478607040 - 8200468: Port the native GSS-API bridge to Windows Reviewed-by: andrew Backport-of: 0b6fbf50d24438117c33fa1a7d3633b792c99983 - 8139348: Deprecate 3DES and RC4 in Kerberos Reviewed-by: andrew Backport-of: ded96ddcde1e9e8556a6ce8948acef27b6e192cc - 8253269: The CheckCommonColors test should provide more info on failure Backport-of: 1c2754bfe3294fb3c80defe5479bdd85b0d07e29 - 8309122: Bump update version of OpenJDK: 8u392 Reviewed-by: serb, sgehwolf ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/343/files - new: https://git.openjdk.org/jdk8u-dev/pull/343/files/5d1821cd..5d1821cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=343&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=343&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/343.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/343/head:pull/343 PR: https://git.openjdk.org/jdk8u-dev/pull/343 From andrew at openjdk.org Wed Jul 19 11:57:26 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 19 Jul 2023 11:57:26 GMT Subject: [jdk8u-dev] Integrated: Merge jdk8u:master In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 01:14:17 GMT, Andrew John Hughes wrote: > Merge jdk8u382-b05 This pull request has now been integrated. Changeset: 587090dd Author: Andrew John Hughes URL: https://git.openjdk.org/jdk8u-dev/commit/587090ddc17c073d56f4d3f52b61f6477d6322b0 Stats: 86 lines in 7 files changed: 63 ins; 10 del; 13 mod Merge ------------- PR: https://git.openjdk.org/jdk8u-dev/pull/343 From phh at openjdk.org Wed Jul 19 16:53:45 2023 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 19 Jul 2023 16:53:45 GMT Subject: [jdk8u-dev] RFR: 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 08:43:34 GMT, sendaoYan wrote: > 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException > > Reviewed-by: Yi Yang The copyright date update isn't in the original commit, so should be removed. Other than that, looks good. What testing have you done? ------------- Changes requested by phh (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/337#pullrequestreview-1537530688 From duke at openjdk.org Thu Jul 20 03:02:47 2023 From: duke at openjdk.org (sendaoYan) Date: Thu, 20 Jul 2023 03:02:47 GMT Subject: [jdk8u-dev] RFR: 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 16:50:51 GMT, Paul Hohensee wrote: > The copyright date update isn't in the original commit, so should be removed. Other than that, looks good. What testing have you done? mine test command is: test=jdk/test/java/net/MulticastSocket/Promiscuous.java nproc=`nproc` ; dir="tmp-jtreg-"`basename $test .java` ; rm -rf $dir ; mkdir -p $dir ; time seq 1000 | xargs -i -n 1 -P `expr $nproc / 2` bash -c "jtreg -ea -esa -timeoutFactor:4 -v:fail,error,time,nopass -nr -w $dir/index-{} $test &> $dir/{}.log ; grep 'Test results: passed: 1' -L $dir/{}.log" Before this patch apply, this test intermittently fail: ![image](https://github.com/openjdk/jdk8u-dev/assets/24123821/35181eac-ba43-471b-a067-29a2a183dab7) After this patch apply, this test run 1000 times all pass: ![image](https://github.com/openjdk/jdk8u-dev/assets/24123821/8da37daa-1662-44e6-b5b3-c6947aab6c0f) ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/337#issuecomment-1643032403 From duke at openjdk.org Thu Jul 20 03:14:16 2023 From: duke at openjdk.org (sendaoYan) Date: Thu, 20 Jul 2023 03:14:16 GMT Subject: [jdk8u-dev] RFR: 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException [v2] In-Reply-To: References: Message-ID: > 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException > > Reviewed-by: Yi Yang sendaoYan has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Backport eccfec498d4062b582282f3b73bba84206a36046 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException Reviewed-by: Yi Yang Signed-off-by: sendaoYan ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/337/files - new: https://git.openjdk.org/jdk8u-dev/pull/337/files/eee9317f..8e365a4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=337&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=337&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/337.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/337/head:pull/337 PR: https://git.openjdk.org/jdk8u-dev/pull/337 From duke at openjdk.org Thu Jul 20 03:15:46 2023 From: duke at openjdk.org (sendaoYan) Date: Thu, 20 Jul 2023 03:15:46 GMT Subject: [jdk8u-dev] RFR: 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 16:50:51 GMT, Paul Hohensee wrote: >> sendaoYan has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> Backport eccfec498d4062b582282f3b73bba84206a36046 >> >> 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException >> >> Reviewed-by: Yi Yang >> Signed-off-by: sendaoYan > > The copyright date update isn't in the original commit, so should be removed. Other than that, looks good. What testing have you done? @phohensee The copyright date update has been removed. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/337#issuecomment-1643039815 From phh at openjdk.org Thu Jul 20 13:36:50 2023 From: phh at openjdk.org (Paul Hohensee) Date: Thu, 20 Jul 2023 13:36:50 GMT Subject: [jdk8u-dev] RFR: 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException [v2] In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 03:14:16 GMT, sendaoYan wrote: >> 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException >> >> Reviewed-by: Yi Yang > > sendaoYan has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Backport eccfec498d4062b582282f3b73bba84206a36046 > > 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException > > Reviewed-by: Yi Yang > Signed-off-by: sendaoYan Looks good, thanks for doing the backport. ------------- Marked as reviewed by phh (Reviewer). PR Review: https://git.openjdk.org/jdk8u-dev/pull/337#pullrequestreview-1539278254 From duke at openjdk.org Sat Jul 22 09:48:45 2023 From: duke at openjdk.org (Tobias Gesellchen) Date: Sat, 22 Jul 2023 09:48:45 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 19:36:56 GMT, Tobias Gesellchen wrote: > See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. I think this can be reviewed. Is there anything to do from my side? ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1646545098 From duke at openjdk.org Mon Jul 24 07:29:46 2023 From: duke at openjdk.org (Alexey Pavlyutkin) Date: Mon, 24 Jul 2023 07:29:46 GMT Subject: [jdk8u-dev] RFR: 8179503: Java should support GET OCSP calls [v2] In-Reply-To: References: Message-ID: <9a7tk7fif9BbPfnH0zTjmNDXmA-jBCS32AqfFuEN6f0=.657a6424-203a-4b6f-bcea-9829e033393c@github.com> On Tue, 6 Jun 2023 06:24:08 GMT, Alexey Pavlyutkin wrote: >> Hi! >> >> I would like to backport **[JDK-8179503: Java should support GET OCSP calls](https://bugs.openjdk.org/browse/JDK-8179503)** for parity with Oracle JDK. >> >> Except the path suffling the following changes were done to original patch: >> >> **`jdk/src/share/classes/sun/security/provider/certpath/OCSP.java`** >> - still reads the response piece by piece using `InputStream.read()` method because `IOUtils.readExactlyNBytes()` is not available >> >> **`jdk/test/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java`** >> - unsupported `List.of()`, `Set.of()`, `Map.of()` replaced with equivalents >> - `algorithm` parameter dropped from instantiation `PKCS8EncodedKeySpec` >> >> **`jdk/test/javax/net/ssl/templates/SSLSocketTemplate.java`** >> - required `public static enum SSLSocketTemplate.Cert` copied from `11u` >> >> Verification (amd64/20.04LTS): newly added `jdk/test/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java` >> Regression (amd64/20.04LTS): `jdk_security` > > Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision: > > restore lost newlines at the end of files Please don't close this, bot. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/330#issuecomment-1647359271 From duke at openjdk.org Mon Jul 24 07:29:45 2023 From: duke at openjdk.org (Alexey Pavlyutkin) Date: Mon, 24 Jul 2023 07:29:45 GMT Subject: [jdk8u-dev] RFR: 8274471: Add support for RSASSA-PSS in OCSP Response In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 09:33:06 GMT, Alexey Pavlyutkin wrote: > Hi! > > I'd like to backport **[JDK-8274471: Add support for RSASSA-PSS in OCSP Response](https://bugs.openjdk.org/browse/JDK-8274471)** for parity with Oracle JDK. > > The patch from `11u` applied with the following changes (except the path shuffling): > > **`jdk/src/share/classes/sun/security/provider/certpath/OCSP.java`** > - `URLEncoder.encode()` accepts desired charset as a string, charset constants are not supported in `8`, so import of `java.nio.charset.StandardCharsets` also skipped > - resolved little baseline conflict > > **`jdk/src/share/classes/sun/security/x509/AlgorithmId.java`** > - required `public static String getDefaultSigAlgForKey(PrivateKey k)` and `private static String ecStrength (int bitLength)` copied from `11` > > Verification (amd64/20.04): `jdk/test/javax/net/ssl/Stapling/HttpsUrlConnClient.java` with new `RSASSA-PSS` case > Regression (amd64/20.04): `jdk_security` Please don't close this, bot. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/331#issuecomment-1647360199 From duke at openjdk.org Mon Jul 24 07:30:49 2023 From: duke at openjdk.org (Alexey Pavlyutkin) Date: Mon, 24 Jul 2023 07:30:49 GMT Subject: [jdk8u-dev] RFR: 8296343: CPVE thrown on missing content-length in OCSP response In-Reply-To: References: Message-ID: On Wed, 7 Jun 2023 10:17:57 GMT, Alexey Pavlyutkin wrote: > Hi! > > Here is backport of **[JDK-8296343: CPVE thrown on missing content-length in OCSP response](https://bugs.openjdk.org/browse/JDK-8296343)**. The patch from `11u` applied with the following changes (except the path shuflling): > > **`jdk/src/java.base/share/classes/sun/security/provider/certpath/OCSP.java`** > - reading response content from the input stream reworked due to `InputStream.readAllBytes()` and `IOUtils.readExactlyNBytes()` are not available in `8` > > **`jdk/test/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java`** > - unsupported `List.of()` and `Set.of()` replaced with equivalent code > - added a newline at the end of the file > > Verification (amd64/20.04): newly added `test/jdk/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java` **FAILS**, will be fixed by backporting of [JDK-8300939](https://bugs.openjdk.org/browse/JDK-8300939) > Regression (amd64/20.04): `jdk_security` Please don't close this, bot. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/332#issuecomment-1647360523 From duke at openjdk.org Mon Jul 24 07:30:49 2023 From: duke at openjdk.org (Alexey Pavlyutkin) Date: Mon, 24 Jul 2023 07:30:49 GMT Subject: [jdk8u-dev] RFR: 8300939: sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to network errors In-Reply-To: <8UMMFqO6YtZ4zrh7iCzjdWVpD7xjNUk_oUWmb8D32UQ=.924222f9-249c-4a40-a15d-bf680a2c9925@github.com> References: <8UMMFqO6YtZ4zrh7iCzjdWVpD7xjNUk_oUWmb8D32UQ=.924222f9-249c-4a40-a15d-bf680a2c9925@github.com> Message-ID: On Wed, 7 Jun 2023 18:28:23 GMT, Alexey Pavlyutkin wrote: > Hi! > > Here is backport of [JDK-8300939](https://bugs.openjdk.org/browse/JDK-8300939) fixing `sun/security/provider/certpath/OCSP/OCSPNoContentLength.java` test. The patch from `11u` applied cleanly except the path shuffling > > Verification/regression (amd64/LTS20.04): `jdk_security` Please don't close this, bot. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/333#issuecomment-1647360670 From gnu.andrew at redhat.com Mon Jul 24 17:31:12 2023 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 24 Jul 2023 18:31:12 +0100 Subject: OpenJDK 8u382 Released Message-ID: We are pleased to announce the release of OpenJDK 8u382. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u382-b05.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u382-b05.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: c29d3443dadd3da1a56e50ff49313944788817bb3d5916dde775720b58968a73 openjdk8u382-b05.tar.xz a7e6b4a0de2b95421308419119099bd543ae4ce6f72cebd598535684805d8d53 openjdk8u382-b05.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u382-b05.sha256 New in release OpenJDK 8u382 (2023-07-18): =========================================== Live versions of these release notes can be found at: * https://bit.ly/openjdk8u382 * CVEs - CVE-2023-22045 - CVE-2023-22049 * Security fixes - JDK-8298676: Enhanced Look and Feel - JDK-8300596: Enhance Jar Signature validation - JDK-8304468: Better array usages - JDK-8305312: Enhanced path handling * Other changes - JDK-8072678: Wrong exception messages in java.awt.color.ICC_ColorSpace - JDK-8151460: Metaspace counters can have inconsistent values - JDK-8152432: Implement setting jtreg @requires properties vm.flavor, vm.bits, vm.compMode - JDK-8185736: missing default exception handler in calls to rethrow_Stub - JDK-8186801: Add regression test to test mapping based charsets (generated at build time) - JDK-8215105: java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java: Wrong Pixel Color - JDK-8241311: Move some charset mapping tests from closed to open - JDK-8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert - JDK-8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec is skipped - JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key - JDK-8276841: Add support for Visual Studio 2022 - JDK-8277881: Missing SessionID in TLS1.3 resumption in compatibility mode - JDK-8278851: Correct signer logic for jars signed with multiple digest algorithms - JDK-8282345: handle latest VS2022 in abstract_vm_version - JDK-8282600: SSLSocketImpl should not use user_canceled workaround when not necessary - JDK-8285515: (dc) DatagramChannel.disconnect fails with "Invalid argument" on macOS 12.4 - JDK-8289301: P11Cipher should not throw out of bounds exception during padding - JDK-8293232: Fix race condition in pkcs11 SessionManager - JDK-8293815: P11PSSSignature.engineUpdate should not print debug messages during normal operation - JDK-8295530: Update Zlib Data Compression Library to Version 1.2.13 - JDK-8298108: Add a regression test for JDK-8297684 - JDK-8298271: java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on Windows - JDK-8301119: Support for GB18030-2022 - JDK-8301400: Allow additional characters for GB18030-2022 support - JDK-8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message - JDK-8303028: Update system property for Java SE specification maintenance version - JDK-8303462: Bump update version of OpenJDK: 8u382 - JDK-8304760: Add 2 Microsoft TLS roots - JDK-8305165: [8u] ServiceThread::nmethods_do is not called to keep nmethods from being zombied while in the queue - JDK-8305681: Allow additional characters for GB18030-2022 (Level 2) support - JDK-8305975: Add TWCA Global Root CA - JDK-8307134: Add GTS root CAs - JDK-8307310: Backport the tests for JDK-8058969 and JDK-8039271 to the OpenJDK8 - JDK-8307531: [aarch64] JDK8 single-step debugging is extremely slow - JDK-8310947: gb18030-2000 not selectable with LANG=zh_CN.GB18030 after JDK-8301119 Notes on individual issues: =========================== core-libs/java.lang: JDK-8305681: Allow additional characters for GB18030-2022 (Level 2) support =========================================================================== In order to support "Implementation Level 2" of the GB18030-2022 standard, the JDK must be able to use characters from the CJK Unified Ideographs Extension E block of Unicode 8.0. The addition of these characters forms Maintenance Release 5 of the Java SE 8 specification, which is implemented in this release of OpenJDK via the addition of a new UnicodeBlock instance, Character.CJK_UNIFIED_IDEOGRAPHS_EXTENSION_E. core-libs/java.util.jar: 8300596: Enhance Jar Signature validation ========================================= A System property "jdk.jar.maxSignatureFileSize" is introduced to configure the maximum number of bytes allowed for the signature-related files in a JAR file during verification. The default value is 8000000 bytes (8 MB). security-libs/java.security: JDK-8307134: Added 4 GTS Root CA Certificates ============================================= The following root certificates have been added to the cacerts truststore: Name: Google Trust Services LLC Alias Name: gtsrootcar1 Distinguished Name: CN=GTS Root R1, O=Google Trust Services LLC, C=US Name: Google Trust Services LLC Alias Name: gtsrootcar2 Distinguished Name: CN=GTS Root R2, O=Google Trust Services LLC, C=US Name: Google Trust Services LLC Alias Name: gtsrootcar3 Distinguished Name: CN=GTS Root R3, O=Google Trust Services LLC, C=US Name: Google Trust Services LLC Alias Name: gtsrootcar4 Distinguished Name: CN=GTS Root R4, O=Google Trust Services LLC, C=US JDK-8304760: Added Microsoft Corporation's 2 TLS Root CA Certificates ===================================================================== The following root certificates has been added to the cacerts truststore: Name: Microsoft Corporation Alias Name: microsoftecc2017 Distinguished Name: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US Name: Microsoft Corporation Alias Name: microsoftrsa2017 Distinguished Name: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US JDK-8305975: Added TWCA Root CA Certificate =========================================== The following root certificate has been added to the cacerts truststore: Name: TWCA Alias Name: twcaglobalrootca Distinguished Name: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW 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 Mon Jul 24 20:00:54 2023 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 24 Jul 2023 20:00:54 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 19:36:56 GMT, Tobias Gesellchen wrote: > See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. Marked as reviewed by phh (Reviewer). Please rebase (i.e., merge with master). That should trigger pre-submit tests. ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/341#pullrequestreview-1544158786 PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1648520541 From serb at openjdk.org Mon Jul 24 20:00:54 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 24 Jul 2023 20:00:54 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 19:36:56 GMT, Tobias Gesellchen wrote: > See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. I will run the tests to check that some dependencies are not missed. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1648522153 From duke at openjdk.org Mon Jul 24 20:16:50 2023 From: duke at openjdk.org (Tobias Gesellchen) Date: Mon, 24 Jul 2023 20:16:50 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 19:56:25 GMT, Paul Hohensee wrote: > Please rebase (i.e., merge with master). That should trigger pre-submit tests. > @phohensee I suppose you didn't want me to rebase my branch, but referred to the default behavior like the openjdk bot mentioned it their recent comment? ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1648541247 From serb at openjdk.org Mon Jul 24 20:20:52 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 24 Jul 2023 20:20:52 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 19:36:56 GMT, Tobias Gesellchen wrote: > See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. Note the you should type "integrate" after the patch will be approved by the jdk8u mantainer in JBS via "jdk8u-fix-yes" label, see https://wiki.openjdk.org/display/jdk8u#Contributing ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1648545506 From serb at openjdk.org Mon Jul 24 20:43:59 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 24 Jul 2023 20:43:59 GMT Subject: [jdk8u-dev] RFR: 8212677: X11 default visual support for IM status window on VNC Message-ID: Hi all, This pull request contains a backport of commit https://github.com/openjdk/jdk/commit/86cf7f8768977aea7b9ea1c90da498a1d91d2891 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Ichiroh Takiguchi on Feb 1, 2019 and was reviewed by Naoto Sato and Sergey Bylokhov @takiguc please take a look. Thanks! ------------- Commit messages: - 8212677: X11 default visual support for IM status window on VNC Changes: https://git.openjdk.org/jdk8u-dev/pull/345/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=345&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8212677 Stats: 33 lines in 2 files changed: 19 ins; 5 del; 9 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/345.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/345/head:pull/345 PR: https://git.openjdk.org/jdk8u-dev/pull/345 From duke at openjdk.org Mon Jul 24 20:56:51 2023 From: duke at openjdk.org (Tobias Gesellchen) Date: Mon, 24 Jul 2023 20:56:51 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 20:17:49 GMT, Sergey Bylokhov wrote: >> See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. > > Note the you should type "integrate" after the patch will be approved by the jdk8u mantainer in JBS via "jdk8u-fix-yes" label, > see https://wiki.openjdk.org/display/jdk8u#Contributing @mrserb looks like I forgot to file a bug in JBS (did that now via Java Incidents). So, we'll have to wait until the JI issue is transferred to JBS. Sorry for my ignorance of the Contribution workflow ? ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1648598631 From serb at openjdk.org Tue Jul 25 02:21:53 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 25 Jul 2023 02:21:53 GMT Subject: [jdk8u-dev] RFR: 8232225: Rework the fix for JDK-8071483 Message-ID: This patch prevents possible name clashes for future backports. Right now the jdk8u-dev has the "Color" folder while the jdk11+ use the "color" folder. So depending on what file system backport is done the resulting folder could be different. This is a proposal to backport the patch which had split the "Color" folder into "color" and "ColorClass". The patch is mostly clean except: - AlphaColorTest and XRenderTranslucentColorDrawTest are not present in JDK 8, both related fixes caused a couple of regressions, so no plans to backport it. - GetInstanceBrokenStream is added to the patch. In the upstream it was pushed after this fix, now we should place it in the correct folder "color" instead of "Color" commit in [openjdk/jdk](https://github.com/openjdk/jdk/commit/e4b73897adf47467461634ceb786540f46aa9eb7) All tests green. ------------- Commit messages: - 8232225: Rework the fix for JDK-8071483 Changes: https://git.openjdk.org/jdk8u-dev/pull/346/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=346&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8232225 Stats: 0 lines in 6 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/346.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/346/head:pull/346 PR: https://git.openjdk.org/jdk8u-dev/pull/346 From inakonechnyy at openjdk.org Tue Jul 25 11:46:04 2023 From: inakonechnyy at openjdk.org (Ilarion Nakonechnyy) Date: Tue, 25 Jul 2023 11:46:04 GMT Subject: [jdk8u-dev] RFR: 8207404: MulticastSocket tests failing on AIX Message-ID: <05e3dm1BROrR_sCq-zzryCP0u5ZKq7mrpEHkpdXZ2pQ=.4b658ebe-9dda-4517-8341-150e9e755828@github.com> This backport fixes the tier2 test: FAILED: java/net/MulticastSocket/JoinLeave.java -- The socket name is not available on this system. (Error setting socket option) Changes are applied non-cleanly. Tested on AIX 7.2 ------------- Commit messages: - Backport bc651663e31ddf05d59bfe6fc7a70c3a7ed708af Changes: https://git.openjdk.org/jdk8u-dev/pull/347/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=347&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8207404 Stats: 376 lines in 4 files changed: 181 ins; 137 del; 58 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/347.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/347/head:pull/347 PR: https://git.openjdk.org/jdk8u-dev/pull/347 From inakonechnyy at openjdk.org Tue Jul 25 13:57:56 2023 From: inakonechnyy at openjdk.org (Ilarion Nakonechnyy) Date: Tue, 25 Jul 2023 13:57:56 GMT Subject: [jdk8u-dev] RFR: 8239365: ProcessBuilder test modifications for AIX execution Message-ID: Applied cleanly, fixes JTREG failed test java/lang/ProcessBuilder/Basic.java on AIX 7.2 ------------- Commit messages: - Backport 2785fe5621bd3af64450f1f5069dc2a4b47785fe Changes: https://git.openjdk.org/jdk8u-dev/pull/348/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=348&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8239365 Stats: 11 lines in 1 file changed: 4 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/348.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/348/head:pull/348 PR: https://git.openjdk.org/jdk8u-dev/pull/348 From btaylor at openjdk.org Tue Jul 25 17:40:50 2023 From: btaylor at openjdk.org (Ben Taylor) Date: Tue, 25 Jul 2023 17:40:50 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 20:53:35 GMT, Tobias Gesellchen wrote: >> Note the you should type "integrate" after the patch will be approved by the jdk8u mantainer in JBS via "jdk8u-fix-yes" label, >> see https://wiki.openjdk.org/display/jdk8u#Contributing > > @mrserb looks like I forgot to file a bug in JBS (did that now via Java Incidents). So, we'll have to wait until the JI issue is transferred to JBS. > Sorry for my ignorance of the Contribution workflow ? @gesellix >I suppose you didn't want me to rebase my branch Any push to your branch (including rebasing your branch on `jdk8u-dev/master`) will rerun the github actions, and cause the pre-submit tests to run now that they are enabled. > looks like I forgot to file a bug in JBS A new bug report is not usually required to backport fixes from jdk tip to older versions - once @mrserb has completed testing, we will add a `jdk8u-fix-request` label on the existing bug [JDK-8214046](https://bugs.openjdk.org/browse/JDK-8214046), and if it is approved a maintainer will add the label `jdk8u-fix-yes`. At that point this PR can be integrated. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1650261300 From duke at openjdk.org Tue Jul 25 17:52:49 2023 From: duke at openjdk.org (Tobias Gesellchen) Date: Tue, 25 Jul 2023 17:52:49 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 19:36:56 GMT, Tobias Gesellchen wrote: > See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. Sounds great, so I'm going to rebase, ignoring https://github.com/openjdk/jdk8u-dev/pull/341#issuecomment-1636857432 and maybe invalidating Paul's approval. Not sure if any of you could check for the newly created JI bug id 9075585 and close it as duplicate of [JDK-8214046](https://bugs.openjdk.org/browse/JDK-8214046). I assumed that a new bug would be required due to JDK-8214046 being "resolved". ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1650282953 From duke at openjdk.org Tue Jul 25 18:03:04 2023 From: duke at openjdk.org (Tobias Gesellchen) Date: Tue, 25 Jul 2023 18:03:04 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to [v2] In-Reply-To: References: Message-ID: > See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. Tobias Gesellchen 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 one additional commit since the last revision: 8214046: [macosx] Undecorated Frame does not Iconify when set to Reviewed-by: dmarkov Backport-of: ab97f65242dad6ad1a7bfb8284954f202eb37369 ------------- Changes: - all: https://git.openjdk.org/jdk8u-dev/pull/341/files - new: https://git.openjdk.org/jdk8u-dev/pull/341/files/16adbd38..77b7b1d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=341&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=341&range=00-01 Stats: 86 lines in 7 files changed: 63 ins; 10 del; 13 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/341.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/341/head:pull/341 PR: https://git.openjdk.org/jdk8u-dev/pull/341 From duke at openjdk.org Tue Jul 25 20:22:50 2023 From: duke at openjdk.org (Tobias Gesellchen) Date: Tue, 25 Jul 2023 20:22:50 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 18:03:04 GMT, Tobias Gesellchen wrote: >> See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. > > Tobias Gesellchen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8214046: [macosx] Undecorated Frame does not Iconify when set to > > Reviewed-by: dmarkov > Backport-of: ab97f65242dad6ad1a7bfb8284954f202eb37369 The GitHub Actions have finished the pre-submit tests with success ? ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1650497876 From phh at openjdk.org Tue Jul 25 22:33:46 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 25 Jul 2023 22:33:46 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 18:03:04 GMT, Tobias Gesellchen wrote: >> See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. > > Tobias Gesellchen 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 one additional commit since the last revision: > > 8214046: [macosx] Undecorated Frame does not Iconify when set to > > Reviewed-by: dmarkov > Backport-of: ab97f65242dad6ad1a7bfb8284954f202eb37369 Tagged the JBS issue. Please post a link to the bug you created when it hits JBS. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1650650532 From serb at openjdk.org Tue Jul 25 23:37:51 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 25 Jul 2023 23:37:51 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 18:03:04 GMT, Tobias Gesellchen wrote: >> See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. > > Tobias Gesellchen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8214046: [macosx] Undecorated Frame does not Iconify when set to > > Reviewed-by: dmarkov > Backport-of: ab97f65242dad6ad1a7bfb8284954f202eb37369 The testing completed no new issues were found. The patch verified by the updated test. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1650705772 From serb at openjdk.org Wed Jul 26 01:45:48 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 26 Jul 2023 01:45:48 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 18:03:04 GMT, Tobias Gesellchen wrote: >> See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. > > Tobias Gesellchen 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 one additional commit since the last revision: > > 8214046: [macosx] Undecorated Frame does not Iconify when set to > > Reviewed-by: dmarkov > Backport-of: ab97f65242dad6ad1a7bfb8284954f202eb37369 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/341#pullrequestreview-1546692341 From phh at openjdk.org Wed Jul 26 18:16:48 2023 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 26 Jul 2023 18:16:48 GMT Subject: [jdk8u-dev] RFR: 8232225: Rework the fix for JDK-8071483 In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 01:47:27 GMT, Sergey Bylokhov wrote: > This patch prevents possible name clashes for future backports. Right now the jdk8u-dev has the "Color" folder while the jdk11+ use the "color" folder. So depending on what file system backport is done the resulting folder could be different. > > This is a proposal to backport the patch which had split the "Color" folder into "color" and "ColorClass". The patch is mostly clean except: > - AlphaColorTest and XRenderTranslucentColorDrawTest are not present in JDK 8, both related fixes caused a couple of regressions, so no plans to backport it. > - GetInstanceBrokenStream is added to the patch. In the upstream it was pushed after this fix, now we should place it in the correct folder "color" instead of "Color" > > commit in [openjdk/jdk](https://github.com/openjdk/jdk/commit/e4b73897adf47467461634ceb786540f46aa9eb7) > > All tests green. Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk8u-dev/pull/346#pullrequestreview-1548337397 From phh at openjdk.org Wed Jul 26 18:23:52 2023 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 26 Jul 2023 18:23:52 GMT Subject: [jdk8u-dev] RFR: 8232225: Rework the fix for JDK-8071483 In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 01:47:27 GMT, Sergey Bylokhov wrote: > This patch prevents possible name clashes for future backports. Right now the jdk8u-dev has the "Color" folder while the jdk11+ use the "color" folder. So depending on what file system backport is done the resulting folder could be different. > > This is a proposal to backport the patch which had split the "Color" folder into "color" and "ColorClass". The patch is mostly clean except: > - AlphaColorTest and XRenderTranslucentColorDrawTest are not present in JDK 8, both related fixes caused a couple of regressions, so no plans to backport it. > - GetInstanceBrokenStream is added to the patch. In the upstream it was pushed after this fix, now we should place it in the correct folder "color" instead of "Color" > > commit in [openjdk/jdk](https://github.com/openjdk/jdk/commit/e4b73897adf47467461634ceb786540f46aa9eb7) > > All tests green. MacOS-x84 java/math/BigInteger/LargeValueExceptions.java presubmit test failure is unrelated. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/346#issuecomment-1652289187 From duke at openjdk.org Wed Jul 26 20:16:47 2023 From: duke at openjdk.org (Tobias Gesellchen) Date: Wed, 26 Jul 2023 20:16:47 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 18:03:04 GMT, Tobias Gesellchen wrote: >> See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. > > Tobias Gesellchen 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 one additional commit since the last revision: > > 8214046: [macosx] Undecorated Frame does not Iconify when set to > > Reviewed-by: dmarkov > Backport-of: ab97f65242dad6ad1a7bfb8284954f202eb37369 This is now pending a `jdk8u-fix-yes` tag on the bug ticket, but nothing to be done by myself, right? I'll wait this time with any _integrate_ commands :) The other ticket created by me is hopefully not blocking anything? I'll post the JBS link here as soon as I get it. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1652429577 From phh at openjdk.org Wed Jul 26 22:15:52 2023 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 26 Jul 2023 22:15:52 GMT Subject: [jdk8u-dev] RFR: 8214046: [macosx] Undecorated Frame does not Iconify when set to [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 18:03:04 GMT, Tobias Gesellchen wrote: >> See https://bugs.openjdk.org/browse/JDK-8214046 with the original patch at https://hg.openjdk.org/jdk/jdk/rev/769dbf384c44. I used https://github.com/openjdk/jdk11u-dev/commit/ab97f65242dad6ad1a7bfb8284954f202eb37369 as backport commit. > > Tobias Gesellchen 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 one additional commit since the last revision: > > 8214046: [macosx] Undecorated Frame does not Iconify when set to > > Reviewed-by: dmarkov > Backport-of: ab97f65242dad6ad1a7bfb8284954f202eb37369 Yes, wait for jdk8u-fix-yes to add /integrate. No, the other ticket isn't blocking anything. :) ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/341#issuecomment-1652579159 From itakiguchi at openjdk.org Sun Jul 30 11:30:45 2023 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Sun, 30 Jul 2023 11:30:45 GMT Subject: [jdk8u-dev] RFR: 8212677: X11 default visual support for IM status window on VNC In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 20:23:40 GMT, Sergey Bylokhov wrote: > Hi all, > > This pull request contains a backport of commit https://github.com/openjdk/jdk/commit/86cf7f8768977aea7b9ea1c90da498a1d91d2891 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Ichiroh Takiguchi on Feb 1, 2019 and was reviewed by Naoto Sato and Sergey Bylokhov > > @takiguc please take a look. > > Thanks! Hello @mrserb . Sorry I'm late. I rebuilt test environment. I could recreate the issue without the patch. Also your patch worked fine with my test environment. I don't have reviewer role. Please find another reviewer. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/345#issuecomment-1657114604 From serb at openjdk.org Sun Jul 30 22:09:47 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 30 Jul 2023 22:09:47 GMT Subject: [jdk8u-dev] RFR: 8212677: X11 default visual support for IM status window on VNC In-Reply-To: References: Message-ID: On Sun, 30 Jul 2023 11:28:09 GMT, Ichiroh Takiguchi wrote: >I could recreate the issue without the patch. >Also your patch worked fine with my test environment. @takiguc, Thank you for the confirmation! ------------- PR Comment: https://git.openjdk.org/jdk8u-dev/pull/345#issuecomment-1657276877 From xliu at openjdk.org Mon Jul 31 23:01:55 2023 From: xliu at openjdk.org (Xin Liu) Date: Mon, 31 Jul 2023 23:01:55 GMT Subject: [jdk8u-dev] RFR: 8173072: zipfs fails to handle incorrect info-zip "extended timestamp extra field" Message-ID: Package nio.zipfs is in demo directory of jdk8u. It is not the part of standard libraries until jdk9. However, we found that some Java8 applications use it and hit a bug. I guess this manifests Hyrum's Law again. This patch can *NOT* apply to jdk8u cleanly. I need to adjust the directory. I drop the cosmetic changes in nio/zipfs/ZipCoder.java. It helps minimize changeset. If we want to include them, we need to backport other patches. We test jtreg locally. I reckon the risk is minimal because the patch only adds a few boundary checks in nio/zipfs/EXTT. Without it, zipfs throws java.lang.ArrayIndexOutOfBoundsException when it encounters a problematic zip file. ------------- Commit messages: - Backport 248778d27a5f8a16e4c90a4f5a6632a7ca8e9a89 Changes: https://git.openjdk.org/jdk8u-dev/pull/349/files Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=349&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8173072 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk8u-dev/pull/349.diff Fetch: git fetch https://git.openjdk.org/jdk8u-dev.git pull/349/head:pull/349 PR: https://git.openjdk.org/jdk8u-dev/pull/349