From zgu at redhat.com Sat Aug 1 23:29:53 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Sat, 1 Aug 2020 19:29:53 -0400 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call In-Reply-To: References: <16ac9ba2-e0d8-4e23-8157-67c1a787da64@redhat.com> Message-ID: Thanks, Paul and Andrew. -Zhengyu On 7/31/20 11:35 AM, Hohensee, Paul wrote: > Thanks, Andrew. > > Zhengyu, you're good afaic too. > > Paul > > ?On 7/31/20, 1:29 AM, "Andrew Haley" wrote: > > On 7/30/20 4:19 PM, Hohensee, Paul wrote: > > I took a look at the webrev. Doesn't seem that extensive (or risky) to me. > > > > Summary of changes: 69 lines changed: 40 ins; 0 del; 29 mod; 31448 unchg. > > > > If we don't do it, besides making future backports a bit more difficult, we'll have a (admittedly subtle) behavioral difference with Oracle, which in this case doesn?t seem justified to me. > > Mmm, OK, that's a way of looking at it. I guess that is enough to > swing behind acceptance of this patch. It's good. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From hohensee at amazon.com Mon Aug 3 15:53:41 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 3 Aug 2020 15:53:41 +0000 Subject: RFO (Request for Opinion): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument Message-ID: I?d like to get Maintainer guidance on whether this patch can be backported. Issue: https://bugs.openjdk.java.net/browse/JDK-8185003 CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 The patch has proven very useful in reducing profile overhead within Amazon, so we?d like to upstream it. The problem is that while the patch is purely additive (adds a new variant of dumpAllThreads for to java.lang.management.ThreadsMXBean), the j.l.m.ThreadMXBean interface is common to all JDK implementations, which strictly speaking means that all JDK implementations must implement it. In contrast, com.sun.management.ThreadMXBean, is ?implementation specific?, so there?s no issue with strict additions to it. In mitigation, the default implementation is to throw an UnsupportedOperationException. The patched JDK passes the TCK. In addition to its standalone utility, the patch increments JMM_VERSION to JDK 10. JMM_VERSION is further updated to JDK 14 by JDK-8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread JDK-8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes These two patches have been backported to 11.0.9 and I?d like to backport them to 8u272 as well. The 11.0.9 backport had no problem because there were no updates to JMM_VERSION between 11 and 13 inclusive. I don?t believe 8231209/8231968 can be backported without backporting 8185003 first, because doing that seems to me to require creation of a new value of JMM_VERSION, because the result wouldn?t include the new dumpAllThreads method from 8185003. Code that queries JMM_VERSION might/would have to be changed to account for the new version, which is more of a compatibility issue than would be backporting 8185003 first. Hence this RFO. Thanks, Paul From alexey at azul.com Mon Aug 3 16:36:17 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 3 Aug 2020 16:36:17 +0000 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> Message-ID: <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> Hello Martin, Thank you for review. Please find my comments below. > On 30 Jul 2020, at 00:12, Martin Balao wrote: > > On 5/24/20 2:21 PM, Alexey Bakhtin wrote: >> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u > > Hi Alexey, > > Thanks for proposing a patch for Step 10 - 8245653. A few comments below. > > Files that we might want to delete because they were modified in JDK-11 > (11.0.7): Yes, you are right. Some of the test below should be also removed in this step . These test passed with both TLSv1.2 and TLSv1.3 implementations but was updated for TLSv1.3. Please see detailed comments for every test below: > > * test/sun/security/ssl > * CertPathRestrictions > * JSSEServer.java > * TLSRestrictions.java Yes, these tests are changed, so should be removed in this step > * ClientHandshaker > * RSAExport.java Copyright date changed only, no reason to remove/update > * DHKeyExchange > * LegacyDHEKeyExchange.java Fixed misprint, but ok remove/update > * GenSSLConfigs > * main.java Yes, removed > * HandshakeHash > * MyProvider.java Test updated for new Provider API, no reason to update for JDK11 > * HandshakeOutStream > * NullCerts.java Changes in the comment only. No reason to remove/update > * InputRecord > * ClientHelloRead.java Changes not required for JDK8 (@modules annotation) > * SSLSocketTimeoutNulls.java Yes, this test should be removed/updated. > * ProtocolVersion > * HttpsProtocols.java Copyright updated without test changes - no reason to remove/update > * SSLContextImpl > * CustomizedCipherSuites.java No changes in the test - no reason to remove/update > * SSLEngineImpl > * DelegatedTaskWrongException.java Copyright updated without test changes - no reason to remove/update > * SSLSocketImpl > * CheckMethods.java > * NonAutoClose.java > * SSLSocketImplThrowsWrongExceptions.java Yes, these test should be updated. Removed in this step > * SetClientMode.java This test marked @ignore in JDK11 but passed in JDK8 with new TLSv1.3 impleentation. No reason to remove > * ServerHandshaker > * AnonCipherWithWantClientAuth.java Yes, this test should be updated. Removed in this step > * GetPeerHostClient.java No functional changes in the test (removed unused import). I think no reason to remove/udate it > * GetPeerHostServer.java No changes in the test > * SocketCreation > * SocketCreation.java Yes, this test should be updated. Removed in this step > * X509TrustManagerImpl > * Symantec > * Distrust.java Yes, this test should be updated. Removed in this step > * CheckNullEntity.java Changes not required for JDK8 (@modules annotation). No reason to remove/update > * rsa > * SignatureOffsets.java > * SignedObjectChain.java Changes not required for JDK8.No reason to remove/update > * test/com/sun/net/ssl > * SSLSecurity > * ProviderTest.java > * TruncateArray.java Changes not required for JDK8 (@modules annotation). No reason to remove/update > * test/javax/net/ssl > * ALPN > * MyX509ExtendedKeyManager.java > * SSLServerSocketAlpnTest.java > * SSLSocketAlpnTest.java Changed copyrigth only, no reason to remove tests > * SSLParameters > * UseCipherSuitesOrder.java Changed copyrigth only, no reason to remove tests > * SSLSession > * CheckMyTrustedKeystore.java Changes not required for JDK8 (@modules annotation). No reason to remove/update > * ServerName > * SSLEngineExplorer.java > * SSLSocketExplorer.java Changed copyrigth only, no reason to remove tests > * TLSv11 > * EmptyCertificateAuthorities.java > * GenericBlockCipher.java > * GenericStreamCipher.java Changes not required for JDK8 (@modules annotation). No reason to remove/update > * TLSv12 > * ShortRSAKeyGCM.java > * SignatureAlgorithms.java Yes, this test could be updated. Removed in this step > * ciphersuites > * DisabledAlgorithms.java No functional changes in the test. No reason to remove/update > * etc > * keystore > * truststore Yes, these files should be removed in this step. > * sanity > * pluggability > * CheckSSLContextExport.java No changes required for JDK8 (uses new provider API) > * templates > * SSLExplorer.java No functional changes in the test (removed unused import) No reason to remove/update > * GetInstance.java Changes not required for JDK8 (@modules annotation). No reason to remove/update > * test/sun/net/www/protocol/https > * HttpsClient > * ProxyAuthTest.java > * ServerIdentityTest.java Yes, these tests should be removed in this step. > * HttpsURLConnection > * B6216082.java Yes, this test should be removed in this step. > * B6226610.java > * CheckMethods.java Changes not required for JDK8 (@modules annotation). No reason to remove/update > * DNSIdentities.java No functional changes in the test (removed unused import) No reason to remove/update > * HttpsCreateSockTest.java > * HttpsSocketFacTest.java Changes not required for JDK8 (@modules annotation). No reason to remove/update > * IPAddressDNSIdentities.java > * IPAddressIPIdentities.java > * IPIdentities.java > * Identities.java No functional changes in the test (removed unused import) No reason to remove/update > * PostThruProxy.java > * PostThruProxyWithAuth.java Changes not required for JDK 8. No reason to remove/update > * RetryHttps.java No functional changes in the test (enabled debug output) No reason to remove/update > * NewImpl > * ComHTTPSConnection.java > * ComHostnameVerified.java Yes, these tests should be removed in this step. > * ChunkedOutputStream.java Changes not required for JDK8 (@modules annotation). No reason to remove/update > > If there is a reason not to delete them, please let me know. > I have updated patch at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v1/ Regards Alexey From gnu.andrew at redhat.com Mon Aug 3 17:26:15 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 3 Aug 2020 18:26:15 +0100 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call In-Reply-To: <16ac9ba2-e0d8-4e23-8157-67c1a787da64@redhat.com> References: <16ac9ba2-e0d8-4e23-8157-67c1a787da64@redhat.com> Message-ID: <20200803172615.GB263856@stopbrexit> On 09:29 Fri 31 Jul , Andrew Haley wrote: > On 7/30/20 4:19 PM, Hohensee, Paul wrote: > > I took a look at the webrev. Doesn't seem that extensive (or risky) to me. > > > > Summary of changes: 69 lines changed: 40 ins; 0 del; 29 mod; 31448 unchg. > > > > If we don't do it, besides making future backports a bit more difficult, we'll have a (admittedly subtle) behavioral difference with Oracle, which in this case doesn?t seem justified to me. > > Mmm, OK, that's a way of looking at it. I guess that is enough to > swing behind acceptance of this patch. It's good. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > If this is going to now be included, it needs to also fix the cases where we worked around its absence. Does this proposed patch do so? Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Mon Aug 3 22:12:49 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 3 Aug 2020 23:12:49 +0100 Subject: OpenJDK 8u272-b01 EA Released Message-ID: <20200803221249.GC263856@stopbrexit> I've made available an early access source bundle for 8u272, based on the tag jdk8u272-b01: https://openjdk-sources.osci.io/openjdk8/openjdk8u272-b01-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u272-b01-ea.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint =3D CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 4032c7ef0220d2bf0efccbca4ebe53f687f5c1e6c6456ceed01051d8f81da189 openjdk8u272-b01-ea.tar.xz 375ba6b9e4519c3df594c4d3a569de1a1ad7eeb17a510860e92a0db170cf7f5b openjdk8u272-b01-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u272-b01-ea.sha256 Changes in 8u272-b01: - JDK-8006205: [TESTBUG] NEED_TEST: please JTREGIFY test/compiler/7177917/Test7177917.java - JDK-8031625: javadoc problems referencing inner class constructors - JDK-8035493: JVMTI PopFrame capability must instruct compilers not to prune locals - JDK-8036088: Replace strtok() with its safe equivalent strtok_s() in DefaultProxySelector.c - JDK-8039082: [TEST_BUG] Test java/awt/dnd/BadSerializationTest/BadSerializationTest.java fails - JDK-8075774: Small readability and performance improvements for zipfs - JDK-8132206: move ScanTest.java into OpenJDK - JDK-8132376: Add @requires os.family to the client tests with access to internal OS-specific API - JDK-8132745: minor cleanup of java/util/Scanner/ScanTest.java - JDK-8137087: [TEST_BUG] Cygwin failure of java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh - JDK-8145808: java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java hangs on Win. 8 - JDK-8151788: NullPointerException from ntlm.Client.type3 - JDK-8151834: Test SmallPrimeExponentP.java times out intermittently - JDK-8153430: jdk regression test MletParserLocaleTest, ParserInfiniteLoopTest reduce default timeout - JDK-8153583: Make OutputAnalyzer.reportDiagnosticSummary public - JDK-8156169: Some sound tests rarely hangs because of incorrect synchronization - JDK-8165936: Potential Heap buffer overflow when seaching timezone info files - JDK-8166148: Fix for JDK-8165936 broke solaris builds - JDK-8167300: Scheduling failures during gcm should be fatal - JDK-8167615: Opensource unit/regression tests for JavaSound - JDK-8172012: [TEST_BUG] delays needed in javax/swing/JTree/4633594/bug4633594.java - JDK-8177628: Opensource unit/regression tests for ImageIO - JDK-8183341: Better cleanup for javax/imageio/AllowSearch.java - JDK-8183351: Better cleanup for jdk/test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh - JDK-8193137: Nashorn crashes when given an empty script file - JDK-8194298: Add support for per Socket configuration of TCP keepalive - JDK-8198004: javax/swing/JFileChooser/6868611/bug6868611.java throws error - JDK-8200313: java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails - JDK-8210147: adjust some WSAGetLastError usages in windows network coding - JDK-8211714: Need to update vm_version.cpp to recognise VS2017 minor versions - JDK-8214862: assert(proj != __null) at compile.cpp:3251 - JDK-8217606: LdapContext#reconnect always opens a new connection - JDK-8217647: JFR: recordings on 32-bit systems unreadable - JDK-8226697: Several tests which need the @key headful keyword are missing it. - JDK-8229378: jdwp library loader in linker_md.c quietly truncates on buffer overflow - JDK-8230303: JDB hangs when running monitor command - JDK-8230711: ConnectionGraph::unique_java_object(Node* N) return NULL if n is not in the CG - JDK-8234617: C1: Incorrect result of field load due to missing narrowing conversion - JDK-8235243: handle VS2017 15.9 and VS2019 in abstract_vm_version - JDK-8235325: build failure on Linux after 8235243 - JDK-8235687: Contents/MacOS/libjli.dylib cannot be a symlink - JDK-8237951: CTW: C2 compilation fails with "malformed control flow" - JDK-8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary - JDK-8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD - JDK-8239819: XToolkit: Misread of screen information memory - JDK-8240295: hs_err elapsed time in seconds is not accurate enough - JDK-8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one - JDK-8242498: Invalid "sun.awt.TimedWindowEvent" object leads to JVM crash - JDK-8243489: Thread CPU Load event may contain wrong data for CPU time under certain conditions - JDK-8244818: Java2D Queue Flusher crash while moving application window to external monitor - JDK-8246310: Clean commented-out code about ModuleEntry andPackageEntry in JFR - JDK-8246384: Enable JFR by default on supported architectures for October 2020 release - JDK-8248643: Remove extra leading space in JDK-8240295 8u backport - JDK-8249610: Make sun.security.krb5.Config.getBooleanObject(String... keys) method public -- Andrew :) Senior 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 From sgehwolf at redhat.com Tue Aug 4 11:06:00 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 04 Aug 2020 13:06:00 +0200 Subject: [8u] RFR Backport 8238380: java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10 In-Reply-To: <1f164f02-f4ae-198d-c2d2-78b1c5249c31@loongson.cn> References: <1f164f02-f4ae-198d-c2d2-78b1c5249c31@loongson.cn> Message-ID: <00c2ba9ca58ae4b92aa959b029d68bc63a8ec67a.camel@redhat.com> On Fri, 2020-07-24 at 00:24 +0800, Leslie Zhai wrote: > Hi, > > I would like to backport the fix for: > > https://bugs.openjdk.java.net/browse/JDK-8238380 > > To OpenJDK 8 updates dev: > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev > > The fix is mostly the same as the version that was committed in 15. > > Webrev: http://cr.openjdk.java.net/~lzhai/8238380-8u/ This looks good to me. Thanks, Severin From zhaixiang at loongson.cn Tue Aug 4 11:15:54 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Tue, 4 Aug 2020 19:15:54 +0800 Subject: [8u] RFR Backport 8238380: java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10 In-Reply-To: <00c2ba9ca58ae4b92aa959b029d68bc63a8ec67a.camel@redhat.com> References: <1f164f02-f4ae-198d-c2d2-78b1c5249c31@loongson.cn> <00c2ba9ca58ae4b92aa959b029d68bc63a8ec67a.camel@redhat.com> Message-ID: <8daca67b-5a44-d052-cacf-acb606dd4c42@loongson.cn> Hi Severin, Thanks for your review! Could you sponsor it? Thanks, Leslie Zhai ? 2020?08?04? 19:06, Severin Gehwolf ??: > On Fri, 2020-07-24 at 00:24 +0800, Leslie Zhai wrote: >> Hi, >> >> I would like to backport the fix for: >> >> https://bugs.openjdk.java.net/browse/JDK-8238380 >> >> To OpenJDK 8 updates dev: >> >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev >> >> The fix is mostly the same as the version that was committed in 15. >> >> Webrev: http://cr.openjdk.java.net/~lzhai/8238380-8u/ > This looks good to me. > > Thanks, > Severin From sgehwolf at redhat.com Tue Aug 4 11:20:26 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 04 Aug 2020 13:20:26 +0200 Subject: [8u] RFR Backport 8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10 In-Reply-To: <33046d7d-4862-e1c3-ca5a-477faecdd1d9@loongson.cn> References: <33046d7d-4862-e1c3-ca5a-477faecdd1d9@loongson.cn> Message-ID: <9d822cfd30c266aad8577f93ecec0bf22bde2b9f.camel@redhat.com> On Fri, 2020-07-24 at 00:24 +0800, Leslie Zhai wrote: > Webrev: http://cr.openjdk.java.net/~lzhai/8238386-8u/ src/solaris/native/sun/nio/ch/sctp/Sctp.c This doesn't seem right. Those changes should go into src/solaris/native/sun/nio/ch/sctp/SctpNet.c should they not? Thanks, Severin From sgehwolf at redhat.com Tue Aug 4 11:32:01 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 04 Aug 2020 13:32:01 +0200 Subject: [8u] RFR Backport 8238380: java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10 In-Reply-To: <8daca67b-5a44-d052-cacf-acb606dd4c42@loongson.cn> References: <1f164f02-f4ae-198d-c2d2-78b1c5249c31@loongson.cn> <00c2ba9ca58ae4b92aa959b029d68bc63a8ec67a.camel@redhat.com> <8daca67b-5a44-d052-cacf-acb606dd4c42@loongson.cn> Message-ID: <4037406e0d8b70a562c8c1982734ba443553f451.camel@redhat.com> On Tue, 2020-08-04 at 19:15 +0800, Leslie Zhai wrote: > Hi Severin, > > Thanks for your review! > > Could you sponsor it? Sure. I'll get it pushed for you. Thanks, Severin From zhaixiang at loongson.cn Tue Aug 4 11:41:15 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Tue, 4 Aug 2020 19:41:15 +0800 Subject: [8u] RFR Backport 8238380: java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10 In-Reply-To: <4037406e0d8b70a562c8c1982734ba443553f451.camel@redhat.com> References: <1f164f02-f4ae-198d-c2d2-78b1c5249c31@loongson.cn> <00c2ba9ca58ae4b92aa959b029d68bc63a8ec67a.camel@redhat.com> <8daca67b-5a44-d052-cacf-acb606dd4c42@loongson.cn> <4037406e0d8b70a562c8c1982734ba443553f451.camel@redhat.com> Message-ID: ? 2020?08?04? 19:32, Severin Gehwolf ??: > On Tue, 2020-08-04 at 19:15 +0800, Leslie Zhai wrote: >> Hi Severin, >> >> Thanks for your review! >> >> Could you sponsor it? > Sure. I'll get it pushed for you. Thank you so much! Cheers, Leslie Zhai > > Thanks, > Severin From zhaixiang at loongson.cn Tue Aug 4 11:45:24 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Tue, 4 Aug 2020 19:45:24 +0800 Subject: [8u] RFR Backport 8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10 In-Reply-To: <9d822cfd30c266aad8577f93ecec0bf22bde2b9f.camel@redhat.com> References: <33046d7d-4862-e1c3-ca5a-477faecdd1d9@loongson.cn> <9d822cfd30c266aad8577f93ecec0bf22bde2b9f.camel@redhat.com> Message-ID: <9becdef0-2731-d9be-3d8c-ee29e7533b25@loongson.cn> ? 2020?08?04? 19:20, Severin Gehwolf ??: > On Fri, 2020-07-24 at 00:24 +0800, Leslie Zhai wrote: >> Webrev: http://cr.openjdk.java.net/~lzhai/8238386-8u/ > > src/solaris/native/sun/nio/ch/sctp/Sctp.c > > This doesn't seem right. Those changes should go > into src/solaris/native/sun/nio/ch/sctp/SctpNet.c should they not? Thanks for your review! You are right! https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/39020dd9b75f I will update my patch when I gotta home. Thanks, Leslie Zhai > > Thanks, > Severin From sgehwolf at redhat.com Tue Aug 4 11:57:16 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 04 Aug 2020 13:57:16 +0200 Subject: [8u] RFR Backport 8238388: libj2gss/NativeFunc.o "multiple definition" link errors with GCC10 In-Reply-To: References: Message-ID: <7c4cb8e1358d52c11365ff9c846ca63c451a6f84.camel@redhat.com> On Fri, 2020-07-24 at 00:24 +0800, Leslie Zhai wrote: > Webrev: http://cr.openjdk.java.net/~lzhai/8238388-8u/ Looks good to me. Thanks, Severin From zhaixiang at loongson.cn Tue Aug 4 12:06:49 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Tue, 4 Aug 2020 20:06:49 +0800 Subject: [8u] RFR Backport 8238388: libj2gss/NativeFunc.o "multiple definition" link errors with GCC10 In-Reply-To: <7c4cb8e1358d52c11365ff9c846ca63c451a6f84.camel@redhat.com> References: <7c4cb8e1358d52c11365ff9c846ca63c451a6f84.camel@redhat.com> Message-ID: <75a17b42-4546-8dcb-9a07-b84312adc25b@loongson.cn> ? 2020?08?04? 19:57, Severin Gehwolf ??: > On Fri, 2020-07-24 at 00:24 +0800, Leslie Zhai wrote: >> Webrev: http://cr.openjdk.java.net/~lzhai/8238388-8u/ > Looks good to me. Thank you so much! Please sponsor it! Cheers, Leslie Zhai > > Thanks, > Severin From katya at azul.com Tue Aug 4 13:35:33 2020 From: katya at azul.com (Ekaterina Vergizova) Date: Tue, 4 Aug 2020 13:35:33 +0000 Subject: [8u] RFR: 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero Message-ID: <0b1f4453893c4bb6a78a196189f34cbd@azul.com> Hello, I would like to backport JFR issue 8219566 to 8u. JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/cb8e16d6ff1e Webrev for 8u: https://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/8219566/webrev.00/ The patch applies almost cleanly except for the second hunk of jfrOptionSet.cpp. It doesn't apply due to different context (different #include list in 8u), reapplied manually. Tested with tier1 and jdk.jfr tests on Linux and Windows. Manually tested with -XX:MaxJavaStackTraceDepth=0 option, java call stacks are collected successfully after the fix. Thanks, Ekaterina From zhaixiang at loongson.cn Tue Aug 4 14:01:10 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Tue, 4 Aug 2020 22:01:10 +0800 Subject: [8u] RFR Backport 8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10 In-Reply-To: <9becdef0-2731-d9be-3d8c-ee29e7533b25@loongson.cn> References: <33046d7d-4862-e1c3-ca5a-477faecdd1d9@loongson.cn> <9d822cfd30c266aad8577f93ecec0bf22bde2b9f.camel@redhat.com> <9becdef0-2731-d9be-3d8c-ee29e7533b25@loongson.cn> Message-ID: Hi Severin, Please review again my update patch: http://cr.openjdk.java.net/~lzhai/8238386-8u/webrev.01/ Thanks, Leslie Zhai ? 8/4/20 7:45 PM, Leslie Zhai ??: > > > ? 2020?08?04? 19:20, Severin Gehwolf ??: >> On Fri, 2020-07-24 at 00:24 +0800, Leslie Zhai wrote: >>> Webrev: http://cr.openjdk.java.net/~lzhai/8238386-8u/ >> >> src/solaris/native/sun/nio/ch/sctp/Sctp.c >> >> This doesn't seem right. Those changes should go >> into src/solaris/native/sun/nio/ch/sctp/SctpNet.c should they not? > Thanks for your review! > You are right! > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/39020dd9b75f > I will update my patch when I gotta home. > Thanks, > Leslie Zhai > >> >> Thanks, >> Severin From neugens at redhat.com Tue Aug 4 14:33:07 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 4 Aug 2020 16:33:07 +0200 Subject: [8u] RFR: 8220657: JFR.dump does not work when filename is set In-Reply-To: <22410d48fbe44f3db5b82ee9fc47aa39@azul.com> References: <22410d48fbe44f3db5b82ee9fc47aa39@azul.com> Message-ID: Hi Ekaterina, Thanks for the fix, the patch is ok. CC'ing Severin for maintainer approval. Cheers, Mario On Thu, Jul 30, 2020 at 10:05 PM Ekaterina Vergizova wrote: > > Hello, > I would like to backport JFR issue 8220657 to 8u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220657 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/bd613b97c7c8 > Webrev for 8u: https://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/8220657/webrev.00/ > > The patch applies cleanly, but the added test TestJcmdDumpWithFileName.java requires some adjustments to pass under 8u: > - the test tags are adjusted > - ProcessHandle.current().pid() calls replaced by ProcessTools.getProcessId() > - Path.of() calls replaced by their 8u analogue Paths.get() > - unsupported syntax `try (stream)` replaced by standard try-with-resources > > Tested with tier1 and jdk.jfr tests on Linux and Windows, the added test TestJcmdDumpWithFileName.java failed before the fix and passes after. > > Thanks, > Ekaterina > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sgehwolf at redhat.com Tue Aug 4 15:49:56 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 04 Aug 2020 17:49:56 +0200 Subject: [8u] RFR: 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics Message-ID: Hi, Please review this OpenJDK 8u backport of a change to be able to disable Java container metrics with -XX:-UseContainerSupport. The JDK 11 change doesn't apply cleanly since JDK 8u splits things across repositories. This is a change to the hotspot and jdk repos. Furthermore, some added build make file changes are needed to get the natives properly built. By-and-large, the change is very similar to JDK 11's version. As with the JDK 11 and jdk/jdk change, this is a Linux- only patch and shouldn't affect other platforms. This patch depends on JDK-8203357, which is currently on review. Bug: https://bugs.openjdk.java.net/browse/JDK-8250627 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/jdk8/01/ JDK 11 change: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/a75956082916 Testing: container testing on Linux x86_64 (including the new test). tier1 no new regressions. Thoughts? Thanks, Severin From sgehwolf at redhat.com Tue Aug 4 16:03:55 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 04 Aug 2020 18:03:55 +0200 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <1e60b154-8c09-91d2-65c7-c4f283b0f407@azul.com> <4a70d3bc9d62883d9a83f0f892ea82bacd571a6c.camel@redhat.com> Message-ID: <3bdc90516ff5f91cb0cb63cbbc5e33dfee662b3f.camel@redhat.com> Hi Andrey, On Mon, 2020-07-20 at 20:48 +0300, Andrey Petushkov wrote: > Hi Severin, > > > On 20.07.2020 14:47, Severin Gehwolf wrote: > > Hi Andrey, > > > > On Fri, 2020-07-17 at 21:44 +0300, Andrey Petushkov wrote: > > > Hi Severin, > > > > > > The code being backported seem to have a bug and will result in a > > > regression if > > > being integrated. > > OK. Do you have any experience on a ballpark number as to how many > > systems this would affect? Is this a common config? > We have seen relevant tests fail only on one type of system. So it might be > rare enough. Let me check whether other systems have all or nothing > cgroups fs > or there are more like that just happened not to have respective test to > fail > > > The problem is that, to my understanding it's legal that only some of known > > > controllers are mounted (at least man says they can be mounted > > > individually). > > > This creates a situation that Metrics gets "active" and populated with > > > some of > > > SubSystems, but not all. As a result OperatingSystemImpl considers > > > containerMetrics > > > available and uses it as a source. The SubSystem code is written the way > > > that it > > > returns 0 for any value if a respective subsystem is missing. At the > > > same time > > > OperatingSystemImpl typically uses >=0 as a sanity check of a value > > > returned from Metrics. > > > Effectively preventing from falling back to native implementation for > > > the actual value > > > and returning 0 instead of actual value > > > > > > The problem actually exhibited by GetTotalPhysicalMemorySize test ran on > > > Raspbian Stretch > > > which happen to have cgroup fs but not /sys/fs/cgroup/memory > > Thanks for the heads-up. A couple of questions: > > > > * Note that this has changed in JDK 15 where unavailable files should > > return -1 (over 0) in case of missing crgoup files. Have you tested > > JDK 15 by any chance? > No, not yet. Let me try > > * Do you see this behaviour in a container or also outside? > The behavior was observed _only_ outside of container. However I believe > we don't run these tests inside a container on RPi. That would be > interesting > to try, let me see OK. So this might be another case of where the container auto-detection gets it wrong. The JDK thinks it's containerized, while it actually isn't. For real cases where this might happen the suggested work-around is to use -XX:-UseContainerSupport. The patch to disable Java metrics using this switch is beeing proposed here: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012334.html The intention is to integrate it together with the OperatingSystemMXBean container awareness patch for 8u. > > > That's not the problem of a backport and of course should be discussed > > > with upstream > > > developers. It just happened that we've found it with a backport so > > > letting you know > > Yes, agreed. It seems an issue with the cgroups Metrics infra in older > > JDKs. Do you mind creating a bug for this issue? > Sure. Let me see the state of JDK15 wrt this issue before filing a bug Any news on the jdk/jdk front? I'm guessing the container test don't run there as they have '@requires docker-support'? Thanks, Severin > > > Regards, > > > Andrey > > > > > > On 17.07.2020 17:07, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Please review this OpenJDK 8u backport for OperatingSystemMXBean's > > > > container awareness which has been backported to Oracle JDK (parity > > > > bug). This backport depends on JDK-8203357[1] for Metrics.java which is > > > > being used in this patch. > > > > > > > > Changes as compared to the JDK 11 patch were: > > > > > > > > * SubSystem.java: 8217338: [Containers] Improve systemd slice memory > > > > limit support not being there => getLongValueMatchingLine() missing > > > > => dropped > > > > * OperatingSystemImpl.java: Introduced Java methods which internally > > > > call the native methods. Renamed native methods to 0 > > > > * Tests were actually done to the hotspot code in later JDKs, thus, > > > > for this backport the tests are in the hotspot portion of the webrev > > > > (separate repo). > > > > * Other than that, it's just the native bits which are in different > > > > files in JDK 8. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226575 > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/01/ > > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8248804 > > > > > > > > Testing: Included docker tests on Linux x86_64. jdk_management tests and > > > > tier 1 tests. No regressions noted. > > > > > > > > If somebody could test this on Windows/Mac, I'd appreciate it. > > > > > > > > Thanks, > > > > Severin > > > > > > > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012164.html > > From neugens at redhat.com Tue Aug 4 16:05:00 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 4 Aug 2020 18:05:00 +0200 Subject: [8u] RFR: 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero In-Reply-To: <0b1f4453893c4bb6a78a196189f34cbd@azul.com> References: <0b1f4453893c4bb6a78a196189f34cbd@azul.com> Message-ID: Hi Ekaterina, Thanks, the fix is good! Cheers, Mario On Tue, Aug 4, 2020 at 3:36 PM Ekaterina Vergizova wrote: > > Hello, > I would like to backport JFR issue 8219566 to 8u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/cb8e16d6ff1e > Webrev for 8u: https://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/8219566/webrev.00/ > > The patch applies almost cleanly except for the second hunk of jfrOptionSet.cpp. > It doesn't apply due to different context (different #include list in 8u), reapplied manually. > > Tested with tier1 and jdk.jfr tests on Linux and Windows. > Manually tested with -XX:MaxJavaStackTraceDepth=0 option, java call stacks are collected successfully after the fix. > > Thanks, > Ekaterina > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Tue Aug 4 16:21:25 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Aug 2020 18:21:25 +0200 Subject: [8u] RFR: 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics In-Reply-To: References: Message-ID: <4e32a070-0307-b081-1847-a5102ae7b99b@redhat.com> On 8/4/20 5:49 PM, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8250627 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/jdk8/01/ > JDK 11 change: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/a75956082916 Substantially, I think the patch is fine. But, I do wonder if the new classes should be in sun.misc.*, not in jdk.internal.*. One of the reasons to use sun.misc.* is to get the proper javac warning on use. jdk.internal is something that is protected by module boundaries in JDK 9+, not available in 8u. -- Thanks, -Aleksey From mbalao at redhat.com Tue Aug 4 17:07:26 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 4 Aug 2020 14:07:26 -0300 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> Message-ID: <6210a318-6d57-de05-1d0f-20eed83eb6f0@redhat.com> Hi Alexey, Thanks for taking the time to thoroughly go through each file! When I first elaborated the list, just sampled a couple of files and was not going to finish it before asking. Then I decided that it might be useful. Comments below. Thanks, Martin.- -- On 8/3/20 1:36 PM, Alexey Bakhtin wrote: >> * ClientHandshaker >> * RSAExport.java > Copyright date changed only, no reason to remove/update Ok >> * GenSSLConfigs >> * main.java > Yes, removed Could not verify this removal. Missing? >> * HandshakeHash >> * MyProvider.java > Test updated for new Provider API, no reason to update for JDK11 Ok. >> * HandshakeOutStream >> * NullCerts.java > Changes in the comment only. No reason to remove/update Can we still delete that commented line in this step? Thanks >> * InputRecord >> * ClientHelloRead.java > Changes not required for JDK8 (@modules annotation) Ok. >> * ProtocolVersion >> * HttpsProtocols.java > Copyright updated without test changes - no reason to remove/update Ok. >> * SSLContextImpl >> * CustomizedCipherSuites.java > No changes in the test - no reason to remove/update The reference to 8208350 was removed. I did not find any reference to DES algorithms. I suggest to remove it in this step. >> * SSLEngineImpl >> * DelegatedTaskWrongException.java > Copyright updated without test changes - no reason to remove/update Ok. >> * SSLSocketImpl >> * SetClientMode.java > This test marked @ignore in JDK11 but passed in JDK8 with new TLSv1.3 impleentation. No reason to remove Passing does not guarantee that the test works properly. Unless we analyze the reasons, I suggest to stick to JDK-11's judgement. >> * ServerHandshaker >> * GetPeerHostClient.java > No functional changes in the test (removed unused import). I think no reason to remove/udate it Even though it's a non-functional change, I'd either remove the import here or delete/add. >> * GetPeerHostServer.java > No changes in the test Ok. >> * X509TrustManagerImpl >> * CheckNullEntity.java > Changes not required for JDK8 (@modules annotation). No reason to remove/update Ok. >> * rsa >> * SignatureOffsets.java >> * SignedObjectChain.java > Changes not required for JDK8.No reason to remove/update Ok, if they pass in Step 11 I have no objections. >> * test/com/sun/net/ssl >> * SSLSecurity >> * ProviderTest.java >> * TruncateArray.java > Changes not required for JDK8 (@modules annotation). No reason to remove/update Ok. And the reference to '8130181' is something we don't even want. >> * test/javax/net/ssl >> * ALPN >> * MyX509ExtendedKeyManager.java >> * SSLServerSocketAlpnTest.java >> * SSLSocketAlpnTest.java > Changed copyrigth only, no reason to remove tests Ok. >> * SSLParameters >> * UseCipherSuitesOrder.java > Changed copyrigth only, no reason to remove tests Ok. >> * SSLSession >> * CheckMyTrustedKeystore.java > Changes not required for JDK8 (@modules annotation). No reason to remove/update Ok. >> * ServerName >> * SSLEngineExplorer.java >> * SSLSocketExplorer.java > Changed copyrigth only, no reason to remove tests Ok. >> * TLSv11 >> * EmptyCertificateAuthorities.java >> * GenericBlockCipher.java >> * GenericStreamCipher.java > Changes not required for JDK8 (@modules annotation). No reason to remove/update Ok. We have the imports but not a big deal really. >> * ciphersuites >> * DisabledAlgorithms.java > No functional changes in the test. No reason to remove/update The reference to 8157035 was removed. I suggest to consider this a relevant change for removal. >> * etc >> * keystore >> * truststore > Yes, these files should be removed in this step. Ok. I'm not seeing this in jdk.patch but that's because this is a change in binaries. I could read the 'Binary files...' message, though. >> * sanity >> * pluggability >> * CheckSSLContextExport.java > No changes required for JDK8 (uses new provider API) Ok, and we don't want the reference to 8130181. >> * templates >> * SSLExplorer.java > No functional changes in the test (removed unused import) No reason to remove/update Ok. >> * GetInstance.java > Changes not required for JDK8 (@modules annotation). No reason to remove/update Ok. >> * test/sun/net/www/protocol/https >> * HttpsURLConnection >> * B6226610.java >> * CheckMethods.java > Changes not required for JDK8 (@modules annotation). No reason to remove/update Ok. >> * DNSIdentities.java > No functional changes in the test (removed unused import) No reason to remove/update Ok. It still hurts to see an used import from an internal class. >> * HttpsCreateSockTest.java >> * HttpsSocketFacTest.java > Changes not required for JDK8 (@modules annotation). No reason to remove/update Ok. >> * IPAddressDNSIdentities.java >> * IPAddressIPIdentities.java >> * IPIdentities.java >> * Identities.java > No functional changes in the test (removed unused import) No reason to remove/update The unused import again. If you want to delete the import as part of this change -diverting a bit from the step spirit-, I'd be happy. Otherwise, okay. >> * PostThruProxy.java >> * PostThruProxyWithAuth.java > Changes not required for JDK 8. No reason to remove/update Ok. >> * RetryHttps.java > No functional changes in the test (enabled debug output) No reason to remove/update Ok. >> * NewImpl >> * ComHTTPSConnection.java >> * ComHostnameVerified.java > Yes, these tests should be removed in this step. Ok. >> * ChunkedOutputStream.java > Changes not required for JDK8 (@modules annotation). No reason to remove/update Ok. There are still a couple of thing I'd like you to have a look (from my previous email): Files that should be removed because they do not exist in JDK-11, were relocated or renamed: * test/sun/security/ssl * SSLContextImpl * DefautlCacheSize.java * Relocated to SSLSessionContextImpl (there might be file changes as well) SSL-related tests that are in JDK-8 but not in JDK-11: * test/sun/net/www/protocol/https * HttpsClient * OriginServer.java * test/sun/security/ssl * SSLEngineImpl * CloseInboundException.java * SessionIdCollisionTest.java Are we sure that we want to keep them? From sgehwolf at redhat.com Tue Aug 4 18:56:51 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 04 Aug 2020 20:56:51 +0200 Subject: [8u] RFR: 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics In-Reply-To: <4e32a070-0307-b081-1847-a5102ae7b99b@redhat.com> References: <4e32a070-0307-b081-1847-a5102ae7b99b@redhat.com> Message-ID: <15bece18a65b6f36ea7c5adee3944ea1ce813722.camel@redhat.com> On Tue, 2020-08-04 at 18:21 +0200, Aleksey Shipilev wrote: > On 8/4/20 5:49 PM, Severin Gehwolf wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8250627 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/jdk8/01/ > > JDK 11 change: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/a75956082916 > > Substantially, I think the patch is fine. Thanks for the review! > But, I do wonder if the new classes should be in sun.misc.*, not in jdk.internal.*. One of the > reasons to use sun.misc.* is to get the proper javac warning on use. jdk.internal is something that > is protected by module boundaries in JDK 9+, not available in 8u. That's a good point. However, we should discuss this in context of JDK- 8203357 which actually introduces the Java metrics classes. This patch, then should follow suite. With that being said, I'm not sure diverging from later JDKs for that reason is warranted. Another data point is JFR java classes which also seem to partially under jdk.jfr.internal in JDK 8u. Just like JDK 11u. Thanks, Severin From sgehwolf at redhat.com Tue Aug 4 19:09:33 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 04 Aug 2020 21:09:33 +0200 Subject: [8u] RFR Backport 8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10 In-Reply-To: References: <33046d7d-4862-e1c3-ca5a-477faecdd1d9@loongson.cn> <9d822cfd30c266aad8577f93ecec0bf22bde2b9f.camel@redhat.com> <9becdef0-2731-d9be-3d8c-ee29e7533b25@loongson.cn> Message-ID: <43b11ba1697020d7b5f50491bce57b4edbdd05d9.camel@redhat.com> Hi, On Tue, 2020-08-04 at 22:01 +0800, Leslie Zhai wrote: > Hi Severin, > > Please review again my update patch: > http://cr.openjdk.java.net/~lzhai/8238386-8u/webrev.01/ Please update the copyright line in SctpNet.c as was done here (for some reason the JDK 11u backport dropped copyright lines): https://hg.openjdk.java.net/jdk/jdk/rev/8e6fa89397ca Thanks, Severin From andrey at azul.com Tue Aug 4 20:22:41 2020 From: andrey at azul.com (Andrey Petushkov) Date: Tue, 4 Aug 2020 23:22:41 +0300 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <3bdc90516ff5f91cb0cb63cbbc5e33dfee662b3f.camel@redhat.com> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <1e60b154-8c09-91d2-65c7-c4f283b0f407@azul.com> <4a70d3bc9d62883d9a83f0f892ea82bacd571a6c.camel@redhat.com> <3bdc90516ff5f91cb0cb63cbbc5e33dfee662b3f.camel@redhat.com> Message-ID: Hi Severin, beg your pardon for not answering promptly. I'm slowly progressing towards answering your questions, but unfortunately due to multiple reasons is very far from desired speed. Please see more inline On 04.08.2020 19:03, Severin Gehwolf wrote: > Hi Andrey, > > On Mon, 2020-07-20 at 20:48 +0300, Andrey Petushkov wrote: >> Hi Severin, >> >> >> On 20.07.2020 14:47, Severin Gehwolf wrote: >>> Hi Andrey, >>> >>> On Fri, 2020-07-17 at 21:44 +0300, Andrey Petushkov wrote: >>>> Hi Severin, >>>> >>>> The code being backported seem to have a bug and will result in a >>>> regression if >>>> being integrated. >>> OK. Do you have any experience on a ballpark number as to how many >>> systems this would affect? Is this a common config? >> We have seen relevant tests fail only on one type of system. So it might be >> rare enough. Let me check whether other systems have all or nothing >> cgroups fs >> or there are more like that just happened not to have respective test to >> fail There are no systems like that I have found. But found reports on the internet that some earlier versions on Ubuntu (on x86) have demonstrated similar behavior. There is in fact recipe how to fix that on the OS level (kernel boot parameter) but I did not verify that this works on raspbian stretch >>>> The problem is that, to my understanding it's legal that only some of known >>>> controllers are mounted (at least man says they can be mounted >>>> individually). >>>> This creates a situation that Metrics gets "active" and populated with >>>> some of >>>> SubSystems, but not all. As a result OperatingSystemImpl considers >>>> containerMetrics >>>> available and uses it as a source. The SubSystem code is written the way >>>> that it >>>> returns 0 for any value if a respective subsystem is missing. At the >>>> same time >>>> OperatingSystemImpl typically uses >=0 as a sanity check of a value >>>> returned from Metrics. >>>> Effectively preventing from falling back to native implementation for >>>> the actual value >>>> and returning 0 instead of actual value >>>> >>>> The problem actually exhibited by GetTotalPhysicalMemorySize test ran on >>>> Raspbian Stretch >>>> which happen to have cgroup fs but not /sys/fs/cgroup/memory >>> Thanks for the heads-up. A couple of questions: >>> >>> * Note that this has changed in JDK 15 where unavailable files should >>> return -1 (over 0) in case of missing crgoup files. Have you tested >>> JDK 15 by any chance? >> No, not yet. Let me try >>> * Do you see this behaviour in a container or also outside? >> The behavior was observed _only_ outside of container. However I believe >> we don't run these tests inside a container on RPi. That would be >> interesting >> to try, let me see I've checked that the same behavior exists inside a container been ran on this system. In fact docker warns that memory quotas are impossible to enforce (WARNING: No memory limit support) and does not change the view of the cgroupfs (which is likely something I should have expected) > OK. So this might be another case of where the container auto-detection > gets it wrong. The JDK thinks it's containerized, while it actually > isn't. For real cases where this might happen the suggested work-around > is to use -XX:-UseContainerSupport. The patch to disable Java metrics > using this switch is beeing proposed here: > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012334.html > > The intention is to integrate it together with the > OperatingSystemMXBean container awareness patch for 8u. Thank you, I've seen your proposal. In fact I'm bit concerned about the approach. Namely the idea to require the user to manually work-around the problem, while JRE is able to do that automatically. Indeed, the case where cgroupfs is incomplete/inconsistent to the extent I have observed could easily be understood and dealt with programmatically. > >>>> That's not the problem of a backport and of course should be discussed >>>> with upstream >>>> developers. It just happened that we've found it with a backport so >>>> letting you know >>> Yes, agreed. It seems an issue with the cgroups Metrics infra in older >>> JDKs. Do you mind creating a bug for this issue? >> Sure. Let me see the state of JDK15 wrt this issue before filing a bug > Any news on the jdk/jdk front? I'm guessing the container test don't > run there as they have '@requires docker-support'? Argh, that turned out to be very much complicated. I've tried to build jdk/jdk as well as jdk15 latest. jdk now requires modern gcc (due to -std=c++14) which is incompatible with target OS (libm.so/libc.so are too old) while jdk15 fails somewhere around monotonic clock support. I need some hacking to make it work. At the moment I cannot empirically verify how jdk/jdk behaves on this test. Will continue Regards, Andrey > > Thanks, > Severin > >>>> Regards, >>>> Andrey >>>> >>>> On 17.07.2020 17:07, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Please review this OpenJDK 8u backport for OperatingSystemMXBean's >>>>> container awareness which has been backported to Oracle JDK (parity >>>>> bug). This backport depends on JDK-8203357[1] for Metrics.java which is >>>>> being used in this patch. >>>>> >>>>> Changes as compared to the JDK 11 patch were: >>>>> >>>>> * SubSystem.java: 8217338: [Containers] Improve systemd slice memory >>>>> limit support not being there => getLongValueMatchingLine() missing >>>>> => dropped >>>>> * OperatingSystemImpl.java: Introduced Java methods which internally >>>>> call the native methods. Renamed native methods to 0 >>>>> * Tests were actually done to the hotspot code in later JDKs, thus, >>>>> for this backport the tests are in the hotspot portion of the webrev >>>>> (separate repo). >>>>> * Other than that, it's just the native bits which are in different >>>>> files in JDK 8. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8226575 >>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/01/ >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8248804 >>>>> >>>>> Testing: Included docker tests on Linux x86_64. jdk_management tests and >>>>> tier 1 tests. No regressions noted. >>>>> >>>>> If somebody could test this on Windows/Mac, I'd appreciate it. >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012164.html >> From zhaixiang at loongson.cn Wed Aug 5 04:56:16 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Wed, 5 Aug 2020 12:56:16 +0800 Subject: [8u] RFR Backport 8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10 In-Reply-To: <43b11ba1697020d7b5f50491bce57b4edbdd05d9.camel@redhat.com> References: <33046d7d-4862-e1c3-ca5a-477faecdd1d9@loongson.cn> <9d822cfd30c266aad8577f93ecec0bf22bde2b9f.camel@redhat.com> <9becdef0-2731-d9be-3d8c-ee29e7533b25@loongson.cn> <43b11ba1697020d7b5f50491bce57b4edbdd05d9.camel@redhat.com> Message-ID: <51f0ff13-c85d-a366-39d6-7026d0ae8f01@loongson.cn> ? 8/5/20 3:09 AM, Severin Gehwolf ??: > Hi, > > On Tue, 2020-08-04 at 22:01 +0800, Leslie Zhai wrote: >> Hi Severin, >> >> Please review again my update patch: >> http://cr.openjdk.java.net/~lzhai/8238386-8u/webrev.01/ > Please update the copyright line in SctpNet.c as was done > here (for some reason the JDK 11u backport dropped copyright > lines): > https://hg.openjdk.java.net/jdk/jdk/rev/8e6fa89397ca Thanks for your careful review! Update patch: http://cr.openjdk.java.net/~lzhai/8238386-8u/webrev.02/ Thanks, Leslie Zhai > > Thanks, > Severin From sgehwolf at redhat.com Wed Aug 5 08:15:40 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 5 Aug 2020 10:15:40 +0200 Subject: [8u] RFR Backport 8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10 In-Reply-To: <51f0ff13-c85d-a366-39d6-7026d0ae8f01@loongson.cn> References: <33046d7d-4862-e1c3-ca5a-477faecdd1d9@loongson.cn> <9d822cfd30c266aad8577f93ecec0bf22bde2b9f.camel@redhat.com> <9becdef0-2731-d9be-3d8c-ee29e7533b25@loongson.cn> <43b11ba1697020d7b5f50491bce57b4edbdd05d9.camel@redhat.com> <51f0ff13-c85d-a366-39d6-7026d0ae8f01@loongson.cn> Message-ID: On Wed, Aug 5, 2020 at 6:56 AM Leslie Zhai wrote: > Update patch: http://cr.openjdk.java.net/~lzhai/8238386-8u/webrev.02/ This looks OK now. Please add the fix request comment and the label. I'll sponsor all 3 patches. Thanks, Severin From zhaixiang at loongson.cn Wed Aug 5 08:51:58 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Wed, 5 Aug 2020 16:51:58 +0800 Subject: [8u] RFR Backport 8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10 In-Reply-To: References: <33046d7d-4862-e1c3-ca5a-477faecdd1d9@loongson.cn> <9d822cfd30c266aad8577f93ecec0bf22bde2b9f.camel@redhat.com> <9becdef0-2731-d9be-3d8c-ee29e7533b25@loongson.cn> <43b11ba1697020d7b5f50491bce57b4edbdd05d9.camel@redhat.com> <51f0ff13-c85d-a366-39d6-7026d0ae8f01@loongson.cn> Message-ID: <9621e072-fa8e-c9a3-6d0d-de4c149a972e@loongson.cn> ? 2020?08?05? 16:15, Severin Gehwolf ??: > On Wed, Aug 5, 2020 at 6:56 AM Leslie Zhai wrote: >> Update patch: http://cr.openjdk.java.net/~lzhai/8238386-8u/webrev.02/ > This looks OK now. Please add the fix request comment and the label. > I'll sponsor all 3 patches. Thank you so much! Added comments and labels. Cheers, Leslie Zhai > > Thanks, > Severin From 1983-01-06 at gmx.net Wed Aug 5 10:12:14 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Wed, 5 Aug 2020 12:12:14 +0200 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <03a72153-58ac-4c26-55a7-f09fa25c63d7@redhat.com> References: <03a72153-58ac-4c26-55a7-f09fa25c63d7@redhat.com> Message-ID: Hi Zhengyu, I am the originator of this bug report and requested the backport from 13 to 11 and 8 via Oracle Support. Unfortunately, I badly need it in OpenJDK too, Oracle JDK is useless for me. Can you go through the webrev and address the comments from Paul Hohensee? I tested this already for Oracle's custom build back then from the SR. I have all testing code in place to verify your patch for 8 and 11 in a huge corporate AD setup. Looking forward to a positive answer, Michael From neugens at redhat.com Wed Aug 5 10:24:23 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 5 Aug 2020 12:24:23 +0200 Subject: [8u] RFR: 8215727: Restore JFR thread sampler loop to old / previous behavior In-Reply-To: References: Message-ID: Hi Ekaterina, Sorry for the late reply, the patch looks good to me, I also didn't see any regressions. Cheers, Mario On Fri, Jul 24, 2020 at 9:43 AM Ekaterina Vergizova wrote: > > Hello, > I would like to backport JFR issue 8215727 to 8u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8215727 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/58154bf80f90 > Webrev for 8u: https://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/8215727/webrev.00/ > > The patch applies almost cleanly except for the third hunk of jfrThreadSampler.cpp. > It doesn't apply due to different context (iterating through java threads is different between 8u and 13), re-applied manually. > > Tested with tier1 and jdk.jfr tests on Linux and Windows, no regression. > > Thanks, > Ekaterina > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From zgu at redhat.com Wed Aug 5 13:48:51 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 5 Aug 2020 09:48:51 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <30EE84DA-76C1-4A33-95FA-18D57117E2E1@amazon.com> References: <30EE84DA-76C1-4A33-95FA-18D57117E2E1@amazon.com> Message-ID: <7fca0e0f-dbf3-bb94-0602-07b5455acd18@redhat.com> Hi Paul, Sorry for replying late. Somehow, this email slipped through the cracks, and thanks Michael for bringing it to my attention. On 7/13/20 5:27 PM, Hohensee, Paul wrote: > The webrev looks it's corrupted. E.g., it includes the changes from 8217606, and not the InitialDirContext.java and CheckConfigs.policy changes you mention. It had dependence on 8217606, now it is pushed, so that the webrev is much cleaner. Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.01/ Test: Reran jdk_other. Thanks, -Zhengyu > > Paul > > ?On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > Hi, > > I would like to backport this patch to 8u for parity with Oracle 8u261. > > The original patch does not apply cleanly. > > Other than a couple of minor conflicts: > > 1) Comments in InitialDirContext.java did not apply cleanly > 2) Unpatched CheckConfigs.policy files did not match > > I made following modification for 8u: > > 1) Removed module-info.java section, it does not apply to 8u. > 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs > (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the > code with ArrayList. > 3) Removed @modules annotation in LdapDnsProviderTest.java > > Additional, I need to modify langtools to get javac to take > com.sun.jndi.ldap.spi package and complain about it. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a > > 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.00/ > 8u langtools webrev: > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webev.00/ > > > Test: > jdk_other on Linux x86_64 > > Thanks, > > -Zhengyu > > > From zgu at redhat.com Wed Aug 5 15:19:52 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 5 Aug 2020 11:19:52 -0400 Subject: [8u] RFR: 8160974: [TESTBUG] Mark more headful tests with @key headful. In-Reply-To: <20200720134834.dftcto4z57gknnl7@qusp> References: <20200720134834.dftcto4z57gknnl7@qusp> Message-ID: <7ba68ece-595a-75f3-61f0-b3a9fe111c6c@redhat.com> Hi, On 7/20/20 9:48 AM, Jonathan Dowland wrote: > Hello, > > Please review this backport of JDK-8160974 to 8u, for parity with > Oracle 8u271. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160974 > jdk9 patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fe58d505fffd > > webrev: > https://jmtd.net/tmp/JDK-8160974/ Jonathan is not a author right now, so I host his webrev. Webrev: http://cr.openjdk.java.net/~zgu/jonathan_downland/JDK-8160974/ Thanks, -Zhengyu > > 228/596 hunks apply without modifications. 16 hunks required manual > rework. The remainder were for files not present in jdk8u. Those files > were: > https://jmtd.net/tmp/JDK-8160974/files_not_present_in_jdk8u.txt > > > Thank you, > From zgu at redhat.com Wed Aug 5 15:21:10 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 5 Aug 2020 11:21:10 -0400 Subject: [8u] RFR: 8159690: [TESTBUG] Mark headful tests with @key headful. In-Reply-To: <20200720093533.hqlyyaxpf6bl7ich@qusp> References: <20200720093533.hqlyyaxpf6bl7ich@qusp> Message-ID: Hi, On 7/20/20 5:35 AM, Jonathan Dowland wrote: > Hello, > > Please review this backport of JDK-8159690 to 8u, for parity with > Oracle 8u271. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159690 > jdk9 patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/980da45565c8 > > webrev: > https://jmtd.net/tmp/JDK-8159690/ Jonathan is not an author right now, so I host his webrev. Webrev: http://cr.openjdk.java.net/~zgu/jonathan_downland/JDK-8159690/ Thanks, -Zhengyu > > 542/842 hunks applied directly from the original patch. 44 I resolved > manually. The remaining hunks are for filenames that do not exist in > jdk8u. Those basenames are listed here: > https://jmtd.net/tmp/JDK-8159690/basenames_not_in_tree.txt > > Note that there are two different tests with the basename > "ImageTransferTest.java", only one of which is in jdk8u. > > > Thank you, > From mbalao at redhat.com Wed Aug 5 15:25:42 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 5 Aug 2020 12:25:42 -0300 Subject: [8u] TLSv1.3 RFR: 8247276: Backport JDK-8161973 to JDK8u In-Reply-To: <4A2A621B-764F-4D07-A9D6-A114BD4AA4F0@azul.com> References: <4A2A621B-764F-4D07-A9D6-A114BD4AA4F0@azul.com> Message-ID: <8dfd64e2-ebc9-ca2c-915a-51c5dd6e56df@redhat.com> Hi Alexey, Thanks for contributing this backport. A few comments: * The reference in the commit message has to be to 8161973 (and not to 8161974 which is a duplicate and is not present in the repository). * Given that the "java/security/cert" tests category is not under the scope of the TLSv1.3 patches (including Step 11 - 8245681), I suggest to include the backport of "test/java/security/cert/PKIXRevocationChecker/OcspUnauthorized.java" as part of this patch. * Note: I'm okay with the decision for test/javax/net/ssl/Stapling/SSLSocketWithStapling.java because it will be file-replaced. Thanks, Martin.- From mbalao at redhat.com Wed Aug 5 16:33:46 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 5 Aug 2020 13:33:46 -0300 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <560d6c0a-1b02-9ae6-65dc-ccc7cd740cf5@redhat.com> References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com> <3e49958c-f1dc-036d-0edf-e4218dee0cbd@redhat.com> <560d6c0a-1b02-9ae6-65dc-ccc7cd740cf5@redhat.com> Message-ID: <539a1f4f-9e9a-eb71-5980-6f278a58ba16@redhat.com> Hi Andrew, On 2/28/20 4:45 PM, Martin Balao wrote: > Webrev.01: > http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.01/ > Can you please take a look at Webrev.01 proposal? [1] Webrev.01 still applies cleanly and no regressions found in sun/security/pkcs11 tests (tested again on 2020-08-05). Thanks, Martin.- -- [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011296.html From mbalao at redhat.com Wed Aug 5 18:43:38 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 5 Aug 2020 15:43:38 -0300 Subject: [8u] TLSv1.3 RFR: 8245474: Add TLS_KRB5 cipher suites support according to RFC-2712 In-Reply-To: <856AA18D-546F-4151-B734-C945905D4567@azul.com> References: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com> <0dcb3904-48cb-deb2-985c-f95fe398cfb7@redhat.com> <786001a2-7c10-80eb-7f83-28264b838835@redhat.com> <3827b74a-bc5d-6376-dcf7-ae796584bcff@redhat.com> <88cc6eb5-815e-51d1-c701-e5fc32a8e359@redhat.com> <87194959-BEB3-4492-99D3-E0B76FC92A1E@azul.com> <856AA18D-546F-4151-B734-C945905D4567@azul.com> Message-ID: Hi Alexey, While doing a final review to this Step, I found a missing check to decide whether KRB5 key exchange mechanisms are available or not. Here there are a few references to the check in the previous SunJSSE engine: [1] [2] [3]. This is analogous to EC key exchange mechanisms in the new SunJSSE engine [4] [5]. In addition, and given that we have finally co-authored this patch, I've added a couple of copyright lines to KrbKeyExchange.java and KrbClientKeyExchange.java files. Webrev.05: * http://cr.openjdk.java.net/~mbalao/webrevs/8245474/8245474.webrev.05/ I'll commit this Step to the incubator repository (once review-approved and previous steps are committed). Thanks, Martin.- -- [1] - http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/84c5676f140b/src/share/classes/sun/security/ssl/CipherSuite.java#l373 [2] - http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/84c5676f140b/src/share/classes/sun/security/ssl/JsseJce.java#l58 [3] - http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/84c5676f140b/src/share/classes/sun/security/ssl/JsseJce.java#l197 [4] - http://hg.openjdk.java.net/jdk-updates/jdk11u/file/d67b0f64be45/src/java.base/share/classes/sun/security/ssl/CipherSuite.java#l1070 [5] - http://hg.openjdk.java.net/jdk-updates/jdk11u/file/d67b0f64be45/src/java.base/share/classes/sun/security/ssl/JsseJce.java#l174 From alexey at azul.com Wed Aug 5 20:04:23 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 5 Aug 2020 20:04:23 +0000 Subject: [8u] TLSv1.3 RFR: 8247276: Backport JDK-8161973 to JDK8u In-Reply-To: <8dfd64e2-ebc9-ca2c-915a-51c5dd6e56df@redhat.com> References: <4A2A621B-764F-4D07-A9D6-A114BD4AA4F0@azul.com> <8dfd64e2-ebc9-ca2c-915a-51c5dd6e56df@redhat.com> Message-ID: Hello Martin, Thank you for review. Please find updated patch with OcspUnauthorized.java test. Commit message will be "8161973: PKIXRevocationChecker.getSoftFailExceptions() not working? : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8247276/webrev.v1/ Regards Alexey > On 5 Aug 2020, at 18:25, Martin Balao wrote: > > Hi Alexey, > > Thanks for contributing this backport. > > A few comments: > > * The reference in the commit message has to be to 8161973 (and not to > 8161974 which is a duplicate and is not present in the repository). > > * Given that the "java/security/cert" tests category is not under the > scope of the TLSv1.3 patches (including Step 11 - 8245681), I suggest to > include the backport of > "test/java/security/cert/PKIXRevocationChecker/OcspUnauthorized.java" as > part of this patch. > * Note: I'm okay with the decision for > test/javax/net/ssl/Stapling/SSLSocketWithStapling.java because it will > be file-replaced. > > Thanks, > Martin.- > From mbalao at redhat.com Wed Aug 5 20:43:21 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 5 Aug 2020 17:43:21 -0300 Subject: [8u] TLSv1.3 RFR: 8247276: Backport JDK-8161973 to JDK8u In-Reply-To: References: <4A2A621B-764F-4D07-A9D6-A114BD4AA4F0@azul.com> <8dfd64e2-ebc9-ca2c-915a-51c5dd6e56df@redhat.com> Message-ID: On 8/5/20 5:04 PM, Alexey Bakhtin wrote: > Please find updated patch with OcspUnauthorized.java test. > Commit message will be "8161973: PKIXRevocationChecker.getSoftFailExceptions() not working? : > http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8247276/webrev.v1/ > Looks good to me. This comment is part of the review too: [1]. Before pushing, please make sure that 'test/javax/net/ssl/Stapling/SSLSocketWithStapling.java' test (pushed by Step 11) passes. Thanks, Martin.- -- [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012350.html From gnu.andrew at redhat.com Thu Aug 6 02:48:08 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 6 Aug 2020 03:48:08 +0100 Subject: [8u] RFR: 8220657: JFR.dump does not work when filename is set In-Reply-To: <22410d48fbe44f3db5b82ee9fc47aa39@azul.com> References: <22410d48fbe44f3db5b82ee9fc47aa39@azul.com> Message-ID: <20200806024808.GA318498@stopbrexit> On 20:04 Thu 30 Jul , Ekaterina Vergizova wrote: > Hello, > I would like to backport JFR issue 8220657 to 8u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220657 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/bd613b97c7c8 > Webrev for 8u: https://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/8220657/webrev.00/ > > The patch applies cleanly, but the added test TestJcmdDumpWithFileName.java requires some adjustments to pass under 8u: > - the test tags are adjusted > - ProcessHandle.current().pid() calls replaced by ProcessTools.getProcessId() > - Path.of() calls replaced by their 8u analogue Paths.get() > - unsupported syntax `try (stream)` replaced by standard try-with-resources > > Tested with tier1 and jdk.jfr tests on Linux and Windows, the added test TestJcmdDumpWithFileName.java failed before the fix and passes after. > > Thanks, > Ekaterina > This patch doesn't build: Compiling 9722 files for BUILD_JDK (/usr/lib/jvm/java-1.8.0-openjdk/bin/java -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 "-Xbootclasspath/p:/home/ahughes/builder/8u-dev/langtools/dist/bootstrap/lib/javac.jar" -cp /home/ahughes/builder/8u-dev/langtools/dist/bootstrap/lib/javac.jar com.sun.tools.javac.Main -bootclasspath /home/ahughes/builder/8u-dev/jdk/classes -source 8 -target 8 -encoding ascii -XDignore.symbol.file=true -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,classfile,dep-ann,divzero,empty,try,varargs -Werror -g -implicit:none -sourcepath "/home/ahughes/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/classes:/home/ahughes/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/classes:/home/ahughes/builder/8u-dev/jdk/gensrc:/home/ahughes/builder/8u-dev/jdk/gensrc_no_srczip" -d /home/ahughes/builder/8u-dev/jdk/classes -h /home/ahughes/builder/8u-dev/jdk/gensrc_headers.BUILD_JDK.tmp @/home/ahughes/builder/8u-dev/jdk/classes/_the.BUILD_JDK_batch.tmp && /usr/bin/mv /home/ahughes/builder/8u-dev/jdk/classes/_the.BUILD_JDK_batch.tmp /home/ahughes/builder/8u-dev/jdk/classes/_the.BUILD_JDK_batch) /home/ahughes/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/classes/jdk/jfr/internal/dcmd/DCmdDump.java:161: error: cannot find symbol reportOperationComplete("Dumped", name, new SafePath(wup.getRealPathText())); ^ symbol: method getRealPathText() location: variable wup of type WriteableUserPath My attention was drawn to this even before building, because, in comparing the 11u version of this patch with this proposed 8u one, this line was changed for the 8u backport: @@ -75,15 +64,13 @@ + wup = new WriteableUserPath(safe.toPath()); + } + r.dumpStopped(wup); -+ reportOperationComplete("Dumped", name, new SafePath(wup.getText())); ++ reportOperationComplete("Dumped", name, new SafePath(wup.getRealPathText())); something which wasn't explained in the above, and, indeed, I see no getRealPathText method in the 8u codebase. Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Thu Aug 6 02:54:08 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 6 Aug 2020 03:54:08 +0100 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <539a1f4f-9e9a-eb71-5980-6f278a58ba16@redhat.com> References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com> <3e49958c-f1dc-036d-0edf-e4218dee0cbd@redhat.com> <560d6c0a-1b02-9ae6-65dc-ccc7cd740cf5@redhat.com> <539a1f4f-9e9a-eb71-5980-6f278a58ba16@redhat.com> Message-ID: <20200806025408.GB318498@stopbrexit> On 13:33 Wed 05 Aug , Martin Balao wrote: > Hi Andrew, > > On 2/28/20 4:45 PM, Martin Balao wrote: > > Webrev.01: > > http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.01/ > > > > Can you please take a look at Webrev.01 proposal? [1] > > Webrev.01 still applies cleanly and no regressions found in > sun/security/pkcs11 tests (tested again on 2020-08-05). > > Thanks, > Martin.- > > -- > [1] - > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011296.html > I didn't go further with the review of this so far, because JDK-8144539 is one of the outstanding test backports for the SQLite patch as well. I intend to return to that bug trail shortly, and we can reconsider both patches once the test backports are resolved. Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Thu Aug 6 04:58:32 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 6 Aug 2020 05:58:32 +0100 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call In-Reply-To: References: Message-ID: <20200806045832.GA472692@stopbrexit> On 13:38 Tue 07 Jul , Zhengyu Gu wrote: > Hi, > > I would like to backport this patch to 8u for the parity of Oracle 8u271. > > The original patch does not apply cleanly, as 8u code diverged from jdk9. > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-6424123 > Original patch: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5217fa82f1a4 > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-6424123-8u/webrev.00/ > > Test: > tier1 on Linux 86_64 > > Thanks, > > -Zhengyu > Having now reviewed this, I can see it contains issues that were resolved in the original review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011527.html and doesn't deal with the cases worked around after this patch. I'll revise my original patch and post it for review. This version is a regression from that one. Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Thu Aug 6 05:17:36 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 6 Aug 2020 06:17:36 +0100 Subject: [8u] RFR: 8191678: [TESTBUG] Add keyword headful in java/awt and javax tests. In-Reply-To: References: Message-ID: <20200806051736.GB472692@stopbrexit> On 11:53 Mon 06 Jul , Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8191678 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191678 > > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/50d61f4b5d1a > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8191678/webrev.00/ > > This change adds "headful" keyword to a number of client tests. Only a > single test (FocusTransitionTest) from this patch is present in 8u - only > changes to it are backported. > > Testing: checked that changed test can be selected with "headful" keyword. > > -- > -Alex > test/jdk/java/awt/Component/GetScreenLocTest/ComponentGetLocationOnScreenNPETest.java: JDK-8189204: Possible NPE in Component::getLocationOnScreen(), not flagged for backport test/jdk/java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java: JDK-8190230: [macosx] Order of overlapping of modal dialogs is wrong, not flagged for backport jdk/test/javax/swing/DefaultButtonModel/DefaultButtonModelCrashTest.java: 8182577: Exception when Tab key moves focus to a JCheckbox with a custom ButtonModel, not flagged for backport test/jdk/javax/swing/GraphicsConfigNotifier/TestMultiScreenGConfigNotify.java: 8178025: HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other, not flagged for backport test/jdk/javax/swing/JButton/TestGlyphBreak.java: 8191428: Regression: Swing button label wrapping with hidpi, not flagged for backport jdk/test/javax/swing/JComboBox/8182031/ComboPopupTest.java: 8182031: Swing's ComboBox Popup opens and closes immediately, not flagged for backport test/jdk/javax/swing/JMenu/8178430/LabelDotTest.java: 8178430: JMenu in GridBagLayout flickers when label text shows "..." and is updated, not flagged for backport test/jdk/javax/swing/JTextArea/TestTabSize.java: 8187957: Tab Size does not work correctly in JTextArea, not flagged for backport jdk/test/javax/swing/dnd/8139050/NativeErrorsInTableDnD.java: 8139050: -[AWTView draggingEnded:]: unrecognized selector message during drag and drop, not flagged for backport jdk/test/javax/swing/plaf/nimbus/TestNimbusOverride.java: 8043315: Nimbus: Setting Nimbus.Overrides property affects custom keymap installation, not flagged for backport test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java: 8188081: Text selection does not clear after focus is lost, not flagged for backport So all seem safe to exclude. In future, please provide such evidence for making such exclusions, especially when the vast majority of the patch is being dropped, as in this case. We don't want to drop such changes if another backport is about to introduce that test. Thanks, -- Andrew :) Senior 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 From katya at azul.com Thu Aug 6 07:11:51 2020 From: katya at azul.com (Ekaterina Vergizova) Date: Thu, 6 Aug 2020 07:11:51 +0000 Subject: [8u] RFR: 8220657: JFR.dump does not work when filename is set In-Reply-To: <20200806024808.GA318498@stopbrexit> References: <22410d48fbe44f3db5b82ee9fc47aa39@azul.com> <20200806024808.GA318498@stopbrexit> Message-ID: <1b515825cdf34d8793c5afd2c1fe01aa@azul.com> Hi Andrew, the method getRealPathText() is introduced by 8224217 which is already approved and included into jdk8u-dev [1]. So the proposed 8220657 patch build successfully against the latest jdk8u-dev. In 11u these patches were applied in reverse order, that's why some additional modifications with getText()/getRealPathText() were required for both of them. Thanks, Ekaterina [1] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/87091b543626 From: Andrew Hughes Sent: Thursday, August 6, 2020 5:48 AM To: Ekaterina Vergizova Cc: jdk8u-dev at openjdk.java.net Subject: Re: [8u] RFR: 8220657: JFR.dump does not work when filename is set On 20:04 Thu 30 Jul , Ekaterina Vergizova wrote: > Hello, > I would like to backport JFR issue 8220657 to 8u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220657 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/bd613b97c7c8 > Webrev for 8u: https://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/8220657/webrev.00/ > > The patch applies cleanly, but the added test TestJcmdDumpWithFileName.java requires some adjustments to pass under 8u: > - the test tags are adjusted > - ProcessHandle.current().pid() calls replaced by ProcessTools.getProcessId() > - Path.of() calls replaced by their 8u analogue Paths.get() > - unsupported syntax `try (stream)` replaced by standard try-with-resources > > Tested with tier1 and jdk.jfr tests on Linux and Windows, the added test TestJcmdDumpWithFileName.java failed before the fix and passes after. > > Thanks, > Ekaterina > This patch doesn't build: Compiling 9722 files for BUILD_JDK (/usr/lib/jvm/java-1.8.0-openjdk/bin/java -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 "-Xbootclasspath/p:/home/ahughes/builder/8u-dev/langtools/dist/bootstrap/lib/javac.jar" -cp /home/ahughes/builder/8u-dev/langtools/dist/bootstrap/lib/javac.jar com.sun.tools.javac.Main -bootclasspath /home/ahughes/builder/8u-dev/jdk/classes -source 8 -target 8 -encoding ascii -XDignore.symbol.file=true -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,classfile,dep-ann,divzero,empty,try,varargs -Werror -g -implicit:none -sourcepath "/home/ahughes/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/classes:/home/ahughes/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/classes:/home/ahughes/builder/8u-dev/jdk/gensrc:/home/ahughes/builder/8u-dev/jdk/gensrc_no_srczip" -d /home/ahughes/builder/8u-dev/jdk/classes -h /home/ahughes/builder/8u-dev/jdk/gensrc_headers.BUILD_JDK.tmp @/home/ahughes/builder/8u-dev/jdk/classes/_the.BUILD_JDK_batch.tmp && /usr/bin/mv /home/ahughes/builder/8u-dev/jdk/classes/_the.BUILD_JDK_batch.tmp /home/ahughes/builder/8u-dev/jdk/classes/_the.BUILD_JDK_batch) /home/ahughes/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/classes/jdk/jfr/internal/dcmd/DCmdDump.java:161: error: cannot find symbol reportOperationComplete("Dumped", name, new SafePath(wup.getRealPathText())); ^ symbol: method getRealPathText() location: variable wup of type WriteableUserPath My attention was drawn to this even before building, because, in comparing the 11u version of this patch with this proposed 8u one, this line was changed for the 8u backport: @@ -75,15 +64,13 @@ + wup = new WriteableUserPath(safe.toPath()); + } + r.dumpStopped(wup); -+ reportOperationComplete("Dumped", name, new SafePath(wup.getText())); ++ reportOperationComplete("Dumped", name, new SafePath(wup.getRealPathText())); something which wasn't explained in the above, and, indeed, I see no getRealPathText method in the 8u codebase. Thanks, -- Andrew :) Senior 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 From neugens at redhat.com Thu Aug 6 08:22:26 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 6 Aug 2020 10:22:26 +0200 Subject: [8u] RFR: 8220657: JFR.dump does not work when filename is set In-Reply-To: <20200806024808.GA318498@stopbrexit> References: <22410d48fbe44f3db5b82ee9fc47aa39@azul.com> <20200806024808.GA318498@stopbrexit> Message-ID: Hi Andrew, I did build and test the patch, perhaps we are testing with a different version? getRealPathText is in the codebase, and I do remember it was introduced some time ago since I recall a similar failure in the past for another change although right now I forgot which patch that was. Cheers, Mario On Thu, Aug 6, 2020 at 4:49 AM Andrew Hughes wrote: > > On 20:04 Thu 30 Jul , Ekaterina Vergizova wrote: > > Hello, > > I would like to backport JFR issue 8220657 to 8u. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220657 > > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/bd613b97c7c8 > > Webrev for 8u: https://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/8220657/webrev.00/ > > > > The patch applies cleanly, but the added test TestJcmdDumpWithFileName.java requires some adjustments to pass under 8u: > > - the test tags are adjusted > > - ProcessHandle.current().pid() calls replaced by ProcessTools.getProcessId() > > - Path.of() calls replaced by their 8u analogue Paths.get() > > - unsupported syntax `try (stream)` replaced by standard try-with-resources > > > > Tested with tier1 and jdk.jfr tests on Linux and Windows, the added test TestJcmdDumpWithFileName.java failed before the fix and passes after. > > > > Thanks, > > Ekaterina > > > > This patch doesn't build: > > Compiling 9722 files for BUILD_JDK > (/usr/lib/jvm/java-1.8.0-openjdk/bin/java -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 "-Xbootclasspath/p:/home/ahughes/builder/8u-dev/langtools/dist/bootstrap/lib/javac.jar" -cp /home/ahughes/builder/8u-dev/langtools/dist/bootstrap/lib/javac.jar com.sun.tools.javac.Main -bootclasspath /home/ahughes/builder/8u-dev/jdk/classes -source 8 -target 8 -encoding ascii -XDignore.symbol.file=true -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,classfile,dep-ann,divzero,empty,try,varargs -Werror -g -implicit:none -sourcepath "/home/ahughes/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/classes:/home/ahughes/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/classes:/home/ahughes/builder/8u-dev/jdk/gensrc:/home/ahughes/builder/8u-dev/jdk/gensrc_no_srczip" -d /home/ahughes/builder/8u-dev/jdk/classes -h /home/ahughes/builder/8u-dev/jdk/gensrc_headers.BUILD_JDK.tmp @/home/ahughes/builder/8u-dev/jdk/classes/_the.BUILD_JDK_batch.tmp && /usr/bin/mv /home/ahughes/builder/8u-dev/jdk/classes/_the.BUILD_JDK_batch.tmp /home/ahughes/builder/8u-dev/jdk/classes/_the.BUILD_JDK_batch) > /home/ahughes/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/classes/jdk/jfr/internal/dcmd/DCmdDump.java:161: error: cannot find symbol > reportOperationComplete("Dumped", name, new SafePath(wup.getRealPathText())); > ^ > symbol: method getRealPathText() > location: variable wup of type WriteableUserPath > > My attention was drawn to this even before building, because, in > comparing the 11u version of this patch with this proposed 8u one, > this line was changed for the 8u backport: > > @@ -75,15 +64,13 @@ > + wup = new WriteableUserPath(safe.toPath()); > + } > + r.dumpStopped(wup); > -+ reportOperationComplete("Dumped", name, new SafePath(wup.getText())); > ++ reportOperationComplete("Dumped", name, new SafePath(wup.getRealPathText())); > > something which wasn't explained in the above, and, indeed, > I see no getRealPathText method in the 8u codebase. > > Thanks, > -- > Andrew :) > > Senior 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 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Thu Aug 6 08:24:05 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 6 Aug 2020 10:24:05 +0200 Subject: [8u] RFR: 8220657: JFR.dump does not work when filename is set In-Reply-To: References: <22410d48fbe44f3db5b82ee9fc47aa39@azul.com> <20200806024808.GA318498@stopbrexit> Message-ID: On Thu, Aug 6, 2020 at 10:22 AM Mario Torre wrote: > > Hi Andrew, > > I did build and test the patch, perhaps we are testing with a different version? > > getRealPathText is in the codebase, and I do remember it was > introduced some time ago since I recall a similar failure in the past > for another change although right now I forgot which patch that was. I should have read all the emails first :) Ekaterina already mentioned it and this is the patch indeed: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/87091b543626 Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sgehwolf at redhat.com Thu Aug 6 09:35:16 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 06 Aug 2020 11:35:16 +0200 Subject: [8u] RFR: 8203357: Container Metrics In-Reply-To: <29d81a510f5ffb7bd7df5f3937f722ad3f383560.camel@redhat.com> References: <29d81a510f5ffb7bd7df5f3937f722ad3f383560.camel@redhat.com> Message-ID: <1008cf64b07601f39ac83674cfba6ad17089498d.camel@redhat.com> On Thu, 2020-07-30 at 11:17 +0200, Severin Gehwolf wrote: > Hi Andrew, > > Thanks for the review! > > On Tue, 2020-07-21 at 20:38 +0100, Andrew Hughes wrote: > > On 16/07/2020 16:48, Severin Gehwolf wrote: > > > Hi, > > > > > > Please review this OpenJDK 8u backport of the Java Metrics classes > > > which are in later JDKs. It is a pre-requisite for JDK-8226575 an > > > Oracle JDK parity issue. Implementations of the interface are provided > > > for Linux only and, thus, are compiled for Linux only. This backport > > > differs from the original JDK 11 change in the following way: > > > > > > * MetricsTester: Arrays.compare() => Arrays.equals(). Arrays.compare() > > > is JDK 9+ only. > > > * JDK-8223147: JFR Backport, brought in test library code included in > > > the JDK 11 changeset. I've only done the needed adjustments to the > > > relevant files in the test libary. Many were already present. > > > * For this backport I've not included changes to the Launcher to > > > support -XshowSettings:system (as in later JDKs). > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203357 > > > webrev: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/01/webrev/ > > > > > > Testing: Included docker tests on Linux x86_64. All pass. Though, they > > > are in dire need of reliability improvements which I'll work on as a > > > follow-up. > > > > > > Thanks, > > > Severin > > > > [...] > > Comments: > > * @author tags are removed from Container.java & Metrics.java. Why? I > > can see a case for removing the "@since 11" but not the authorship. > > * Removal of test code related to the module system seems fine. > > [...] > > > Comments: > > * The Makefile changes look right and in line with those for Mac OS & AIX. > > * The MetricsTester changes look correct. I can only imagine this > > wasn't caught when the test was backported because JDK-8206456 was also > > backported and so the length != 0 checks that introduced were never > > triggered (as the metrics weren't actually there) > > It appears MetricsTester was never run, thus compiled. So I think this > never worked in 8u. Now code uses it and the Arrays.compare() JDK 9+ > feature needed to be reworked. > > [...] > > > So, action items are the missing @author tags and launcher support. > > New webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/02/webrev/ > > Thoughts? Ping? This is blocking some other backports in my queue. Thanks, Severin From sgehwolf at redhat.com Thu Aug 6 09:53:07 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 06 Aug 2020 11:53:07 +0200 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <7fca0e0f-dbf3-bb94-0602-07b5455acd18@redhat.com> References: <30EE84DA-76C1-4A33-95FA-18D57117E2E1@amazon.com> <7fca0e0f-dbf3-bb94-0602-07b5455acd18@redhat.com> Message-ID: <5853f2c103f16165cadd1465687a6c46d2d8ffa5.camel@redhat.com> Hi Zhengyu, On Wed, 2020-08-05 at 09:48 -0400, Zhengyu Gu wrote: > Hi Paul, > > Sorry for replying late. Somehow, this email slipped through the cracks, > and thanks Michael for bringing it to my attention. > > > On 7/13/20 5:27 PM, Hohensee, Paul wrote: > > The webrev looks it's corrupted. E.g., it includes the changes from 8217606, and not the InitialDirContext.java and CheckConfigs.policy changes you mention. > > It had dependence on 8217606, now it is pushed, so that the webrev is > much cleaner. > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.01/ The original patch required a CSR[1], so we should file one for JDK 8u too. I wonder where the CSR is for Oracle JDK 8, though. Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8192975 > Test: > Reran jdk_other. > > Thanks, > > -Zhengyu > > > > > Paul > > > > ?On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > > > Hi, > > > > I would like to backport this patch to 8u for parity with Oracle 8u261. > > > > The original patch does not apply cleanly. > > > > Other than a couple of minor conflicts: > > > > 1) Comments in InitialDirContext.java did not apply cleanly > > 2) Unpatched CheckConfigs.policy files did not match > > > > I made following modification for 8u: > > > > 1) Removed module-info.java section, it does not apply to 8u. > > 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs > > (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the > > code with ArrayList. > > 3) Removed @modules annotation in LdapDnsProviderTest.java > > > > Additional, I need to modify langtools to get javac to take > > com.sun.jndi.ldap.spi package and complain about it. > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 > > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a > > > > 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.00/ > > 8u langtools webrev: > > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webev.00/ > > > > > > Test: > > jdk_other on Linux x86_64 > > > > Thanks, > > > > -Zhengyu > > > > > > From aph at redhat.com Thu Aug 6 11:18:07 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 6 Aug 2020 12:18:07 +0100 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call In-Reply-To: <20200806045832.GA472692@stopbrexit> References: <20200806045832.GA472692@stopbrexit> Message-ID: On 8/6/20 5:58 AM, Andrew Hughes wrote: > > Having now reviewed this, I can see it contains issues that were resolved > in the original review thread: > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011527.html > > and doesn't deal with the cases worked around after this patch. > > I'll revise my original patch and post it for review. This version is > a regression from that one. Great catch. Phew. In this case, the patch is very marginal. It's not at all clear it was worth backporting in the first place. And we've risked regression for it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Thu Aug 6 12:56:29 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 6 Aug 2020 08:56:29 -0400 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call In-Reply-To: <20200806045832.GA472692@stopbrexit> References: <20200806045832.GA472692@stopbrexit> Message-ID: <431f80a0-eda5-1ffe-d6f2-db374440893d@redhat.com> Hi Andrew, > > Having now reviewed this, I can see it contains issues that were resolved > in the original review thread: > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011527.html > > and doesn't deal with the cases worked around after this patch. > Good catch! I would like to withdraw my patch and go with your revised patch. -Zhengyu > I'll revise my original patch and post it for review. This version is > a regression from that one. > > Thanks, > From zgu at redhat.com Thu Aug 6 14:13:35 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 6 Aug 2020 10:13:35 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <5853f2c103f16165cadd1465687a6c46d2d8ffa5.camel@redhat.com> References: <30EE84DA-76C1-4A33-95FA-18D57117E2E1@amazon.com> <7fca0e0f-dbf3-bb94-0602-07b5455acd18@redhat.com> <5853f2c103f16165cadd1465687a6c46d2d8ffa5.camel@redhat.com> Message-ID: <8ee26908-c26c-6b20-00bd-1224f1fd9dca@redhat.com> On 8/6/20 5:53 AM, Severin Gehwolf wrote: > Hi Zhengyu, > > On Wed, 2020-08-05 at 09:48 -0400, Zhengyu Gu wrote: >> Hi Paul, >> >> Sorry for replying late. Somehow, this email slipped through the cracks, >> and thanks Michael for bringing it to my attention. >> >> >> On 7/13/20 5:27 PM, Hohensee, Paul wrote: >>> The webrev looks it's corrupted. E.g., it includes the changes from 8217606, and not the InitialDirContext.java and CheckConfigs.policy changes you mention. >> >> It had dependence on 8217606, now it is pushed, so that the webrev is >> much cleaner. >> >> Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.01/ > > The original patch required a CSR[1], so we should file one for JDK 8u > too. I wonder where the CSR is for Oracle JDK 8, though. It does not seem to have a CSR for 11u backport(?) Do 8u need one? Thanks, -Zhengyu > > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8192975 > >> Test: >> Reran jdk_other. >> >> Thanks, >> >> -Zhengyu >> >> >> >>> Paul >>> >>> ?On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: >>> >>> Hi, >>> >>> I would like to backport this patch to 8u for parity with Oracle 8u261. >>> >>> The original patch does not apply cleanly. >>> >>> Other than a couple of minor conflicts: >>> >>> 1) Comments in InitialDirContext.java did not apply cleanly >>> 2) Unpatched CheckConfigs.policy files did not match >>> >>> I made following modification for 8u: >>> >>> 1) Removed module-info.java section, it does not apply to 8u. >>> 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs >>> (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the >>> code with ArrayList. >>> 3) Removed @modules annotation in LdapDnsProviderTest.java >>> >>> Additional, I need to modify langtools to get javac to take >>> com.sun.jndi.ldap.spi package and complain about it. >>> >>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 >>> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a >>> >>> 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.00/ >>> 8u langtools webrev: >>> http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webev.00/ >>> >>> >>> Test: >>> jdk_other on Linux x86_64 >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>> > From sgehwolf at redhat.com Thu Aug 6 15:00:30 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 06 Aug 2020 17:00:30 +0200 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <8ee26908-c26c-6b20-00bd-1224f1fd9dca@redhat.com> References: <30EE84DA-76C1-4A33-95FA-18D57117E2E1@amazon.com> <7fca0e0f-dbf3-bb94-0602-07b5455acd18@redhat.com> <5853f2c103f16165cadd1465687a6c46d2d8ffa5.camel@redhat.com> <8ee26908-c26c-6b20-00bd-1224f1fd9dca@redhat.com> Message-ID: <798973ab6f046e82131c0167aeff9843aba4ab70.camel@redhat.com> On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > > The original patch required a CSR[1], so we should file one for JDK 8u > > too. I wonder where the CSR is for Oracle JDK 8, though. > > It does not seem to have a CSR for 11u backport(?) Do 8u need one? Right. I don't know about what happened there for Oracle JDK. You could try to ask. I believe we need one since this is changing the 8 SE API by adding: javax/naming/ldap/spi/LdapDnsProvider.java javax/naming/ldap/spi/LdapDnsProviderResult.java Thanks, Severin From sgehwolf at redhat.com Thu Aug 6 15:54:27 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 06 Aug 2020 17:54:27 +0200 Subject: [8u] RFR: 8226899: Problemlist compiler/rtm tests Message-ID: <17f9cda265405d773276134741b938c062c65ccb.camel@redhat.com> Hi, For tier1 tests on OpenJDK 8u we frequently see failing rtm tests. These have been problem-listed in JDK 11 and 13. I propose to do the same to reduce noise. This patch depends on JDK-8078450[1] also proposed for review. Only difference to JDK 11's version are context changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8226899 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226899/01/webrev/ Testing: hotspot_tier1 with JDK-8078450 and JDK-8230388. No more rtm failures. Thoughts? Thanks, Severin [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012181.html From hohensee at amazon.com Thu Aug 6 20:40:11 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 6 Aug 2020 20:40:11 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider Message-ID: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> In InitialDirContext.java, the new comments use @code instead of the pair prevalent in JDK 8. Would be worth checking the Javadoc to see if there's any real difference. If there is, replace the @code uses with pairs. Fwiw, I've done that when backporting javadoc before. I ran the test/com/sun/jndi/ldap/ tests with your patch on my Linux box. Your new tests pass, the old ones perform the same as before the patch. ?On 8/5/20, 6:52 AM, "Zhengyu Gu" wrote: Hi Paul, Sorry for replying late. Somehow, this email slipped through the cracks, and thanks Michael for bringing it to my attention. On 7/13/20 5:27 PM, Hohensee, Paul wrote: > The webrev looks it's corrupted. E.g., it includes the changes from 8217606, and not the InitialDirContext.java and CheckConfigs.policy changes you mention. It had dependence on 8217606, now it is pushed, so that the webrev is much cleaner. Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.01/ Test: Reran jdk_other. Thanks, -Zhengyu > > Paul > > On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > Hi, > > I would like to backport this patch to 8u for parity with Oracle 8u261. > > The original patch does not apply cleanly. > > Other than a couple of minor conflicts: > > 1) Comments in InitialDirContext.java did not apply cleanly > 2) Unpatched CheckConfigs.policy files did not match > > I made following modification for 8u: > > 1) Removed module-info.java section, it does not apply to 8u. > 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs > (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the > code with ArrayList. > 3) Removed @modules annotation in LdapDnsProviderTest.java > > Additional, I need to modify langtools to get javac to take > com.sun.jndi.ldap.spi package and complain about it. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a > > 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.00/ > 8u langtools webrev: > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webev.00/ > > > Test: > jdk_other on Linux x86_64 > > Thanks, > > -Zhengyu > > > From hohensee at amazon.com Thu Aug 6 20:48:24 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 6 Aug 2020 20:48:24 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider Message-ID: <3ADB157F-0EA4-46E3-8704-78F1A1F87401@amazon.com> +1 on needing a CSR for the backport. I'd missed the CSR link because it was buried under "Show 5 more links". I posted an RFO (Request for Opinion) on the same topic of approving strictly additive CSRs for backport. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012319.html Thanks, Paul ?On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf" wrote: On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > > The original patch required a CSR[1], so we should file one for JDK 8u > > too. I wonder where the CSR is for Oracle JDK 8, though. > > It does not seem to have a CSR for 11u backport(?) Do 8u need one? Right. I don't know about what happened there for Oracle JDK. You could try to ask. I believe we need one since this is changing the 8 SE API by adding: javax/naming/ldap/spi/LdapDnsProvider.java javax/naming/ldap/spi/LdapDnsProviderResult.java Thanks, Severin From hohensee at amazon.com Thu Aug 6 21:32:34 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 6 Aug 2020 21:32:34 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <3ADB157F-0EA4-46E3-8704-78F1A1F87401@amazon.com> References: <3ADB157F-0EA4-46E3-8704-78F1A1F87401@amazon.com> Message-ID: <62619760-4743-4CD7-809D-CA79F5CA50C1@amazon.com> I filed a backport issue https://bugs.openjdk.java.net/browse/JDK-8251270 and corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8251270 and assigned them to Zhengyu. ?On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: +1 on needing a CSR for the backport. I'd missed the CSR link because it was buried under "Show 5 more links". I posted an RFO (Request for Opinion) on the same topic of approving strictly additive CSRs for backport. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012319.html Thanks, Paul On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf" wrote: On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > > The original patch required a CSR[1], so we should file one for JDK 8u > > too. I wonder where the CSR is for Oracle JDK 8, though. > > It does not seem to have a CSR for 11u backport(?) Do 8u need one? Right. I don't know about what happened there for Oracle JDK. You could try to ask. I believe we need one since this is changing the 8 SE API by adding: javax/naming/ldap/spi/LdapDnsProvider.java javax/naming/ldap/spi/LdapDnsProviderResult.java Thanks, Severin From gnu.andrew at redhat.com Fri Aug 7 04:35:36 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 7 Aug 2020 05:35:36 +0100 Subject: [8u] RFR: 8220657: JFR.dump does not work when filename is set In-Reply-To: <1b515825cdf34d8793c5afd2c1fe01aa@azul.com> References: <22410d48fbe44f3db5b82ee9fc47aa39@azul.com> <20200806024808.GA318498@stopbrexit> <1b515825cdf34d8793c5afd2c1fe01aa@azul.com> Message-ID: <20200807043536.GA646601@stopbrexit> On 07:11 Thu 06 Aug , Ekaterina Vergizova wrote: > Hi Andrew, > the method getRealPathText() is introduced by 8224217 which is already approved and included into jdk8u-dev [1]. > So the proposed 8220657 patch build successfully against the latest jdk8u-dev. > > In 11u these patches were applied in reverse order, that's why some additional modifications with getText()/getRealPathText() were required for both of them. > > Thanks, Ekaterina > > [1] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/87091b543626 > Right, I saw that later when pulling in the most recent changes. I didn't expect that to be necessary, given the 8220657 patch was posted before the last build promotion, on 2020-07-30. 8224217 was not pushed until 2020-08-03. Please don't post patches that rely on changes that aren't yet committed. Thanks for the explanation on getRealPathText(). I assume the change to that line was part of 8224217 in 11u, but couldn't be applied in 8u because that fix was backported before 8220657. Please try and keep to the same order where possible. I'm happy enough with this now and it can be re-flagged for approval (jdk8u-fix-request). Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Fri Aug 7 05:01:49 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 7 Aug 2020 06:01:49 +0100 Subject: [8u] RFR: 8203357: Container Metrics In-Reply-To: <1008cf64b07601f39ac83674cfba6ad17089498d.camel@redhat.com> References: <29d81a510f5ffb7bd7df5f3937f722ad3f383560.camel@redhat.com> <1008cf64b07601f39ac83674cfba6ad17089498d.camel@redhat.com> Message-ID: <20200807050149.GB646601@stopbrexit> On 11:35 Thu 06 Aug , Severin Gehwolf wrote: snip... > > > > New webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/02/webrev/ > > > > Thoughts? > > Ping? This is blocking some other backports in my queue. > > Thanks, > Severin > This is the first time I've seen this. I was busy with the 8u265 release last week and then away on the Thursday. To make this manageable, I again split it into the existing changes and the three new files, LauncherHelper.java, launcher.properties and Settings.java. Comparing this patch (sans changes to those files) with the original shows the author tags being reinstated. Looks fine. Comparing the three new sets of changes with the 11u changes: * LauncherHelper.java: Missing copyright header change. * launcher.properties: Ordering is different in 8u but change seems ok. * Settings.java: is checkNoContains the same as checkNotContains? JDK-8154470 seems to suggest so, as well as explaining the indentation difference as well. Action items; just the missing copyright header, AFAICS. Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Fri Aug 7 05:15:11 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 7 Aug 2020 06:15:11 +0100 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <798973ab6f046e82131c0167aeff9843aba4ab70.camel@redhat.com> References: <30EE84DA-76C1-4A33-95FA-18D57117E2E1@amazon.com> <7fca0e0f-dbf3-bb94-0602-07b5455acd18@redhat.com> <5853f2c103f16165cadd1465687a6c46d2d8ffa5.camel@redhat.com> <8ee26908-c26c-6b20-00bd-1224f1fd9dca@redhat.com> <798973ab6f046e82131c0167aeff9843aba4ab70.camel@redhat.com> Message-ID: <20200807051511.GC646601@stopbrexit> On 17:00 Thu 06 Aug , Severin Gehwolf wrote: > On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > > > The original patch required a CSR[1], so we should file one for JDK 8u > > > too. I wonder where the CSR is for Oracle JDK 8, though. > > > > It does not seem to have a CSR for 11u backport(?) Do 8u need one? > > Right. I don't know about what happened there for Oracle JDK. You could > try to ask. > > I believe we need one since this is changing the 8 SE API by adding: > > javax/naming/ldap/spi/LdapDnsProvider.java > javax/naming/ldap/spi/LdapDnsProviderResult.java > > Thanks, > Severin > I haven't looked at the patch in full (and doesn't seem to be linked in this mail). Are these new public classes? If so, that's more than just a behavioural compatibility change. It changes the API specification of Java 8. That requires a maintenance release of the specification (as with ALPN) or you would need to house such classes in a different namespace (as was done with Nimbus for OpenJDK 6). Thanks, -- Andrew :) Senior 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 From sgehwolf at redhat.com Fri Aug 7 12:05:04 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 07 Aug 2020 14:05:04 +0200 Subject: [8u] RFR: 8203357: Container Metrics In-Reply-To: <20200807050149.GB646601@stopbrexit> References: <29d81a510f5ffb7bd7df5f3937f722ad3f383560.camel@redhat.com> <1008cf64b07601f39ac83674cfba6ad17089498d.camel@redhat.com> <20200807050149.GB646601@stopbrexit> Message-ID: Hi Andrew! On Fri, 2020-08-07 at 06:01 +0100, Andrew Hughes wrote: > On 11:35 Thu 06 Aug , Severin Gehwolf wrote: > > snip... > > > > New webrev: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/02/webrev/ > > > > > > Thoughts? > > > > Ping? This is blocking some other backports in my queue. > > > > Thanks, > > Severin > > > > This is the first time I've seen this. I was busy with the 8u265 > release last week and then away on the Thursday. OK. Thanks for the review! > To make this manageable, I again split it into the existing changes > and the three new files, LauncherHelper.java, launcher.properties and > Settings.java. > > Comparing this patch (sans changes to those files) with the original > shows the author tags being reinstated. Looks fine. > > Comparing the three new sets of changes with the 11u changes: > > * LauncherHelper.java: Missing copyright header change. Fixed here: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/03/webrev/ > * launcher.properties: Ordering is different in 8u but change seems ok. > * Settings.java: is checkNoContains the same as checkNotContains? I believe so, yes. JDK 8's checkNoContains is: static void checkNoContains(TestResult tr, String str) { if (tr.contains(str)) { System.out.println(tr.status); throw new RuntimeException(str + " found"); } } JDK 11's checkNotContains is: static void checkNotContains(TestResult tr, String str) { if (!tr.notContains(str)) { System.out.println(tr); throw new RuntimeException(str + " found"); } } > JDK-8154470 seems to suggest so, as well as explaining the indentation > difference as well. > > Action items; just the missing copyright header, AFAICS. Thanks! Fixed in webrev 03: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/03/webrev/ Thanks, Severin From sgehwolf at redhat.com Fri Aug 7 12:33:24 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 07 Aug 2020 14:33:24 +0200 Subject: [8u] RFR: 8203357: Container Metrics In-Reply-To: References: <29d81a510f5ffb7bd7df5f3937f722ad3f383560.camel@redhat.com> <1008cf64b07601f39ac83674cfba6ad17089498d.camel@redhat.com> <20200807050149.GB646601@stopbrexit> Message-ID: <0b504f1642e0c728af0f3b7dd8e0956059f1f49c.camel@redhat.com> On Fri, 2020-08-07 at 14:05 +0200, Severin Gehwolf wrote: > > * Settings.java: is checkNoContains the same as checkNotContains? > > I believe so, yes. Well for the purpose of this test it should be fine to use checkNoContains. It's used elsewhere in Settings.java test too. checkNotContains doesn't exist. > JDK 8's checkNoContains is: > static void checkNoContains(TestResult tr, String str) { > if (tr.contains(str)) { > System.out.println(tr.status); > throw new RuntimeException(str + " found"); > } > } > > JDK 11's checkNotContains is: > static void checkNotContains(TestResult tr, String str) { > if (!tr.notContains(str)) { > System.out.println(tr); > throw new RuntimeException(str + " found"); > } > } Actually, the status message which is being printed if the test fails will be slightly different in JDK 8. But for the purpose of this test this shouldn't matter. Thanks, Severin From zgu at redhat.com Fri Aug 7 12:47:53 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 7 Aug 2020 08:47:53 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <62619760-4743-4CD7-809D-CA79F5CA50C1@amazon.com> References: <3ADB157F-0EA4-46E3-8704-78F1A1F87401@amazon.com> <62619760-4743-4CD7-809D-CA79F5CA50C1@amazon.com> Message-ID: <611cda55-9a4b-e4ad-1c32-591e0dde90c5@redhat.com> Hi Paul, Based on Alan Bateman's comment, we can not backport public API to 8u. I guess LdapDnsProvider.java and LdapDnsProviderResult.java have to be moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages. I will withdraw this CSR, ok? Thanks, -Zhengyu On 8/6/20 5:32 PM, Hohensee, Paul wrote: > I filed a backport issue > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > and corresponding CSR > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > and assigned them to Zhengyu. > > ?On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > +1 on needing a CSR for the backport. I'd missed the CSR link because it was buried under "Show 5 more links". > > I posted an RFO (Request for Opinion) on the same topic of approving strictly additive CSRs for backport. > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012319.html > > Thanks, > Paul > > On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf" wrote: > > On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > > > The original patch required a CSR[1], so we should file one for JDK 8u > > > too. I wonder where the CSR is for Oracle JDK 8, though. > > > > It does not seem to have a CSR for 11u backport(?) Do 8u need one? > > Right. I don't know about what happened there for Oracle JDK. You could > try to ask. > > I believe we need one since this is changing the 8 SE API by adding: > > javax/naming/ldap/spi/LdapDnsProvider.java > javax/naming/ldap/spi/LdapDnsProviderResult.java > > Thanks, > Severin > > > From hohensee at amazon.com Fri Aug 7 13:55:58 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 7 Aug 2020 13:55:58 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <611cda55-9a4b-e4ad-1c32-591e0dde90c5@redhat.com> References: <3ADB157F-0EA4-46E3-8704-78F1A1F87401@amazon.com> <62619760-4743-4CD7-809D-CA79F5CA50C1@amazon.com> <611cda55-9a4b-e4ad-1c32-591e0dde90c5@redhat.com> Message-ID: <30E27230-7A9F-4EB3-B883-F336354E0728@amazon.com> You can backport this to 8u. As Michael Osipov wrote (and Alan as a comment on the 8u CSR), you just need to change the 8u CSR and patch to move the new functionality to com.sun.jndi.ldap and com.sun.jndi.ldap.spi. Thanks, Paul ?On 8/7/20, 5:48 AM, "Zhengyu Gu" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Paul, Based on Alan Bateman's comment, we can not backport public API to 8u. I guess LdapDnsProvider.java and LdapDnsProviderResult.java have to be moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages. I will withdraw this CSR, ok? Thanks, -Zhengyu On 8/6/20 5:32 PM, Hohensee, Paul wrote: > I filed a backport issue > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > and corresponding CSR > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > and assigned them to Zhengyu. > > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > +1 on needing a CSR for the backport. I'd missed the CSR link because it was buried under "Show 5 more links". > > I posted an RFO (Request for Opinion) on the same topic of approving strictly additive CSRs for backport. > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012319.html > > Thanks, > Paul > > On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf" wrote: > > On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > > > The original patch required a CSR[1], so we should file one for JDK 8u > > > too. I wonder where the CSR is for Oracle JDK 8, though. > > > > It does not seem to have a CSR for 11u backport(?) Do 8u need one? > > Right. I don't know about what happened there for Oracle JDK. You could > try to ask. > > I believe we need one since this is changing the 8 SE API by adding: > > javax/naming/ldap/spi/LdapDnsProvider.java > javax/naming/ldap/spi/LdapDnsProviderResult.java > > Thanks, > Severin > > > From zgu at redhat.com Fri Aug 7 14:43:28 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 7 Aug 2020 10:43:28 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <30E27230-7A9F-4EB3-B883-F336354E0728@amazon.com> References: <3ADB157F-0EA4-46E3-8704-78F1A1F87401@amazon.com> <62619760-4743-4CD7-809D-CA79F5CA50C1@amazon.com> <611cda55-9a4b-e4ad-1c32-591e0dde90c5@redhat.com> <30E27230-7A9F-4EB3-B883-F336354E0728@amazon.com> Message-ID: On 8/7/20 9:55 AM, Hohensee, Paul wrote: > You can backport this to 8u. As Michael Osipov wrote (and Alan as a comment on the 8u CSR), you just need to change the 8u CSR and patch to move the new functionality to com.sun.jndi.ldap and com.sun.jndi.ldap.spi. Right. But we don't need CSR for that, correct? Thanks, -Zhengyu > > Thanks, > Paul > > ?On 8/7/20, 5:48 AM, "Zhengyu Gu" wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi Paul, > > Based on Alan Bateman's comment, we can not backport public API to 8u. I > guess LdapDnsProvider.java and LdapDnsProviderResult.java have to be > moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages. > > I will withdraw this CSR, ok? > > Thanks, > > -Zhengyu > > > > > > On 8/6/20 5:32 PM, Hohensee, Paul wrote: > > I filed a backport issue > > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > > > and corresponding CSR > > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > > > and assigned them to Zhengyu. > > > > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > > > +1 on needing a CSR for the backport. I'd missed the CSR link because it was buried under "Show 5 more links". > > > > I posted an RFO (Request for Opinion) on the same topic of approving strictly additive CSRs for backport. > > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012319.html > > > > Thanks, > > Paul > > > > On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf" wrote: > > > > On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > > > > The original patch required a CSR[1], so we should file one for JDK 8u > > > > too. I wonder where the CSR is for Oracle JDK 8, though. > > > > > > It does not seem to have a CSR for 11u backport(?) Do 8u need one? > > > > Right. I don't know about what happened there for Oracle JDK. You could > > try to ask. > > > > I believe we need one since this is changing the 8 SE API by adding: > > > > javax/naming/ldap/spi/LdapDnsProvider.java > > javax/naming/ldap/spi/LdapDnsProviderResult.java > > > > Thanks, > > Severin > > > > > > > > From sgehwolf at redhat.com Fri Aug 7 15:24:46 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 07 Aug 2020 17:24:46 +0200 Subject: [8u] RFR 8243138: Enhance BaseLdapServer to support starttls extended request In-Reply-To: <44430764-4423-ac3b-1566-bbd77eb06c2a@redhat.com> References: <44430764-4423-ac3b-1566-bbd77eb06c2a@redhat.com> Message-ID: <27440984df7f49aadbde6e460bbc021b321b4296.camel@redhat.com> Hi Zhengyu, On Tue, 2020-07-14 at 08:47 -0400, Zhengyu Gu wrote: > I would like to backport this patch for parity with Oracle 8u271. > > The original patch does not apply cleanly, but conflicts are minors [1]. > > 1) JDK-8217606 backport converted jdk9 style try-with-resource to > try-catch-finally, that caused the first conflict. > 2) jdk8 does not support 'var' language feature. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8243138 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/df5a2fb15971 > 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243138-8u/webrev.00/ I only see context differences besides the local variable change from 'var' => 'Socket'. OK. Patch looks good to me. Thanks, Severin > Test: > jdk_other > > Thanks, > > -Zhengyu > > > [1] > diff -r 19be2797f698 -r a78123a1f329 > test/com/sun/jndi/ldap/lib/BaseLdapServer.java > --- a/test/com/sun/jndi/ldap/lib/BaseLdapServer.java Thu Apr 23 16:36:05 > 2020 +0800 > +++ b/test/com/sun/jndi/ldap/lib/BaseLdapServer.java Tue Jun 30 10:37:07 > 2020 -0400 > @@ -119,6 +119,7 @@ > // No need to close socket's streams separately, they will be > closed > // automatically when `socket.close()` is called > beforeConnectionHandled(socket); > + ConnWrapper connWrapper = new ConnWrapper(socket); > try { > OutputStream out = socket.getOutputStream(); > InputStream in = socket.getInputStream(); > @@ -154,7 +155,7 @@ > } > handleRequestEx(socket, new LdapMessage(request), out, > connWrapper); > if (connWrapper.updateRequired()) { > - var wrapper = connWrapper.getWrapper(); > + Socket wrapper = connWrapper.getWrapper(); > in = wrapper.getInputStream(); > out = wrapper.getOutputStream(); > connWrapper.clearFlag(); > > > From zgu at redhat.com Fri Aug 7 15:30:29 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 7 Aug 2020 11:30:29 -0400 Subject: [8u] RFR 8243138: Enhance BaseLdapServer to support starttls extended request In-Reply-To: <27440984df7f49aadbde6e460bbc021b321b4296.camel@redhat.com> References: <44430764-4423-ac3b-1566-bbd77eb06c2a@redhat.com> <27440984df7f49aadbde6e460bbc021b321b4296.camel@redhat.com> Message-ID: Thanks, Severin. >> >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8243138 >> Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/df5a2fb15971 >> 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243138-8u/webrev.00/ > > I only see context differences besides the local variable change from > 'var' => 'Socket'. OK. The first conflict is caused by: The original patch: ConnWrapper connWrapper = new ConnWrapper(socket); >> try (socket) { and 8u: ConnWrapper connWrapper = new ConnWrapper(socket); >> try { -Zhengyu > > Patch looks good to me. > > Thanks, > Severin > >> Test: >> jdk_other >> >> Thanks, >> >> -Zhengyu >> >> >> [1] >> diff -r 19be2797f698 -r a78123a1f329 >> test/com/sun/jndi/ldap/lib/BaseLdapServer.java >> --- a/test/com/sun/jndi/ldap/lib/BaseLdapServer.java Thu Apr 23 16:36:05 >> 2020 +0800 >> +++ b/test/com/sun/jndi/ldap/lib/BaseLdapServer.java Tue Jun 30 10:37:07 >> 2020 -0400 >> @@ -119,6 +119,7 @@ >> // No need to close socket's streams separately, they will be >> closed >> // automatically when `socket.close()` is called >> beforeConnectionHandled(socket); >> + ConnWrapper connWrapper = new ConnWrapper(socket); >> try { >> OutputStream out = socket.getOutputStream(); >> InputStream in = socket.getInputStream(); >> @@ -154,7 +155,7 @@ >> } >> handleRequestEx(socket, new LdapMessage(request), out, >> connWrapper); >> if (connWrapper.updateRequired()) { >> - var wrapper = connWrapper.getWrapper(); >> + Socket wrapper = connWrapper.getWrapper(); >> in = wrapper.getInputStream(); >> out = wrapper.getOutputStream(); >> connWrapper.clearFlag(); >> >> >> > From sgehwolf at redhat.com Fri Aug 7 15:39:03 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 07 Aug 2020 17:39:03 +0200 Subject: [8u] RFR: 6574989: TEST_BUG: javax/sound/sampled/Clip/bug5070081.java fails sometimes In-Reply-To: <20200714145007.qf6g54wworbr54df@qusp> References: <20200714145007.qf6g54wworbr54df@qusp> Message-ID: <165cdf34d3037428eb324e924d53da790d022115.camel@redhat.com> Hi Jon, On Tue, 2020-07-14 at 15:50 +0100, Jonathan Dowland wrote: > Hello, > > Please review this "backport" of JDK-6574989 to 8u, for parity with > Oracle 8u271. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6574989 > jdk9 patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0f4994564ae6 > > webrev (I needed the practice generating one): > https://jmtd.net/tmp/JDK-6574989/ > > The patch applies cleanly to jdk8u-dev without path changes, and the > test builds and runs post patching with java(1) built from jdk8u-dev, > so I suppose label jdk8u-fix-request is sufficient? > > However, on my system (Linux/amd64; the original report description > states "fails sometimes on windows platforms"), both pre and post patch, > the test consistently fails. I'm not sure whether that warrants further > investigation, or whether that should block backporting the patch. It's the opposite for me. Fails consistently pre patch. Passes after. Looks good. Approved. Thanks, Severin From hohensee at amazon.com Fri Aug 7 16:14:44 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 7 Aug 2020 16:14:44 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider Message-ID: <4DB5E2A1-2FC5-4C7C-AD35-328CEE9FF790@amazon.com> We do, because any behavioral/API change needs one, even to platform dependent classes. ?On 8/7/20, 7:44 AM, "Zhengyu Gu" wrote: On 8/7/20 9:55 AM, Hohensee, Paul wrote: > You can backport this to 8u. As Michael Osipov wrote (and Alan as a comment on the 8u CSR), you just need to change the 8u CSR and patch to move the new functionality to com.sun.jndi.ldap and com.sun.jndi.ldap.spi. Right. But we don't need CSR for that, correct? Thanks, -Zhengyu > > Thanks, > Paul > > On 8/7/20, 5:48 AM, "Zhengyu Gu" wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi Paul, > > Based on Alan Bateman's comment, we can not backport public API to 8u. I > guess LdapDnsProvider.java and LdapDnsProviderResult.java have to be > moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages. > > I will withdraw this CSR, ok? > > Thanks, > > -Zhengyu > > > > > > On 8/6/20 5:32 PM, Hohensee, Paul wrote: > > I filed a backport issue > > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > > > and corresponding CSR > > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > > > and assigned them to Zhengyu. > > > > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > > > +1 on needing a CSR for the backport. I'd missed the CSR link because it was buried under "Show 5 more links". > > > > I posted an RFO (Request for Opinion) on the same topic of approving strictly additive CSRs for backport. > > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012319.html > > > > Thanks, > > Paul > > > > On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf" wrote: > > > > On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > > > > The original patch required a CSR[1], so we should file one for JDK 8u > > > > too. I wonder where the CSR is for Oracle JDK 8, though. > > > > > > It does not seem to have a CSR for 11u backport(?) Do 8u need one? > > > > Right. I don't know about what happened there for Oracle JDK. You could > > try to ask. > > > > I believe we need one since this is changing the 8 SE API by adding: > > > > javax/naming/ldap/spi/LdapDnsProvider.java > > javax/naming/ldap/spi/LdapDnsProviderResult.java > > > > Thanks, > > Severin > > > > > > > > From sgehwolf at redhat.com Fri Aug 7 16:25:15 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 07 Aug 2020 18:25:15 +0200 Subject: [8u] RFR 8243138: Enhance BaseLdapServer to support starttls extended request In-Reply-To: References: <44430764-4423-ac3b-1566-bbd77eb06c2a@redhat.com> <27440984df7f49aadbde6e460bbc021b321b4296.camel@redhat.com> Message-ID: On Fri, 2020-08-07 at 11:30 -0400, Zhengyu Gu wrote: > Thanks, Severin. > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8243138 > > > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/df5a2fb15971 > > > 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243138-8u/webrev.00/ > > > > I only see context differences besides the local variable change from > > 'var' => 'Socket'. OK. > > The first conflict is caused by: > > The original patch: > ConnWrapper connWrapper = new ConnWrapper(socket); > >> try (socket) { > > and 8u: > > ConnWrapper connWrapper = new ConnWrapper(socket); > >> try { > Yes. That's what I meant. The context around the line being patched is different. Thanks, Severin From denghui.ddh at alibaba-inc.com Sat Aug 8 08:51:12 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Sat, 08 Aug 2020 16:51:12 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSOiA4MjUwODc1OiBJbmNvcnJlY3QgcGFyYW1ldGVyIHR5cGUgZm9yIHVw?= =?UTF-8?B?ZGF0ZV9udW1iZXIgaW4gSkRLX1ZlcnNpb246Ompka191cGRhdGU=?= In-Reply-To: <0b7b6b85-175a-415c-a24b-14203ca76370.denghui.ddh@alibaba-inc.com> References: <0b7b6b85-175a-415c-a24b-14203ca76370.denghui.ddh@alibaba-inc.com> Message-ID: <8ac590bd-0897-4623-9a57-8a368a0f2b24.denghui.ddh@alibaba-inc.com> A gentle ping. Thanks. ------------------------------------------------------------------ From:???(??) Send Time:2020?7?31?(???) 16:00 To:jdk8u-dev Subject:[8u] RFR: 8250875: Incorrect parameter type for update_number in JDK_Version::jdk_update Hi, Could I have a review of this trivial fix that amend the type of update_number in JDK_Version::jdk_update? Summary: Now the update number is over 255, and if we make some flags obsolete later, it will cause a build failure Bug: https://bugs.openjdk.java.net/browse/JDK-8250875 Webrev: http://cr.openjdk.java.net/~ddong/8250875/webrev.00/ Thanks Denghui Dong From felix at imagic.ch Mon Aug 10 09:15:20 2020 From: felix at imagic.ch (Peter Felix) Date: Mon, 10 Aug 2020 09:15:20 +0000 Subject: 0 values for Font.getStringBounds() Message-ID: <031036E3485502418107574F2C750F23025ACAEAD5@srvmx01.imagic.local> I?d like to report a bug based on Font.getStringBounds(). With the following lines it is reproducible: String test = "abcdefghijklmnopqrstuvwxyz "; Font f = new Font("Arial", 0, 1560); int[] widths = new int[test.length()]; for (int i = 0; i < widths.length; i++) { FontRenderContext context = new FontRenderContext(new AffineTransform(1, 0, 0, 1, 0, 0), true, true); double w = f.getStringBounds(test, i, i + 1, context).getWidth(); widths[i] = (int) w; } for (int i = 0; i < widths.length; i++) { System.out.print(widths[i] + " "); } Output ok (with Amazon Corretto 8.202): 867 867 780 867 867 433 867 867 346 346 780 346 1299 867 867 867 867 519 780 433 867 780 1126 780 780 780 433 If I set the font size to 3000 instead of 1560 then the output is 1668 1668 1500 1668 1668 833 1668 1668 666 666 1500 666 2499 1668 1668 1668 1668 999 1500 833 1668 1500 2166 1500 1500 1500 833 If I set the font size to 100 instead of 1560 then the output is 55 55 50 55 55 27 55 55 22 22 50 22 83 55 55 55 55 33 50 27 55 50 72 50 50 50 27 Output nok (with Amazon Corretto 8.232, 8.252, 8.265 and with AdoptOpenJDK 8.265): 867 0 780 0 867 0 0 0 0 0 0 0 0 867 867 0 0 519 780 0 867 780 0 780 0 780 433 If I set the font size to 3000 instead of 1560 then the output is 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 833 If I set the font size to 100 instead of 1560 then the output is (with this size the values are ok) 55 55 50 55 55 27 55 55 22 22 50 22 83 55 55 55 55 33 50 27 55 50 72 50 50 50 27 Thanks, Peter Felix Software-Entwickler Telefon: +41 44 809 40 60 E-Mail: felix at imagic.ch Imagic Bildverarbeitung AG Europa-Strasse 27 CH-8152 Glattbrugg www.imagic.ch [LinkedIn] [xing_share_button3] From christoph.langer at sap.com Mon Aug 10 12:25:08 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Aug 2020 12:25:08 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <4DB5E2A1-2FC5-4C7C-AD35-328CEE9FF790@amazon.com> References: <4DB5E2A1-2FC5-4C7C-AD35-328CEE9FF790@amazon.com> Message-ID: Hi, as I'm in parallel working on an 11u backport and have the same requirement for a CSR, I added release 11-pool to the CSR item (JDK-8251270). I think we can have one CSR for both releases. The user-visible change that we want to do, that is, the introduction of com.sun.jndi.ldap.spi. LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the same, so I guess it is most convenient. Hope you're all ok with that? (I'll take no answer as a yes ??) I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi instead of javax.naming.ldap.spi. Best regards Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Hohensee, Paul > Sent: Freitag, 7. August 2020 18:15 > To: Zhengyu Gu ; Severin Gehwolf > ; jdk8u-dev ; > Andrew Hughes > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve host/domain > names within the default JNDI LDAP provider > > We do, because any behavioral/API change needs one, even to platform > dependent classes. > > ?On 8/7/20, 7:44 AM, "Zhengyu Gu" wrote: > > On 8/7/20 9:55 AM, Hohensee, Paul wrote: > > You can backport this to 8u. As Michael Osipov wrote (and Alan as a > comment on the 8u CSR), you just need to change the 8u CSR and patch to > move the new functionality to com.sun.jndi.ldap and com.sun.jndi.ldap.spi. > > Right. But we don't need CSR for that, correct? > > Thanks, > > -Zhengyu > > > > > Thanks, > > Paul > > > > On 8/7/20, 5:48 AM, "Zhengyu Gu" wrote: > > > > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender and > know the content is safe. > > > > > > > > Hi Paul, > > > > Based on Alan Bateman's comment, we can not backport public API to > 8u. I > > guess LdapDnsProvider.java and LdapDnsProviderResult.java have to > be > > moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages. > > > > I will withdraw this CSR, ok? > > > > Thanks, > > > > -Zhengyu > > > > > > > > > > > > On 8/6/20 5:32 PM, Hohensee, Paul wrote: > > > I filed a backport issue > > > > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > > > > > and corresponding CSR > > > > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > > > > > and assigned them to Zhengyu. > > > > > > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul" > > wrote: > > > > > > +1 on needing a CSR for the backport. I'd missed the CSR link > because it was buried under "Show 5 more links". > > > > > > I posted an RFO (Request for Opinion) on the same topic of > approving strictly additive CSRs for backport. > > > > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020- > August/012319.html > > > > > > Thanks, > > > Paul > > > > > > On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf" > > wrote: > > > > > > On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > > > > > The original patch required a CSR[1], so we should file one > for JDK 8u > > > > > too. I wonder where the CSR is for Oracle JDK 8, though. > > > > > > > > It does not seem to have a CSR for 11u backport(?) Do 8u need > one? > > > > > > Right. I don't know about what happened there for Oracle JDK. > You could > > > try to ask. > > > > > > I believe we need one since this is changing the 8 SE API by > adding: > > > > > > javax/naming/ldap/spi/LdapDnsProvider.java > > > javax/naming/ldap/spi/LdapDnsProviderResult.java > > > > > > Thanks, > > > Severin > > > > > > > > > > > > > > From alexey at azul.com Mon Aug 10 13:16:38 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 10 Aug 2020 13:16:38 +0000 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: <6210a318-6d57-de05-1d0f-20eed83eb6f0@redhat.com> References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> <6210a318-6d57-de05-1d0f-20eed83eb6f0@redhat.com> Message-ID: Hi Matrtin, Thank you for review. Please find updated patch at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v2/ Some comments below. Regards Alexey > On 4 Aug 2020, at 20:07, Martin Balao wrote: > > Hi Alexey, > > Thanks for taking the time to thoroughly go through each file! When I > first elaborated the list, just sampled a couple of files and was not > going to finish it before asking. Then I decided that it might be useful. > > Comments below. > > Thanks, > Martin.- > -- > > On 8/3/20 1:36 PM, Alexey Bakhtin wrote: >>> * ClientHandshaker >>> * RSAExport.java >> Copyright date changed only, no reason to remove/update > > Ok > >>> * GenSSLConfigs >>> * main.java >> Yes, removed > > Could not verify this removal. Missing? Yes. removed again > >>> * HandshakeHash >>> * MyProvider.java >> Test updated for new Provider API, no reason to update for JDK11 > > Ok. > >>> * HandshakeOutStream >>> * NullCerts.java >> Changes in the comment only. No reason to remove/update > > Can we still delete that commented line in this step? Thanks OK. The line is removed without file removal. > >>> * InputRecord >>> * ClientHelloRead.java >> Changes not required for JDK8 (@modules annotation) > > Ok. > >>> * ProtocolVersion >>> * HttpsProtocols.java >> Copyright updated without test changes - no reason to remove/update > > Ok. > >>> * SSLContextImpl >>> * CustomizedCipherSuites.java >> No changes in the test - no reason to remove/update > > The reference to 8208350 was removed. I did not find any reference to > DES algorithms. I suggest to remove it in this step. Even if this test is modified as part of 8208350, it does not test 8208350 functionality. So, reference to 8208350 should be removed. Test updated without file removal. > >>> * SSLEngineImpl >>> * DelegatedTaskWrongException.java >> Copyright updated without test changes - no reason to remove/update > > Ok. > >>> * SSLSocketImpl >>> * SetClientMode.java >> This test marked @ignore in JDK11 but passed in JDK8 with new TLSv1.3 impleentation. No reason to remove > > Passing does not guarantee that the test works properly. Unless we > analyze the reasons, I suggest to stick to JDK-11's judgement. OK. Test removed > >>> * ServerHandshaker >>> * GetPeerHostClient.java >> No functional changes in the test (removed unused import). I think no reason to remove/udate it > > Even though it's a non-functional change, I'd either remove the import > here or delete/add. OK. import removed > >>> * GetPeerHostServer.java >> No changes in the test > > Ok. > >>> * X509TrustManagerImpl >>> * CheckNullEntity.java >> Changes not required for JDK8 (@modules annotation). No reason to remove/update > > Ok. > >>> * rsa >>> * SignatureOffsets.java >>> * SignedObjectChain.java >> Changes not required for JDK8.No reason to remove/update > > Ok, if they pass in Step 11 I have no objections. > >>> * test/com/sun/net/ssl >>> * SSLSecurity >>> * ProviderTest.java >>> * TruncateArray.java >> Changes not required for JDK8 (@modules annotation). No reason to remove/update > > Ok. And the reference to '8130181' is something we don't even want. > >>> * test/javax/net/ssl >>> * ALPN >>> * MyX509ExtendedKeyManager.java >>> * SSLServerSocketAlpnTest.java >>> * SSLSocketAlpnTest.java >> Changed copyrigth only, no reason to remove tests > > Ok. > >>> * SSLParameters >>> * UseCipherSuitesOrder.java >> Changed copyrigth only, no reason to remove tests > > Ok. > >>> * SSLSession >>> * CheckMyTrustedKeystore.java >> Changes not required for JDK8 (@modules annotation). No reason to remove/update > > Ok. > >>> * ServerName >>> * SSLEngineExplorer.java >>> * SSLSocketExplorer.java >> Changed copyrigth only, no reason to remove tests > > Ok. > >>> * TLSv11 >>> * EmptyCertificateAuthorities.java >>> * GenericBlockCipher.java >>> * GenericStreamCipher.java >> Changes not required for JDK8 (@modules annotation). No reason to remove/update > > Ok. We have the imports but not a big deal really. > >>> * ciphersuites >>> * DisabledAlgorithms.java >> No functional changes in the test. No reason to remove/update > > The reference to 8157035 was removed. I suggest to consider this a > relevant change for removal. OK. Test removed > >>> * etc >>> * keystore >>> * truststore >> Yes, these files should be removed in this step. > > Ok. I'm not seeing this in jdk.patch but that's because this is a change > in binaries. I could read the 'Binary files...' message, though. > >>> * sanity >>> * pluggability >>> * CheckSSLContextExport.java >> No changes required for JDK8 (uses new provider API) > > Ok, and we don't want the reference to 8130181. > >>> * templates >>> * SSLExplorer.java >> No functional changes in the test (removed unused import) No reason to remove/update > > Ok. > >>> * GetInstance.java >> Changes not required for JDK8 (@modules annotation). No reason to remove/update > > Ok. > >>> * test/sun/net/www/protocol/https >>> * HttpsURLConnection >>> * B6226610.java >>> * CheckMethods.java >> Changes not required for JDK8 (@modules annotation). No reason to remove/update > > Ok. > >>> * DNSIdentities.java >> No functional changes in the test (removed unused import) No reason to remove/update > > Ok. It still hurts to see an used import from an internal class. OK. Unused import is removed > >>> * HttpsCreateSockTest.java >>> * HttpsSocketFacTest.java >> Changes not required for JDK8 (@modules annotation). No reason to remove/update > > Ok. > >>> * IPAddressDNSIdentities.java >>> * IPAddressIPIdentities.java >>> * IPIdentities.java >>> * Identities.java >> No functional changes in the test (removed unused import) No reason to remove/update > > The unused import again. If you want to delete the import as part of > this change -diverting a bit from the step spirit-, I'd be happy. > Otherwise, okay. OK. Unused import is removed. > >>> * PostThruProxy.java >>> * PostThruProxyWithAuth.java >> Changes not required for JDK 8. No reason to remove/update > > Ok. > >>> * RetryHttps.java >> No functional changes in the test (enabled debug output) No reason to remove/update > > Ok. > >>> * NewImpl >>> * ComHTTPSConnection.java >>> * ComHostnameVerified.java >> Yes, these tests should be removed in this step. > > Ok. > >>> * ChunkedOutputStream.java >> Changes not required for JDK8 (@modules annotation). No reason to remove/update > > Ok. > > > There are still a couple of thing I'd like you to have a look (from my > previous email): > > Files that should be removed because they do not exist in JDK-11, were > relocated or renamed: > > * test/sun/security/ssl > * SSLContextImpl > * DefautlCacheSize.java > * Relocated to SSLSessionContextImpl (there might be file changes as > well) > Yes, you are right. This test should be moved into test/sun/security/ssl/SSLSessionContextImpl I will update JDK-8245477 accordingly > SSL-related tests that are in JDK-8 but not in JDK-11: > > * test/sun/net/www/protocol/https > * HttpsClient > * OriginServer.java Yes, you are right. test/sun/net/www/protocol/https/HttpsClient tests were updated in JDK11. The following files should be removed and updated in the next step: * ProxyAuthTest.java * ServerIdentityTest.java * OriginServer.java > * test/sun/security/ssl > * SSLEngineImpl > * CloseInboundException.java This test was removed as part of JDK-8196584: TLS 1.3 Implementation Removed > * SessionIdCollisionTest.java This test was added as part of JDK-8203190 and not applicable to JDK11 implementation. Removed > > Are we sure that we want to keep them? > > From christoph.langer at sap.com Mon Aug 10 13:25:28 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Aug 2020 13:25:28 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <7fca0e0f-dbf3-bb94-0602-07b5455acd18@redhat.com> References: <30EE84DA-76C1-4A33-95FA-18D57117E2E1@amazon.com> <7fca0e0f-dbf3-bb94-0602-07b5455acd18@redhat.com> Message-ID: Hi Zhengyu, as has been pointed out, you'll need to move the two classes from package javax.naming.ldap.spi into package com.sun.jndi.ldap.spi. After all, 8u backport should be easier than 11u backport for this patch since there's no implication with export restrictions from platform modules in JDK8 ?? Best regards Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of Zhengyu > Gu > Sent: Mittwoch, 5. August 2020 15:49 > To: Hohensee, Paul ; jdk8u-dev dev at openjdk.java.net> > Cc: 1983-01-06 at gmx.net > Subject: Re: [8u] RFR 8160768: Add capability to custom resolve host/domain > names within the default JNDI LDAP provider > > Hi Paul, > > Sorry for replying late. Somehow, this email slipped through the cracks, > and thanks Michael for bringing it to my attention. > > > On 7/13/20 5:27 PM, Hohensee, Paul wrote: > > The webrev looks it's corrupted. E.g., it includes the changes from 8217606, > and not the InitialDirContext.java and CheckConfigs.policy changes you > mention. > > It had dependence on 8217606, now it is pushed, so that the webrev is > much cleaner. > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.01/ > > Test: > Reran jdk_other. > > Thanks, > > -Zhengyu > > > > > > > Paul > > > > ?On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" retn at openjdk.java.net on behalf of zgu at redhat.com> wrote: > > > > Hi, > > > > I would like to backport this patch to 8u for parity with Oracle 8u261. > > > > The original patch does not apply cleanly. > > > > Other than a couple of minor conflicts: > > > > 1) Comments in InitialDirContext.java did not apply cleanly > > 2) Unpatched CheckConfigs.policy files did not match > > > > I made following modification for 8u: > > > > 1) Removed module-info.java section, it does not apply to 8u. > > 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs > > (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the > > code with ArrayList. > > 3) Removed @modules annotation in LdapDnsProviderTest.java > > > > Additional, I need to modify langtools to get javac to take > > com.sun.jndi.ldap.spi package and complain about it. > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 > > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a > > > > 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768- > 8u/jdk/webrev.00/ > > 8u langtools webrev: > > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webev.00/ > > > > > > Test: > > jdk_other on Linux x86_64 > > > > Thanks, > > > > -Zhengyu > > > > > > From zgu at redhat.com Mon Aug 10 13:35:29 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 10 Aug 2020 09:35:29 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: References: <30EE84DA-76C1-4A33-95FA-18D57117E2E1@amazon.com> <7fca0e0f-dbf3-bb94-0602-07b5455acd18@redhat.com> Message-ID: <21e99a2d-183e-9bdc-ff5c-97b0e4918510@redhat.com> On 8/10/20 9:25 AM, Langer, Christoph wrote: > Hi Zhengyu, > > as has been pointed out, you'll need to move the two classes from package javax.naming.ldap.spi into package com.sun.jndi.ldap.spi. Yes. My latest webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.02/ http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webrev.01/ but LdapDnsProviderTest.java test failed with connection denial, looks like there may be security implications. Thanks, -Zhengyu > > After all, 8u backport should be easier than 11u backport for this patch since there's no implication with export restrictions from platform modules in JDK8 ?? > > Best regards > Christoph > >> -----Original Message----- >> From: jdk8u-dev On Behalf Of Zhengyu >> Gu >> Sent: Mittwoch, 5. August 2020 15:49 >> To: Hohensee, Paul ; jdk8u-dev > dev at openjdk.java.net> >> Cc: 1983-01-06 at gmx.net >> Subject: Re: [8u] RFR 8160768: Add capability to custom resolve host/domain >> names within the default JNDI LDAP provider >> >> Hi Paul, >> >> Sorry for replying late. Somehow, this email slipped through the cracks, >> and thanks Michael for bringing it to my attention. >> >> >> On 7/13/20 5:27 PM, Hohensee, Paul wrote: >>> The webrev looks it's corrupted. E.g., it includes the changes from 8217606, >> and not the InitialDirContext.java and CheckConfigs.policy changes you >> mention. >> >> It had dependence on 8217606, now it is pushed, so that the webrev is >> much cleaner. >> >> Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.01/ >> >> Test: >> Reran jdk_other. >> >> Thanks, >> >> -Zhengyu >> >> >> >>> >>> Paul >>> >>> ?On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" > retn at openjdk.java.net on behalf of zgu at redhat.com> wrote: >>> >>> Hi, >>> >>> I would like to backport this patch to 8u for parity with Oracle 8u261. >>> >>> The original patch does not apply cleanly. >>> >>> Other than a couple of minor conflicts: >>> >>> 1) Comments in InitialDirContext.java did not apply cleanly >>> 2) Unpatched CheckConfigs.policy files did not match >>> >>> I made following modification for 8u: >>> >>> 1) Removed module-info.java section, it does not apply to 8u. >>> 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs >>> (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the >>> code with ArrayList. >>> 3) Removed @modules annotation in LdapDnsProviderTest.java >>> >>> Additional, I need to modify langtools to get javac to take >>> com.sun.jndi.ldap.spi package and complain about it. >>> >>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 >>> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a >>> >>> 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768- >> 8u/jdk/webrev.00/ >>> 8u langtools webrev: >>> http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webev.00/ >>> >>> >>> Test: >>> jdk_other on Linux x86_64 >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>> > From alexey at azul.com Mon Aug 10 13:35:58 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 10 Aug 2020 13:35:58 +0000 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: <8a78da1e-d5b6-6c6a-7e69-7c26adc2d9b4@redhat.com> References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> <8a78da1e-d5b6-6c6a-7e69-7c26adc2d9b4@redhat.com> Message-ID: <04695F9C-D8DC-45C3-8C67-D1A17316349B@azul.com> Hi Martin, As discussed in [1] test/sun/security/ssl/SSLContextImpl/DefautlCacheSize.java should be moved to the test/sun/security/ssl/SSLSessionContextImpl/ directory I have updated the patch with this modification only: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v4/ GIT diff : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v4/jdk.git.diff Regards Alexey ---- [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012388.html > On 29 Jul 2020, at 20:16, Martin Balao wrote: > > On 7/29/20 12:12 PM, Alexey Bakhtin wrote: >> Updated webrev at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v3/ > > Hi, > > The goal of Step 9 - 8245477 was to align JSSE regression test hierarchy > to JDK-11 (changes introduced to main line by 8032473 [1]). This > alignment will make easier to understand which tests were modified by > the new SunJSSE engine, and do file-replacement in Steps 10 (removal of > the existing file) and 11 (addition of the new version). In addition to > file-relocation, minor path-related adjustments were made in Step 9 > (i.e.: paths to keystores used by some tests). > > Path changes in tests (keystore locations): > > * Ok. > > Template library relocation (sun/security/ssl/templates -> > javax/net/ssl/templates) and adjustment of tests that use it: > > * Ok. > > No other change in test files: > > * Ok. > > Relocations (review against 8032473) > > * Ok. > > Test regressions > > * It's not my expectation to verify no test regressions on this Step. > Tests that do not enforce TLSv1.2 or below will probably fail if TLSv1.3 > is negotiated. Tests that depend on internal APIs will likely fail too. > > The following comments and their replies are part of this review: [2], > [3], [4] and [5]. > > With that said, Step 9 - 8245477 Webrev.03 looks good to me. Please hold > the push until the whole series is review-approved and maintainer-approved. > > When committing this patch, please include a reference to 8032473 in the > message. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8032473 > [2] - > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012273.html > [3] - > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012280.html > [4] - > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012283.html > [5] - > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012299.html > From hohensee at amazon.com Mon Aug 10 14:44:41 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 10 Aug 2020 14:44:41 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider Message-ID: I don't think you can have the same CSR for both releases because it messes up the accounting. I.e., there's a backport issues for 8u and another one for 11u, and each of these needs its own CSR. The two CSRs will have identical content in this case. :) Paul ?On 8/10/20, 5:25 AM, "Langer, Christoph" wrote: Hi, as I'm in parallel working on an 11u backport and have the same requirement for a CSR, I added release 11-pool to the CSR item (JDK-8251270). I think we can have one CSR for both releases. The user-visible change that we want to do, that is, the introduction of com.sun.jndi.ldap.spi. LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the same, so I guess it is most convenient. Hope you're all ok with that? (I'll take no answer as a yes ??) I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi instead of javax.naming.ldap.spi. Best regards Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Hohensee, Paul > Sent: Freitag, 7. August 2020 18:15 > To: Zhengyu Gu ; Severin Gehwolf > ; jdk8u-dev ; > Andrew Hughes > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve host/domain > names within the default JNDI LDAP provider > > We do, because any behavioral/API change needs one, even to platform > dependent classes. > > On 8/7/20, 7:44 AM, "Zhengyu Gu" wrote: > > On 8/7/20 9:55 AM, Hohensee, Paul wrote: > > You can backport this to 8u. As Michael Osipov wrote (and Alan as a > comment on the 8u CSR), you just need to change the 8u CSR and patch to > move the new functionality to com.sun.jndi.ldap and com.sun.jndi.ldap.spi. > > Right. But we don't need CSR for that, correct? > > Thanks, > > -Zhengyu > > > > > Thanks, > > Paul > > > > On 8/7/20, 5:48 AM, "Zhengyu Gu" wrote: > > > > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender and > know the content is safe. > > > > > > > > Hi Paul, > > > > Based on Alan Bateman's comment, we can not backport public API to > 8u. I > > guess LdapDnsProvider.java and LdapDnsProviderResult.java have to > be > > moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages. > > > > I will withdraw this CSR, ok? > > > > Thanks, > > > > -Zhengyu > > > > > > > > > > > > On 8/6/20 5:32 PM, Hohensee, Paul wrote: > > > I filed a backport issue > > > > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > > > > > and corresponding CSR > > > > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > > > > > and assigned them to Zhengyu. > > > > > > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul" > > wrote: > > > > > > +1 on needing a CSR for the backport. I'd missed the CSR link > because it was buried under "Show 5 more links". > > > > > > I posted an RFO (Request for Opinion) on the same topic of > approving strictly additive CSRs for backport. > > > > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020- > August/012319.html > > > > > > Thanks, > > > Paul > > > > > > On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf" > > wrote: > > > > > > On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > > > > > The original patch required a CSR[1], so we should file one > for JDK 8u > > > > > too. I wonder where the CSR is for Oracle JDK 8, though. > > > > > > > > It does not seem to have a CSR for 11u backport(?) Do 8u need > one? > > > > > > Right. I don't know about what happened there for Oracle JDK. > You could > > > try to ask. > > > > > > I believe we need one since this is changing the 8 SE API by > adding: > > > > > > javax/naming/ldap/spi/LdapDnsProvider.java > > > javax/naming/ldap/spi/LdapDnsProviderResult.java > > > > > > Thanks, > > > Severin > > > > > > > > > > > > > > From hohensee at amazon.com Mon Aug 10 15:52:29 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 10 Aug 2020 15:52:29 +0000 Subject: [8u] RFR: 8250875: Incorrect parameter type for update_number in JDK_Version::jdk_update Message-ID: Lgtm. I updated the issue description to explain why this is needed. Thanks, Paul ?On 8/8/20, 1:54 AM, "jdk8u-dev on behalf of Denghui Dong" wrote: A gentle ping. Thanks. ------------------------------------------------------------------ From:???(??) Send Time:2020?7?31?(???) 16:00 To:jdk8u-dev Subject:[8u] RFR: 8250875: Incorrect parameter type for update_number in JDK_Version::jdk_update Hi, Could I have a review of this trivial fix that amend the type of update_number in JDK_Version::jdk_update? Summary: Now the update number is over 255, and if we make some flags obsolete later, it will cause a build failure Bug: https://bugs.openjdk.java.net/browse/JDK-8250875 Webrev: http://cr.openjdk.java.net/~ddong/8250875/webrev.00/ Thanks Denghui Dong From mbalao at redhat.com Mon Aug 10 17:31:33 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 10 Aug 2020 14:31:33 -0300 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: <04695F9C-D8DC-45C3-8C67-D1A17316349B@azul.com> References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> <8a78da1e-d5b6-6c6a-7e69-7c26adc2d9b4@redhat.com> <04695F9C-D8DC-45C3-8C67-D1A17316349B@azul.com> Message-ID: <4c8f0edf-8388-3f61-2166-c50599fe2bcb@redhat.com> On 8/10/20 10:35 AM, Alexey Bakhtin wrote: > As discussed in [1] test/sun/security/ssl/SSLContextImpl/DefautlCacheSize.java should be moved to the > test/sun/security/ssl/SSLSessionContextImpl/ directory > > I have updated the patch with this modification only: > http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v4/ > GIT diff : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v4/jdk.git.diff > As Alexey said, 'DefautlCacheSize.java' wrong location was noticed during the review of Step 10 - 8245653: Remove 8u TLS tests [1]. Webrev.04 for 8245477 removes the file at the wrong location. Don't we want to add the file at the new location? (as done with the other files) Thanks, Martin.- -- [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012305.html From mbalao at redhat.com Mon Aug 10 18:29:45 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 10 Aug 2020 15:29:45 -0300 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: <4c8f0edf-8388-3f61-2166-c50599fe2bcb@redhat.com> References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> <8a78da1e-d5b6-6c6a-7e69-7c26adc2d9b4@redhat.com> <04695F9C-D8DC-45C3-8C67-D1A17316349B@azul.com> <4c8f0edf-8388-3f61-2166-c50599fe2bcb@redhat.com> Message-ID: <8f63807b-2be7-3d53-a85d-5e27c6902495@redhat.com> On 8/10/20 2:31 PM, Martin Balao wrote: > Webrev.04 for 8245477 removes the file at the wrong location. Don't we > want to add the file at the new location? (as done with the other files) Ah, overlooked it! DefautlCacheSize.java was moved correctly and it's the same file. Webrev.04 for 8245477 looks good to me. Thanks, Martin.- From christoph.langer at sap.com Mon Aug 10 19:00:13 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Aug 2020 19:00:13 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: References: Message-ID: Hi Paul, well, I've seen Oracle doing such Multi-Release CSRs. E.g. https://bugs.openjdk.java.net/browse/JDK-8235540. Copying Joe for clarification. @Joe: Was this an accident or a correct way to use the CSR process? Generally I would welcome this as I believe it could reduce some process overhead... Nevertheless, in this case, while the backport service implementation classes are the same, there are minor differences in the implementation (e.g. addition of module jdk.naming.ldap in 11u and different package for LdapDnsProviderService) that would speak for two separate CSRs. I don't know... Cheers Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Montag, 10. August 2020 16:45 > To: Langer, Christoph ; Zhengyu Gu > ; Severin Gehwolf ; jdk8u-dev > ; Andrew Hughes > ; jdk-updates-dev at openjdk.java.net > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve host/domain > names within the default JNDI LDAP provider > > I don't think you can have the same CSR for both releases because it messes > up the accounting. I.e., there's a backport issues for 8u and another one for > 11u, and each of these needs its own CSR. The two CSRs will have identical > content in this case. :) > > Paul > > ?On 8/10/20, 5:25 AM, "Langer, Christoph" > wrote: > > Hi, > > as I'm in parallel working on an 11u backport and have the same > requirement for a CSR, I added release 11-pool to the CSR item (JDK- > 8251270). I think we can have one CSR for both releases. The user-visible > change that we want to do, that is, the introduction of com.sun.jndi.ldap.spi. > LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the > same, so I guess it is most convenient. > > Hope you're all ok with that? (I'll take no answer as a yes ??) > > I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi instead > of javax.naming.ldap.spi. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk8u-dev On Behalf Of > > Hohensee, Paul > > Sent: Freitag, 7. August 2020 18:15 > > To: Zhengyu Gu ; Severin Gehwolf > > ; jdk8u-dev ; > > Andrew Hughes > > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve > host/domain > > names within the default JNDI LDAP provider > > > > We do, because any behavioral/API change needs one, even to platform > > dependent classes. > > > > On 8/7/20, 7:44 AM, "Zhengyu Gu" wrote: > > > > On 8/7/20 9:55 AM, Hohensee, Paul wrote: > > > You can backport this to 8u. As Michael Osipov wrote (and Alan as a > > comment on the 8u CSR), you just need to change the 8u CSR and patch > to > > move the new functionality to com.sun.jndi.ldap and > com.sun.jndi.ldap.spi. > > > > Right. But we don't need CSR for that, correct? > > > > Thanks, > > > > -Zhengyu > > > > > > > > Thanks, > > > Paul > > > > > > On 8/7/20, 5:48 AM, "Zhengyu Gu" wrote: > > > > > > CAUTION: This email originated from outside of the organization. > Do > > not click links or open attachments unless you can confirm the sender > and > > know the content is safe. > > > > > > > > > > > > Hi Paul, > > > > > > Based on Alan Bateman's comment, we can not backport public API > to > > 8u. I > > > guess LdapDnsProvider.java and LdapDnsProviderResult.java have > to > > be > > > moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages. > > > > > > I will withdraw this CSR, ok? > > > > > > Thanks, > > > > > > -Zhengyu > > > > > > > > > > > > > > > > > > On 8/6/20 5:32 PM, Hohensee, Paul wrote: > > > > I filed a backport issue > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > > > > > > > and corresponding CSR > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > > > > > > > and assigned them to Zhengyu. > > > > > > > > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul" > > hohensee at amazon.com> > > wrote: > > > > > > > > +1 on needing a CSR for the backport. I'd missed the CSR link > > because it was buried under "Show 5 more links". > > > > > > > > I posted an RFO (Request for Opinion) on the same topic of > > approving strictly additive CSRs for backport. > > > > > > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020- > > August/012319.html > > > > > > > > Thanks, > > > > Paul > > > > > > > > On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf" > > > > wrote: > > > > > > > > On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > > > > > > The original patch required a CSR[1], so we should file > one > > for JDK 8u > > > > > > too. I wonder where the CSR is for Oracle JDK 8, though. > > > > > > > > > > It does not seem to have a CSR for 11u backport(?) Do 8u > need > > one? > > > > > > > > Right. I don't know about what happened there for Oracle > JDK. > > You could > > > > try to ask. > > > > > > > > I believe we need one since this is changing the 8 SE API by > > adding: > > > > > > > > javax/naming/ldap/spi/LdapDnsProvider.java > > > > javax/naming/ldap/spi/LdapDnsProviderResult.java > > > > > > > > Thanks, > > > > Severin > > > > > > > > > > > > > > > > > > > > > From mbalao at redhat.com Mon Aug 10 19:46:36 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 10 Aug 2020 16:46:36 -0300 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> <6210a318-6d57-de05-1d0f-20eed83eb6f0@redhat.com> Message-ID: <2c600b69-f208-a2d2-74fc-675491952e5a@redhat.com> Hi Alexey, Thanks for proposing a new Webrev. Comments inline. Regards, Martin.- On 8/10/20 10:16 AM, Alexey Bakhtin wrote: >>>> * GenSSLConfigs >>>> * main.java >>> Yes, removed >> >> Could not verify this removal. Missing? > Yes. removed again Ok. >>>> * HandshakeOutStream >>>> * NullCerts.java >>> Changes in the comment only. No reason to remove/update >> >> Can we still delete that commented line in this step? Thanks > OK. The line is removed without file removal. Good. >>>> * SSLContextImpl >>>> * CustomizedCipherSuites.java >>> No changes in the test - no reason to remove/update >> >> The reference to 8208350 was removed. I did not find any reference to >> DES algorithms. I suggest to remove it in this step. > Even if this test is modified as part of 8208350, it does not test 8208350 functionality. > So, reference to 8208350 should be removed. Test updated without file removal. Ok. >>>> * SSLSocketImpl >>>> * SetClientMode.java >>> This test marked @ignore in JDK11 but passed in JDK8 with new TLSv1.3 impleentation. No reason to remove >> >> Passing does not guarantee that the test works properly. Unless we >> analyze the reasons, I suggest to stick to JDK-11's judgement. > OK. Test removed Ok. >>>> * ServerHandshaker >>>> * GetPeerHostClient.java >>> No functional changes in the test (removed unused import). I think no reason to remove/udate it >> >> Even though it's a non-functional change, I'd either remove the import >> here or delete/add. > OK. import removed Ok. >>>> * ciphersuites >>>> * DisabledAlgorithms.java >>> No functional changes in the test. No reason to remove/update >> >> The reference to 8157035 was removed. I suggest to consider this a >> relevant change for removal. > OK. Test removed Ok. >>>> * DNSIdentities.java >>> No functional changes in the test (removed unused import) No reason to remove/update >> >> Ok. It still hurts to see an used import from an internal class. > OK. Unused import is removed Good, thanks. >>>> * IPAddressDNSIdentities.java >>>> * IPAddressIPIdentities.java >>>> * IPIdentities.java >>>> * Identities.java >>> No functional changes in the test (removed unused import) No reason to remove/update >> >> The unused import again. If you want to delete the import as part of >> this change -diverting a bit from the step spirit-, I'd be happy. >> Otherwise, okay. > OK. Unused import is removed. Good, thanks! >> Files that should be removed because they do not exist in JDK-11, were >> relocated or renamed: >> >> * test/sun/security/ssl >> * SSLContextImpl >> * DefautlCacheSize.java >> * Relocated to SSLSessionContextImpl (there might be file changes as >> well) >> > Yes, you are right. This test should be moved into test/sun/security/ssl/SSLSessionContextImpl > I will update JDK-8245477 accordingly > Ok. Verified in Step 9 (8245477) - Webrev 04: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012395.html >> SSL-related tests that are in JDK-8 but not in JDK-11: >> >> * test/sun/net/www/protocol/https >> * HttpsClient >> * OriginServer.java > > Yes, you are right. test/sun/net/www/protocol/https/HttpsClient tests were updated in JDK11. > The following files should be removed and updated in the next step: > * OriginServer.java > Was OriginServer.java removal missing from Webrev.02? I could not verify this change. >> * test/sun/security/ssl >> * SSLEngineImpl >> * CloseInboundException.java > This test was removed as part of JDK-8196584: TLS 1.3 Implementation > Removed Ok. Yes, I think that's better. >> * SessionIdCollisionTest.java > This test was added as part of JDK-8203190 and not applicable to JDK11 implementation. Removed Good. From alexey at azul.com Mon Aug 10 20:05:46 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 10 Aug 2020 20:05:46 +0000 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: <2c600b69-f208-a2d2-74fc-675491952e5a@redhat.com> References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> <6210a318-6d57-de05-1d0f-20eed83eb6f0@redhat.com> <2c600b69-f208-a2d2-74fc-675491952e5a@redhat.com> Message-ID: Hi Martin, >>> SSL-related tests that are in JDK-8 but not in JDK-11: >>> >>> * test/sun/net/www/protocol/https >>> * HttpsClient >>> * OriginServer.java >> >> Yes, you are right. test/sun/net/www/protocol/https/HttpsClient tests were updated in JDK11. >> The following files should be removed and updated in the next step: >> * OriginServer.java >> > > Was OriginServer.java removal missing from Webrev.02? I could not verify > this change. Your are right. Removed and updated in the same location: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v2/ Regards Alexey From mbalao at redhat.com Mon Aug 10 20:08:39 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 10 Aug 2020 17:08:39 -0300 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> <6210a318-6d57-de05-1d0f-20eed83eb6f0@redhat.com> <2c600b69-f208-a2d2-74fc-675491952e5a@redhat.com> Message-ID: <60b630c9-0e63-5879-774e-5460de1ffb02@redhat.com> On 8/10/20 5:05 PM, Alexey Bakhtin wrote: > > Your are right. Removed and updated in the same location: > http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v2/ > Is that different from Webrev.02? If so, I suggest to name it Webrev.03. Thanks, Martin.- From alexey at azul.com Mon Aug 10 20:19:26 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 10 Aug 2020 20:19:26 +0000 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: <60b630c9-0e63-5879-774e-5460de1ffb02@redhat.com> References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> <6210a318-6d57-de05-1d0f-20eed83eb6f0@redhat.com> <2c600b69-f208-a2d2-74fc-675491952e5a@redhat.com> <60b630c9-0e63-5879-774e-5460de1ffb02@redhat.com> Message-ID: OK. Webrev renamed to webrev.03 : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v3/ Regards Alexey > On 10 Aug 2020, at 23:08, Martin Balao wrote: > > On 8/10/20 5:05 PM, Alexey Bakhtin wrote: >> >> Your are right. Removed and updated in the same location: >> http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v2/ >> > > Is that different from Webrev.02? If so, I suggest to name it Webrev.03. > > Thanks, > Martin.- > From hohensee at amazon.com Mon Aug 10 20:31:03 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 10 Aug 2020 20:31:03 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider Message-ID: I've no problem with using the same CSR as long as the language is identical. :) ?On 8/10/20, 12:01 PM, "Langer, Christoph" wrote: Hi Paul, well, I've seen Oracle doing such Multi-Release CSRs. E.g. https://bugs.openjdk.java.net/browse/JDK-8235540. Copying Joe for clarification. @Joe: Was this an accident or a correct way to use the CSR process? Generally I would welcome this as I believe it could reduce some process overhead... Nevertheless, in this case, while the backport service implementation classes are the same, there are minor differences in the implementation (e.g. addition of module jdk.naming.ldap in 11u and different package for LdapDnsProviderService) that would speak for two separate CSRs. I don't know... Cheers Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Montag, 10. August 2020 16:45 > To: Langer, Christoph ; Zhengyu Gu > ; Severin Gehwolf ; jdk8u-dev > ; Andrew Hughes > ; jdk-updates-dev at openjdk.java.net > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve host/domain > names within the default JNDI LDAP provider > > I don't think you can have the same CSR for both releases because it messes > up the accounting. I.e., there's a backport issues for 8u and another one for > 11u, and each of these needs its own CSR. The two CSRs will have identical > content in this case. :) > > Paul > > On 8/10/20, 5:25 AM, "Langer, Christoph" > wrote: > > Hi, > > as I'm in parallel working on an 11u backport and have the same > requirement for a CSR, I added release 11-pool to the CSR item (JDK- > 8251270). I think we can have one CSR for both releases. The user-visible > change that we want to do, that is, the introduction of com.sun.jndi.ldap.spi. > LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the > same, so I guess it is most convenient. > > Hope you're all ok with that? (I'll take no answer as a yes ??) > > I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi instead > of javax.naming.ldap.spi. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk8u-dev On Behalf Of > > Hohensee, Paul > > Sent: Freitag, 7. August 2020 18:15 > > To: Zhengyu Gu ; Severin Gehwolf > > ; jdk8u-dev ; > > Andrew Hughes > > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve > host/domain > > names within the default JNDI LDAP provider > > > > We do, because any behavioral/API change needs one, even to platform > > dependent classes. > > > > On 8/7/20, 7:44 AM, "Zhengyu Gu" wrote: > > > > On 8/7/20 9:55 AM, Hohensee, Paul wrote: > > > You can backport this to 8u. As Michael Osipov wrote (and Alan as a > > comment on the 8u CSR), you just need to change the 8u CSR and patch > to > > move the new functionality to com.sun.jndi.ldap and > com.sun.jndi.ldap.spi. > > > > Right. But we don't need CSR for that, correct? > > > > Thanks, > > > > -Zhengyu > > > > > > > > Thanks, > > > Paul > > > > > > On 8/7/20, 5:48 AM, "Zhengyu Gu" wrote: > > > > > > CAUTION: This email originated from outside of the organization. > Do > > not click links or open attachments unless you can confirm the sender > and > > know the content is safe. > > > > > > > > > > > > Hi Paul, > > > > > > Based on Alan Bateman's comment, we can not backport public API > to > > 8u. I > > > guess LdapDnsProvider.java and LdapDnsProviderResult.java have > to > > be > > > moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages. > > > > > > I will withdraw this CSR, ok? > > > > > > Thanks, > > > > > > -Zhengyu > > > > > > > > > > > > > > > > > > On 8/6/20 5:32 PM, Hohensee, Paul wrote: > > > > I filed a backport issue > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > > > > > > > and corresponding CSR > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > > > > > > > > and assigned them to Zhengyu. > > > > > > > > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul" > > hohensee at amazon.com> > > wrote: > > > > > > > > +1 on needing a CSR for the backport. I'd missed the CSR link > > because it was buried under "Show 5 more links". > > > > > > > > I posted an RFO (Request for Opinion) on the same topic of > > approving strictly additive CSRs for backport. > > > > > > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020- > > August/012319.html > > > > > > > > Thanks, > > > > Paul > > > > > > > > On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf" > > > > wrote: > > > > > > > > On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > > > > > > The original patch required a CSR[1], so we should file > one > > for JDK 8u > > > > > > too. I wonder where the CSR is for Oracle JDK 8, though. > > > > > > > > > > It does not seem to have a CSR for 11u backport(?) Do 8u > need > > one? > > > > > > > > Right. I don't know about what happened there for Oracle > JDK. > > You could > > > > try to ask. > > > > > > > > I believe we need one since this is changing the 8 SE API by > > adding: > > > > > > > > javax/naming/ldap/spi/LdapDnsProvider.java > > > > javax/naming/ldap/spi/LdapDnsProviderResult.java > > > > > > > > Thanks, > > > > Severin > > > > > > > > > > > > > > > > > > > > > From mbalao at redhat.com Mon Aug 10 20:52:58 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 10 Aug 2020 17:52:58 -0300 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> <6210a318-6d57-de05-1d0f-20eed83eb6f0@redhat.com> <2c600b69-f208-a2d2-74fc-675491952e5a@redhat.com> <60b630c9-0e63-5879-774e-5460de1ffb02@redhat.com> Message-ID: <331164a9-4844-2b3d-05b5-0eb3b690e447@redhat.com> On 8/10/20 5:19 PM, Alexey Bakhtin wrote: > OK. > Webrev renamed to webrev.03 : > http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v3/ Thanks for that. Webrev.03 addresses all my comments so far but just realized there are a few more thing we may need to look at. In particular, I checked what tests were modified by the original TLS 1.3 patch (8196584) and created a diff list of those not under the categories covered here so far: * test/jdk/ProblemList.txt (modified) * do we need to black-list those in JDK-8? * test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java (modified) * I suggest including this change. * test/jdk/java/net/httpclient/MockServer.java (modified) * Not strictly necessary. * test/jdk/sun/security/ec/TestEC.java (modified) * Do we need this change? * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java (modified) * Do we need this change? * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.sh (modified) * Do we need this change? * test/jdk/sun/security/tools/keytool/PrintSSL.java (modified) * Looks like nice to have. If you agree, we can handle this in a separated step. Also, in Step 11 I expect nothing but new files from JDK 11.0.7 without any changes. If you need modifications on top of these files, please include them on a separated step -so it's much easier for me to review-. Let me know what you think. Thanks, Martin.- From mbalao at redhat.com Mon Aug 10 23:04:32 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 10 Aug 2020 20:04:32 -0300 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <20200806025408.GB318498@stopbrexit> References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com> <3e49958c-f1dc-036d-0edf-e4218dee0cbd@redhat.com> <560d6c0a-1b02-9ae6-65dc-ccc7cd740cf5@redhat.com> <539a1f4f-9e9a-eb71-5980-6f278a58ba16@redhat.com> <20200806025408.GB318498@stopbrexit> Message-ID: <313db6f4-b5d0-c08b-f6e7-78506b70b472@redhat.com> Hi Andrew, On 8/5/20 11:54 PM, Andrew Hughes wrote: > I didn't go further with the review of this so far, because JDK-8144539 is > one of the outstanding test backports for the SQLite patch as well. I intend > to return to that bug trail shortly, and we can reconsider both patches once > the test backports are resolved. I believe that 8144539 should not be a blocker for 8080462 because: the overlap/conflict between them does not appear to be fundamental -and has been addressed in the current backport proposal-; 8144539 does not look like a trivial backport -at least at first glance, given the number of files affected-; and, 8144539 does not seem to have the same priority than 8080462 -so a low priority backport is currently blocking a high priority one-. Looks to me that 8144539 is not even required for compatibility between JDKs, but 8080462 certainly is. Thanks, Martin.- From christoph.langer at sap.com Tue Aug 11 05:55:42 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 11 Aug 2020 05:55:42 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <048c8ca1-c9c4-d04b-e657-edd5fb11be41@oracle.com> References: <048c8ca1-c9c4-d04b-e657-edd5fb11be41@oracle.com> Message-ID: Hi Joe, thanks for the clarification. So for this change I'll file a separate CSR for 11u, due to the implementation differences. But generally sharing CSRs between 8u and 11u would be possible. Good to know. Cheers Christoph > -----Original Message----- > From: Joe Darcy > Sent: Montag, 10. August 2020 23:22 > To: Langer, Christoph ; Hohensee, Paul > ; Zhengyu Gu ; Severin > Gehwolf ; jdk8u-dev dev at openjdk.java.net>; Andrew Hughes ; jdk- > updates-dev at openjdk.java.net > Subject: Re: [8u] RFR 8160768: Add capability to custom resolve host/domain > names within the default JNDI LDAP provider > > Hello, > > The practices of CSR and multiple releases have evolved slightly as the > system has been in use for a few years now. > > The CSR FAQ https://wiki.openjdk.java.net/display/csr/CSR+FAQs covers > some of the conditions as quoted below [1]. > > In cases where > > ??? 1) the exact same change is being made in multiple release trains > > and > > ??? 2) the decision to but the change in multiple releases is being > made at the same time > > then a single CSR can be shared by putting multiple releases (or release > families) in the fixVesion field. > > In this case, it sounds like there are some minor differences so two CSR > should be filed. > > Criteria 2) means that if, say, there is a CSR to put a change in 11u > and that change is pushed and three months later there is a desire to > put the change into 8u, a separate CSR would be needed. I treat the CSRs > as updatable until the underlying bug is pushed to a repo. After that > point, it should generally not be further modified or reused. > > HTH, > > -Joe > > [1] Q: How should I get CSR review for multiple release trains? > A: Say you want to get an interface change into JDK N and later decide > the change is also desirable and appropriate for the JDK (N-1) update > release and that update release is using the CSR process. First a CSR > should be created from the main bug targeted at JDK N. Afterward, if a > backport of the main bug covering JDK (N-1) does not already exist, a > backport of the main bug covering JDK (N-1) should be created. Then, a > CSR can be created from that backport. The CSR for the backport should > explicitly state how the interface change for the backport relates to > the interface change for the main release: either the interface change > is the same or, if it differs, what the difference is. > > On 8/10/2020 12:00 PM, Langer, Christoph wrote: > > Hi Paul, > > > > well, I've seen Oracle doing such Multi-Release CSRs. E.g. > https://bugs.openjdk.java.net/browse/JDK-8235540. Copying Joe for > clarification. @Joe: Was this an accident or a correct way to use the CSR > process? Generally I would welcome this as I believe it could reduce some > process overhead... > > > > Nevertheless, in this case, while the backport service implementation > classes are the same, there are minor differences in the implementation > (e.g. addition of module jdk.naming.ldap in 11u and different package for > LdapDnsProviderService) that would speak for two separate CSRs. I don't > know... > > > > Cheers > > Christoph > > > >> -----Original Message----- > >> From: Hohensee, Paul > >> Sent: Montag, 10. August 2020 16:45 > >> To: Langer, Christoph ; Zhengyu Gu > >> ; Severin Gehwolf ; jdk8u- > dev > >> ; Andrew Hughes > >> ; jdk-updates-dev at openjdk.java.net > >> Subject: RE: [8u] RFR 8160768: Add capability to custom resolve > host/domain > >> names within the default JNDI LDAP provider > >> > >> I don't think you can have the same CSR for both releases because it > messes > >> up the accounting. I.e., there's a backport issues for 8u and another one > for > >> 11u, and each of these needs its own CSR. The two CSRs will have identical > >> content in this case. :) > >> > >> Paul > >> > >> ?On 8/10/20, 5:25 AM, "Langer, Christoph" > >> wrote: > >> > >> Hi, > >> > >> as I'm in parallel working on an 11u backport and have the same > >> requirement for a CSR, I added release 11-pool to the CSR item (JDK- > >> 8251270). I think we can have one CSR for both releases. The user-visible > >> change that we want to do, that is, the introduction of > com.sun.jndi.ldap.spi. > >> LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the > >> same, so I guess it is most convenient. > >> > >> Hope you're all ok with that? (I'll take no answer as a yes ??) > >> > >> I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi > instead > >> of javax.naming.ldap.spi. > >> > >> Best regards > >> Christoph > >> > >> > -----Original Message----- > >> > From: jdk8u-dev On Behalf Of > >> > Hohensee, Paul > >> > Sent: Freitag, 7. August 2020 18:15 > >> > To: Zhengyu Gu ; Severin Gehwolf > >> > ; jdk8u-dev dev at openjdk.java.net>; > >> > Andrew Hughes > >> > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve > >> host/domain > >> > names within the default JNDI LDAP provider > >> > > >> > We do, because any behavioral/API change needs one, even to > platform > >> > dependent classes. > >> > > >> > On 8/7/20, 7:44 AM, "Zhengyu Gu" wrote: > >> > > >> > On 8/7/20 9:55 AM, Hohensee, Paul wrote: > >> > > You can backport this to 8u. As Michael Osipov wrote (and Alan as > a > >> > comment on the 8u CSR), you just need to change the 8u CSR and > patch > >> to > >> > move the new functionality to com.sun.jndi.ldap and > >> com.sun.jndi.ldap.spi. > >> > > >> > Right. But we don't need CSR for that, correct? > >> > > >> > Thanks, > >> > > >> > -Zhengyu > >> > > >> > > > >> > > Thanks, > >> > > Paul > >> > > > >> > > On 8/7/20, 5:48 AM, "Zhengyu Gu" wrote: > >> > > > >> > > CAUTION: This email originated from outside of the > organization. > >> Do > >> > not click links or open attachments unless you can confirm the sender > >> and > >> > know the content is safe. > >> > > > >> > > > >> > > > >> > > Hi Paul, > >> > > > >> > > Based on Alan Bateman's comment, we can not backport public > API > >> to > >> > 8u. I > >> > > guess LdapDnsProvider.java and LdapDnsProviderResult.java > have > >> to > >> > be > >> > > moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi > packages. > >> > > > >> > > I will withdraw this CSR, ok? > >> > > > >> > > Thanks, > >> > > > >> > > -Zhengyu > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > On 8/6/20 5:32 PM, Hohensee, Paul wrote: > >> > > > I filed a backport issue > >> > > > > >> > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > >> > > > > >> > > > and corresponding CSR > >> > > > > >> > > > https://bugs.openjdk.java.net/browse/JDK-8251270 > >> > > > > >> > > > and assigned them to Zhengyu. > >> > > > > >> > > > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul" > >> > >> hohensee at amazon.com> > >> > wrote: > >> > > > > >> > > > +1 on needing a CSR for the backport. I'd missed the CSR > link > >> > because it was buried under "Show 5 more links". > >> > > > > >> > > > I posted an RFO (Request for Opinion) on the same topic of > >> > approving strictly additive CSRs for backport. > >> > > > > >> > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020- > >> > August/012319.html > >> > > > > >> > > > Thanks, > >> > > > Paul > >> > > > > >> > > > On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin > Gehwolf" > >> > sgehwolf at redhat.com> > >> > wrote: > >> > > > > >> > > > On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: > >> > > > > > The original patch required a CSR[1], so we should file > >> one > >> > for JDK 8u > >> > > > > > too. I wonder where the CSR is for Oracle JDK 8, > though. > >> > > > > > >> > > > > It does not seem to have a CSR for 11u backport(?) Do > 8u > >> need > >> > one? > >> > > > > >> > > > Right. I don't know about what happened there for > Oracle > >> JDK. > >> > You could > >> > > > try to ask. > >> > > > > >> > > > I believe we need one since this is changing the 8 SE API > by > >> > adding: > >> > > > > >> > > > javax/naming/ldap/spi/LdapDnsProvider.java > >> > > > javax/naming/ldap/spi/LdapDnsProviderResult.java > >> > > > > >> > > > Thanks, > >> > > > Severin > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > >> From christoph.langer at sap.com Tue Aug 11 07:35:22 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 11 Aug 2020 07:35:22 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <21e99a2d-183e-9bdc-ff5c-97b0e4918510@redhat.com> References: <30EE84DA-76C1-4A33-95FA-18D57117E2E1@amazon.com> <7fca0e0f-dbf3-bb94-0602-07b5455acd18@redhat.com> <21e99a2d-183e-9bdc-ff5c-97b0e4918510@redhat.com> Message-ID: Hi Zhengyu, I have now created CSR JDK-8251380 for 11u and JDK-8251270 is 8u again, back on your name. I think, we should not do changes to src/share/classes/javax/naming/directory/InitialDirContext.java. The changes are Javadoc only but they'd alter the spec, so we rather should not touch that file. I've also stated in the CSRs that the file isn't touched by the backports. As for failing tests - I also see some in 11u. The initial version was a bit shaky, I guess. There are follow up fixes which have been backported by Oracle as well (JDK-8139965, JDK- 8237834). I'll pick these for 11u, too. Best regards Christoph > -----Original Message----- > From: Zhengyu Gu > Sent: Montag, 10. August 2020 15:35 > To: Langer, Christoph ; Hohensee, Paul > ; jdk8u-dev > Subject: Re: [8u] RFR 8160768: Add capability to custom resolve host/domain > names within the default JNDI LDAP provider > > > > On 8/10/20 9:25 AM, Langer, Christoph wrote: > > Hi Zhengyu, > > > > as has been pointed out, you'll need to move the two classes from package > javax.naming.ldap.spi into package com.sun.jndi.ldap.spi. > Yes. My latest webrev: > > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.02/ > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webrev.01/ > > but LdapDnsProviderTest.java test failed with connection denial, looks > like there may be security implications. > > Thanks, > > -Zhengyu > > > > > After all, 8u backport should be easier than 11u backport for this patch > since there's no implication with export restrictions from platform modules in > JDK8 ?? > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: jdk8u-dev On Behalf Of > Zhengyu > >> Gu > >> Sent: Mittwoch, 5. August 2020 15:49 > >> To: Hohensee, Paul ; jdk8u-dev >> dev at openjdk.java.net> > >> Cc: 1983-01-06 at gmx.net > >> Subject: Re: [8u] RFR 8160768: Add capability to custom resolve > host/domain > >> names within the default JNDI LDAP provider > >> > >> Hi Paul, > >> > >> Sorry for replying late. Somehow, this email slipped through the cracks, > >> and thanks Michael for bringing it to my attention. > >> > >> > >> On 7/13/20 5:27 PM, Hohensee, Paul wrote: > >>> The webrev looks it's corrupted. E.g., it includes the changes from > 8217606, > >> and not the InitialDirContext.java and CheckConfigs.policy changes you > >> mention. > >> > >> It had dependence on 8217606, now it is pushed, so that the webrev is > >> much cleaner. > >> > >> Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768- > 8u/jdk/webrev.01/ > >> > >> Test: > >> Reran jdk_other. > >> > >> Thanks, > >> > >> -Zhengyu > >> > >> > >> > >>> > >>> Paul > >>> > >>> ?On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" >> retn at openjdk.java.net on behalf of zgu at redhat.com> wrote: > >>> > >>> Hi, > >>> > >>> I would like to backport this patch to 8u for parity with Oracle 8u261. > >>> > >>> The original patch does not apply cleanly. > >>> > >>> Other than a couple of minor conflicts: > >>> > >>> 1) Comments in InitialDirContext.java did not apply cleanly > >>> 2) Unpatched CheckConfigs.policy files did not match > >>> > >>> I made following modification for 8u: > >>> > >>> 1) Removed module-info.java section, it does not apply to 8u. > >>> 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs > >>> (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the > >>> code with ArrayList. > >>> 3) Removed @modules annotation in LdapDnsProviderTest.java > >>> > >>> Additional, I need to modify langtools to get javac to take > >>> com.sun.jndi.ldap.spi package and complain about it. > >>> > >>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 > >>> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a > >>> > >>> 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768- > >> 8u/jdk/webrev.00/ > >>> 8u langtools webrev: > >>> http://cr.openjdk.java.net/~zgu/JDK-8160768- > 8u/langtools/webev.00/ > >>> > >>> > >>> Test: > >>> jdk_other on Linux x86_64 > >>> > >>> Thanks, > >>> > >>> -Zhengyu > >>> > >>> > >>> > > From alexey at azul.com Tue Aug 11 08:05:47 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 11 Aug 2020 08:05:47 +0000 Subject: [8u] TLSv1.3 RFR: 8233621: Mismatch in jsse.enableMFLNExtension property name Message-ID: <046D3A63-0991-48F6-940B-7A6BE6840A93@azul.com> Hello All, Please review the patch required to fix jsse.enableMFLNExtension property name in the TLSv1.3 implementation. This is backport of JDK-8233621 [1]. Original patch applies cleanly except of location of modified file. Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251340/webrev.v0 JBS task: https://bugs.openjdk.java.net/browse/JDK-8251340 CSR: https://bugs.openjdk.java.net/browse/JDK-8248721 [1] - https://bugs.openjdk.java.net/browse/JDK-8233621 Regards Alexey From alexey at azul.com Tue Aug 11 08:17:04 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 11 Aug 2020 08:17:04 +0000 Subject: [8u] TLSv1.3 RFR: 8251341: Minimal Java specification change Message-ID: <046ABE72-88F7-4445-B127-226908AB5186@azul.com> Hello All, Please review small patch required to update java specification for TLSv1.3 protocol in the javax.net.ssl.ExtendedSSLSession class. Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251341/webrev.v0 JBS task: https://bugs.openjdk.java.net/browse/JDK-8251341 CSR: https://bugs.openjdk.java.net/browse/JDK-8248721 Regards Alexey From sgehwolf at redhat.com Tue Aug 11 08:57:52 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 11 Aug 2020 10:57:52 +0200 Subject: [8u] RFR: 8250875: Incorrect parameter type for update_number in JDK_Version::jdk_update In-Reply-To: <8ac590bd-0897-4623-9a57-8a368a0f2b24.denghui.ddh@alibaba-inc.com> References: <0b7b6b85-175a-415c-a24b-14203ca76370.denghui.ddh@alibaba-inc.com> <8ac590bd-0897-4623-9a57-8a368a0f2b24.denghui.ddh@alibaba-inc.com> Message-ID: <0e744aa7a2a6578bc27d967c2db5beccb00dd84e.camel@redhat.com> On Sat, 2020-08-08 at 16:51 +0800, Denghui Dong wrote: > A gentle ping. FYI: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012316.html Thanks, Severin > ------------------------------------------------------------------ > From:???(??) > Send Time:2020?7?31?(???) 16:00 > To:jdk8u-dev > Subject:[8u] RFR: 8250875: Incorrect parameter type for update_number in JDK_Version::jdk_update > > Hi, > Could I have a review of this trivial fix that amend the type of update_number in JDK_Version::jdk_update? > Summary: > Now the update number is over 255, and if we make some flags obsolete later, > it will cause a build failure > > Bug: https://bugs.openjdk.java.net/browse/JDK-8250875 > Webrev: http://cr.openjdk.java.net/~ddong/8250875/webrev.00/ > > Thanks > Denghui Dong From sgehwolf at redhat.com Tue Aug 11 11:58:22 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 11 Aug 2020 13:58:22 +0200 Subject: [8u] RFR: 8203357: Container Metrics In-Reply-To: References: <29d81a510f5ffb7bd7df5f3937f722ad3f383560.camel@redhat.com> <1008cf64b07601f39ac83674cfba6ad17089498d.camel@redhat.com> <20200807050149.GB646601@stopbrexit> Message-ID: <12f99cd4f865df8e9b568900fcd2cad9cd4f448e.camel@redhat.com> Hi Andrew, On Fri, 2020-08-07 at 14:05 +0200, Severin Gehwolf wrote: > > Comparing the three new sets of changes with the 11u changes: > > * LauncherHelper.java: Missing copyright header change. > > Fixed here: > > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/03/webrev/ Incremental diff: diff --git a/src/share/classes/sun/launcher/LauncherHelper.java b/src/share/classes/sun/launcher/LauncherHelper.java +++ a/src/share/classes/sun/launcher/LauncherHelper.java --- b/src/share/classes/sun/launcher/LauncherHelper.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2007, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2007, 2018, 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 Is this OK now? Thanks, Severin From joe.darcy at oracle.com Mon Aug 10 21:22:08 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 10 Aug 2020 14:22:08 -0700 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: References: Message-ID: <048c8ca1-c9c4-d04b-e657-edd5fb11be41@oracle.com> Hello, The practices of CSR and multiple releases have evolved slightly as the system has been in use for a few years now. The CSR FAQ https://wiki.openjdk.java.net/display/csr/CSR+FAQs covers some of the conditions as quoted below [1]. In cases where ??? 1) the exact same change is being made in multiple release trains and ??? 2) the decision to but the change in multiple releases is being made at the same time then a single CSR can be shared by putting multiple releases (or release families) in the fixVesion field. In this case, it sounds like there are some minor differences so two CSR should be filed. Criteria 2) means that if, say, there is a CSR to put a change in 11u and that change is pushed and three months later there is a desire to put the change into 8u, a separate CSR would be needed. I treat the CSRs as updatable until the underlying bug is pushed to a repo. After that point, it should generally not be further modified or reused. HTH, -Joe [1] Q: How should I get CSR review for multiple release trains? A: Say you want to get an interface change into JDK N and later decide the change is also desirable and appropriate for the JDK (N-1) update release and that update release is using the CSR process. First a CSR should be created from the main bug targeted at JDK N. Afterward, if a backport of the main bug covering JDK (N-1) does not already exist, a backport of the main bug covering JDK (N-1) should be created. Then, a CSR can be created from that backport. The CSR for the backport should explicitly state how the interface change for the backport relates to the interface change for the main release: either the interface change is the same or, if it differs, what the difference is. On 8/10/2020 12:00 PM, Langer, Christoph wrote: > Hi Paul, > > well, I've seen Oracle doing such Multi-Release CSRs. E.g. https://bugs.openjdk.java.net/browse/JDK-8235540. Copying Joe for clarification. @Joe: Was this an accident or a correct way to use the CSR process? Generally I would welcome this as I believe it could reduce some process overhead... > > Nevertheless, in this case, while the backport service implementation classes are the same, there are minor differences in the implementation (e.g. addition of module jdk.naming.ldap in 11u and different package for LdapDnsProviderService) that would speak for two separate CSRs. I don't know... > > Cheers > Christoph > >> -----Original Message----- >> From: Hohensee, Paul >> Sent: Montag, 10. August 2020 16:45 >> To: Langer, Christoph ; Zhengyu Gu >> ; Severin Gehwolf ; jdk8u-dev >> ; Andrew Hughes >> ; jdk-updates-dev at openjdk.java.net >> Subject: RE: [8u] RFR 8160768: Add capability to custom resolve host/domain >> names within the default JNDI LDAP provider >> >> I don't think you can have the same CSR for both releases because it messes >> up the accounting. I.e., there's a backport issues for 8u and another one for >> 11u, and each of these needs its own CSR. The two CSRs will have identical >> content in this case. :) >> >> Paul >> >> ?On 8/10/20, 5:25 AM, "Langer, Christoph" >> wrote: >> >> Hi, >> >> as I'm in parallel working on an 11u backport and have the same >> requirement for a CSR, I added release 11-pool to the CSR item (JDK- >> 8251270). I think we can have one CSR for both releases. The user-visible >> change that we want to do, that is, the introduction of com.sun.jndi.ldap.spi. >> LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the >> same, so I guess it is most convenient. >> >> Hope you're all ok with that? (I'll take no answer as a yes ??) >> >> I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi instead >> of javax.naming.ldap.spi. >> >> Best regards >> Christoph >> >> > -----Original Message----- >> > From: jdk8u-dev On Behalf Of >> > Hohensee, Paul >> > Sent: Freitag, 7. August 2020 18:15 >> > To: Zhengyu Gu ; Severin Gehwolf >> > ; jdk8u-dev ; >> > Andrew Hughes >> > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve >> host/domain >> > names within the default JNDI LDAP provider >> > >> > We do, because any behavioral/API change needs one, even to platform >> > dependent classes. >> > >> > On 8/7/20, 7:44 AM, "Zhengyu Gu" wrote: >> > >> > On 8/7/20 9:55 AM, Hohensee, Paul wrote: >> > > You can backport this to 8u. As Michael Osipov wrote (and Alan as a >> > comment on the 8u CSR), you just need to change the 8u CSR and patch >> to >> > move the new functionality to com.sun.jndi.ldap and >> com.sun.jndi.ldap.spi. >> > >> > Right. But we don't need CSR for that, correct? >> > >> > Thanks, >> > >> > -Zhengyu >> > >> > > >> > > Thanks, >> > > Paul >> > > >> > > On 8/7/20, 5:48 AM, "Zhengyu Gu" wrote: >> > > >> > > CAUTION: This email originated from outside of the organization. >> Do >> > not click links or open attachments unless you can confirm the sender >> and >> > know the content is safe. >> > > >> > > >> > > >> > > Hi Paul, >> > > >> > > Based on Alan Bateman's comment, we can not backport public API >> to >> > 8u. I >> > > guess LdapDnsProvider.java and LdapDnsProviderResult.java have >> to >> > be >> > > moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages. >> > > >> > > I will withdraw this CSR, ok? >> > > >> > > Thanks, >> > > >> > > -Zhengyu >> > > >> > > >> > > >> > > >> > > >> > > On 8/6/20 5:32 PM, Hohensee, Paul wrote: >> > > > I filed a backport issue >> > > > >> > > > https://bugs.openjdk.java.net/browse/JDK-8251270 >> > > > >> > > > and corresponding CSR >> > > > >> > > > https://bugs.openjdk.java.net/browse/JDK-8251270 >> > > > >> > > > and assigned them to Zhengyu. >> > > > >> > > > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul" >> > > hohensee at amazon.com> >> > wrote: >> > > > >> > > > +1 on needing a CSR for the backport. I'd missed the CSR link >> > because it was buried under "Show 5 more links". >> > > > >> > > > I posted an RFO (Request for Opinion) on the same topic of >> > approving strictly additive CSRs for backport. >> > > > >> > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020- >> > August/012319.html >> > > > >> > > > Thanks, >> > > > Paul >> > > > >> > > > On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf" >> > >> > wrote: >> > > > >> > > > On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote: >> > > > > > The original patch required a CSR[1], so we should file >> one >> > for JDK 8u >> > > > > > too. I wonder where the CSR is for Oracle JDK 8, though. >> > > > > >> > > > > It does not seem to have a CSR for 11u backport(?) Do 8u >> need >> > one? >> > > > >> > > > Right. I don't know about what happened there for Oracle >> JDK. >> > You could >> > > > try to ask. >> > > > >> > > > I believe we need one since this is changing the 8 SE API by >> > adding: >> > > > >> > > > javax/naming/ldap/spi/LdapDnsProvider.java >> > > > javax/naming/ldap/spi/LdapDnsProviderResult.java >> > > > >> > > > Thanks, >> > > > Severin >> > > > >> > > > >> > > > >> > > >> > > >> > >> From alexey at azul.com Tue Aug 11 14:11:42 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 11 Aug 2020 14:11:42 +0000 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: <331164a9-4844-2b3d-05b5-0eb3b690e447@redhat.com> References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> <6210a318-6d57-de05-1d0f-20eed83eb6f0@redhat.com> <2c600b69-f208-a2d2-74fc-675491952e5a@redhat.com> <60b630c9-0e63-5879-774e-5460de1ffb02@redhat.com> <331164a9-4844-2b3d-05b5-0eb3b690e447@redhat.com> Message-ID: <514443F9-4FCD-4AAA-830C-255B1481E6D1@azul.com> Hi Martin, Thank you for detailed review. Updated patch at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v4/ Regards Alexey > On 10 Aug 2020, at 23:52, Martin Balao wrote: > > On 8/10/20 5:19 PM, Alexey Bakhtin wrote: >> OK. >> Webrev renamed to webrev.03 : >> http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v3/ > > Thanks for that. Webrev.03 addresses all my comments so far but just > realized there are a few more thing we may need to look at. > > In particular, I checked what tests were modified by the original TLS > 1.3 patch (8196584) and created a diff list of those not under the > categories covered here so far: > > * test/jdk/ProblemList.txt (modified) > * do we need to black-list those in JDK-8? Agree. It should be updated but not at this step. > * test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java (modified) > * I suggest including this change. OK. Make sense. Removed in this step > * test/jdk/java/net/httpclient/MockServer.java (modified) > * Not strictly necessary. > * test/jdk/sun/security/ec/TestEC.java (modified) > * Do we need this change? OK. Update of this test is included into the next step, but it would be better to remove it and add in the next step. Removed > * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java (modified) > * Do we need this change? > * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.sh (modified) > * Do we need this change? Agree. Tests removed > * test/jdk/sun/security/tools/keytool/PrintSSL.java (modified) > * Looks like nice to have. Agree. Test removed > If you agree, we can handle this in a separated step. Also, in Step 11 I > expect nothing but new files from JDK 11.0.7 without any changes. If you > need modifications on top of these files, please include them on a > separated step -so it's much easier for me to review-. > I think we can handle it in this step and add new version of the tests in Step 11 > Let me know what you think. > > Thanks, > Martin.- > From zgu at redhat.com Tue Aug 11 14:40:44 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 11 Aug 2020 10:40:44 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: References: <30EE84DA-76C1-4A33-95FA-18D57117E2E1@amazon.com> <7fca0e0f-dbf3-bb94-0602-07b5455acd18@redhat.com> <21e99a2d-183e-9bdc-ff5c-97b0e4918510@redhat.com> Message-ID: <38bd72c7-23aa-17ba-e354-7d4585da55b6@redhat.com> On 8/11/20 3:35 AM, Langer, Christoph wrote: > Hi Zhengyu, > > I have now created CSR JDK-8251380 for 11u and JDK-8251270 is 8u again, back on your name. Thanks. > > I think, we should not do changes to src/share/classes/javax/naming/directory/InitialDirContext.java. The changes are Javadoc only but they'd alter the spec, so we rather should not touch that file. I've also stated in the CSRs that the file isn't touched by the backports. > I agree. I tried to edit comments to refer new classes, it stroke me that it is wrong to have public API referring implementation specific classes. > As for failing tests - I also see some in 11u. The initial version was a bit shaky, I guess. There are follow up fixes which have been backported by Oracle as well (JDK-8139965, JDK- 8237834). I'll pick these for 11u, too. > I think I fixed the test in 8u, now it passes jdk_other. I am pondering if we need a TCK run. Thanks, -Zhengyu > Best regards > Christoph > >> -----Original Message----- >> From: Zhengyu Gu >> Sent: Montag, 10. August 2020 15:35 >> To: Langer, Christoph ; Hohensee, Paul >> ; jdk8u-dev >> Subject: Re: [8u] RFR 8160768: Add capability to custom resolve host/domain >> names within the default JNDI LDAP provider >> >> >> >> On 8/10/20 9:25 AM, Langer, Christoph wrote: >>> Hi Zhengyu, >>> >>> as has been pointed out, you'll need to move the two classes from package >> javax.naming.ldap.spi into package com.sun.jndi.ldap.spi. >> Yes. My latest webrev: >> >> http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.02/ >> http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webrev.01/ >> >> but LdapDnsProviderTest.java test failed with connection denial, looks >> like there may be security implications. >> >> Thanks, >> >> -Zhengyu >> >>> >>> After all, 8u backport should be easier than 11u backport for this patch >> since there's no implication with export restrictions from platform modules in >> JDK8 ?? >>> >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: jdk8u-dev On Behalf Of >> Zhengyu >>>> Gu >>>> Sent: Mittwoch, 5. August 2020 15:49 >>>> To: Hohensee, Paul ; jdk8u-dev >>> dev at openjdk.java.net> >>>> Cc: 1983-01-06 at gmx.net >>>> Subject: Re: [8u] RFR 8160768: Add capability to custom resolve >> host/domain >>>> names within the default JNDI LDAP provider >>>> >>>> Hi Paul, >>>> >>>> Sorry for replying late. Somehow, this email slipped through the cracks, >>>> and thanks Michael for bringing it to my attention. >>>> >>>> >>>> On 7/13/20 5:27 PM, Hohensee, Paul wrote: >>>>> The webrev looks it's corrupted. E.g., it includes the changes from >> 8217606, >>>> and not the InitialDirContext.java and CheckConfigs.policy changes you >>>> mention. >>>> >>>> It had dependence on 8217606, now it is pushed, so that the webrev is >>>> much cleaner. >>>> >>>> Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768- >> 8u/jdk/webrev.01/ >>>> >>>> Test: >>>> Reran jdk_other. >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> >>>> >>>>> >>>>> Paul >>>>> >>>>> ?On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" >>> retn at openjdk.java.net on behalf of zgu at redhat.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I would like to backport this patch to 8u for parity with Oracle 8u261. >>>>> >>>>> The original patch does not apply cleanly. >>>>> >>>>> Other than a couple of minor conflicts: >>>>> >>>>> 1) Comments in InitialDirContext.java did not apply cleanly >>>>> 2) Unpatched CheckConfigs.policy files did not match >>>>> >>>>> I made following modification for 8u: >>>>> >>>>> 1) Removed module-info.java section, it does not apply to 8u. >>>>> 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs >>>>> (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the >>>>> code with ArrayList. >>>>> 3) Removed @modules annotation in LdapDnsProviderTest.java >>>>> >>>>> Additional, I need to modify langtools to get javac to take >>>>> com.sun.jndi.ldap.spi package and complain about it. >>>>> >>>>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 >>>>> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a >>>>> >>>>> 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768- >>>> 8u/jdk/webrev.00/ >>>>> 8u langtools webrev: >>>>> http://cr.openjdk.java.net/~zgu/JDK-8160768- >> 8u/langtools/webev.00/ >>>>> >>>>> >>>>> Test: >>>>> jdk_other on Linux x86_64 >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>>> >>>>> >>> > From hohensee at amazon.com Tue Aug 11 14:46:51 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 11 Aug 2020 14:46:51 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider Message-ID: If you have changed only com.sun.* classes, a TCK run isn't needed because the TCK doesn't check com.sun.* classes. ?On 8/11/20, 7:43 AM, "Zhengyu Gu" wrote: On 8/11/20 3:35 AM, Langer, Christoph wrote: > Hi Zhengyu, > > I have now created CSR JDK-8251380 for 11u and JDK-8251270 is 8u again, back on your name. Thanks. > > I think, we should not do changes to src/share/classes/javax/naming/directory/InitialDirContext.java. The changes are Javadoc only but they'd alter the spec, so we rather should not touch that file. I've also stated in the CSRs that the file isn't touched by the backports. > I agree. I tried to edit comments to refer new classes, it stroke me that it is wrong to have public API referring implementation specific classes. > As for failing tests - I also see some in 11u. The initial version was a bit shaky, I guess. There are follow up fixes which have been backported by Oracle as well (JDK-8139965, JDK- 8237834). I'll pick these for 11u, too. > I think I fixed the test in 8u, now it passes jdk_other. I am pondering if we need a TCK run. Thanks, -Zhengyu > Best regards > Christoph > >> -----Original Message----- >> From: Zhengyu Gu >> Sent: Montag, 10. August 2020 15:35 >> To: Langer, Christoph ; Hohensee, Paul >> ; jdk8u-dev >> Subject: Re: [8u] RFR 8160768: Add capability to custom resolve host/domain >> names within the default JNDI LDAP provider >> >> >> >> On 8/10/20 9:25 AM, Langer, Christoph wrote: >>> Hi Zhengyu, >>> >>> as has been pointed out, you'll need to move the two classes from package >> javax.naming.ldap.spi into package com.sun.jndi.ldap.spi. >> Yes. My latest webrev: >> >> http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.02/ >> http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webrev.01/ >> >> but LdapDnsProviderTest.java test failed with connection denial, looks >> like there may be security implications. >> >> Thanks, >> >> -Zhengyu >> >>> >>> After all, 8u backport should be easier than 11u backport for this patch >> since there's no implication with export restrictions from platform modules in >> JDK8 ?? >>> >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: jdk8u-dev On Behalf Of >> Zhengyu >>>> Gu >>>> Sent: Mittwoch, 5. August 2020 15:49 >>>> To: Hohensee, Paul ; jdk8u-dev >>> dev at openjdk.java.net> >>>> Cc: 1983-01-06 at gmx.net >>>> Subject: Re: [8u] RFR 8160768: Add capability to custom resolve >> host/domain >>>> names within the default JNDI LDAP provider >>>> >>>> Hi Paul, >>>> >>>> Sorry for replying late. Somehow, this email slipped through the cracks, >>>> and thanks Michael for bringing it to my attention. >>>> >>>> >>>> On 7/13/20 5:27 PM, Hohensee, Paul wrote: >>>>> The webrev looks it's corrupted. E.g., it includes the changes from >> 8217606, >>>> and not the InitialDirContext.java and CheckConfigs.policy changes you >>>> mention. >>>> >>>> It had dependence on 8217606, now it is pushed, so that the webrev is >>>> much cleaner. >>>> >>>> Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768- >> 8u/jdk/webrev.01/ >>>> >>>> Test: >>>> Reran jdk_other. >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> >>>> >>>>> >>>>> Paul >>>>> >>>>> On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" >>> retn at openjdk.java.net on behalf of zgu at redhat.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I would like to backport this patch to 8u for parity with Oracle 8u261. >>>>> >>>>> The original patch does not apply cleanly. >>>>> >>>>> Other than a couple of minor conflicts: >>>>> >>>>> 1) Comments in InitialDirContext.java did not apply cleanly >>>>> 2) Unpatched CheckConfigs.policy files did not match >>>>> >>>>> I made following modification for 8u: >>>>> >>>>> 1) Removed module-info.java section, it does not apply to 8u. >>>>> 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs >>>>> (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the >>>>> code with ArrayList. >>>>> 3) Removed @modules annotation in LdapDnsProviderTest.java >>>>> >>>>> Additional, I need to modify langtools to get javac to take >>>>> com.sun.jndi.ldap.spi package and complain about it. >>>>> >>>>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 >>>>> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a >>>>> >>>>> 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768- >>>> 8u/jdk/webrev.00/ >>>>> 8u langtools webrev: >>>>> http://cr.openjdk.java.net/~zgu/JDK-8160768- >> 8u/langtools/webev.00/ >>>>> >>>>> >>>>> Test: >>>>> jdk_other on Linux x86_64 >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>>> >>>>> >>> > From zgu at redhat.com Tue Aug 11 15:01:05 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 11 Aug 2020 11:01:05 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> Message-ID: <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> Hi, Webrevs are updated to reflect CSR[1]. jdk: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.02/ langtools: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webrev.01/ 1) Instead of public APIs, LdapDnsProvider and LdapDnsProviderResult are implementation specific classes, under com.sun.jdni.ldap.spi package. 2) Reverted InitialDirContext.java changes. They are comment only changes. Since InitialDirContext is a public API, should not refer implementation specific information. 3) Updated tests to reflect (1) Test: jdk_other on Linux x86_64 (include new tests) Thanks, -Zhengyu [1] https://bugs.openjdk.java.net/browse/JDK-8251270 On 8/6/20 4:40 PM, Hohensee, Paul wrote: > In InitialDirContext.java, the new comments use @code instead of the pair prevalent in JDK 8. Would be worth checking the Javadoc to see if there's any real difference. If there is, replace the @code uses with pairs. Fwiw, I've done that when backporting javadoc before. > > I ran the test/com/sun/jndi/ldap/ tests with your patch on my Linux box. Your new tests pass, the old ones perform the same as before the patch. > > ?On 8/5/20, 6:52 AM, "Zhengyu Gu" wrote: > > Hi Paul, > > Sorry for replying late. Somehow, this email slipped through the cracks, > and thanks Michael for bringing it to my attention. > > > On 7/13/20 5:27 PM, Hohensee, Paul wrote: > > The webrev looks it's corrupted. E.g., it includes the changes from 8217606, and not the InitialDirContext.java and CheckConfigs.policy changes you mention. > > It had dependence on 8217606, now it is pushed, so that the webrev is > much cleaner. > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.01/ > > Test: > Reran jdk_other. > > Thanks, > > -Zhengyu > > > > > > > Paul > > > > On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > > > Hi, > > > > I would like to backport this patch to 8u for parity with Oracle 8u261. > > > > The original patch does not apply cleanly. > > > > Other than a couple of minor conflicts: > > > > 1) Comments in InitialDirContext.java did not apply cleanly > > 2) Unpatched CheckConfigs.policy files did not match > > > > I made following modification for 8u: > > > > 1) Removed module-info.java section, it does not apply to 8u. > > 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs > > (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the > > code with ArrayList. > > 3) Removed @modules annotation in LdapDnsProviderTest.java > > > > Additional, I need to modify langtools to get javac to take > > com.sun.jndi.ldap.spi package and complain about it. > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 > > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a > > > > 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.00/ > > 8u langtools webrev: > > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webev.00/ > > > > > > Test: > > jdk_other on Linux x86_64 > > > > Thanks, > > > > -Zhengyu > > > > > > > > From zgu at redhat.com Tue Aug 11 15:02:28 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 11 Aug 2020 11:02:28 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: References: Message-ID: <9b2b9faa-cf34-1b96-06de-41ba531d6f7c@redhat.com> On 8/11/20 10:46 AM, Hohensee, Paul wrote: > If you have changed only com.sun.* classes, a TCK run isn't needed because the TCK doesn't check com.sun.* classes. Good. Thanks, Paul! -Zhengyu > > ?On 8/11/20, 7:43 AM, "Zhengyu Gu" wrote: > > On 8/11/20 3:35 AM, Langer, Christoph wrote: > > Hi Zhengyu, > > > > I have now created CSR JDK-8251380 for 11u and JDK-8251270 is 8u again, back on your name. > > Thanks. > > > > > I think, we should not do changes to src/share/classes/javax/naming/directory/InitialDirContext.java. The changes are Javadoc only but they'd alter the spec, so we rather should not touch that file. I've also stated in the CSRs that the file isn't touched by the backports. > > > I agree. I tried to edit comments to refer new classes, it stroke me > that it is wrong to have public API referring implementation specific > classes. > > > As for failing tests - I also see some in 11u. The initial version was a bit shaky, I guess. There are follow up fixes which have been backported by Oracle as well (JDK-8139965, JDK- 8237834). I'll pick these for 11u, too. > > > > I think I fixed the test in 8u, now it passes jdk_other. I am pondering > if we need a TCK run. > > Thanks, > > -Zhengyu > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: Zhengyu Gu > >> Sent: Montag, 10. August 2020 15:35 > >> To: Langer, Christoph ; Hohensee, Paul > >> ; jdk8u-dev > >> Subject: Re: [8u] RFR 8160768: Add capability to custom resolve host/domain > >> names within the default JNDI LDAP provider > >> > >> > >> > >> On 8/10/20 9:25 AM, Langer, Christoph wrote: > >>> Hi Zhengyu, > >>> > >>> as has been pointed out, you'll need to move the two classes from package > >> javax.naming.ldap.spi into package com.sun.jndi.ldap.spi. > >> Yes. My latest webrev: > >> > >> http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.02/ > >> http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webrev.01/ > >> > >> but LdapDnsProviderTest.java test failed with connection denial, looks > >> like there may be security implications. > >> > >> Thanks, > >> > >> -Zhengyu > >> > >>> > >>> After all, 8u backport should be easier than 11u backport for this patch > >> since there's no implication with export restrictions from platform modules in > >> JDK8 ?? > >>> > >>> Best regards > >>> Christoph > >>> > >>>> -----Original Message----- > >>>> From: jdk8u-dev On Behalf Of > >> Zhengyu > >>>> Gu > >>>> Sent: Mittwoch, 5. August 2020 15:49 > >>>> To: Hohensee, Paul ; jdk8u-dev >>>> dev at openjdk.java.net> > >>>> Cc: 1983-01-06 at gmx.net > >>>> Subject: Re: [8u] RFR 8160768: Add capability to custom resolve > >> host/domain > >>>> names within the default JNDI LDAP provider > >>>> > >>>> Hi Paul, > >>>> > >>>> Sorry for replying late. Somehow, this email slipped through the cracks, > >>>> and thanks Michael for bringing it to my attention. > >>>> > >>>> > >>>> On 7/13/20 5:27 PM, Hohensee, Paul wrote: > >>>>> The webrev looks it's corrupted. E.g., it includes the changes from > >> 8217606, > >>>> and not the InitialDirContext.java and CheckConfigs.policy changes you > >>>> mention. > >>>> > >>>> It had dependence on 8217606, now it is pushed, so that the webrev is > >>>> much cleaner. > >>>> > >>>> Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768- > >> 8u/jdk/webrev.01/ > >>>> > >>>> Test: > >>>> Reran jdk_other. > >>>> > >>>> Thanks, > >>>> > >>>> -Zhengyu > >>>> > >>>> > >>>> > >>>>> > >>>>> Paul > >>>>> > >>>>> On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" >>>> retn at openjdk.java.net on behalf of zgu at redhat.com> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I would like to backport this patch to 8u for parity with Oracle 8u261. > >>>>> > >>>>> The original patch does not apply cleanly. > >>>>> > >>>>> Other than a couple of minor conflicts: > >>>>> > >>>>> 1) Comments in InitialDirContext.java did not apply cleanly > >>>>> 2) Unpatched CheckConfigs.policy files did not match > >>>>> > >>>>> I made following modification for 8u: > >>>>> > >>>>> 1) Removed module-info.java section, it does not apply to 8u. > >>>>> 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs > >>>>> (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the > >>>>> code with ArrayList. > >>>>> 3) Removed @modules annotation in LdapDnsProviderTest.java > >>>>> > >>>>> Additional, I need to modify langtools to get javac to take > >>>>> com.sun.jndi.ldap.spi package and complain about it. > >>>>> > >>>>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 > >>>>> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a > >>>>> > >>>>> 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768- > >>>> 8u/jdk/webrev.00/ > >>>>> 8u langtools webrev: > >>>>> http://cr.openjdk.java.net/~zgu/JDK-8160768- > >> 8u/langtools/webev.00/ > >>>>> > >>>>> > >>>>> Test: > >>>>> jdk_other on Linux x86_64 > >>>>> > >>>>> Thanks, > >>>>> > >>>>> -Zhengyu > >>>>> > >>>>> > >>>>> > >>> > > > > From mbalao at redhat.com Tue Aug 11 15:30:25 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 11 Aug 2020 12:30:25 -0300 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: <514443F9-4FCD-4AAA-830C-255B1481E6D1@azul.com> References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> <6210a318-6d57-de05-1d0f-20eed83eb6f0@redhat.com> <2c600b69-f208-a2d2-74fc-675491952e5a@redhat.com> <60b630c9-0e63-5879-774e-5460de1ffb02@redhat.com> <331164a9-4844-2b3d-05b5-0eb3b690e447@redhat.com> <514443F9-4FCD-4AAA-830C-255B1481E6D1@azul.com> Message-ID: Hi Alexey, On 8/11/20 11:11 AM, Alexey Bakhtin wrote: >> >> * test/jdk/ProblemList.txt (modified) >> * do we need to black-list those in JDK-8? > Agree. It should be updated but not at this step. > >> * test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java (modified) >> * I suggest including this change. > OK. Make sense. Removed in this step >> * test/jdk/java/net/httpclient/MockServer.java (modified) >> * Not strictly necessary. >> * test/jdk/sun/security/ec/TestEC.java (modified) >> * Do we need this change? > OK. Update of this test is included into the next step, but it would be better to remove it and add in the next step. Removed >> * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java (modified) >> * Do we need this change? >> * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.sh (modified) >> * Do we need this change? > Agree. Tests removed >> * test/jdk/sun/security/tools/keytool/PrintSSL.java (modified) >> * Looks like nice to have. > Agree. Test removed >> If you agree, we can handle this in a separated step. Also, in Step 11 I >> expect nothing but new files from JDK 11.0.7 without any changes. If you >> need modifications on top of these files, please include them on a >> separated step -so it's much easier for me to review-. >> > I think we can handle it in this step and add new version of the tests in Step 11 > I've some concerns regarding the file-replacement approach for these test files out of SSL categories. The reason is that together with the file-replacement we are bringing other changes not related to SSL, which may cause test failures or miss-documentation. For example, TestEC.java introduces a reference to 8168078 which is not even fixed in JDK-8 and a run-command with different arguments -which I guess is to test 8168078-. Another example is ClientAuth.java, which changes the way in which the SunPKCS11 security provider instance is created and loaded -is the mechanism used supported in JDK-8?-. In ClientAuth.sh most of the changes are tabs replacement but there are a few other that we would need to analyze. PrintSSL seems to bring many changes, which I'm certain that will require rework because 'jdk.test.lib.process.OutputAnalyzer' import is not the same in JDK-8. printssl.sh deletion was unintended? Even if we create a new step to revert these changes, I believe it's easier and more clean (and easier) to apply 8196584 changes affecting these files in a separated step, particularly because these changes are very small. As a result, I'm inclined to approve your Webrev.03. Does it make sense to you? Thanks, Martin.- From mbalao at redhat.com Tue Aug 11 15:43:05 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 11 Aug 2020 12:43:05 -0300 Subject: [8u] TLSv1.3 RFR: 8251341: Minimal Java specification change In-Reply-To: <046ABE72-88F7-4445-B127-226908AB5186@azul.com> References: <046ABE72-88F7-4445-B127-226908AB5186@azul.com> Message-ID: <9c2f9de7-2930-0aef-914b-2646a12e1d53@redhat.com> Hi Alexey, Thanks for proposing this change. On 8/11/20 5:17 AM, Alexey Bakhtin wrote: > Please review small patch required to update java specification for TLSv1.3 protocol > in the javax.net.ssl.ExtendedSSLSession class. > > Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251341/webrev.v0 > JBS task: https://bugs.openjdk.java.net/browse/JDK-8251341 > CSR: https://bugs.openjdk.java.net/browse/JDK-8248721 With this change we align the source code to what has been approved in the original TLS 1.3 CSR [1], that we've taken to the JKD-8 TLS 1.3 CSR [2]. Looks good to me. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8202625 [2] - https://bugs.openjdk.java.net/browse/JDK-8248721 From mbalao at redhat.com Tue Aug 11 15:47:02 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 11 Aug 2020 12:47:02 -0300 Subject: [8u] TLSv1.3 RFR: 8251341: Minimal Java specification change In-Reply-To: <9c2f9de7-2930-0aef-914b-2646a12e1d53@redhat.com> References: <046ABE72-88F7-4445-B127-226908AB5186@azul.com> <9c2f9de7-2930-0aef-914b-2646a12e1d53@redhat.com> Message-ID: <48f6ac19-0279-5bc0-77a0-98e8c627ae12@redhat.com> On 8/11/20 12:43 PM, Martin Balao wrote: > Hi Alexey, > > Thanks for proposing this change. > > On 8/11/20 5:17 AM, Alexey Bakhtin wrote: >> Please review small patch required to update java specification for TLSv1.3 protocol >> in the javax.net.ssl.ExtendedSSLSession class. >> >> Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251341/webrev.v0 >> JBS task: https://bugs.openjdk.java.net/browse/JDK-8251341 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8248721 > > With this change we align the source code to what has been approved in > the original TLS 1.3 CSR [1], that we've taken to the JKD-8 TLS 1.3 CSR [2]. > > Looks good to me. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8202625 > [2] - https://bugs.openjdk.java.net/browse/JDK-8248721 > Note: I'll refer to 8251341 as Step 13 From mbalao at redhat.com Tue Aug 11 15:59:33 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 11 Aug 2020 12:59:33 -0300 Subject: [8u] TLSv1.3 RFR: 8233621: Mismatch in jsse.enableMFLNExtension property name In-Reply-To: <046D3A63-0991-48F6-940B-7A6BE6840A93@azul.com> References: <046D3A63-0991-48F6-940B-7A6BE6840A93@azul.com> Message-ID: <65b0a2a6-9769-09a9-c21c-1c35ad951ced@redhat.com> Hi Alexey, Thanks for proposing this patch. On 8/11/20 5:05 AM, Alexey Bakhtin wrote: > This is backport of JDK-8233621 [1]. Original patch applies cleanly > except of location of modified file. > > Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251340/webrev.v0 > JBS task: https://bugs.openjdk.java.net/browse/JDK-8251340 > CSR: https://bugs.openjdk.java.net/browse/JDK-8248721 > > [1] - https://bugs.openjdk.java.net/browse/JDK-8233621 There are no differences with the main line patch and applies cleanly (modulo path). Looks good to me. Please include the same commit message, author, reviewer, etc. than in 8233621. Thanks, Martin.- From mbalao at redhat.com Tue Aug 11 16:01:53 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 11 Aug 2020 13:01:53 -0300 Subject: [8u] TLSv1.3 RFR: 8233621: Mismatch in jsse.enableMFLNExtension property name In-Reply-To: <65b0a2a6-9769-09a9-c21c-1c35ad951ced@redhat.com> References: <046D3A63-0991-48F6-940B-7A6BE6840A93@azul.com> <65b0a2a6-9769-09a9-c21c-1c35ad951ced@redhat.com> Message-ID: <8a16d1ad-1688-db27-3be6-cc2592f9c2a2@redhat.com> On 8/11/20 12:59 PM, Martin Balao wrote: > Hi Alexey, > > Thanks for proposing this patch. > > On 8/11/20 5:05 AM, Alexey Bakhtin wrote: >> This is backport of JDK-8233621 [1]. Original patch applies cleanly >> except of location of modified file. >> >> Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251340/webrev.v0 >> JBS task: https://bugs.openjdk.java.net/browse/JDK-8251340 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8248721 >> >> [1] - https://bugs.openjdk.java.net/browse/JDK-8233621 > > There are no differences with the main line patch and applies cleanly > (modulo path). > > Looks good to me. > > Please include the same commit message, author, reviewer, etc. than in > 8233621. > > Thanks, > Martin.- > Note: I'll refer to 8233621 as Step 14. From alexey at azul.com Tue Aug 11 16:51:10 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 11 Aug 2020 16:51:10 +0000 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> <6210a318-6d57-de05-1d0f-20eed83eb6f0@redhat.com> <2c600b69-f208-a2d2-74fc-675491952e5a@redhat.com> <60b630c9-0e63-5879-774e-5460de1ffb02@redhat.com> <331164a9-4844-2b3d-05b5-0eb3b690e447@redhat.com> <514443F9-4FCD-4AAA-830C-255B1481E6D1@azul.com> Message-ID: Hi Martin, OK. We can postpone update of these tests. So, please forget webrev.v4 and proceed with webrev.v3 Regards Alexey > On 11 Aug 2020, at 18:30, Martin Balao wrote: > > Hi Alexey, > > On 8/11/20 11:11 AM, Alexey Bakhtin wrote: >>> >>> * test/jdk/ProblemList.txt (modified) >>> * do we need to black-list those in JDK-8? >> Agree. It should be updated but not at this step. >> >>> * test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java (modified) >>> * I suggest including this change. >> OK. Make sense. Removed in this step >>> * test/jdk/java/net/httpclient/MockServer.java (modified) >>> * Not strictly necessary. >>> * test/jdk/sun/security/ec/TestEC.java (modified) >>> * Do we need this change? >> OK. Update of this test is included into the next step, but it would be better to remove it and add in the next step. Removed >>> * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java (modified) >>> * Do we need this change? >>> * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.sh (modified) >>> * Do we need this change? >> Agree. Tests removed >>> * test/jdk/sun/security/tools/keytool/PrintSSL.java (modified) >>> * Looks like nice to have. >> Agree. Test removed >>> If you agree, we can handle this in a separated step. Also, in Step 11 I >>> expect nothing but new files from JDK 11.0.7 without any changes. If you >>> need modifications on top of these files, please include them on a >>> separated step -so it's much easier for me to review-. >>> >> I think we can handle it in this step and add new version of the tests in Step 11 >> > > I've some concerns regarding the file-replacement approach for these > test files out of SSL categories. The reason is that together with the > file-replacement we are bringing other changes not related to SSL, which > may cause test failures or miss-documentation. For example, TestEC.java > introduces a reference to 8168078 which is not even fixed in JDK-8 and a > run-command with different arguments -which I guess is to test 8168078-. > Another example is ClientAuth.java, which changes the way in which the > SunPKCS11 security provider instance is created and loaded -is the > mechanism used supported in JDK-8?-. In ClientAuth.sh most of the > changes are tabs replacement but there are a few other that we would > need to analyze. PrintSSL seems to bring many changes, which I'm certain > that will require rework because 'jdk.test.lib.process.OutputAnalyzer' > import is not the same in JDK-8. printssl.sh deletion was unintended? > > Even if we create a new step to revert these changes, I believe it's > easier and more clean (and easier) to apply 8196584 changes affecting > these files in a separated step, particularly because these changes are > very small. > > As a result, I'm inclined to approve your Webrev.03. Does it make sense > to you? > > Thanks, > Martin.- > From zgu at redhat.com Tue Aug 11 18:16:28 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 11 Aug 2020 14:16:28 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: References: <9b2b9faa-cf34-1b96-06de-41ba531d6f7c@redhat.com> Message-ID: <0203d22a-56ae-53aa-c724-f977344ee6d0@redhat.com> On 8/11/20 1:29 PM, Langer, Christoph wrote: > Hi, > > I agree that a JCK run isn't necessary if we don't touch things in javax.naming.*. Though it probably won't hurt ?? > > I have one question regarding the langtools changes: Would not having these changes prevent the jdk change from building? Right, without the changes, tests won't build. > > Also, could you share the latest webrev? jdk: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.02/ langtools: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webrev.01/ Thanks, -Zhengyu > > Best regards > Christoph > >> -----Original Message----- >> From: Zhengyu Gu >> Sent: Dienstag, 11. August 2020 17:02 >> To: Hohensee, Paul ; Langer, Christoph >> ; jdk8u-dev >> Cc: Severin Gehwolf >> Subject: Re: [8u] RFR 8160768: Add capability to custom resolve host/domain >> names within the default JNDI LDAP provider >> >> >> On 8/11/20 10:46 AM, Hohensee, Paul wrote: >>> If you have changed only com.sun.* classes, a TCK run isn't needed >> because the TCK doesn't check com.sun.* classes. >> >> Good. Thanks, Paul! >> >> -Zhengyu >> >>> >>> ?On 8/11/20, 7:43 AM, "Zhengyu Gu" wrote: >>> >>> On 8/11/20 3:35 AM, Langer, Christoph wrote: >>> > Hi Zhengyu, >>> > >>> > I have now created CSR JDK-8251380 for 11u and JDK-8251270 is 8u >> again, back on your name. >>> >>> Thanks. >>> >>> > >>> > I think, we should not do changes to >> src/share/classes/javax/naming/directory/InitialDirContext.java. The >> changes are Javadoc only but they'd alter the spec, so we rather should not >> touch that file. I've also stated in the CSRs that the file isn't touched by the >> backports. >>> > >>> I agree. I tried to edit comments to refer new classes, it stroke me >>> that it is wrong to have public API referring implementation specific >>> classes. >>> >>> > As for failing tests - I also see some in 11u. The initial version was a bit >> shaky, I guess. There are follow up fixes which have been backported by >> Oracle as well (JDK-8139965, JDK- 8237834). I'll pick these for 11u, too. >>> > >>> >>> I think I fixed the test in 8u, now it passes jdk_other. I am pondering >>> if we need a TCK run. >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> > Best regards >>> > Christoph >>> > >>> >> -----Original Message----- >>> >> From: Zhengyu Gu >>> >> Sent: Montag, 10. August 2020 15:35 >>> >> To: Langer, Christoph ; Hohensee, Paul >>> >> ; jdk8u-dev > dev at openjdk.java.net> >>> >> Subject: Re: [8u] RFR 8160768: Add capability to custom resolve >> host/domain >>> >> names within the default JNDI LDAP provider >>> >> >>> >> >>> >> >>> >> On 8/10/20 9:25 AM, Langer, Christoph wrote: >>> >>> Hi Zhengyu, >>> >>> >>> >>> as has been pointed out, you'll need to move the two classes from >> package >>> >> javax.naming.ldap.spi into package com.sun.jndi.ldap.spi. >>> >> Yes. My latest webrev: >>> >> >>> >> http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.02/ >>> >> http://cr.openjdk.java.net/~zgu/JDK-8160768- >> 8u/langtools/webrev.01/ >>> >> >>> >> but LdapDnsProviderTest.java test failed with connection denial, >> looks >>> >> like there may be security implications. >>> >> >>> >> Thanks, >>> >> >>> >> -Zhengyu >>> >> >>> >>> >>> >>> After all, 8u backport should be easier than 11u backport for this >> patch >>> >> since there's no implication with export restrictions from platform >> modules in >>> >> JDK8 ?? >>> >>> >>> >>> Best regards >>> >>> Christoph >>> >>> >>> >>>> -----Original Message----- >>> >>>> From: jdk8u-dev On Behalf >> Of >>> >> Zhengyu >>> >>>> Gu >>> >>>> Sent: Mittwoch, 5. August 2020 15:49 >>> >>>> To: Hohensee, Paul ; jdk8u-dev >> >>>> dev at openjdk.java.net> >>> >>>> Cc: 1983-01-06 at gmx.net >>> >>>> Subject: Re: [8u] RFR 8160768: Add capability to custom resolve >>> >> host/domain >>> >>>> names within the default JNDI LDAP provider >>> >>>> >>> >>>> Hi Paul, >>> >>>> >>> >>>> Sorry for replying late. Somehow, this email slipped through the >> cracks, >>> >>>> and thanks Michael for bringing it to my attention. >>> >>>> >>> >>>> >>> >>>> On 7/13/20 5:27 PM, Hohensee, Paul wrote: >>> >>>>> The webrev looks it's corrupted. E.g., it includes the changes from >>> >> 8217606, >>> >>>> and not the InitialDirContext.java and CheckConfigs.policy changes >> you >>> >>>> mention. >>> >>>> >>> >>>> It had dependence on 8217606, now it is pushed, so that the >> webrev is >>> >>>> much cleaner. >>> >>>> >>> >>>> Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768- >>> >> 8u/jdk/webrev.01/ >>> >>>> >>> >>>> Test: >>> >>>> Reran jdk_other. >>> >>>> >>> >>>> Thanks, >>> >>>> >>> >>>> -Zhengyu >>> >>>> >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> Paul >>> >>>>> >>> >>>>> On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" >> >> >>>> retn at openjdk.java.net on behalf of zgu at redhat.com> wrote: >>> >>>>> >>> >>>>> Hi, >>> >>>>> >>> >>>>> I would like to backport this patch to 8u for parity with Oracle >> 8u261. >>> >>>>> >>> >>>>> The original patch does not apply cleanly. >>> >>>>> >>> >>>>> Other than a couple of minor conflicts: >>> >>>>> >>> >>>>> 1) Comments in InitialDirContext.java did not apply cleanly >>> >>>>> 2) Unpatched CheckConfigs.policy files did not match >>> >>>>> >>> >>>>> I made following modification for 8u: >>> >>>>> >>> >>>>> 1) Removed module-info.java section, it does not apply to 8u. >>> >>>>> 2) LdapDnsProvider.java and LdapDnsProviderResult.java use >> APIs >>> >>>>> (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote >> the >>> >>>>> code with ArrayList. >>> >>>>> 3) Removed @modules annotation in >> LdapDnsProviderTest.java >>> >>>>> >>> >>>>> Additional, I need to modify langtools to get javac to take >>> >>>>> com.sun.jndi.ldap.spi package and complain about it. >>> >>>>> >>> >>>>> Original bug: https://bugs.openjdk.java.net/browse/JDK- >> 8160768 >>> >>>>> Original patch: >> http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a >>> >>>>> >>> >>>>> 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768- >>> >>>> 8u/jdk/webrev.00/ >>> >>>>> 8u langtools webrev: >>> >>>>> http://cr.openjdk.java.net/~zgu/JDK-8160768- >>> >> 8u/langtools/webev.00/ >>> >>>>> >>> >>>>> >>> >>>>> Test: >>> >>>>> jdk_other on Linux x86_64 >>> >>>>> >>> >>>>> Thanks, >>> >>>>> >>> >>>>> -Zhengyu >>> >>>>> >>> >>>>> >>> >>>>> >>> >>> >>> > >>> >>> > From zgu at redhat.com Tue Aug 11 18:48:46 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 11 Aug 2020 14:48:46 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> Message-ID: Hi Michael, > My tests/comments: > * @since still says 12. Is that correct? > * Should LdapDnsProvider and LdapDnsProviderResult document that they > have been moved in 12? Right. I am not sure about that. Paul and Christoph, anything suggestions? > which relies on A records only and cannot be used to perform > GSS-API/Kerberos authentication afterwards. > > You have my approval. Thanks! -Zhengyu > > Thank you very much for pursuing this! > > Michael > From mbalao at redhat.com Tue Aug 11 19:03:42 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 11 Aug 2020 16:03:42 -0300 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> <5DDFFF95-2ABB-40A7-B8FB-E81DEC37A6AA@azul.com> <6210a318-6d57-de05-1d0f-20eed83eb6f0@redhat.com> <2c600b69-f208-a2d2-74fc-675491952e5a@redhat.com> <60b630c9-0e63-5879-774e-5460de1ffb02@redhat.com> <331164a9-4844-2b3d-05b5-0eb3b690e447@redhat.com> <514443F9-4FCD-4AAA-830C-255B1481E6D1@azul.com> Message-ID: <1918acca-7389-3abe-381e-417cf8ee4ed3@redhat.com> Hi, The goal of Step 10 - 8245653 is to remove those SSL-related test files that have changed in JDK-11 (11.0.7), so we can replace them with the new version in Step 11 - 8245681. With SSL-related test we mean the following test categories: * test/com/sun/net/ssl * test/javax/net/ssl * test/sun/net/www/protocol/https * test/sun/security/ssl * test/sun/security/pkcs11/sslecc Check that Step 10 only contains deleted files (no new files nor modifications): * Ok * There are a few 'modification' exceptions that were manually reviewed. All of them are opportunistic minor changes (such as removing unused imports) requested in the previous review comments, and overall help to improve the alignment between JDK-8 and JDK-11 version of the same tests. Check that all deleted files were effectively changed in JDK-11: * test/com/sun/net/ssl * Ok * test/javax/net/ssl * Ok * test/sun/net/www/protocol/https * Ok * test/sun/security/ssl * Ok * test/sun/security/pkcs11/sslecc * Ok Check that there are no files changed in JDK-11 that were not deleted here: * test/com/sun/net/ssl * Ok * test/javax/net/ssl * Ok * test/sun/net/www/protocol/https * Ok * test/sun/security/ssl * Ok * test/sun/security/pkcs11/sslecc * Ok Check there are no SSL-related tests in JDK-8 not present in JDK-11: * test/com/sun/net/ssl * Ok * test/javax/net/ssl * Ok * test/sun/net/www/protocol/https * Ok * test/sun/security/ssl * Ok * test/sun/security/pkcs11/sslecc * Ok Check that TLS 1.3 patch (8196584) do not affect other tests out of SSL-related test categories: * test/jdk/sun/security/krb5/auto * In JDK-8 we won't delete SSL-related tests in this category because we offer backward-compatibility support for Kerberos cipher suites. In Step 11+ I'll check that we have no regressions here -if I'm right, Alexey already checked that in the context of Step 7-. * Changes on the following files will be addressed at a later step: * test/jdk/ProblemList.txt * test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java * test/jdk/java/net/httpclient/MockServer.java * Opportunistic change in debug prints. Not strictly necessary but we may include it as well. * test/jdk/sun/security/ec/TestEC.java * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.sh * test/jdk/sun/security/tools/keytool/PrintSSL.java Other comments that are part of this review: [1], [2], [3] and [4]. With that said, Step 10 - 8245653 Webrev.03 looks good to me. NOTE: Webrev.04 won't be used, for the reasons expressed in [5]. Thanks, Martin.- -- [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012305.html [2] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012338.html [3] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012397.html [4] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012402.html [5] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012416.html From alvdavi at amazon.com Tue Aug 11 22:13:16 2020 From: alvdavi at amazon.com (David Alvarez) Date: Tue, 11 Aug 2020 15:13:16 -0700 Subject: 0 values for Font.getStringBounds() In-Reply-To: <031036E3485502418107574F2C750F23025ACAEAD5@srvmx01.imagic.local> References: <031036E3485502418107574F2C750F23025ACAEAD5@srvmx01.imagic.local> Message-ID: Hi, We have seen this can cause characters to overlap on swing when using large fonts too. It seems JDK-8225286, which was backported into 8, introduced the issue. It seems to me we might need to backport JDK-8233097 [1] in order to fix this. -- David [1] https://bugs.openjdk.java.net/browse/JDK-8233097 On 2020-08-10 02:15, Peter Felix wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > I?d like to report a bug based on Font.getStringBounds(). > > With the following lines it is reproducible: > > String test = "abcdefghijklmnopqrstuvwxyz "; > Font f = new Font("Arial", 0, 1560); > int[] widths = new int[test.length()]; > for (int i = 0; i < widths.length; i++) { > FontRenderContext context = new FontRenderContext(new AffineTransform(1, 0, 0, 1, 0, 0), true, true); > double w = f.getStringBounds(test, i, i + 1, context).getWidth(); > widths[i] = (int) w; > } > > for (int i = 0; i < widths.length; i++) { > System.out.print(widths[i] + " "); > } > > > Output ok (with Amazon Corretto 8.202): > 867 867 780 867 867 433 867 867 346 346 780 346 1299 867 867 867 867 519 780 433 867 780 1126 780 780 780 433 > If I set the font size to 3000 instead of 1560 then the output is > 1668 1668 1500 1668 1668 833 1668 1668 666 666 1500 666 2499 1668 1668 1668 1668 999 1500 833 1668 1500 2166 1500 1500 1500 833 > If I set the font size to 100 instead of 1560 then the output is > 55 55 50 55 55 27 55 55 22 22 50 22 83 55 55 55 55 33 50 27 55 50 72 50 50 50 27 > > > Output nok (with Amazon Corretto 8.232, 8.252, 8.265 and with AdoptOpenJDK 8.265): > 867 0 780 0 867 0 0 0 0 0 0 0 0 867 867 0 0 519 780 0 867 780 0 780 0 780 433 > If I set the font size to 3000 instead of 1560 then the output is > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 833 > If I set the font size to 100 instead of 1560 then the output is (with this size the values are ok) > 55 55 50 55 55 27 55 55 22 22 50 22 83 55 55 55 55 33 50 27 55 50 72 50 50 50 27 > > Thanks, > > Peter Felix > > Software-Entwickler > > > > Telefon: > > +41 44 809 40 60 > > E-Mail: felix at imagic.ch > > > > Imagic Bildverarbeitung AG > > Europa-Strasse 27 > > CH-8152 Glattbrugg > > > > www.imagic.ch > > [LinkedIn] [xing_share_button3] > > > From gnu.andrew at redhat.com Wed Aug 12 02:56:18 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 12 Aug 2020 03:56:18 +0100 Subject: [8u] RFR: 8203357: Container Metrics In-Reply-To: References: <29d81a510f5ffb7bd7df5f3937f722ad3f383560.camel@redhat.com> <1008cf64b07601f39ac83674cfba6ad17089498d.camel@redhat.com> <20200807050149.GB646601@stopbrexit> Message-ID: <20200812025618.GA2371920@stopbrexit> On 14:05 Fri 07 Aug , Severin Gehwolf wrote: snip... > > > > Action items; just the missing copyright header, AFAICS. > > Thanks! Fixed in webrev 03: > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/03/webrev/ > > Thanks, > Severin > Thanks. This looks good. Please flag with jdk8u-fix-request. -- Andrew :) Senior 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 From felix at imagic.ch Wed Aug 12 06:22:25 2020 From: felix at imagic.ch (Peter Felix) Date: Wed, 12 Aug 2020 06:22:25 +0000 Subject: AW: 0 values for Font.getStringBounds() In-Reply-To: References: <031036E3485502418107574F2C750F23025ACAEAD5@srvmx01.imagic.local> Message-ID: <031036E3485502418107574F2C750F23025ACAF1D0@srvmx01.imagic.local> Hi David, thanks a lot for your answer. What have to be done that JDK-8233097 will be backported into 8? Thanks, Peter Peter Felix Software-Entwickler Telefon: +41 44 809 40 60 E-Mail: felix at imagic.ch Imagic Bildverarbeitung AG Europa-Strasse 27 CH-8152 Glattbrugg www.imagic.ch -----Urspr?ngliche Nachricht----- Von: David Alvarez Gesendet: Mittwoch, 12. August 2020 00:13 An: Peter Felix ; jdk8u-dev at openjdk.java.net Betreff: Re: 0 values for Font.getStringBounds() Hi, We have seen this can cause characters to overlap on swing when using large fonts too. It seems JDK-8225286, which was backported into 8, introduced the issue. It seems to me we might need to backport JDK-8233097 [1] in order to fix this. -- David [1] https://bugs.openjdk.java.net/browse/JDK-8233097 On 2020-08-10 02:15, Peter Felix wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > I?d like to report a bug based on Font.getStringBounds(). > > With the following lines it is reproducible: > > String test = "abcdefghijklmnopqrstuvwxyz "; Font f = new > Font("Arial", 0, 1560); int[] widths = new int[test.length()]; for > (int i = 0; i < widths.length; i++) { > FontRenderContext context = new FontRenderContext(new AffineTransform(1, 0, 0, 1, 0, 0), true, true); > double w = f.getStringBounds(test, i, i + 1, context).getWidth(); > widths[i] = (int) w; > } > > for (int i = 0; i < widths.length; i++) { > System.out.print(widths[i] + " "); } > > > Output ok (with Amazon Corretto 8.202): > 867 867 780 867 867 433 867 867 346 346 780 346 1299 867 867 867 867 > 519 780 433 867 780 1126 780 780 780 433 If I set the font size to > 3000 instead of 1560 then the output is > 1668 1668 1500 1668 1668 833 1668 1668 666 666 1500 666 2499 1668 1668 > 1668 1668 999 1500 833 1668 1500 2166 1500 1500 1500 833 If I set the > font size to 100 instead of 1560 then the output is > 55 55 50 55 55 27 55 55 22 22 50 22 83 55 55 55 55 33 50 27 55 50 72 > 50 50 50 27 > > > Output nok (with Amazon Corretto 8.232, 8.252, 8.265 and with AdoptOpenJDK 8.265): > 867 0 780 0 867 0 0 0 0 0 0 0 0 867 867 0 0 519 780 0 867 780 0 780 0 > 780 433 If I set the font size to 3000 instead of 1560 then the output > is > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 833 If I set the > font size to 100 instead of 1560 then the output is (with this size > the values are ok) > 55 55 50 55 55 27 55 55 22 22 50 22 83 55 55 55 55 33 50 27 55 50 72 > 50 50 50 27 > > Thanks, > > Peter Felix > > Software-Entwickler > > > > Telefon: > > +41 44 809 40 60 > > E-Mail: felix at imagic.ch > > > > Imagic Bildverarbeitung AG > > Europa-Strasse 27 > > CH-8152 Glattbrugg > > > > www.imagic.ch > > [LinkedIn] > [xing_share_button3] > > > > From sgehwolf at redhat.com Wed Aug 12 08:51:22 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 12 Aug 2020 10:51:22 +0200 Subject: [8u] RFR: 8203357: Container Metrics In-Reply-To: <20200812025618.GA2371920@stopbrexit> References: <29d81a510f5ffb7bd7df5f3937f722ad3f383560.camel@redhat.com> <1008cf64b07601f39ac83674cfba6ad17089498d.camel@redhat.com> <20200807050149.GB646601@stopbrexit> <20200812025618.GA2371920@stopbrexit> Message-ID: <494bf5aa2fdcb7c4336a12a01ec090810765d00a.camel@redhat.com> On Wed, 2020-08-12 at 03:56 +0100, Andrew Hughes wrote: > On 14:05 Fri 07 Aug , Severin Gehwolf wrote: > > snip... > > > > Action items; just the missing copyright header, AFAICS. > > > > Thanks! Fixed in webrev 03: > > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/03/webrev/ > > > > Thanks, > > Severin > > > > Thanks. This looks good. Please flag with jdk8u-fix-request. Thanks for the review. I've added the tags and a Fix Request comment. Cheers, Severin From alexey at azul.com Wed Aug 12 17:51:05 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 12 Aug 2020 17:51:05 +0000 Subject: [8u] TLSv1.3 RFR: 8245681: Add TLSv1.3 regression test from 11.0.7 In-Reply-To: References: <7D92607F-B8F0-4E84-B6C2-5E2AB4E42824@azul.com> <04f0d809-2f53-5335-9828-72b198bf369f@azul.com> Message-ID: Hello Martin, Please find new version of the patch for TLSv1.3 regression tests: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v2/ Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v2/jdk.git.diff This patch adds TLS related tests from JDK11.07 without any modification. This patch does not include: - DTLS tests: - javax/net/ssl/DTLS - javax/net/ssl/DTLSv10 - sun/security/ssl/SSLContextImpl - CustomizedDTLSDefaultProtocols.java - CustomizedDTLSServerDefaultProtocols.java - DefaultDTLSEnabledProtocols.java - javax/net/ssl/finalize: This test was added as part of JDK-8169416. Not related to TLSv1.3 implementation. Test uses unsupported Reference.reachabilityFence - javax/net/ssl/HttpsURLConnection/Equals.java This test was added as part of JDK-8055299. Not backported to JDK8 yet - MFLNTest tests: - javax/net/ssl/TLS/TLSMFLNTest.java - javax/net/ssl/TLS1/TLSMFLNTest.java - javax/net/ssl/TLS11/TLSMFLNTest.java These tests based on the SSLParameters.setMaximumPacketSize?() public API which is not available in JDK8: - TEST.properties files for different tests. These files are not required for JDK8 Regards Alexey > On 22 Jul 2020, at 21:44, Alexey Bakhtin wrote: > > Please find updated patch for TLSv1,3 regression tests: > http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v1 > > This version fixes test issues caused by client default disabled TLSv1.3 protocol : > - javax/net/ssl/SSLSession/ResumeTLS13withSNI.java > - javax/net/ssl/SSLSocket/Tls13PacketSize.java > - javax/net/ssl/Stapling/HttpsUrlConnClient.java > - javax/net/ssl/Stapling/SSLEngineWithStapling.java > - javax/net/ssl/Stapling/SSLSocketWithStapling.java > - javax/net/ssl/Stapling/StapleEnableProps.java > - javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java > > Also, this version reverts incorrectly modified sun/security/krb5/auto/SSL.java test > > Regards > Alexey > >> On 28 May 2020, at 19:56, Alexey Bakhtin wrote: >> >> Hello Dmitry, >> >> Yes, you are right. >> I?ve uploaded non-incremental webrev for the JDK-8245653 "Remove 8u TLS tests? by mistake. >> I?ve updated it in the same location : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v0/ >> >> JDK-8245681 should be applied cleanly now >> >> Thank you >> Alexey >> >> >>> On 28 May 2020, at 19:07, Dmitry Cherepanov wrote: >>> >>> Hi Alexey, >>> >>> On 24.05.2020 21:05, Alexey Bakhtin wrote: >>>> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u >>>> >>>> JBS task: https://bugs.openjdk.java.net/browse/JDK-8245681 >>>> Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v0/ >>>> >>>> This is a third part of TLS test update. >>> >>> When I tried to apply patches, I got conflicts in the last step. There are a lot of rejects due to the fact that new test files already exist. >>> >>> For example, the third part (of test update) adds new file - test/javax/net/ssl/ALPN/SSLEngineAlpnTest.java >>> which existed before and was moved by the first part (of test update) from test/sun/security/ssl/javax/net/ssl/ALPN/SSLEngineAlpnTest.java to test/javax/net/ssl/ALPN/SSLEngineAlpnTest.java >>> >>> Could you please double check that it's the latest version of webrev? >>> >>> Thanks >>> >>> Dmitry >>> > From alexey at azul.com Wed Aug 12 18:55:57 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 12 Aug 2020 18:55:57 +0000 Subject: [8u] TLSv1.3 RFR: 8251478: Backport TLSv1.3 regression tests to JDK8u Message-ID: <4E845CF2-E84F-413B-8193-64FD521BA647@azul.com> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u JBS task: https://bugs.openjdk.java.net/browse/JDK-8251478 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v0/ Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v0/jdk.git.diff This is a fourth part of TLS test update. This patch fixes JDK8 compatibility for the TLSv1.3 regression tests. Most of the fixes are : - removed @modules annotation - fixed path to libraries Specific test changes: - fixed KeyStore creation: - javax/net/ssl/SSLSession/RenegotiateTLS13.java: - sun/security/ssl/SSLEngineImpl/SSLEngineKeyImpl.java - sun/security/ssl/SSLEngineImpl/TLS13BeginHandshake.java - sun/security/ssl/SSLSocketImpl/SSLSocketKeyLimit.java - fixed ArrayList creation: - javax/net/ssl/SSLSession/ResumeTLS13withSNI.java - javax/net/ssl/Stapling/SSLEngineWithStapling.java - fixed JDK8 compatibility - javax/net/ssl/templates/SSLContextTemplate.java - added fix for the client default disabled TLSv1.3 protocol - javax/net/ssl/TLS/TLSClientPropertyTest.java - sun/security/ssl/SSLContextImpl/CustomizedServerDefaultProtocol.java - sun/security/ssl/SSLContextImpl/DefaultEnabledProtocols.java - fixed HttpsURLConnection API changes - sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java - added ?jdk.tls.client.protocols? cmdline options to fix client default disabled TLSv1.3 protocol: - javax/net/ssl/SSLSession/ResumeTLS13withSNI.java - javax/net/ssl/SSLSocket/TLS13PacketSize.java - javax/net/ssl/Stapling/HttpsUrlConnClient.java - javax/net/ssl/Stapling/SSLEngineWithStapling.java - javax/net/ssl/Stapling/SSLSocketWithStapling.java - javax/net/ssl/Stapling/StapleEnableProps.java - sun/security/ssl/SLSessionImpl/ResumeChecksClient.java - sun/security/ssl/SLSessionImpl/ResumeChecksServer.java - fixed issues related to DTLS specific API not available in JDK8: - javax/net/ssl/TLSCommon/Protocol.java - javax/net/ssl/TLSCommon/RehandshakeWithCipherChangeTest.java - javax/net/ssl/TLSCommon/RehandshakeWithDataExTest.java - javax/net/ssl/TLSCommon/SSLEngineTestCase.java - changed test run script: - sun/security/ssl/Stapling - sun/security/ssl/internal Regards Alexey From mbalao at redhat.com Wed Aug 12 20:27:44 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 12 Aug 2020 17:27:44 -0300 Subject: [8u] TLSv1.3 RFR: 8245681: Add TLSv1.3 regression test from 11.0.7 In-Reply-To: References: <7D92607F-B8F0-4E84-B6C2-5E2AB4E42824@azul.com> <04f0d809-2f53-5335-9828-72b198bf369f@azul.com> Message-ID: <0e9f68c6-dd0e-c2f7-50bf-28bf23a3a012@redhat.com> Hi Alexey, Thanks for proposing this patch. On 8/12/20 2:51 PM, Alexey Bakhtin wrote: > Please find new version of the patch for TLSv1.3 regression tests: > http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v2/ > Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v2/jdk.git.diff > > This patch adds TLS related tests from JDK11.07 without any modification. > This patch does not include: > - DTLS tests: > - javax/net/ssl/DTLS > - javax/net/ssl/DTLSv10 > - sun/security/ssl/SSLContextImpl > - CustomizedDTLSDefaultProtocols.java > - CustomizedDTLSServerDefaultProtocols.java > - DefaultDTLSEnabledProtocols.java Ok. > - javax/net/ssl/finalize: > This test was added as part of JDK-8169416. Not related to TLSv1.3 implementation. Test uses unsupported Reference.reachabilityFence Yeah, I see the problem. Contrary to MFLN (see below), I'm not that concerned about this test. I'm okay. > - javax/net/ssl/HttpsURLConnection/Equals.java > This test was added as part of JDK-8055299. Not backported to JDK8 yet Why? > - MFLNTest tests: > - javax/net/ssl/TLS/TLSMFLNTest.java > - javax/net/ssl/TLS1/TLSMFLNTest.java > - javax/net/ssl/TLS11/TLSMFLNTest.java > These tests based on the SSLParameters.setMaximumPacketSize?() public API which is not available in JDK8: We've introduced the MFLN extension with the new SunJSSE engine, so looks to me that these tests are important. Can you please point me to this dependency? We need to figure out a way of bypassing the dependency, even if we need to use non-public APIs. I'd only agree if we have a strong reason -but I hope we don't-. > - TEST.properties files for different tests. These files are not required for JDK8 Ok. In addition to the previous, I've noticed that Step 11 adds a few files not in previous SSL-related categories: * test/java/security/testlibrary/CertificateBuilder.java (new) * test/java/security/testlibrary/SimpleOCSPServer.java (new) * test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java (new) How did you find them? Seems that they are not part of 8196584 (original TLS 1.3 patch). My question is not only to judge these files but also to make sure that we are not missing anything. Thanks, Martin.- From alvdavi at amazon.com Wed Aug 12 21:40:03 2020 From: alvdavi at amazon.com (David Alvarez) Date: Wed, 12 Aug 2020 14:40:03 -0700 Subject: AW: 0 values for Font.getStringBounds() In-Reply-To: <031036E3485502418107574F2C750F23025ACAF1D0@srvmx01.imagic.local> References: <031036E3485502418107574F2C750F23025ACAEAD5@srvmx01.imagic.local> <031036E3485502418107574F2C750F23025ACAF1D0@srvmx01.imagic.local> Message-ID: Hi, It is already done, it should be included with 8u272. -- David On 2020-08-11 23:22, Peter Felix wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi David, > > thanks a lot for your answer. What have to be done that JDK-8233097 will be backported into 8? > > Thanks, > Peter > > Peter Felix > Software-Entwickler > > Telefon: > +41 44 809 40 60 > E-Mail: felix at imagic.ch > > Imagic Bildverarbeitung AG > Europa-Strasse 27 > CH-8152 Glattbrugg > > www.imagic.ch > > > > -----Urspr?ngliche Nachricht----- > Von: David Alvarez > Gesendet: Mittwoch, 12. August 2020 00:13 > An: Peter Felix ; jdk8u-dev at openjdk.java.net > Betreff: Re: 0 values for Font.getStringBounds() > > Hi, > > We have seen this can cause characters to overlap on swing when using large fonts too. It seems JDK-8225286, which was backported into 8, introduced the issue. > > It seems to me we might need to backport JDK-8233097 [1] in order to fix this. > > -- > David > > [1] https://bugs.openjdk.java.net/browse/JDK-8233097 > > On 2020-08-10 02:15, Peter Felix wrote: >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. >> >> >> >> I?d like to report a bug based on Font.getStringBounds(). >> >> With the following lines it is reproducible: >> >> String test = "abcdefghijklmnopqrstuvwxyz "; Font f = new >> Font("Arial", 0, 1560); int[] widths = new int[test.length()]; for >> (int i = 0; i < widths.length; i++) { >> FontRenderContext context = new FontRenderContext(new AffineTransform(1, 0, 0, 1, 0, 0), true, true); >> double w = f.getStringBounds(test, i, i + 1, context).getWidth(); >> widths[i] = (int) w; >> } >> >> for (int i = 0; i < widths.length; i++) { >> System.out.print(widths[i] + " "); } >> >> >> Output ok (with Amazon Corretto 8.202): >> 867 867 780 867 867 433 867 867 346 346 780 346 1299 867 867 867 867 >> 519 780 433 867 780 1126 780 780 780 433 If I set the font size to >> 3000 instead of 1560 then the output is >> 1668 1668 1500 1668 1668 833 1668 1668 666 666 1500 666 2499 1668 1668 >> 1668 1668 999 1500 833 1668 1500 2166 1500 1500 1500 833 If I set the >> font size to 100 instead of 1560 then the output is >> 55 55 50 55 55 27 55 55 22 22 50 22 83 55 55 55 55 33 50 27 55 50 72 >> 50 50 50 27 >> >> >> Output nok (with Amazon Corretto 8.232, 8.252, 8.265 and with AdoptOpenJDK 8.265): >> 867 0 780 0 867 0 0 0 0 0 0 0 0 867 867 0 0 519 780 0 867 780 0 780 0 >> 780 433 If I set the font size to 3000 instead of 1560 then the output >> is >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 833 If I set the >> font size to 100 instead of 1560 then the output is (with this size >> the values are ok) >> 55 55 50 55 55 27 55 55 22 22 50 22 83 55 55 55 55 33 50 27 55 50 72 >> 50 50 50 27 >> >> Thanks, >> >> Peter Felix >> >> Software-Entwickler >> >> >> >> Telefon: >> >> +41 44 809 40 60 >> >> E-Mail: felix at imagic.ch >> >> >> >> Imagic Bildverarbeitung AG >> >> Europa-Strasse 27 >> >> CH-8152 Glattbrugg >> >> >> >> www.imagic.ch >> >> [LinkedIn] >> [xing_share_button3] >> >> >> >> From alexey at azul.com Thu Aug 13 09:21:08 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 13 Aug 2020 09:21:08 +0000 Subject: [8u] TLSv1.3 RFR: 8245681: Add TLSv1.3 regression test from 11.0.7 In-Reply-To: <0e9f68c6-dd0e-c2f7-50bf-28bf23a3a012@redhat.com> References: <7D92607F-B8F0-4E84-B6C2-5E2AB4E42824@azul.com> <04f0d809-2f53-5335-9828-72b198bf369f@azul.com> <0e9f68c6-dd0e-c2f7-50bf-28bf23a3a012@redhat.com> Message-ID: <66A03F4D-3EC4-43D2-9B2B-33E1F6BEDFD1@azul.com> Hi Martin, Please see my comments below. Regards Alexey > On 12 Aug 2020, at 23:27, Martin Balao wrote: > > Hi Alexey, > > Thanks for proposing this patch. > > On 8/12/20 2:51 PM, Alexey Bakhtin wrote: >> Please find new version of the patch for TLSv1.3 regression tests: >> http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v2/ >> Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v2/jdk.git.diff >> >> This patch adds TLS related tests from JDK11.07 without any modification. >> This patch does not include: >> - DTLS tests: >> - javax/net/ssl/DTLS >> - javax/net/ssl/DTLSv10 >> - sun/security/ssl/SSLContextImpl >> - CustomizedDTLSDefaultProtocols.java >> - CustomizedDTLSServerDefaultProtocols.java >> - DefaultDTLSEnabledProtocols.java > > Ok. > >> - javax/net/ssl/finalize: >> This test was added as part of JDK-8169416. Not related to TLSv1.3 implementation. Test uses unsupported Reference.reachabilityFence > > Yeah, I see the problem. Contrary to MFLN (see below), I'm not that > concerned about this test. I'm okay. > >> - javax/net/ssl/HttpsURLConnection/Equals.java >> This test was added as part of JDK-8055299. Not backported to JDK8 yet > > Why? JDK-8055299 is not backported to JDK8u and not related to TLSv1.3 functionality. This fix can be backported separately > >> - MFLNTest tests: >> - javax/net/ssl/TLS/TLSMFLNTest.java >> - javax/net/ssl/TLS1/TLSMFLNTest.java >> - javax/net/ssl/TLS11/TLSMFLNTest.java >> These tests based on the SSLParameters.setMaximumPacketSize?() public API which is not available in JDK8: > > We've introduced the MFLN extension with the new SunJSSE engine, so > looks to me that these tests are important. Can you please point me to > this dependency? We need to figure out a way of bypassing the > dependency, even if we need to use non-public APIs. I'd only agree if we > have a strong reason -but I hope we don't-. TLSMFLNTest tests are based on the TLSCommon/SSLEngineTestCase.java class. SSLEngineTestCase uses SSLParameters.setMaximumPacketSize() to change default Max Fragment Length. Actually, it is interesting situation. It seems MFL can be set with SSLParameters.setMaximumPacketSize() API only. This API is not available in JDK8u and MFLNExtension is not usable without this API (client sends MFLNExtension if it is not default only) So, we need custom API to set/get MaxPacketSize or exclude MFLNExtension functionality from the implementation. > >> - TEST.properties files for different tests. These files are not required for JDK8 > > Ok. > > In addition to the previous, I've noticed that Step 11 adds a few files > not in previous SSL-related categories: > > * test/java/security/testlibrary/CertificateBuilder.java (new) > * test/java/security/testlibrary/SimpleOCSPServer.java (new) These classes used by javax/net/ssl/Stapling and sun/security/ssl/Stapling tests These classes was added as part of JDK-8046321: OCSP Stapling for TLS > * test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java (new) This class should be excluded. It is used by javax/net/ssl/HttpsURLConnection/Equals.java which is not added in this step, so SimpleSSLContext.java is not required > > How did you find them? I've found these classes by running and fixing test dependency > Seems that they are not part of 8196584 (original > TLS 1.3 patch). My question is not only to judge these files but also to > make sure that we are not missing anything. > > Thanks, > Martin.- > From sgehwolf at redhat.com Thu Aug 13 09:51:55 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 13 Aug 2020 11:51:55 +0200 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> Message-ID: <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> On Tue, 2020-08-11 at 14:48 -0400, Zhengyu Gu wrote: > Hi Michael, > > > My tests/comments: > > * @since still says 12. Is that correct? I agree. Zhengyu, please remove the @since 12 tags in this backport. It doesn't make sense to have them in either 11 or 8. > > * Should LdapDnsProvider and LdapDnsProviderResult document that they > > have been moved in 12? > > Right. I am not sure about that. Paul and Christoph, anything suggestions? I don't think this should be documented in JDK head (which would be JDK 16 now). After all, JDK 11 and JDK 8 fixes are *backports* of the original fix in JDK 12. I'm afraid, this is something for users to know and adjust accordingly for later JDK migrations. Thanks, Severin From zgu at redhat.com Thu Aug 13 12:49:57 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 13 Aug 2020 08:49:57 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> Message-ID: <75cbaa5f-ce24-9a4b-0b3e-232bc9304e6e@redhat.com> On 8/13/20 5:51 AM, Severin Gehwolf wrote: > On Tue, 2020-08-11 at 14:48 -0400, Zhengyu Gu wrote: >> Hi Michael, >> >>> My tests/comments: >>> * @since still says 12. Is that correct? > > I agree. Zhengyu, please remove the @since 12 tags in this backport. It > doesn't make sense to have them in either 11 or 8. Okay, updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.03/ Could I get formal review? Michael reviewed/tested previous version, but I don't see him on 8u reviewer list. Also, I see a new CR (JDK-8251269) for this backport, I assume I should use JDK-8251269 to push this backport, correct? Thanks, -Zhengyu > >>> * Should LdapDnsProvider and LdapDnsProviderResult document that they >>> have been moved in 12? >> >> Right. I am not sure about that. Paul and Christoph, anything suggestions? > > I don't think this should be documented in JDK head (which would be JDK > 16 now). After all, JDK 11 and JDK 8 fixes are *backports* of the > original fix in JDK 12. I'm afraid, this is something for users to know > and adjust accordingly for later JDK migrations. > > Thanks, > Severin > From sgehwolf at redhat.com Thu Aug 13 12:55:02 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 13 Aug 2020 14:55:02 +0200 Subject: [8u] RFR: 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics In-Reply-To: <4e32a070-0307-b081-1847-a5102ae7b99b@redhat.com> References: <4e32a070-0307-b081-1847-a5102ae7b99b@redhat.com> Message-ID: <6b6a431f820901b61eee0df895d695db7fdddc18.camel@redhat.com> Hi Aleksey, On Tue, 2020-08-04 at 18:21 +0200, Aleksey Shipilev wrote: > On 8/4/20 5:49 PM, Severin Gehwolf wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8250627 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/jdk8/01/ > > JDK 11 change: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/a75956082916 > > Substantially, I think the patch is fine. Can I consider this patch reviewed? > But, I do wonder if the new classes should be in sun.misc.*, not in jdk.internal.*. One of the > reasons to use sun.misc.* is to get the proper javac warning on use. jdk.internal is something that > is protected by module boundaries in JDK 9+, not available in 8u. With JDK-8203357 now in 8u, I wonder whether we should amend javac to print warnings for jdk.internal packages too? Would that help alleviate your concern? Thanks, Severin From shade at redhat.com Thu Aug 13 13:08:05 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 13 Aug 2020 15:08:05 +0200 Subject: [8u] RFR: 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics In-Reply-To: <6b6a431f820901b61eee0df895d695db7fdddc18.camel@redhat.com> References: <4e32a070-0307-b081-1847-a5102ae7b99b@redhat.com> <6b6a431f820901b61eee0df895d695db7fdddc18.camel@redhat.com> Message-ID: On 8/13/20 2:55 PM, Severin Gehwolf wrote: > On Tue, 2020-08-04 at 18:21 +0200, Aleksey Shipilev wrote: >> On 8/4/20 5:49 PM, Severin Gehwolf wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250627 >>> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/jdk8/01/ >>> JDK 11 change: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/a75956082916 >> >> Substantially, I think the patch is fine. > > Can I consider this patch reviewed? Yes. >> But, I do wonder if the new classes should be in sun.misc.*, not in jdk.internal.*. One of the >> reasons to use sun.misc.* is to get the proper javac warning on use. jdk.internal is something that >> is protected by module boundaries in JDK 9+, not available in 8u. > > With JDK-8203357 now in 8u, I wonder whether we should amend javac to > print warnings for jdk.internal packages too? Would that help alleviate > your concern? It would help, sure. But it is not very necessary, to be honest. -- Thanks, -Aleksey From sgehwolf at redhat.com Thu Aug 13 14:01:16 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 13 Aug 2020 16:01:16 +0200 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <75cbaa5f-ce24-9a4b-0b3e-232bc9304e6e@redhat.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <75cbaa5f-ce24-9a4b-0b3e-232bc9304e6e@redhat.com> Message-ID: <81fd56367ec9b2b2e4a415fb9240e03676a9b783.camel@redhat.com> Hi Zhengyu, On Thu, 2020-08-13 at 08:49 -0400, Zhengyu Gu wrote: > > On 8/13/20 5:51 AM, Severin Gehwolf wrote: > > On Tue, 2020-08-11 at 14:48 -0400, Zhengyu Gu wrote: > > > Hi Michael, > > > > > > > My tests/comments: > > > > * @since still says 12. Is that correct? > > > > I agree. Zhengyu, please remove the @since 12 tags in this backport. It > > doesn't make sense to have them in either 11 or 8. > > Okay, updated: > > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.03/ > > Could I get formal review? I'll review it later today. > Also, I see a new CR (JDK-8251269) for this backport, I assume I should > use JDK-8251269 to push this backport, correct? No, please don't. hg-updater should be smart enough to figure out this manual JDK 8u backport bug (8-pool) and use it to mark it resolved once you push using JDK-8160768. JDK-8251269 got created to be able to create a CSR for it for 8u. HTH. Thanks, Severin From zgu at redhat.com Thu Aug 13 14:15:53 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 13 Aug 2020 10:15:53 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <81fd56367ec9b2b2e4a415fb9240e03676a9b783.camel@redhat.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <75cbaa5f-ce24-9a4b-0b3e-232bc9304e6e@redhat.com> <81fd56367ec9b2b2e4a415fb9240e03676a9b783.camel@redhat.com> Message-ID: <48f08fc4-68e1-2cdb-4386-0787d7fb0833@redhat.com> On 8/13/20 10:01 AM, Severin Gehwolf wrote: > Hi Zhengyu, > > On Thu, 2020-08-13 at 08:49 -0400, Zhengyu Gu wrote: >> >> On 8/13/20 5:51 AM, Severin Gehwolf wrote: >>> On Tue, 2020-08-11 at 14:48 -0400, Zhengyu Gu wrote: >>>> Hi Michael, >>>> >>>>> My tests/comments: >>>>> * @since still says 12. Is that correct? >>> >>> I agree. Zhengyu, please remove the @since 12 tags in this backport. It >>> doesn't make sense to have them in either 11 or 8. >> >> Okay, updated: >> >> http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.03/ >> >> Could I get formal review? > > I'll review it later today. > >> Also, I see a new CR (JDK-8251269) for this backport, I assume I should >> use JDK-8251269 to push this backport, correct? > > No, please don't. hg-updater should be smart enough to figure out this > manual JDK 8u backport bug (8-pool) and use it to mark it resolved once > you push using JDK-8160768. JDK-8251269 got created to be able to > create a CSR for it for 8u. Great! Thanks, -Zhengyu > > HTH. > > Thanks, > Severin > From zgu at redhat.com Thu Aug 13 14:38:27 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 13 Aug 2020 10:38:27 -0400 Subject: [8u] RFR 8060721: Test runtime/SharedArchiveFile/LimitSharedSizes.java fails in jdk 9 fcs new platforms/compiler In-Reply-To: References: Message-ID: <95308d1f-5763-bdcb-b8a3-bb5ea7ab951a@redhat.com> Ping! Thanks, -Zhengyu On 6/15/20 2:17 PM, Zhengyu Gu wrote: > Hi, > > I would like to backport this patch to OpenJDK 8u as Oracle parity. > > The original patch does not apply cleanly, as it was preceded by > JDK-8148630 (unify logging [1]) that is not backportable to 8u. > > Original bug:? https://bugs.openjdk.java.net/browse/JDK-8060721 > Original patch: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8666e625f2a4 > > 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8060721-8u/webrev.00/ > > Thanks, > > -Zhengyu > > > [1] https://bugs.openjdk.java.net/browse/JDK-8148630 From shade at redhat.com Thu Aug 13 14:55:08 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 13 Aug 2020 16:55:08 +0200 Subject: [8u] RFR 8060721: Test runtime/SharedArchiveFile/LimitSharedSizes.java fails in jdk 9 fcs new platforms/compiler In-Reply-To: References: Message-ID: On 6/15/20 8:17 PM, Zhengyu Gu wrote: > The original patch does not apply cleanly, as it was preceded by > JDK-8148630 (unify logging [1]) that is not backportable to 8u. Hm. It looks that JDK-8062370 is the one that is actually in the way? https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/110ec5963eb1#l18.1 > Original bug: https://bugs.openjdk.java.net/browse/JDK-8060721 > Original patch: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8666e625f2a4 > 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8060721-8u/webrev.00/ 8u backport looks fine to me. What a rabbit hole of a bug. -- Thanks, -Aleksey From zgu at redhat.com Thu Aug 13 15:10:23 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 13 Aug 2020 11:10:23 -0400 Subject: [8u] RFR 8060721: Test runtime/SharedArchiveFile/LimitSharedSizes.java fails in jdk 9 fcs new platforms/compiler In-Reply-To: References: Message-ID: On 8/13/20 10:55 AM, Aleksey Shipilev wrote: > On 6/15/20 8:17 PM, Zhengyu Gu wrote: >> The original patch does not apply cleanly, as it was preceded by >> JDK-8148630 (unify logging [1]) that is not backportable to 8u. > > Hm. It looks that JDK-8062370 is the one that is actually in the way? > https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/110ec5963eb1#l18.1 > Right. >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8060721 >> Original patch: >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8666e625f2a4 >> 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8060721-8u/webrev.00/ > > 8u backport looks fine to me. > Thanks, Aleksey. -Zhengyu > What a rabbit hole of a bug. > From sgehwolf at redhat.com Thu Aug 13 20:33:13 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 13 Aug 2020 22:33:13 +0200 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <75cbaa5f-ce24-9a4b-0b3e-232bc9304e6e@redhat.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <75cbaa5f-ce24-9a4b-0b3e-232bc9304e6e@redhat.com> Message-ID: <927893dfb91f3624871c97205cb61e2b13ea7a72.camel@redhat.com> Hi Zhengyu, On Thu, 2020-08-13 at 08:49 -0400, Zhengyu Gu wrote: > > On 8/13/20 5:51 AM, Severin Gehwolf wrote: > > On Tue, 2020-08-11 at 14:48 -0400, Zhengyu Gu wrote: > > > Hi Michael, > > > > > > > My tests/comments: > > > > * @since still says 12. Is that correct? > > > > I agree. Zhengyu, please remove the @since 12 tags in this backport. It > > doesn't make sense to have them in either 11 or 8. > > Okay, updated: > > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.03/ > > Could I get formal review? 59 public LdapDnsProviderResult(String domainName, List endpoints) { 60 this.domainName = (domainName == null) ? "" : domainName; 61 this.endpoints = new ArrayList<>(); 62 this.endpoints.addAll(endpoints); Lines 61 and 62 can be simplified to: this.endpoints = new ArrayList<>(endpoints); com.sun.jndi.ldap.spi.LdapDnsProvider: 33 /** 34 * Service-provider class for DNS lookups when performing LDAP operations. 35 * 36 *

An LDAP DNS provider is a concrete subclass of this class that 37 * has a zero-argument constructor. LDAP DNS providers are located using the 38 * ServiceLoader facility, as specified by 39 * {@linkplain javax.naming.directory.InitialDirContext InitialDirectContext}. I believe this refers to the the added javadoc in the original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l5.15 This doc change has been left out as specified by the CSR[1]. However, it leaves some details as to how this works to be desired. I wonder if we should add some documentation in place of the reference here, or remove the reference entirely. It seems doing the former would make more sense. Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8251270 From katya at azul.com Fri Aug 14 14:42:01 2020 From: katya at azul.com (Ekaterina Vergizova) Date: Fri, 14 Aug 2020 14:42:01 +0000 Subject: [8u] RFR: 8213448: [TESTBUG] enhance jfr/jvm/TestDumpOnCrash Message-ID: <29a2b4bb2c9e40d1b0542ea900826957@azul.com> Hello, I would like to backport JFR test only issue 8213448 to 8u as a prerequisite for JDK-8217362 backport. JBS: https://bugs.openjdk.java.net/browse/JDK-8213448 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/f0af7fd0c9ca Webrev for 8u: https://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/8213448/webrev.00/ The patch doesn't apply cleanly due to the different context (Crasher.main method content, ProcessTools.createJavaProcessBuilder parameters), reapplied manually. Then I made the following modifications to adjust the test to 8u: - ProcessHandle.current().pid() calls are replaced by ProcessTools.getProcessId() - Process.pid() call is replaced by obtaining pid from the process output due to lack of Process.pid() method in 8u. The affected test passed successfully on Linux and Windows. Thanks, Ekaterina From hdriscoll at radiantlogic.com Fri Aug 14 18:07:01 2020 From: hdriscoll at radiantlogic.com (Heather Driscoll) Date: Fri, 14 Aug 2020 11:07:01 -0700 Subject: Question regarding support of TLS 1.3 Message-ID: Good Morning, Right now we have upgraded to jdk8u265-b01 (version for Windows). We wanted to know why the latest JDK 8 and JSSE.JAR did not support TLS1.3 , like Oracle and Azul did. Please advise. Best Regards, Heather Driscoll Project Manager Radiant Logic, Inc. 75 Rowland Way, Suite 300 Novato, CA 94945 hdriscoll at radiantlogic.com www.radiantlogic.com From aph at redhat.com Sun Aug 16 17:43:05 2020 From: aph at redhat.com (Andrew Haley) Date: Sun, 16 Aug 2020 18:43:05 +0100 Subject: Question regarding support of TLS 1.3 In-Reply-To: References: Message-ID: <010d4f0f-96e3-285c-036a-0cb5210d56f3@redhat.com> On 14/08/2020 19:07, Heather Driscoll wrote: > Right now we have upgraded to jdk8u265-b01 (version for Windows). We wanted > to know why the latest JDK 8 and JSSE.JAR did not support TLS1.3 , like > Oracle and Azul did. Please advise. We're pedalling as fast as we can. Right now engineers from Red Hat, Azul, and others are working to get TLS 1.3 into the next official OpenJDK 8u release. However, it's a critical and complex piece of software and it takes a long time to review it all. I'm sure you don't want us to rush it or break anything. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Mon Aug 17 05:26:48 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 17 Aug 2020 06:26:48 +0100 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> Message-ID: <20200817052648.GA2640315@stopbrexit> On 11:51 Thu 13 Aug , Severin Gehwolf wrote: > On Tue, 2020-08-11 at 14:48 -0400, Zhengyu Gu wrote: > > Hi Michael, > > > > > My tests/comments: > > > * @since still says 12. Is that correct? > > I agree. Zhengyu, please remove the @since 12 tags in this backport. It > doesn't make sense to have them in either 11 or 8. > I disagree. Such tags are a useful indicator that this is a backported API that wasn't in 8 GA. What would be the issue with leaving them in? Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Mon Aug 17 05:49:02 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 17 Aug 2020 06:49:02 +0100 Subject: [8u] RFR Backport 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 In-Reply-To: References: <9491cfd6-18b3-aeff-e7d3-8ec4fc0c77e8@redhat.com> <106cb997-5693-c24b-f0e0-c70e8e21d877@redhat.com> Message-ID: <20200817054902.GB2640315@stopbrexit> On 17:22 Wed 17 Jun , Elliott Baron wrote: snip... > > My main concern is that, although we don't add the new algorithms to > > DigestMethod & SignatureMethod, or their tests, we do seem to be adding > > support in e.g. JCEMapper for new algorithms like SHA3. I think we > > should be consistent here and if we're not going to put new algorithms > > in DigestMethod & SignatureMethod, and not include tests of them, they > > shouldn't be being implemented. > > Makes sense to me. I've removed the code related to SHA-3 algorithms, and > also Whirlpool, which also seems to not be unimplemented. > > Revised 8u Webrev: > https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8177334/webrev.02/ > > I noticed that RIPEMD-160 is already present, but not provided by any > default crypto provider. I suppose this is to allow the XML-DSig code to > work with third-party providers. We could follow suit and include the new > algorithms after all, but as you said, there's no good way to test them as > part of the JDK. > Thanks. Changed version looks good. > > > > I also wonder why getSignature was pulled into DOMSignatureMethod.java > > from JDK-8042967. Why was this needed? > > > > This allowed a cleaner backport for the new RSASSA-PSS DOMSignatureMethods. > They worked in the original by overriding the getSignature method to insert > special handling for the PSSParameterSpec. Maybe I could add an instanceof > special case to the original 8u code instead to do this? > Ok, I'm fine with just including that one method and not trying to backport a new feature for this. Just include something in the Summary line of the commit along the lines of: "Summary: Includes DOMSignatureMethod.getSignature from JDK-8042967" which will cause it to be found for any keyword searches for 8042967. > Thanks, > Elliott > > [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011571.html > Let's get this in finally and kick the tyres on it. Please flag with jdk8u-fix-request. -- Andrew :) Senior 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 From gnu.andrew at redhat.com Mon Aug 17 05:51:51 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 17 Aug 2020 06:51:51 +0100 Subject: [8u] RFR Backport 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 In-Reply-To: <20200817054902.GB2640315@stopbrexit> References: <9491cfd6-18b3-aeff-e7d3-8ec4fc0c77e8@redhat.com> <106cb997-5693-c24b-f0e0-c70e8e21d877@redhat.com> <20200817054902.GB2640315@stopbrexit> Message-ID: <20200817055151.GC2640315@stopbrexit> On 06:49 Mon 17 Aug , Andrew Hughes wrote: > > Let's get this in finally and kick the tyres on it. Please flag with > jdk8u-fix-request. Forgot to add; the THIRD_PARTY_README change will need to be duplicated to the other repos... :-( See Aleksey's recent backport of JDK-8046274 for an example. It doesn't need additional review as the change is in this webrev, but the file does need to be kept in sync. Thanks, -- Andrew :) Senior 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 From andrew_m_leonard at uk.ibm.com Mon Aug 17 14:20:00 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 17 Aug 2020 15:20:00 +0100 Subject: RFR: 8251886: Unable to use --disable-zip-debug-info on JDK8 Windows Message-ID: Hi, Please can I request a sponsor for this fix to support --disable-zip-debug on Windows? https://bugs.openjdk.java.net/browse/JDK-8251886 webrev: http://cr.openjdk.java.net/~aleonard/8251886/webrev.00/ Tier1 clean Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From hdriscoll at radiantlogic.com Mon Aug 17 16:29:40 2020 From: hdriscoll at radiantlogic.com (Heather Driscoll) Date: Mon, 17 Aug 2020 09:29:40 -0700 Subject: Question regarding support of TLS 1.3 In-Reply-To: <010d4f0f-96e3-285c-036a-0cb5210d56f3@redhat.com> References: <010d4f0f-96e3-285c-036a-0cb5210d56f3@redhat.com> Message-ID: Thank you for your response and hard work. I appreciate it. I will let management know. Best Regards, Heather Driscoll Project Manager Radiant Logic, Inc. 75 Rowland Way, Suite 300 Novato, CA 94945 hdriscoll at radiantlogic.com www.radiantlogic.com On Sun, Aug 16, 2020 at 10:43 AM Andrew Haley wrote: > On 14/08/2020 19:07, Heather Driscoll wrote: > > Right now we have upgraded to jdk8u265-b01 (version for Windows). We > wanted > > to know why the latest JDK 8 and JSSE.JAR did not support TLS1.3 , like > > Oracle and Azul did. Please advise. > > We're pedalling as fast as we can. Right now engineers from Red Hat, > Azul, and others are working to get TLS 1.3 into the next official > OpenJDK 8u release. However, it's a critical and complex piece of > software and it takes a long time to review it all. I'm sure you don't > want us to rush it or break anything. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From gnu.andrew at redhat.com Mon Aug 17 17:26:22 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 17 Aug 2020 18:26:22 +0100 Subject: RFR: 8251886: Unable to use --disable-zip-debug-info on JDK8 Windows In-Reply-To: References: Message-ID: <20200817172622.GB2749792@stopbrexit> On 15:20 Mon 17 Aug , Andrew Leonard wrote: > Hi, > Please can I request a sponsor for this fix to support --disable-zip-debug > on Windows? > https://bugs.openjdk.java.net/browse/JDK-8251886 > webrev: http://cr.openjdk.java.net/~aleonard/8251886/webrev.00/ > Tier1 clean > > Many thanks > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Is this https://bugs.openjdk.java.net/browse/JDK-8025936? It seems backporting that would also unify the handling of unpack. Thanks, -- Andrew :) Senior 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 From zgu at redhat.com Mon Aug 17 17:34:22 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 17 Aug 2020 13:34:22 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <20200817052648.GA2640315@stopbrexit> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> Message-ID: <3aeeca99-1eda-db76-be44-54f4659bd774@redhat.com> >>> >>>> My tests/comments: >>>> * @since still says 12. Is that correct? >> >> I agree. Zhengyu, please remove the @since 12 tags in this backport. It >> doesn't make sense to have them in either 11 or 8. >> > > I disagree. Such tags are a useful indicator that this is a backported > API that wasn't in 8 GA. > > What would be the issue with leaving them in? Javadoc looks a little awkward to refer to later release? Anyway, I don't have strong opinion on this, will do whatever 11u backport chooses to do. Christroph, what's your take? Thanks, -Zhengyu > > Thanks, > From gnu.andrew at redhat.com Mon Aug 17 17:43:04 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 17 Aug 2020 18:43:04 +0100 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <3aeeca99-1eda-db76-be44-54f4659bd774@redhat.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> <3aeeca99-1eda-db76-be44-54f4659bd774@redhat.com> Message-ID: <20200817174304.GC2749792@stopbrexit> On 13:34 Mon 17 Aug , Zhengyu Gu wrote: > > > > > > > > > > My tests/comments: > > > > > * @since still says 12. Is that correct? > > > > > > I agree. Zhengyu, please remove the @since 12 tags in this backport. It > > > doesn't make sense to have them in either 11 or 8. > > > > > > > I disagree. Such tags are a useful indicator that this is a backported > > API that wasn't in 8 GA. > > > > What would be the issue with leaving them in? > > Javadoc looks a little awkward to refer to later release? > Do we build Javadoc for these internal packages? > Anyway, I don't have strong opinion on this, will do whatever 11u backport > chooses to do. Christroph, what's your take? Is this not in 11u yet? > > Thanks, > > -Zhengyu > > > > > Thanks, > > > Thanks, -- Andrew :) Senior 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 From andrew_m_leonard at uk.ibm.com Mon Aug 17 19:02:01 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 17 Aug 2020 20:02:01 +0100 Subject: RFR: 8251886: Unable to use --disable-zip-debug-info on JDK8 Windows In-Reply-To: <20200817172622.GB2749792@stopbrexit> References: <20200817172622.GB2749792@stopbrexit> Message-ID: Hi Andrew, I hadn't seen that bug, I'm looking through the changesets for it: https://hg.openjdk.java.net/jdk/jdk/rev/5193a7e23f14 https://hg.openjdk.java.net/jdk/jdk/rev/4cbb04a368cb And must say seems quite a bit more complex, there's some tidying up in those, but not sure I understand the actual change although GNU make is hard to follow sometimes, i'll have a compare of it tomorrow. Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Hughes To: Andrew Leonard Cc: jdk8u-dev at openjdk.java.net Date: 17/08/2020 18:26 Subject: [EXTERNAL] Re: RFR: 8251886: Unable to use --disable-zip-debug-info on JDK8 Windows On 15:20 Mon 17 Aug , Andrew Leonard wrote: > Hi, > Please can I request a sponsor for this fix to support --disable-zip-debug > on Windows? > https://bugs.openjdk.java.net/browse/JDK-8251886 > webrev: http://cr.openjdk.java.net/~aleonard/8251886/webrev.00/ > Tier1 clean > > Many thanks > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Is this https://bugs.openjdk.java.net/browse/JDK-8025936? It seems backporting that would also unify the handling of unpack. Thanks, -- Andrew :) Senior 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 [attachment "signature.asc" deleted by Andrew Leonard/UK/IBM] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From ebaron at redhat.com Mon Aug 17 20:56:51 2020 From: ebaron at redhat.com (Elliott Baron) Date: Mon, 17 Aug 2020 16:56:51 -0400 Subject: [8u] RFR Backport 8217878: ENVELOPING XML signature no longer works Message-ID: Hi, I'd like to request a review to backport 8217878 to 8u. Note: this changeset also fixes "8218629: XML Digital Signature throws NAMESPACE_ERR exception on OpenJDK 11, works 8/9/10". Original fix: https://bugs.openjdk.java.net/browse/JDK-8217878 https://hg.openjdk.java.net/jdk/jdk/rev/d870bb08194a The original JDK 13 fix did not apply cleanly. I had to make a few minor changes outlined below. org/jcp/xml/dsig/internal/dom/DOMReference: - Remove Node type parameter from context due to "8046949: Generify the javax.xml.crypto API" not in 8u. org/jcp/xml/dsig/internal/dom/DOMSignatureMethod: - Context changed in several hunks since we didn't backport "8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes" to 8u. org/jcp/xml/dsig/internal/dom/DOMXMLSignature: - Adding SuppressWarnings annotations back isn't necessary since they were removed by "8046949: Generify the javax.xml.crypto API", which was not backported to 8u. 8u webrev: http://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8217878/webrev.00/ Testing: x86_64 build, jdk_tier1, jdk_security tests Thanks, Elliott From gnu.andrew at redhat.com Mon Aug 17 22:33:57 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 17 Aug 2020 23:33:57 +0100 Subject: [8u] RFR Backport 8217878: ENVELOPING XML signature no longer works In-Reply-To: References: Message-ID: <20200817223357.GA2801852@stopbrexit> On 16:56 Mon 17 Aug , Elliott Baron wrote: > Hi, > > I'd like to request a review to backport 8217878 to 8u. > > Note: this changeset also fixes "8218629: XML Digital Signature throws > NAMESPACE_ERR exception on OpenJDK 11, works 8/9/10". > > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8217878 > https://hg.openjdk.java.net/jdk/jdk/rev/d870bb08194a > > The original JDK 13 fix did not apply cleanly. I had to make a few minor > changes outlined below. > > org/jcp/xml/dsig/internal/dom/DOMReference: > - Remove Node type parameter from context due to "8046949: Generify the > javax.xml.crypto API" not in 8u. > > org/jcp/xml/dsig/internal/dom/DOMSignatureMethod: > - Context changed in several hunks since we didn't backport "8042967: Add > variant of DSA Signature algorithms that do not ASN.1 encode the signature > bytes" to 8u. > > org/jcp/xml/dsig/internal/dom/DOMXMLSignature: > - Adding SuppressWarnings annotations back isn't necessary since they were > removed by "8046949: Generify the javax.xml.crypto API", which was not > backported to 8u. > > 8u webrev: > http://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8217878/webrev.00/ > > Testing: x86_64 build, jdk_tier1, jdk_security tests > > Thanks, > Elliott > This looks fine to me. As you say, the differences are mostly just context and the lack of a few enhancement patches in 8u. I assume adding @SuppressWarnings wasn't necessary because it is already there (i.e. was never removed)? Please flag for approval with jdk8u-fix-request. Thanks, -- Andrew :) Senior 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 From ebaron at redhat.com Mon Aug 17 22:35:32 2020 From: ebaron at redhat.com (Elliott Baron) Date: Mon, 17 Aug 2020 18:35:32 -0400 Subject: [8u] RFR Backport 8217878: ENVELOPING XML signature no longer works In-Reply-To: <20200817223357.GA2801852@stopbrexit> References: <20200817223357.GA2801852@stopbrexit> Message-ID: On 2020-08-17 6:33 p.m., Andrew Hughes wrote: > On 16:56 Mon 17 Aug , Elliott Baron wrote: >> Hi, >> >> I'd like to request a review to backport 8217878 to 8u. >> >> Note: this changeset also fixes "8218629: XML Digital Signature throws >> NAMESPACE_ERR exception on OpenJDK 11, works 8/9/10". >> >> Original fix: >> https://bugs.openjdk.java.net/browse/JDK-8217878 >> https://hg.openjdk.java.net/jdk/jdk/rev/d870bb08194a >> >> The original JDK 13 fix did not apply cleanly. I had to make a few minor >> changes outlined below. >> >> org/jcp/xml/dsig/internal/dom/DOMReference: >> - Remove Node type parameter from context due to "8046949: Generify the >> javax.xml.crypto API" not in 8u. >> >> org/jcp/xml/dsig/internal/dom/DOMSignatureMethod: >> - Context changed in several hunks since we didn't backport "8042967: Add >> variant of DSA Signature algorithms that do not ASN.1 encode the signature >> bytes" to 8u. >> >> org/jcp/xml/dsig/internal/dom/DOMXMLSignature: >> - Adding SuppressWarnings annotations back isn't necessary since they were >> removed by "8046949: Generify the javax.xml.crypto API", which was not >> backported to 8u. >> >> 8u webrev: >> http://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8217878/webrev.00/ >> >> Testing: x86_64 build, jdk_tier1, jdk_security tests >> >> Thanks, >> Elliott >> > > This looks fine to me. As you say, the differences are mostly just context > and the lack of a few enhancement patches in 8u. I assume adding @SuppressWarnings > wasn't necessary because it is already there (i.e. was never removed)? That's correct. They're already present. From alvdavi at amazon.com Tue Aug 18 19:10:59 2020 From: alvdavi at amazon.com (David Alvarez) Date: Tue, 18 Aug 2020 12:10:59 -0700 Subject: [8u] RFR 8249846: Change of behavior after JDK-8237117: Better ForkJoinPool behavior Message-ID: <55a59080-5b52-46ac-d556-43d2ee9760e7@amazon.com> Hi, I would like to request a review for JDK-8249846 During the backport of JDK-8237117 a regression was added that affected how the DefaultForkJoinWorkerThreadFactory works. The idea was to change the context for threads in the commonPool, but it ended up affecting the threads in all pools created with that factory. This patch decouples the commonPool from the DefaultForkJoinWorkerThreadFactory Bug: https://bugs.openjdk.java.net/browse/JDK-8249846 Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8249846/webrev.8u.jdk.00/ My original intention when writing the patch was to make the CommonPool use the InnocuousForkJoinWorkerThreadFactory [1] in all cases, regardless of whether a SecurityManager is installed or not, as we are already creating threads with an innocuous AccessControlContext for commonPool threads even when there is no SecurityManager installed. However, the InnocuousForkJoinWorkerThreadFactory creates InnocuousForkJoinWorkerThreads [2], which have some more nuances, like the erase of ThreadLocal variables or avoid setting an UncaughtExceptionHandler. I was afraid of introducing more regressions with this change (in fact, one jtreg test [3] did fail because it was setting an uncaught exception handler), that is why I decided to go for a new factory (DefaultCommonPoolForkJoinWorkerThreadFactory) that mimics current behavior, even if it means the behavior of the common pool if a SecurityManager is installed during initialization is still not the same as if the SecurityManager is installed after initialization. David -- [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/4d586f39fed3/src/share/classes/java/util/concurrent/ForkJoinPool.java#l3429 [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/4d586f39fed3/src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java#l231 [3] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/4d586f39fed3/test/java/util/concurrent/forkjoin/ThrowingRunnable.java#l66 From gnu.andrew at redhat.com Wed Aug 19 05:23:50 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Aug 2020 06:23:50 +0100 Subject: [8u] RFR 8249846: Change of behavior after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: <55a59080-5b52-46ac-d556-43d2ee9760e7@amazon.com> References: <55a59080-5b52-46ac-d556-43d2ee9760e7@amazon.com> Message-ID: <20200819052350.GA2926077@stopbrexit> On 12:10 Tue 18 Aug , David Alvarez wrote: > Hi, > > I would like to request a review for JDK-8249846 > > During the backport of JDK-8237117 a regression was added that affected > how the DefaultForkJoinWorkerThreadFactory works. The idea was to change > the context for threads in the commonPool, but it ended up affecting the > threads in all pools created with that factory. This patch decouples the > commonPool from the DefaultForkJoinWorkerThreadFactory > > Bug: https://bugs.openjdk.java.net/browse/JDK-8249846 > Webrev: > http://cr.openjdk.java.net/~alvdavi/webrevs/8249846/webrev.8u.jdk.00/ > > My original intention when writing the patch was to make the CommonPool > use the InnocuousForkJoinWorkerThreadFactory [1] in all cases, > regardless of whether a SecurityManager is installed or not, as we are > already creating threads with an innocuous AccessControlContext for > commonPool threads even when there is no SecurityManager installed. > However, the InnocuousForkJoinWorkerThreadFactory creates > InnocuousForkJoinWorkerThreads [2], which have some more nuances, like > the erase of ThreadLocal variables or avoid setting an > UncaughtExceptionHandler. I was afraid of introducing more regressions > with this change (in fact, one jtreg test [3] did fail because it was > setting an uncaught exception handler), that is why I decided to go for > a new factory (DefaultCommonPoolForkJoinWorkerThreadFactory) that mimics > current behavior, even if it means the behavior of the common pool if a > SecurityManager is installed during initialization is still not the same > as if the SecurityManager is installed after initialization. > > > David > > -- > [1] > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/4d586f39fed3/src/share/classes/java/util/concurrent/ForkJoinPool.java#l3429 > [2] > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/4d586f39fed3/src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java#l231 > [3] > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/4d586f39fed3/test/java/util/concurrent/forkjoin/ThrowingRunnable.java#l66 > Should this not go to jdk/jdk first or is it only applicable to 8u? Thanks, -- Andrew :) Senior 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 From alvdavi at amazon.com Wed Aug 19 05:33:35 2020 From: alvdavi at amazon.com (David Alvarez) Date: Tue, 18 Aug 2020 22:33:35 -0700 Subject: [8u] RFR 8249846: Change of behavior after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: <20200819052350.GA2926077@stopbrexit> References: <55a59080-5b52-46ac-d556-43d2ee9760e7@amazon.com> <20200819052350.GA2926077@stopbrexit> Message-ID: <14c27926-587c-0622-3815-efe4a90d9bab@amazon.com> Hi, The bug is marked as 9-na and 11-na, and there is a comment stating this will be specific to 8u. Furthermore, Oracle has decided to patch this same bug in 8u271, but not in tip. David On 2020-08-18 22:23, Andrew Hughes wrote: > On 12:10 Tue 18 Aug , David Alvarez wrote: >> Hi, >> >> I would like to request a review for JDK-8249846 >> >> During the backport of JDK-8237117 a regression was added that affected >> how the DefaultForkJoinWorkerThreadFactory works. The idea was to change >> the context for threads in the commonPool, but it ended up affecting the >> threads in all pools created with that factory. This patch decouples the >> commonPool from the DefaultForkJoinWorkerThreadFactory >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8249846 >> Webrev: >> http://cr.openjdk.java.net/~alvdavi/webrevs/8249846/webrev.8u.jdk.00/ >> >> My original intention when writing the patch was to make the CommonPool >> use the InnocuousForkJoinWorkerThreadFactory [1] in all cases, >> regardless of whether a SecurityManager is installed or not, as we are >> already creating threads with an innocuous AccessControlContext for >> commonPool threads even when there is no SecurityManager installed. >> However, the InnocuousForkJoinWorkerThreadFactory creates >> InnocuousForkJoinWorkerThreads [2], which have some more nuances, like >> the erase of ThreadLocal variables or avoid setting an >> UncaughtExceptionHandler. I was afraid of introducing more regressions >> with this change (in fact, one jtreg test [3] did fail because it was >> setting an uncaught exception handler), that is why I decided to go for >> a new factory (DefaultCommonPoolForkJoinWorkerThreadFactory) that mimics >> current behavior, even if it means the behavior of the common pool if a >> SecurityManager is installed during initialization is still not the same >> as if the SecurityManager is installed after initialization. >> >> >> David >> >> -- >> [1] >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/4d586f39fed3/src/share/classes/java/util/concurrent/ForkJoinPool.java#l3429 >> [2] >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/4d586f39fed3/src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java#l231 >> [3] >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/4d586f39fed3/test/java/util/concurrent/forkjoin/ThrowingRunnable.java#l66 >> > > Should this not go to jdk/jdk first or is it only applicable to 8u? > > Thanks, > From gnu.andrew at redhat.com Wed Aug 19 05:35:29 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Aug 2020 06:35:29 +0100 Subject: RFR: 8251886: Unable to use --disable-zip-debug-info on JDK8 Windows In-Reply-To: References: <20200817172622.GB2749792@stopbrexit> Message-ID: <20200819053529.GB2926077@stopbrexit> On 20:02 Mon 17 Aug , Andrew Leonard wrote: > Hi Andrew, > I hadn't seen that bug, I'm looking through the changesets for it: > https://hg.openjdk.java.net/jdk/jdk/rev/5193a7e23f14 > https://hg.openjdk.java.net/jdk/jdk/rev/4cbb04a368cb It took me a while to find it through tracing back through the history of the file. If a new patch is against a stable release, I try and check if/how it is solved in later releases to see if there is a possibility something could be backported instead. > And must say seems quite a bit more complex, there's some tidying up in > those, but not sure I understand the actual change although GNU make is > hard to follow sometimes, i'll have a compare of it tomorrow. It looks more complicated than it is, because a block is being moved, but the contents are largely the same. The main change is the dependency for creating the zip: ifeq ($(OPENJDK_TARGET_OS), windows) $$($1_OBJECT_DIR)/$$(LIBRARY_PREFIX)$$($1_LIBRARY).diz : $$($1_TARGET) $(CD) $$($1_OBJECT_DIR) \ && $(ZIP) -q $$@ $$($1_LIBRARY).map $$($1_LIBRARY).pdb becomes # The dependency on TARGET is needed on windows for debuginfo files # to be rebuilt properly. $$($1_DEBUGINFO_ZIP): $$($1_DEBUGINFO_FILES) $$($1_TARGET) $(CD) $$($1_OBJECT_DIR) \ && $(ZIP) -q $$@ $$($1_DEBUGINFO_FILES) ($1_DEBUGINFO_FILES is defined as the map and pdb file) Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Wed Aug 19 05:39:26 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Aug 2020 06:39:26 +0100 Subject: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times In-Reply-To: <7C96E000-B255-4A5C-8CA1-8084308FB9E2@amazon.com> References: <7C96E000-B255-4A5C-8CA1-8084308FB9E2@amazon.com> Message-ID: <20200819053926.GC2926077@stopbrexit> On 14:46 Fri 17 Jul , Hohensee, Paul wrote: > I?d change the oops_do() comment to > > // G1 does its own checking > > because the assert has a general G1 check (i.e., UseG1GC) rather than a specific one. All uses of oops_do() by G1 will have to do their own checks, not just the array slice case that your current comment says. > > Other than that, lgtm. I?ll sponsor the patch and add a ?reviewed? comment to the issue. > > Thanks, > Paul > This was a bit difficult to follow at first, as a few hunks seem to have moved files, but I agree it looks ok. FWIW, JDK-8079082: "VerifyNoCSetOopsClosure is derived twice from Closure" introduced the additional assert as part of its refactoring. Thanks, -- Andrew :) Senior 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 From alvdavi at amazon.com Wed Aug 19 06:23:56 2020 From: alvdavi at amazon.com (David Alvarez) Date: Tue, 18 Aug 2020 23:23:56 -0700 Subject: [8u] RFR Backport 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 Message-ID: <79d7abe1-1d84-9981-b138-68f7d67b8a4d@amazon.com> Hi, First, sorry, I managed to delete some of the list emails from my inbox, so I can't respond in the proper thread, but I have copied the original subject, I hope that is enough to locate the original thread (which spawns a few months) I've noticed that 8177334 has landed in openjdk8u272, the update to Apache Santuario. When the initial RFR was sent, it was mentioned that there were three subsequent bugfixes pending. One of them is still missing, JDK-8236645 [1], which is 8u specific and not present in tip, so no backport. What is the plan regarding this one? I have seen no further comment on the issue (if this has been already discussed, my apologies). Are we going to ship openjdk8u272 with this known issue? David -- [1] https://bugs.openjdk.java.net/browse/JDK-8236645 From sgehwolf at redhat.com Wed Aug 19 06:51:08 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 19 Aug 2020 08:51:08 +0200 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <20200817052648.GA2640315@stopbrexit> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> Message-ID: <78a1c49794afdf13013a4c3d75efab50f4745870.camel@redhat.com> On Mon, 2020-08-17 at 06:26 +0100, Andrew Hughes wrote: > On 11:51 Thu 13 Aug , Severin Gehwolf wrote: > > On Tue, 2020-08-11 at 14:48 -0400, Zhengyu Gu wrote: > > > Hi Michael, > > > > > > > My tests/comments: > > > > * @since still says 12. Is that correct? > > > > I agree. Zhengyu, please remove the @since 12 tags in this backport. It > > doesn't make sense to have them in either 11 or 8. > > > > I disagree. Such tags are a useful indicator that this is a backported > API that wasn't in 8 GA. If we are starting to rely on @since tags as an indicator for backports then we're in trouble. Instead, the bug system and source control should be used for this. Given that, by removing the @since tag we don't loose info that it's a backport. > What would be the issue with leaving them in? A couple of reasons: * It's confusing. Mentioning something related to JDK 12 in a JDK 8 tree is, well, confusing. It only wouldn't be so if you are intimately familiar with the process and know about this mailing list discussion. * @Since tags are usually used for *publicly* exposed classes as an aid for JDK API consumers. "This API is available for JDK 12 and onwards". I'm aware there are instances where it was used for internal classes too, but they become less prominent these days. It makes sense to have them for the original JDK 12 change. For the JDK 8u backport, classes have been moved to a private package. It's not a 1-to-1 backport. The value of it being preserved regardless makes little sense. It's not the original class where it was added to begin with. * The SinceTree.java interface mentions this in its javadoc: "Returns the text explaining the availability of the item being documented." That's wrong for code in JDK 8. We'd be putting a @since 12 on code introduced in an update version of 8u. Overall, the drawbacks outweigh the benefits. Thanks, Severin From sgehwolf at redhat.com Wed Aug 19 07:41:09 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 19 Aug 2020 09:41:09 +0200 Subject: [8u] RFR Backport 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 In-Reply-To: <79d7abe1-1d84-9981-b138-68f7d67b8a4d@amazon.com> References: <79d7abe1-1d84-9981-b138-68f7d67b8a4d@amazon.com> Message-ID: <8697741f36c0e20c8bd10ae24953064374a1e98a.camel@redhat.com> Hi David, On Tue, 2020-08-18 at 23:23 -0700, David Alvarez wrote: > Hi, > > First, sorry, I managed to delete some of the list emails from my inbox, > so I can't respond in the proper thread, but I have copied the original > subject, I hope that is enough to locate the original thread (which > spawns a few months) > > I've noticed that 8177334 has landed in openjdk8u272, the update to > Apache Santuario. When the initial RFR was sent, it was mentioned that > there were three subsequent bugfixes pending. One of them is still > missing, JDK-8236645 [1], which is 8u specific and not present in tip, > so no backport. What is the plan regarding this one? I have seen no > further comment on the issue (if this has been already discussed, my > apologies). Are we going to ship openjdk8u272 with this known issue? We should try to get JDK-8236645 fixed for OpenJDK 8u. Elliott, if not on your radar already, I think the 8u CSR has enough info to get a patch going which should fix this. What do you think? https://bugs.openjdk.java.net/browse/JDK-8237765 Thanks, Severin > David > > -- > [1] https://bugs.openjdk.java.net/browse/JDK-8236645 > > From jaroslav.bachorik at datadoghq.com Wed Aug 19 09:32:41 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Wed, 19 Aug 2020 11:32:41 +0200 Subject: [8u] RFR 8249158: THREAD_START and THREAD_END event posted in primordial phase In-Reply-To: References: Message-ID: Hi Andrew, On Wed, Jul 29, 2020 at 11:03 AM Andrew Dinn wrote: > > Hi Jaroslav, > > On 28/07/2020 16:44, Jaroslav Bachor?k wrote: > > This patch is backing out the backport of JDK-8233197. The backport > > changed slightly the init order and thus broke the expected behavior > > of the JVMTI VMStart routine (more information in JIRA ticket). > > > > Since the original fix (JDK-8233197) is fixing an issue which can not > > be hit in JDK 8 due to different implementation of the VM init phases > > it makes sense to back out the backport and restore the original JVMTI > > behavior. > > > > JIRA : https://bugs.openjdk.java.net/browse/JDK-8249158 > > CR : http://cr.openjdk.java.net/~jbachorik/8249158 > > > > The backout is fairly straightforward. When applied all jdk/jfr and > > hotspot/runtime tests are passing. > The backout looks correct to me except for one (non-functional) detail. > > At thread.cpp:3545 you now appear to have two copies of the comment > explaining the significance of bug 4211085. Aaah! Thanks! Fixed - http://cr.openjdk.java.net/~jbachorik/8249158/webrev.01/ -JB- > > regards, > > > Andrew Dinn > ----------- > From adinn at redhat.com Wed Aug 19 09:37:00 2020 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 19 Aug 2020 10:37:00 +0100 Subject: [8u] RFR 8249158: THREAD_START and THREAD_END event posted in primordial phase In-Reply-To: References: Message-ID: <088e929f-df03-2960-6ae9-c0ec81abc793@redhat.com> On 19/08/2020 10:32, Jaroslav Bachor?k wrote: > On Wed, Jul 29, 2020 at 11:03 AM Andrew Dinn wrote: >> >> Hi Jaroslav, >> >> On 28/07/2020 16:44, Jaroslav Bachor?k wrote: >>> This patch is backing out the backport of JDK-8233197. The backport >>> changed slightly the init order and thus broke the expected behavior >>> of the JVMTI VMStart routine (more information in JIRA ticket). >>> >>> Since the original fix (JDK-8233197) is fixing an issue which can not >>> be hit in JDK 8 due to different implementation of the VM init phases >>> it makes sense to back out the backport and restore the original JVMTI >>> behavior. >>> >>> JIRA : https://bugs.openjdk.java.net/browse/JDK-8249158 >>> CR : http://cr.openjdk.java.net/~jbachorik/8249158 >>> >>> The backout is fairly straightforward. When applied all jdk/jfr and >>> hotspot/runtime tests are passing. >> The backout looks correct to me except for one (non-functional) detail. >> >> At thread.cpp:3545 you now appear to have two copies of the comment >> explaining the significance of bug 4211085. > > Aaah! Thanks! Fixed - http://cr.openjdk.java.net/~jbachorik/8249158/webrev.01/ Thanks. Looks good. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From alexey at azul.com Wed Aug 19 13:31:03 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 19 Aug 2020 13:31:03 +0000 Subject: [8u] TLSv1.3 RFR: 8245681: Add TLSv1.3 regression test from 11.0.7 In-Reply-To: <66A03F4D-3EC4-43D2-9B2B-33E1F6BEDFD1@azul.com> References: <7D92607F-B8F0-4E84-B6C2-5E2AB4E42824@azul.com> <04f0d809-2f53-5335-9828-72b198bf369f@azul.com> <0e9f68c6-dd0e-c2f7-50bf-28bf23a3a012@redhat.com> <66A03F4D-3EC4-43D2-9B2B-33E1F6BEDFD1@azul.com> Message-ID: Hi Martin, Please find new version of the patch for TLSv1.3 regression test: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v3/ Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v3/jdk.git.diff In this version I?ve added MFLN tests from JDK11. Even if JDK8 does not supported SSLParameters.set/getMaximumPacketSize?() methods, server side can process MFLN Extension received from the client. These tests will modified for JDK8 in the next step : JDK-8251478 test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java is removed Regards Alexey > On 13 Aug 2020, at 12:21, Alexey Bakhtin wrote: > > Hi Martin, > > Please see my comments below. > > Regards > Alexey > >> On 12 Aug 2020, at 23:27, Martin Balao wrote: >> >> Hi Alexey, >> >> Thanks for proposing this patch. >> >> On 8/12/20 2:51 PM, Alexey Bakhtin wrote: >>> Please find new version of the patch for TLSv1.3 regression tests: >>> http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v2/ >>> Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v2/jdk.git.diff >>> >>> This patch adds TLS related tests from JDK11.07 without any modification. >>> This patch does not include: >>> - DTLS tests: >>> - javax/net/ssl/DTLS >>> - javax/net/ssl/DTLSv10 >>> - sun/security/ssl/SSLContextImpl >>> - CustomizedDTLSDefaultProtocols.java >>> - CustomizedDTLSServerDefaultProtocols.java >>> - DefaultDTLSEnabledProtocols.java >> >> Ok. >> >>> - javax/net/ssl/finalize: >>> This test was added as part of JDK-8169416. Not related to TLSv1.3 implementation. Test uses unsupported Reference.reachabilityFence >> >> Yeah, I see the problem. Contrary to MFLN (see below), I'm not that >> concerned about this test. I'm okay. >> >>> - javax/net/ssl/HttpsURLConnection/Equals.java >>> This test was added as part of JDK-8055299. Not backported to JDK8 yet >> >> Why? > JDK-8055299 is not backported to JDK8u and not related to TLSv1.3 functionality. > This fix can be backported separately > >> >>> - MFLNTest tests: >>> - javax/net/ssl/TLS/TLSMFLNTest.java >>> - javax/net/ssl/TLS1/TLSMFLNTest.java >>> - javax/net/ssl/TLS11/TLSMFLNTest.java >>> These tests based on the SSLParameters.setMaximumPacketSize?() public API which is not available in JDK8: >> >> We've introduced the MFLN extension with the new SunJSSE engine, so >> looks to me that these tests are important. Can you please point me to >> this dependency? We need to figure out a way of bypassing the >> dependency, even if we need to use non-public APIs. I'd only agree if we >> have a strong reason -but I hope we don't-. > > TLSMFLNTest tests are based on the TLSCommon/SSLEngineTestCase.java class. > SSLEngineTestCase uses SSLParameters.setMaximumPacketSize() to change default Max Fragment Length. > Actually, it is interesting situation. It seems MFL can be set with SSLParameters.setMaximumPacketSize() API only. This API is not available in JDK8u and MFLNExtension is not usable without this API (client sends MFLNExtension if it is not default only) > So, we need custom API to set/get MaxPacketSize or exclude MFLNExtension functionality from the implementation. > >> >>> - TEST.properties files for different tests. These files are not required for JDK8 >> >> Ok. >> >> In addition to the previous, I've noticed that Step 11 adds a few files >> not in previous SSL-related categories: >> >> * test/java/security/testlibrary/CertificateBuilder.java (new) >> * test/java/security/testlibrary/SimpleOCSPServer.java (new) > These classes used by javax/net/ssl/Stapling and sun/security/ssl/Stapling tests > These classes was added as part of JDK-8046321: OCSP Stapling for TLS >> * test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java (new) > This class should be excluded. > It is used by javax/net/ssl/HttpsURLConnection/Equals.java which is not added in this step, so SimpleSSLContext.java is not required > >> >> How did you find them? > > I've found these classes by running and fixing test dependency > >> Seems that they are not part of 8196584 (original >> TLS 1.3 patch). My question is not only to judge these files but also to >> make sure that we are not missing anything. >> >> Thanks, >> Martin.- From alexey at azul.com Wed Aug 19 13:44:32 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 19 Aug 2020 13:44:32 +0000 Subject: [8u] TLSv1.3 RFR: 8251478: Backport TLSv1.3 regression tests to JDK8u In-Reply-To: <4E845CF2-E84F-413B-8193-64FD521BA647@azul.com> References: <4E845CF2-E84F-413B-8193-64FD521BA647@azul.com> Message-ID: <529B5CE4-2055-4015-A6DD-1774E18D1C7A@azul.com> Please find updated version of the patch: Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v1 Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v1/jdk.git.diff This version contains updates for the MFLN Extension tests Regards Alexey > On 12 Aug 2020, at 21:55, Alexey Bakhtin wrote: > > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u > > JBS task: https://bugs.openjdk.java.net/browse/JDK-8251478 > Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v0/ > Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v0/jdk.git.diff > > This is a fourth part of TLS test update. > > This patch fixes JDK8 compatibility for the TLSv1.3 regression tests. > Most of the fixes are : > - removed @modules annotation > - fixed path to libraries > > Specific test changes: > - fixed KeyStore creation: > - javax/net/ssl/SSLSession/RenegotiateTLS13.java: > - sun/security/ssl/SSLEngineImpl/SSLEngineKeyImpl.java > - sun/security/ssl/SSLEngineImpl/TLS13BeginHandshake.java > - sun/security/ssl/SSLSocketImpl/SSLSocketKeyLimit.java > - fixed ArrayList creation: > - javax/net/ssl/SSLSession/ResumeTLS13withSNI.java > - javax/net/ssl/Stapling/SSLEngineWithStapling.java > - fixed JDK8 compatibility > - javax/net/ssl/templates/SSLContextTemplate.java > - added fix for the client default disabled TLSv1.3 protocol > - javax/net/ssl/TLS/TLSClientPropertyTest.java > - sun/security/ssl/SSLContextImpl/CustomizedServerDefaultProtocol.java > - sun/security/ssl/SSLContextImpl/DefaultEnabledProtocols.java > - fixed HttpsURLConnection API changes > - sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java > - added ?jdk.tls.client.protocols? cmdline options to fix client default disabled TLSv1.3 protocol: > - javax/net/ssl/SSLSession/ResumeTLS13withSNI.java > - javax/net/ssl/SSLSocket/TLS13PacketSize.java > - javax/net/ssl/Stapling/HttpsUrlConnClient.java > - javax/net/ssl/Stapling/SSLEngineWithStapling.java > - javax/net/ssl/Stapling/SSLSocketWithStapling.java > - javax/net/ssl/Stapling/StapleEnableProps.java > - sun/security/ssl/SLSessionImpl/ResumeChecksClient.java > - sun/security/ssl/SLSessionImpl/ResumeChecksServer.java > - fixed issues related to DTLS specific API not available in JDK8: > - javax/net/ssl/TLSCommon/Protocol.java > - javax/net/ssl/TLSCommon/RehandshakeWithCipherChangeTest.java > - javax/net/ssl/TLSCommon/RehandshakeWithDataExTest.java > - javax/net/ssl/TLSCommon/SSLEngineTestCase.java > - changed test run script: > - sun/security/ssl/Stapling > - sun/security/ssl/internal > > Regards > Alexey From ebaron at redhat.com Wed Aug 19 15:26:32 2020 From: ebaron at redhat.com (Elliott Baron) Date: Wed, 19 Aug 2020 11:26:32 -0400 Subject: [8u] RFR Backport 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 In-Reply-To: <8697741f36c0e20c8bd10ae24953064374a1e98a.camel@redhat.com> References: <79d7abe1-1d84-9981-b138-68f7d67b8a4d@amazon.com> <8697741f36c0e20c8bd10ae24953064374a1e98a.camel@redhat.com> Message-ID: <6aef08b6-4bc1-2587-93f5-0cecf8d6bc17@redhat.com> Hi, On 2020-08-19 3:41 a.m., Severin Gehwolf wrote: > Hi David, > > On Tue, 2020-08-18 at 23:23 -0700, David Alvarez wrote: >> Hi, >> >> First, sorry, I managed to delete some of the list emails from my inbox, >> so I can't respond in the proper thread, but I have copied the original >> subject, I hope that is enough to locate the original thread (which >> spawns a few months) >> >> I've noticed that 8177334 has landed in openjdk8u272, the update to >> Apache Santuario. When the initial RFR was sent, it was mentioned that >> there were three subsequent bugfixes pending. One of them is still >> missing, JDK-8236645 [1], which is 8u specific and not present in tip, >> so no backport. What is the plan regarding this one? I have seen no >> further comment on the issue (if this has been already discussed, my >> apologies). Are we going to ship openjdk8u272 with this known issue? > > We should try to get JDK-8236645 fixed for OpenJDK 8u. Elliott, if not > on your radar already, I think the 8u CSR has enough info to get a > patch going which should fix this. What do you think? > https://bugs.openjdk.java.net/browse/JDK-8237765 > > Thanks, > Severin > >> David >> >> -- >> [1] https://bugs.openjdk.java.net/browse/JDK-8236645 >> I've completed the work for JDK-8236645 and I'll propose it for review today. It's a fairly simple fix, so I anticipate we can get it in soon. Thanks, Elliott From hohensee at amazon.com Wed Aug 19 15:48:33 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 19 Aug 2020 15:48:33 +0000 Subject: RFO (Request for Opinion): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument In-Reply-To: References: Message-ID: <80681535-3885-4762-BCC6-AA893543D152@amazon.com> Based on other email, the answer seems to be that the patch cannot be backported as is, rather the new methods must be moved to com.sun.management.ThreadMXBean. See https://bugs.openjdk.java.net/browse/JDK-8251498 for a discussion. Paul ?On 8/3/20, 8:57 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: I?d like to get Maintainer guidance on whether this patch can be backported. Issue: https://bugs.openjdk.java.net/browse/JDK-8185003 CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 The patch has proven very useful in reducing profile overhead within Amazon, so we?d like to upstream it. The problem is that while the patch is purely additive (adds a new variant of dumpAllThreads for to java.lang.management.ThreadsMXBean), the j.l.m.ThreadMXBean interface is common to all JDK implementations, which strictly speaking means that all JDK implementations must implement it. In contrast, com.sun.management.ThreadMXBean, is ?implementation specific?, so there?s no issue with strict additions to it. In mitigation, the default implementation is to throw an UnsupportedOperationException. The patched JDK passes the TCK. In addition to its standalone utility, the patch increments JMM_VERSION to JDK 10. JMM_VERSION is further updated to JDK 14 by JDK-8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread JDK-8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes These two patches have been backported to 11.0.9 and I?d like to backport them to 8u272 as well. The 11.0.9 backport had no problem because there were no updates to JMM_VERSION between 11 and 13 inclusive. I don?t believe 8231209/8231968 can be backported without backporting 8185003 first, because doing that seems to me to require creation of a new value of JMM_VERSION, because the result wouldn?t include the new dumpAllThreads method from 8185003. Code that queries JMM_VERSION might/would have to be changed to account for the new version, which is more of a compatibility issue than would be backporting 8185003 first. Hence this RFO. Thanks, Paul From hohensee at amazon.com Wed Aug 19 16:16:33 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 19 Aug 2020 16:16:33 +0000 Subject: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument Message-ID: <8B42FF96-373A-4B03-8B93-D4A47D765F3E@amazon.com> Please review this backport to jdk8u. I especially need a CSR review, since the CSR approval process can be a bottleneck. The patch significantly reduces fleet profiling overhead, and a version of it has been in production at Amazon for over 3 years. Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8185003 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 Original patch: http://hg.openjdk.java.net/jdk10/master/rev/68d46cb9be45 Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251494 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251498 Backport JDK webrev: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.05/ Backport Hotspot webrev: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.05/ Details of the interface changes needed for the backport are in the Description of the Backport CSR 8251498. The actual functional changes are minimal and low risk. Passes the included (suitably modified) test, as well as the tests in jdk/test/java/lang/management/ThreadMXBean jdk/test/com/sun/management/ThreadMXBean Thanks, Paul From aph at redhat.com Wed Aug 19 16:26:09 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Aug 2020 17:26:09 +0100 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support Message-ID: > > On 8/5/20 11:54 PM, Andrew Hughes wrote: > > I didn't go further with the review of this so far, because > > JDK-8144539 is one of the outstanding test backports for the > > SQLite patch as well. I intend to return to that bug trail > > shortly, and we can reconsider both patches once the test > > backports are resolved. > > I believe that 8144539 should not be a blocker for 8080462 because: > the overlap/conflict between them does not appear to be fundamental > -and has been addressed in the current backport proposal-; 8144539 > does not look like a trivial backport -at least at first glance, > given the number of files affected-; and, 8144539 does not seem to > have the same priority than 8080462 -so a low priority backport is > currently blocking a high priority one-. Looks to me that 8144539 is > not even required for compatibility between JDKs, but 8080462 > certainly is. We can't wait any longer for this. Martin, please feel free to commit http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.01/ Andrew. From aph at redhat.com Wed Aug 19 16:36:24 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Aug 2020 17:36:24 +0100 Subject: [8u] TLSv1.3 RFR: 8245474: Add TLS_KRB5 cipher suites support according to RFC-2712 In-Reply-To: References: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com> <0dcb3904-48cb-deb2-985c-f95fe398cfb7@redhat.com> <786001a2-7c10-80eb-7f83-28264b838835@redhat.com> <3827b74a-bc5d-6376-dcf7-ae796584bcff@redhat.com> <88cc6eb5-815e-51d1-c701-e5fc32a8e359@redhat.com> <87194959-BEB3-4492-99D3-E0B76FC92A1E@azul.com> <856AA18D-546F-4151-B734-C945905D4567@azul.com> Message-ID: <0e369641-24dd-97f9-4e79-cc3856cb457d@redhat.com> On 05/08/2020 19:43, Martin Balao wrote: > > While doing a final review to this Step, I found a missing check to > decide whether KRB5 key exchange mechanisms are available or not. Here > there are a few references to the check in the previous SunJSSE engine: > [1] [2] [3]. This is analogous to EC key exchange mechanisms in the new > SunJSSE engine [4] [5]. > > In addition, and given that we have finally co-authored this patch, I've > added a couple of copyright lines to KrbKeyExchange.java and > KrbClientKeyExchange.java files. > > Webrev.05: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8245474/8245474.webrev.05/ OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ebaron at redhat.com Wed Aug 19 16:54:28 2020 From: ebaron at redhat.com (Elliott Baron) Date: Wed, 19 Aug 2020 12:54:28 -0400 Subject: [8u] RFR 8236645: JDK 8u231 introduces a regression with incompatible handling of XML messages Message-ID: <3b1feb7c-298b-9b7a-62dd-1457672ba7fa@redhat.com> Hi, I'd like to request a review of 8236645 for 8u. 8236645 is a bug fix for Oracle JDK 8 that I have re-implemented for OpenJDK 8u. Original fix: https://bugs.openjdk.java.net/browse/JDK-8236645 CSR: https://bugs.openjdk.java.net/browse/JDK-8237765 This fixes a regression introduced by 8177334 and 8217878 by introducing a new system property "com.sun.org.apache.xml.internal.security.lineFeedOnly", which gives Base64 encodings in XML digital signatures the same line-ending format as before these changes were made. The CSR outlined the behaviour of this system property and how it was originally implemented. I added a new test file for this change, based on test cases in javax/xml/crypto/dsig/GenerationTests. This allows us to run the test with the property enabled and disabled, and also doesn't interfere with future backports affecting GenerationTests. 8u webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8236645/webrev.00/ Testing: x86_64 build, jdk_tier1, jdk_security tests Thanks, Elliott From sgehwolf at redhat.com Wed Aug 19 18:02:10 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 19 Aug 2020 20:02:10 +0200 Subject: [8u] RFR 8236645: JDK 8u231 introduces a regression with incompatible handling of XML messages In-Reply-To: <3b1feb7c-298b-9b7a-62dd-1457672ba7fa@redhat.com> References: <3b1feb7c-298b-9b7a-62dd-1457672ba7fa@redhat.com> Message-ID: Hi Elliott, On Wed, 2020-08-19 at 12:54 -0400, Elliott Baron wrote: > Hi, > > I'd like to request a review of 8236645 for 8u. 8236645 is a bug fix for > Oracle JDK 8 that I have re-implemented for OpenJDK 8u. > > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8236645 > CSR: > https://bugs.openjdk.java.net/browse/JDK-8237765 > > This fixes a regression introduced by 8177334 and 8217878 by introducing > a new system property > "com.sun.org.apache.xml.internal.security.lineFeedOnly", which gives > Base64 encodings in XML digital signatures the same line-ending format > as before these changes were made. The CSR outlined the behaviour of > this system property and how it was originally implemented. > > I added a new test file for this change, based on test cases in > javax/xml/crypto/dsig/GenerationTests. This allows us to run the test > with the property enabled and disabled, and also doesn't interfere with > future backports affecting GenerationTests. > > 8u webrev: > https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8236645/webrev.00/ The CSR states: """ This new property has no effect on default behavior nor when com.sun.org.apache.xml.internal.security.ignoreLineBreaks property is set. """ If I read your patch right, then it would not work as specified when both com.sun.org.apache.xml.internal.security.ignoreLineBreaks *and* com.sun.org.apache.xml.internal.security.lineFeedOnly are both set: 451 public static String encodeToString(byte[] bytes) { 452 if (lineFeedOnly) { 453 return LF_ENCODER.encodeToString(bytes); 454 } 455 if (ignoreLineBreaks) { 456 return Base64.getEncoder().encodeToString(bytes); 457 } 458 return Base64.getMimeEncoder().encodeToString(bytes); 459 } Lines 452-454 should move after line 457. test/javax/xml/crypto/dsig/LineFeedOnlyTest.java 63 /* @test id=LF 64 * @bug 8236645 65 * @summary Test "lineFeedOnly" property prevents CR in Base64 encoded output 66 * @run main/othervm/timeout=300 -Dcom.sun.org.apache.xml.internal.security.lineFeedOnly=true LineFeedOnlyTest 67 */ 68 69 /* @test id=CRLF 70 * @bug 8236645 71 * @summary Test "lineFeedOnly" property prevents CR in Base64 encoded output 72 * @run main/othervm/timeout=300 -Dcom.sun.org.apache.xml.internal.security.lineFeedOnly=false LineFeedOnlyTest 73 */ Couldn't we simplify this by using just multiple @run tags? How about this? /* @test * @bug 8236645 * @summary Test "lineFeedOnly" property prevents CR in Base64 encoded output * @run main/othervm/timeout=300 -Dcom.sun.org.apache.xml.internal.security.lineFeedOnly=false LineFeedOnlyTest * @run main/othervm/timeout=300 -Dcom.sun.org.apache.xml.internal.security.lineFeedOnly=true LineFeedOnlyTest */ Thanks, Severin From ebaron at redhat.com Wed Aug 19 18:11:24 2020 From: ebaron at redhat.com (Elliott Baron) Date: Wed, 19 Aug 2020 14:11:24 -0400 Subject: [8u] RFR 8236645: JDK 8u231 introduces a regression with incompatible handling of XML messages In-Reply-To: References: <3b1feb7c-298b-9b7a-62dd-1457672ba7fa@redhat.com> Message-ID: Hi Severin, On 2020-08-19 2:02 p.m., Severin Gehwolf wrote: > Hi Elliott, > > On Wed, 2020-08-19 at 12:54 -0400, Elliott Baron wrote: >> Hi, >> >> I'd like to request a review of 8236645 for 8u. 8236645 is a bug fix for >> Oracle JDK 8 that I have re-implemented for OpenJDK 8u. >> >> Original fix: >> https://bugs.openjdk.java.net/browse/JDK-8236645 >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8237765 >> >> This fixes a regression introduced by 8177334 and 8217878 by introducing >> a new system property >> "com.sun.org.apache.xml.internal.security.lineFeedOnly", which gives >> Base64 encodings in XML digital signatures the same line-ending format >> as before these changes were made. The CSR outlined the behaviour of >> this system property and how it was originally implemented. >> >> I added a new test file for this change, based on test cases in >> javax/xml/crypto/dsig/GenerationTests. This allows us to run the test >> with the property enabled and disabled, and also doesn't interfere with >> future backports affecting GenerationTests. >> >> 8u webrev: >> https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8236645/webrev.00/ > > The CSR states: > """ > This new property has no effect on default behavior nor when > com.sun.org.apache.xml.internal.security.ignoreLineBreaks property is > set. > """ > > If I read your patch right, then it would not work as specified when > both com.sun.org.apache.xml.internal.security.ignoreLineBreaks *and* > com.sun.org.apache.xml.internal.security.lineFeedOnly are both set: > > 451 public static String encodeToString(byte[] bytes) { > 452 if (lineFeedOnly) { > 453 return LF_ENCODER.encodeToString(bytes); > 454 } > 455 if (ignoreLineBreaks) { > 456 return Base64.getEncoder().encodeToString(bytes); > 457 } > 458 return Base64.getMimeEncoder().encodeToString(bytes); > 459 } > > Lines 452-454 should move after line 457. Good catch! Thank you for pointing this out. > > test/javax/xml/crypto/dsig/LineFeedOnlyTest.java > > 63 /* @test id=LF > 64 * @bug 8236645 > 65 * @summary Test "lineFeedOnly" property prevents CR in Base64 encoded output > 66 * @run main/othervm/timeout=300 -Dcom.sun.org.apache.xml.internal.security.lineFeedOnly=true LineFeedOnlyTest > 67 */ > 68 > 69 /* @test id=CRLF > 70 * @bug 8236645 > 71 * @summary Test "lineFeedOnly" property prevents CR in Base64 encoded output > 72 * @run main/othervm/timeout=300 -Dcom.sun.org.apache.xml.internal.security.lineFeedOnly=false LineFeedOnlyTest > 73 */ > > Couldn't we simplify this by using just multiple @run tags? > > How about this? > > /* @test > * @bug 8236645 > * @summary Test "lineFeedOnly" property prevents CR in Base64 encoded output > * @run main/othervm/timeout=300 -Dcom.sun.org.apache.xml.internal.security.lineFeedOnly=false LineFeedOnlyTest > * @run main/othervm/timeout=300 -Dcom.sun.org.apache.xml.internal.security.lineFeedOnly=true LineFeedOnlyTest > */ Sounds good to me. Here's an updated webrev that addresses both of these points: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8236645/webrev.01/ Thanks, Elliott From sgehwolf at redhat.com Wed Aug 19 18:19:52 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 19 Aug 2020 20:19:52 +0200 Subject: [8u] RFR 8236645: JDK 8u231 introduces a regression with incompatible handling of XML messages In-Reply-To: References: <3b1feb7c-298b-9b7a-62dd-1457672ba7fa@redhat.com> Message-ID: <48642ba1970e16533076215490d7d03eaef38d03.camel@redhat.com> On Wed, 2020-08-19 at 14:11 -0400, Elliott Baron wrote: > Here's an updated webrev that addresses both of these points: > https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8236645/webrev.01/ Please add a case to the test where both properties are being set capturing indended behaviour. Thanks, Severin From ebaron at redhat.com Wed Aug 19 18:54:19 2020 From: ebaron at redhat.com (Elliott Baron) Date: Wed, 19 Aug 2020 14:54:19 -0400 Subject: [8u] RFR 8236645: JDK 8u231 introduces a regression with incompatible handling of XML messages In-Reply-To: <48642ba1970e16533076215490d7d03eaef38d03.camel@redhat.com> References: <3b1feb7c-298b-9b7a-62dd-1457672ba7fa@redhat.com> <48642ba1970e16533076215490d7d03eaef38d03.camel@redhat.com> Message-ID: <2600448e-2cd7-75a1-3c85-3c05eada080c@redhat.com> Hi Severin, On 2020-08-19 2:19 p.m., Severin Gehwolf wrote: > On Wed, 2020-08-19 at 14:11 -0400, Elliott Baron wrote: >> Here's an updated webrev that addresses both of these points: >> https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8236645/webrev.01/ > > Please add a case to the test where both properties are being set > capturing indended behaviour. > Good idea. I've also added a test for the default behaviour with no properties set. Updated webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8236645/webrev.02/ Thanks, Elliott From gnu.andrew at redhat.com Thu Aug 20 03:09:51 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Aug 2020 04:09:51 +0100 Subject: OpenJDK 8u272-b0{2,3,4} Released Message-ID: <20200820030951.GA3030259@stopbrexit> I've made available early access source bundles for 8u272, based on the tags jdk8u272-b02, jdk8u272-b03 & jdk8u272-b04: https://openjdk-sources.osci.io/openjdk8/openjdk8u272-b02-ea.tar.xz https://openjdk-sources.osci.io/openjdk8/openjdk8u272-b03-ea.tar.xz https://openjdk-sources.osci.io/openjdk8/openjdk8u272-b04-ea.tar.xz The tarballs are accompanied by digital signatures available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u272-b02-ea.tar.xz.sig https://openjdk-sources.osci.io/openjdk8/openjdk8u272-b03-ea.tar.xz.sig https://openjdk-sources.osci.io/openjdk8/openjdk8u272-b04-ea.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint =3D CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: da34f72bae0db9d434081da4f363fe1909ec21f6afb9cebe034b69e38ff30632 openjdk8u272-b02-ea.tar.xz 1e7a5b68834591e2807b5baea3db97fb3745d4c251370b0d1a8ac9c869647579 openjdk8u272-b02-ea.tar.xz.sig 85f3b3113e2a09b94a219c7e33213913903c121d915bca4f3d94d218bf8f1121 openjdk8u272-b03-ea.tar.xz a4945ab42b1d0b66915529d4add87123147f27bfafc75f92c60a95e9e59e5818 openjdk8u272-b03-ea.tar.xz.sig b521ee3b1f95afb04df1931d2957161448f4544a62412a53999ed030634d0f37 openjdk8u272-b04-ea.tar.xz 856e2b7e8e4c6a3ee6a87231e038c372bde0ca552c6101e93865dbb28db0fd06 openjdk8u272-b04-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u272-b02-ea.sha256 https://openjdk-sources.osci.io/openjdk8/openjdk8u272-b03-ea.sha256 https://openjdk-sources.osci.io/openjdk8/openjdk8u272-b04-ea.sha256 Changes in 8u272-b02: - JDK-8023697: failed class resolution reports different class name in detail message for the first and subsequent times - JDK-8025886: replace [[ and == bash extensions in regtest - JDK-8046274: Removing dependency on jakarta-regexp - JDK-8048933: -XX:+TraceExceptions output should include the message - JDK-8076151: [TESTBUG] Test java/awt/FontClass/CreateFont/fileaccess/FontFile.java fails - JDK-8148854: Class names "SomeClass" and "LSomeClass;" treated by JVM as an equivalent - JDK-8154313: Generated javadoc scattered all over the place - JDK-8163251: Hard coded loop limit prevents reading of smart card data greater than 8k - JDK-8173300: [TESTBUG]compiler/tiered/NonTieredLevelsTest.java fails with compiler.whitebox.SimpleTestCaseHelper(int) must be compiled - JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java - JDK-8191678: [TESTBUG] Add keyword headful in java/awt FocusTransitionTest test. - JDK-8201633: Problems with AES-GCM native acceleration - JDK-8211049: Second parameter of "initialize" method is not used - JDK-8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero - JDK-8220165: Encryption using GCM results in RuntimeException- input length out of bound - JDK-8220555: JFR tool shows potentially misleading message when it cannot access a file - JDK-8224217: RecordingInfo should use textual representation of path - JDK-8231779: crash HeapWord*ParallelScavengeHeap::failed_mem_allocate - JDK-8238380: java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10 - JDK-8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10 - JDK-8238388: libj2gss/NativeFunc.o "multiple definition" link errors with GCC10 - JDK-8242556: Cannot load RSASSA-PSS public key with non-null params from byte array - JDK-8250755: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java Changes in 8u272-b03: - JDK-6574989: TEST_BUG: javax/sound/sampled/Clip/bug5070081.java fails sometimes - JDK-8148754: C2 loop unrolling fails due to unexpected graph shape - JDK-8192953: sun/management/jmxremote/bootstrap/*.sh tests fail with error : revokeall.exe: Permission denied - JDK-8203357: Container Metrics - JDK-8209113: Use WeakReference for lastFontStrike for created Fonts - JDK-8216283: Allow shorter method sampling interval than 10 ms - JDK-8221569: JFR tool produces incorrect output when both --categories and --events are specified - JDK-8233097: Fontmetrics for large Fonts has zero width - JDK-8248851: CMS: Missing memory fences between free chunk check and klass read - JDK-8250875: Incorrect parameter type for update_number in JDK_Version::jdk_update Changes in 8u272-b04: - JDK-8061616: HotspotDiagnosticMXBean.getVMOption() throws IllegalArgumentException for flags of type double - JDK-8177334: Update xmldsig implementation to Apache Santuario 2.1.1 - JDK-8217878: ENVELOPING XML signature no longer works in JDK 11 - JDK-8218629: XML Digital Signature throws NAMESPACE_ERR exception on OpenJDK 11, works 8/9/10 - JDK-8243138: Enhance BaseLdapServer to support starttls extended request Thanks, -- Andrew :) Senior 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 From shade at redhat.com Thu Aug 20 07:30:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Aug 2020 09:30:23 +0200 Subject: [8u] RFR (XS) 8252084: Minimal VM fails to bootcycle: undefined symbol: AgeTableTracer::is_tenuring_distribution_event_enabled Message-ID: Hi, This is 8u-specific bug that only manifests with Minimal VM x86_32: $ CXX=i686-linux-gnu-g++ CC=i686-linux-gnu-gcc sh ./configure --with-debug-level=fastdebug --with-jtreg=/home/shade/Install/jtreg --disable-precompiled-headers --with-native-debug-symbols=internal --openjdk-target=i386-linux-gnu --with-extra-cflags=-Wno-error --with-toolchain-path=/chroots/i386/ --with-jvm-variants=minimal1 $ CONF=linux-x86-normal-minimal1-fastdebug make bootcycle-images ... Error: dl failure on line 893 Error: failed /home/shade/trunks/jdk8u-dev/build/linux-x86-normal-minimal1-fastdebug/images/j2sdk-image/jre/lib/i386/minimal/libjvm.so, because /home/shade/trunks/jdk8u-dev/build/linux-x86-normal-minimal1-fastdebug/images/j2sdk-image/jre/lib/i386/minimal/libjvm.so: undefined symbol: _ZN14AgeTableTracer38is_tenuring_distribution_event_enabledEv I believe this is caused by JFR integration, and the fix looks simple: build ageTableTracer.cpp even when most GCs are disabled by Minimal VM: hotspot $ diff -r eb30962d9b6d make/excludeSrc.make --- a/make/excludeSrc.make Fri Feb 08 20:51:55 2019 -0500 +++ b/make/excludeSrc.make Thu Aug 20 09:28:53 2020 +0200 @@ -95,6 +95,7 @@ gc_shared_keep := \ adaptiveSizePolicy.cpp \ ageTable.cpp \ + ageTableTracer.cpp \ collectorCounters.cpp \ cSpaceCounters.cpp \ gcId.cpp \ Testing: x86_32 minimal bootcycle build -- Thanks, -Aleksey From sgehwolf at redhat.com Thu Aug 20 08:20:31 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 20 Aug 2020 10:20:31 +0200 Subject: [8u] RFR 8236645: JDK 8u231 introduces a regression with incompatible handling of XML messages In-Reply-To: <2600448e-2cd7-75a1-3c85-3c05eada080c@redhat.com> References: <3b1feb7c-298b-9b7a-62dd-1457672ba7fa@redhat.com> <48642ba1970e16533076215490d7d03eaef38d03.camel@redhat.com> <2600448e-2cd7-75a1-3c85-3c05eada080c@redhat.com> Message-ID: <29856a4ed39c734b3ae2be7200eb5cac45b33b4f.camel@redhat.com> Hi Elliott, On Wed, 2020-08-19 at 14:54 -0400, Elliott Baron wrote: > Good idea. I've also added a test for the default behaviour with no > properties set. > > Updated webrev: > https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8236645/webrev.02/ Looks good to me. Thanks, Severin From sgehwolf at redhat.com Thu Aug 20 08:37:10 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 20 Aug 2020 10:37:10 +0200 Subject: [8u] RFR (XS) 8252084: Minimal VM fails to bootcycle: undefined symbol: AgeTableTracer::is_tenuring_distribution_event_enabled In-Reply-To: References: Message-ID: <7a56cacf61ec28695332406c6ec3a676274b13b3.camel@redhat.com> Hi Aleksey, On Thu, 2020-08-20 at 09:30 +0200, Aleksey Shipilev wrote: > Hi, > > This is 8u-specific bug that only manifests with Minimal VM x86_32: > > $ CXX=i686-linux-gnu-g++ CC=i686-linux-gnu-gcc sh ./configure --with-debug-level=fastdebug > --with-jtreg=/home/shade/Install/jtreg --disable-precompiled-headers > --with-native-debug-symbols=internal --openjdk-target=i386-linux-gnu --with-extra-cflags=-Wno-error > --with-toolchain-path=/chroots/i386/ --with-jvm-variants=minimal1 > > $ CONF=linux-x86-normal-minimal1-fastdebug make bootcycle-images > ... > Error: dl failure on line 893 > Error: failed > /home/shade/trunks/jdk8u-dev/build/linux-x86-normal-minimal1-fastdebug/images/j2sdk-image/jre/lib/i386/minimal/libjvm.so, > because > /home/shade/trunks/jdk8u-dev/build/linux-x86-normal-minimal1-fastdebug/images/j2sdk-image/jre/lib/i386/minimal/libjvm.so: > undefined symbol: _ZN14AgeTableTracer38is_tenuring_distribution_event_enabledEv > > I believe this is caused by JFR integration, and the fix looks simple: build ageTableTracer.cpp even > when most GCs are disabled by Minimal VM: > > hotspot $ diff -r eb30962d9b6d make/excludeSrc.make > --- a/make/excludeSrc.make Fri Feb 08 20:51:55 2019 -0500 > +++ b/make/excludeSrc.make Thu Aug 20 09:28:53 2020 +0200 > @@ -95,6 +95,7 @@ > gc_shared_keep := \ > adaptiveSizePolicy.cpp \ > ageTable.cpp \ > + ageTableTracer.cpp \ > collectorCounters.cpp \ > cSpaceCounters.cpp \ > gcId.cpp \ > > Testing: x86_32 minimal bootcycle build This seems fine to me. Thanks, Severin From shade at redhat.com Thu Aug 20 08:43:48 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Aug 2020 10:43:48 +0200 Subject: [8u] RFR (XS) 8252084: Minimal VM fails to bootcycle: undefined symbol: AgeTableTracer::is_tenuring_distribution_event_enabled In-Reply-To: <7a56cacf61ec28695332406c6ec3a676274b13b3.camel@redhat.com> References: <7a56cacf61ec28695332406c6ec3a676274b13b3.camel@redhat.com> Message-ID: <51d8df39-a231-52b5-a30d-8f07db1c0cf8@redhat.com> On 8/20/20 10:37 AM, Severin Gehwolf wrote: > This seems fine to me. Thanks, tagged. -- -Aleksey From sgehwolf at redhat.com Thu Aug 20 12:26:48 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 20 Aug 2020 14:26:48 +0200 Subject: RFR[8u]: 8251546: 8u backport of JDK-8194298 breaks AIX and Solaris builds Message-ID: <1a75af7860695641fd1cedd60241a5fde9246035.camel@redhat.com> Hi, Could I please get a review of this 8u-only change fixing a build break on AIX and Solaris introduced with the backport of JDK-8194298? The fix as such is 8u only as later backports don't have that issue. The gist of the patch is to: * move the impls of {s,g}etTcpSocketOption and socketOptionSupported functions out of the else block of ifdef __solaris__. They are guarded by their own ifdefs and no-op impls are being provided for platforms which aren't supported (as before). * define some constants on AIX/Solaris so that the code compiles. Constants aren't used in the impl and this allows for?setTcpSocketOption/getTcpSocketOption call-sites to remain outside any ifdef blocks. Bug: https://bugs.openjdk.java.net/browse/JDK-8251546 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8251546/02/webrev/ Testing: Builds on AIX and Solaris. Linux x86_64 and keepalive tests. Thoughts? Thanks, Severin From shade at redhat.com Thu Aug 20 12:33:45 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Aug 2020 14:33:45 +0200 Subject: RFR[8u]: 8251546: 8u backport of JDK-8194298 breaks AIX and Solaris builds In-Reply-To: <1a75af7860695641fd1cedd60241a5fde9246035.camel@redhat.com> References: <1a75af7860695641fd1cedd60241a5fde9246035.camel@redhat.com> Message-ID: On 8/20/20 2:26 PM, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this 8u-only change fixing a build break > on AIX and Solaris introduced with the backport of JDK-8194298? The fix > as such is 8u only as later backports don't have that issue. > > The gist of the patch is to: > * move the impls of {s,g}etTcpSocketOption and socketOptionSupported > functions out of the else block of ifdef __solaris__. They are > guarded by their own ifdefs and no-op impls are being provided for > platforms which aren't supported (as before). > * define some constants on AIX/Solaris so that the code compiles. > Constants aren't used in the impl and this allows > for?setTcpSocketOption/getTcpSocketOption call-sites to remain > outside any ifdef blocks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251546 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8251546/02/webrev/ Looks fine. -- Thanks, -Aleksey From andrew_m_leonard at uk.ibm.com Thu Aug 20 12:56:36 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 20 Aug 2020 13:56:36 +0100 Subject: RFR: 8251886: Unable to use --disable-zip-debug-info on JDK8 Windows In-Reply-To: <20200817172622.GB2749792@stopbrexit> References: <20200817172622.GB2749792@stopbrexit> Message-ID: Hi Andrew, I've done a webrev for the backport of https://bugs.openjdk.java.net/browse/JDK-8025936 http://cr.openjdk.java.net/~aleonard/8025936/ Tests on the various platforms are all good. The original patch would not backport directly since it's quite old, but it didn't take too much to fix up. The main thing to add was the no_strip conditions. I have added jdk8u-fix-request to the bug to backport. Would you be able to sponsor please? Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Hughes To: Andrew Leonard Cc: jdk8u-dev at openjdk.java.net Date: 17/08/2020 18:26 Subject: [EXTERNAL] Re: RFR: 8251886: Unable to use --disable-zip-debug-info on JDK8 Windows On 15:20 Mon 17 Aug , Andrew Leonard wrote: > Hi, > Please can I request a sponsor for this fix to support --disable-zip-debug > on Windows? > https://bugs.openjdk.java.net/browse/JDK-8251886 > webrev: http://cr.openjdk.java.net/~aleonard/8251886/webrev.00/ > Tier1 clean > > Many thanks > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Is this https://bugs.openjdk.java.net/browse/JDK-8025936? It seems backporting that would also unify the handling of unpack. Thanks, -- Andrew :) Senior 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 [attachment "signature.asc" deleted by Andrew Leonard/UK/IBM] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From sgehwolf at redhat.com Thu Aug 20 13:21:26 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 20 Aug 2020 15:21:26 +0200 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> Message-ID: <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> On Tue, 2020-07-21 at 17:57 +0100, Andrew Hughes wrote: > > On 17/07/2020 15:07, Severin Gehwolf wrote: > > Hi, > > > > Please review this OpenJDK 8u backport for OperatingSystemMXBean's > > container awareness which has been backported to Oracle JDK (parity > > bug). This backport depends on JDK-8203357[1] for Metrics.java which is > > being used in this patch. > > > > In that case, let's wait until that backport is reviewed and committed. JDK-8203357 has been pushed a while ago. Could I get a review of this please? Thanks, Severin From gnu.andrew at redhat.com Thu Aug 20 17:16:07 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Aug 2020 18:16:07 +0100 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <78a1c49794afdf13013a4c3d75efab50f4745870.camel@redhat.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> <78a1c49794afdf13013a4c3d75efab50f4745870.camel@redhat.com> Message-ID: <20200820171607.GC3112706@stopbrexit> On 08:51 Wed 19 Aug , Severin Gehwolf wrote: > On Mon, 2020-08-17 at 06:26 +0100, Andrew Hughes wrote: > > On 11:51 Thu 13 Aug , Severin Gehwolf wrote: > > > On Tue, 2020-08-11 at 14:48 -0400, Zhengyu Gu wrote: > > > > Hi Michael, > > > > > > > > > My tests/comments: > > > > > * @since still says 12. Is that correct? > > > > > > I agree. Zhengyu, please remove the @since 12 tags in this backport. It > > > doesn't make sense to have them in either 11 or 8. > > > > > > > I disagree. Such tags are a useful indicator that this is a backported > > API that wasn't in 8 GA. > > If we are starting to rely on @since tags as an indicator for backports > then we're in trouble. Instead, the bug system and source control > should be used for this. Given that, by removing the @since tag we > don't loose info that it's a backport. > I didn't claim it was the only indicator. It is useful to have it there in the source code if you're looking at the file concerned. It's also easily accessible. Being able to find the same information in the bug system or source control system requires you to be aware of their existence and to know to look for such information there. To find the same information as the simple @since tag provides, I would need a checkout of the code from the source code repository, to know how to look up when that file was added, and then use the bug ID to lookup in the bug database in which JDK it was added. All a lot more complicated than one line of text that only requires the sources concerned. > > What would be the issue with leaving them in? > > A couple of reasons: > > * It's confusing. Mentioning something related to JDK 12 in a JDK 8 > tree is, well, confusing. It only wouldn't be so if you are > intimately familiar with the process and know about this mailing > list discussion. I guess we have to beg to differ on this. I don't find it confusing. The @since tag has long-term well-defined semantics familiar to any Java user. I don't think it's that complicated to infer that if "@since 12" is used in 8u sources, it must have been backported. I have used it in this manner for years (e.g. [0] [1]) and never been aware of anyone finding it confusing before. On the contrary, to know to strip this information in a backport does require the person backporting to have knowledge of the need to do that and this discussion. > * @Since tags are usually used for *publicly* exposed classes as an > aid for JDK API consumers. "This API is available for JDK 12 and > onwards". I'm aware there are instances where it was used for > internal classes too, but they become less prominent these days. It > makes sense to have them for the original JDK 12 change. For the JDK > 8u backport, classes have been moved to a private package. It's not > a 1-to-1 backport. The value of it being preserved regardless makes > little sense. It's not the original class where it was added to > begin with. It is rare that public API would be backported. The one case where this has happened (ALPN+RSA-PSS) used "@since 8". I'd have preferred "@since 8M3" or "@since 8u41". It not being publicly exposed actually seems more reason to just leave it in, as Javadoc won't be generated, so only someone looking at the source would see it. > * The SinceTree.java interface mentions this in its javadoc: "Returns > the text explaining the availability of the item being documented." > That's wrong for code in JDK 8. We'd be putting a @since 12 on code > introduced in an update version of 8u. 12 was its first availability. You could use @since 8u272 if you like. The main concern is to make it clear that it wasn't part of 8 GA. > > Overall, the drawbacks outweigh the benefits. > I disagree. It seems mandating this could result in unnecessary differences between 8u & later sources, and additional work for backporters, all for no clear benefit. > Thanks, > Severin > [0] https://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/9ab3c966585d [1] https://openjdk.java.net/jeps/129 [2] https://jdk.java.net/java-se-ri/8-MR3 -- Andrew :) Senior 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 From gnu.andrew at redhat.com Thu Aug 20 17:20:03 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Aug 2020 18:20:03 +0100 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: References: Message-ID: <20200820172003.GD3112706@stopbrexit> On 17:26 Wed 19 Aug , Andrew Haley wrote: > > > > On 8/5/20 11:54 PM, Andrew Hughes wrote: > > > I didn't go further with the review of this so far, because > > > JDK-8144539 is one of the outstanding test backports for the > > > SQLite patch as well. I intend to return to that bug trail > > > shortly, and we can reconsider both patches once the test > > > backports are resolved. > > > > I believe that 8144539 should not be a blocker for 8080462 because: > > the overlap/conflict between them does not appear to be fundamental > > -and has been addressed in the current backport proposal-; 8144539 > > does not look like a trivial backport -at least at first glance, > > given the number of files affected-; and, 8144539 does not seem to > > have the same priority than 8080462 -so a low priority backport is > > currently blocking a high priority one-. Looks to me that 8144539 is > > not even required for compatibility between JDKs, but 8080462 > > certainly is. > > We can't wait any longer for this. Martin, please feel free to commit > http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.01/ > > Andrew. > I'm working on the dependencies for this right now. A few days is hardly going to matter. I'll then review Martin's fix. -- Andrew :) Senior 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 From gnu.andrew at redhat.com Thu Aug 20 17:22:33 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Aug 2020 18:22:33 +0100 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> Message-ID: <20200820172233.GE3112706@stopbrexit> On 15:21 Thu 20 Aug , Severin Gehwolf wrote: > On Tue, 2020-07-21 at 17:57 +0100, Andrew Hughes wrote: > > > > On 17/07/2020 15:07, Severin Gehwolf wrote: > > > Hi, > > > > > > Please review this OpenJDK 8u backport for OperatingSystemMXBean's > > > container awareness which has been backported to Oracle JDK (parity > > > bug). This backport depends on JDK-8203357[1] for Metrics.java which is > > > being used in this patch. > > > > > > > In that case, let's wait until that backport is reviewed and committed. > > JDK-8203357 has been pushed a while ago. Could I get a review of this > please? > > Thanks, > Severin > Please link to the updated webrev against current 8u-dev. Thanks, -- Andrew :) Senior 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 From sgehwolf at redhat.com Thu Aug 20 17:42:40 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 20 Aug 2020 19:42:40 +0200 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <20200820172233.GE3112706@stopbrexit> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> <20200820172233.GE3112706@stopbrexit> Message-ID: On Thu, 2020-08-20 at 18:22 +0100, Andrew Hughes wrote: > On 15:21 Thu 20 Aug , Severin Gehwolf wrote: > > On Tue, 2020-07-21 at 17:57 +0100, Andrew Hughes wrote: > > > On 17/07/2020 15:07, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Please review this OpenJDK 8u backport for OperatingSystemMXBean's > > > > container awareness which has been backported to Oracle JDK (parity > > > > bug). This backport depends on JDK-8203357[1] for Metrics.java which is > > > > being used in this patch. > > > > > > > > > > In that case, let's wait until that backport is reviewed and committed. > > > > JDK-8203357 has been pushed a while ago. Could I get a review of this > > please? > > > > Thanks, > > Severin > > > > Please link to the updated webrev against current 8u-dev. They're unchanged: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012178.html webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/01/ Thanks, Severin From gnu.andrew at redhat.com Thu Aug 20 18:19:13 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Aug 2020 19:19:13 +0100 Subject: [RFR] [8u] 8078334: Mark regression tests using randomness Message-ID: <20200820181913.GF3112706@stopbrexit> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8078334/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8078334 This is a long but simple patch, which tags a number of test cases. It removes unnecessary differences between the copies of these test cases in 8u and in later versions, simplifying future backports (in particular, those for PKCS#11). Most of the differences between this patch and the 9u version are due to differing context and a few missing test cases: * The TEST.ROOT change is already present in 8u, thanks to JDK-8151731: "Add new jtreg keywords to jdk 8" * The test/com/oracle/security ucrypto tests are not present in 8u, as UCrypto wasn't added to OpenJDK until JDK-8046002: "Move Ucrypto to the open jdk repo". It's a Solaris feature so I see little need to backport it. * test/com/sun/crypto/provider/Cipher/RSA/TestOAEP.java has an additional bug ID in 8u, changing the context. * test/java/io/InputStream/TransferTo.java is not present in 8u, as the transferTo method is not in 8u (introduced by JDK-8066867: Add InputStream transferTo to transfer content to an OutputStream) * test/java/lang/ClassLoader/Assert.java, test/java/lang/Math/HypotTests.java, test/java/lang/Math/IeeeRecommendedTests.java, test/java/lang/Math/Log1pTests.java have slight context differences in 8u. * test/java/lang/invoke/MethodHandles/CatchExceptionTest.java does not have the "intermittent" keyword in 8u. It seems JDK-8055269: "java/lang/invoke/MethodHandles/CatchExceptionTest.java fails intermittently" will have fixed this. * test/java/math/BigDecimal/StringConstructor.java, test/java/math/BigInteger/BigIntegerTest.java, test/java/math/BigInteger/ModPow65537.java, test/java/math/BigInteger/PrimeTest.java, test/java/math/BigInteger/SymmetricRangeTests.java, test/java/util/Arrays/Correct.java, test/java/util/Base64/TestBase64.java, test/java/util/BitSet/BSMethods.java have slight context differences in 8u (fewer bug IDs) * test/java/util/logging/FileHandlerLongLimit.java was introduced by JDK-8059767: "FileHandler should allow 'long' limits and handle overflow of MeteredStream.written.", which is an enhancement out of scope for backport. * test/java/util/logging/FileHandlerPatternExceptions.java was introduced by JDK-8025690: "Default FileHandler constructor doesn't throw NullPointerException if pattern is empty and count > 1" which changes the behaviour of a public constructor and so too risky for backport. * test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java was introduced by JDK-8060132: "Handlers configured on abstract nodes in logging.properties are not always properly closed", which changes behaviour in a way worthy of a release note, so not suitable for backport. * test/java/util/logging/LoggingDeadlock.java has slight context differences. * test/java/util/zip/DeInflate.java already gained the tag in JDK-8184682: "Upgrade compression library" * test/java/util/zip/InflateIn_DeflateOut.java, test/sun/nio/cs/TestStringCoding.java, test/java/util/zip/ZipFile/ReadZip.java have additional bug IDs in 8u. * test/java/util/zip/ZipFile/Assortment.java, test/java/util/zip/ZipFile/MultiThreadedReadTest.java, test/javax/crypto/KeyGenerator/TestKGParity.java, test/sun/management/jmxremote/startstop/JMXStartStopTest.java, test/sun/misc/FloatingDecimal/TestFloatingDecimal.java, test/sun/security/provider/DSA/TestDSA2.java, test/sun/security/rsa/TestKeyPairGenerator.java and test/sun/security/rsa/TestSignatures.java have slight context differences. * test/sun/security/mscapi/PrngSlow.java has an additional @requires in 8u. * test/javax/net/ssl/SSLEngine/LargeBufs.java, test/sun/security/ssl/GenSSLConfigs/main.java and test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java can be found in test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java, test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java and test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java in 8u, respectively. Backporting JDK-8032473: "Restructure JSSE regression test hierarchy in jdk test" seems pointless, given the imminent import of TLS 1.3. Ok for 8u? Thanks, -- Andrew :) Senior 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 From volker.simonis at gmail.com Thu Aug 20 18:30:16 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 20 Aug 2020 20:30:16 +0200 Subject: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument In-Reply-To: <8B42FF96-373A-4B03-8B93-D4A47D765F3E@amazon.com> References: <8B42FF96-373A-4B03-8B93-D4A47D765F3E@amazon.com> Message-ID: On Wed, Aug 19, 2020 at 6:17 PM Hohensee, Paul wrote: > > Please review this backport to jdk8u. I especially need a CSR review, since the CSR approval process can be a bottleneck. The patch significantly reduces fleet profiling overhead, and a version of it has been in production at Amazon for over 3 years. > > > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8185003 > > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 > > Original patch: http://hg.openjdk.java.net/jdk10/master/rev/68d46cb9be45 > > > > Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251494 > > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251498 > > Backport JDK webrev: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.05/ > JDK part looks good to me. > Backport Hotspot webrev: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.05/ > HotSpot part looks good to me but see discussion below. > > > Details of the interface changes needed for the backport are in the Description of the Backport CSR 8251498. The actual functional changes are minimal and low risk. > I've also reviewed the CSR yesterday which I think is fine. But now, when looking at the implementation, I'm a little concerned about changing JMM_VERSION from " 0x20010203" to "0x20020000" in "jmm.h". This might be especially problematic in combination with the changes in "Management::get_jmm_interface()" which is called by JVM_GetManagement(): void* Management::get_jmm_interface(int version) { #if INCLUDE_MANAGEMENT - if (version == JMM_VERSION_1_0) { + if (version == JMM_VERSION) { return (void*) &jmm_interface; } #endif // INCLUDE_MANAGEMENT return NULL; } You've correctly fixed the single caller of "JVM_GetManagement()" in the JDK (in "JNI_OnLoad()" in "management.c"): - jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION_1_0); + jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION); but I wonder if there are other monitoring/serviceability tools out there which use this interface and which will break after this change. A quick search revealed at least two StackOverflow entries which recommend using "JVM_GetManagement(JMM_VERSION_1_0)" [1,2] and there's a talk and a blog entry doing the same [3, 4]. I'm not sure how relevant this is but I think a much safer and backwards-compatible way of doing this downport would be the following: - don't change "Management::get_jmm_interface()" (i.e. still check for "JMM_VERSION_1_0") but return the "new" JMM_VERSION in "jmm_GetVersion()". This won't break anything but will make it possible for clients to detect the new version if they want. - don't change the signature of "DumpThreads()". Instead add a new version (e.g. "DumpThreadsMaxDepth()/jmm_DumpThreadsMaxDepth()") to the "JMMInterface" struct and to "jmm_interface" in "management.cpp". You can do this in one of the two first, reserved fields of "JMMInterface" so you won't break binary compatibility. "jmm_DumpThreads()" will then be a simple wrapper which calls "jmm_DumpThreadsMaxDepth()" with Integer.MAX_VALUE as depth. - in the jdk you then simply call "DumpThreadsMaxDepth()" in "Java_sun_management_ThreadImpl_dumpThreads0()" I think this way we can maintain full binary compatibility while still using the new feature. What do you think? Best regards, Volker [1] https://stackoverflow.com/questions/23632653/generate-java-heap-dump-on-uncaught-exception [2] https://stackoverflow.com/questions/60887816/jvm-options-printnmtstatistics-save-info-to-file [3] https://sudonull.com/post/25841-JVM-TI-how-to-make-a-plugin-for-a-virtual-machine-Odnoklassniki-company-blog [4] https://2019.jpoint.ru/talks/2o8scc5jbaurnqqlsydzxv/ > > Passes the included (suitably modified) test, as well as the tests in > > > > jdk/test/java/lang/management/ThreadMXBean > > jdk/test/com/sun/management/ThreadMXBean > > > > Thanks, > > Paul From gnu.andrew at redhat.com Thu Aug 20 20:29:33 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Aug 2020 21:29:33 +0100 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> <20200820172233.GE3112706@stopbrexit> Message-ID: <20200820202933.GA3306744@stopbrexit> On 19:42 Thu 20 Aug , Severin Gehwolf wrote: > > They're unchanged: > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012178.html > > webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/01/ > > Thanks, > Severin > Thanks. In future, it would help to tag the issue with jdk8u-needs-review and link to the RFR there, so it doesn't get lost in the mail. See the OpenJDK wiki [0] for further information and a link to the 8u review filter. The mapping of the native files from 11u to 8u is rather confusing, as the changes are not 1:1. A conversion mapping would have been helpful. >From what I can work out, * src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c => src/aix/native/sun/management/AixOperatingSystem.c getSystemCpuLoad renamed to getSystemCpuLoad0 as noted. Copyright line missing. getHostConfiguredCpuCount0 & getSingleCpuLoad0 missing. * src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c => src/solaris/native/sun/management/LinuxOperatingSystem.c getSystemCpuLoad renamed to getSystemCpuLoad0 as noted. Looks good, though there is an odd missing whitespace change near sysconf(_SC_NPROCESSORS_ONLN). * src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c => src/solaris/native/sun/management/MacosxOperatingSystem.c getSystemCpuLoad renamed to getSystemCpuLoad0 as noted. Copyright line missing. getHostConfiguredCpuCount0 & getSingleCpuLoad0 missing. * N/A => src/solaris/native/sun/management/OperatingSystemImpl.c Addition of '0' suffix as noted. getHostConfiguredCpuCount0 & getSingleCpuLoad0 implemented here under #ifndef linux. * src/jdk.management/solaris/native/libmanagement_ext/UnixOperatingSystem.c => src/solaris/native/sun/management/SolarisOperatingSystem.c getSystemCpuLoad renamed to getSystemCpuLoad0 as noted. Copyright line missing. getHostConfiguredCpuCount0 & getSingleCpuLoad0 missing. * N/A => src/windows/native/sun/management/OperatingSystemImpl.c Addition of '0' suffix as noted. getHostConfiguredCpuCount0 & getSingleCpuLoad0 implemented here as in UnixOperatingSystem.c Copyright line missing. So AixOperatingSystem.c, MacosxOperatingSystem.c, LinuxOperatingSystem.c and SolarisOperatingSystem.c share common code from OperatingSystemImpl.c, and thus the default implementations of getHostConfiguredCpuCount0 & getSingleCpuLoad0 can be shared rather than appearing in each individual file. Is this correct? Again, clarification on these in the original RFR would have helped the review. If my assumption is correct, then the only fix needed for these files is to add the missing copyright updates in the non-Linux files. There is no Windows file in the 11u version. Why is it needed in 8u? In both, OperatingSystemImpl.java seems to be under src/jdk.management/unix/classes or src/solaris/classes/sun/management, rather than share/classes. Your description of the Subsystem.java changes is quite terse. Can you explain in more detail why the readMatchingLines change is not needed? OperatingSystemImpl.java & OperatingSystemMXBean.java look fine. [0] https://wiki.openjdk.java.net/display/jdk8u/Main Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Thu Aug 20 20:44:15 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Aug 2020 21:44:15 +0100 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <20200820202933.GA3306744@stopbrexit> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> <20200820172233.GE3112706@stopbrexit> <20200820202933.GA3306744@stopbrexit> Message-ID: <20200820204415.GA3308293@stopbrexit> On 21:29 Thu 20 Aug , Andrew Hughes wrote: > On 19:42 Thu 20 Aug , Severin Gehwolf wrote: > > > > They're unchanged: > > > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012178.html > > > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/01/ > > > > Thanks, > > Severin > > > > Thanks. In future, it would help to tag the issue with jdk8u-needs-review > and link to the RFR there, so it doesn't get lost in the mail. See > the OpenJDK wiki [0] for further information and a link to the 8u review > filter. > > The mapping of the native files from 11u to 8u is rather confusing, as > the changes are not 1:1. A conversion mapping would have been helpful. > > From what I can work out, > > * src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c > => src/aix/native/sun/management/AixOperatingSystem.c > > getSystemCpuLoad renamed to getSystemCpuLoad0 as noted. > Copyright line missing. > getHostConfiguredCpuCount0 & getSingleCpuLoad0 missing. > > * src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c > => src/solaris/native/sun/management/LinuxOperatingSystem.c > > getSystemCpuLoad renamed to getSystemCpuLoad0 as noted. > > Looks good, though there is an odd missing whitespace change near > sysconf(_SC_NPROCESSORS_ONLN). > > * src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c > => src/solaris/native/sun/management/MacosxOperatingSystem.c > > getSystemCpuLoad renamed to getSystemCpuLoad0 as noted. > Copyright line missing. > getHostConfiguredCpuCount0 & getSingleCpuLoad0 missing. > > * N/A > => src/solaris/native/sun/management/OperatingSystemImpl.c > > Addition of '0' suffix as noted. > getHostConfiguredCpuCount0 & getSingleCpuLoad0 implemented here under #ifndef linux. > > * src/jdk.management/solaris/native/libmanagement_ext/UnixOperatingSystem.c > => src/solaris/native/sun/management/SolarisOperatingSystem.c > > getSystemCpuLoad renamed to getSystemCpuLoad0 as noted. > Copyright line missing. > getHostConfiguredCpuCount0 & getSingleCpuLoad0 missing. > > * N/A > => src/windows/native/sun/management/OperatingSystemImpl.c > > Addition of '0' suffix as noted. > getHostConfiguredCpuCount0 & getSingleCpuLoad0 implemented here as in UnixOperatingSystem.c > Copyright line missing. > > So AixOperatingSystem.c, MacosxOperatingSystem.c, > LinuxOperatingSystem.c and SolarisOperatingSystem.c share common code > from OperatingSystemImpl.c, and thus the default implementations of > getHostConfiguredCpuCount0 & getSingleCpuLoad0 can be shared rather > than appearing in each individual file. Is this correct? > > Again, clarification on these in the original RFR would have helped > the review. If my assumption is correct, then the only fix needed > for these files is to add the missing copyright updates in the non-Linux > files. > > There is no Windows file in the 11u version. Why is it needed in 8u? > In both, OperatingSystemImpl.java seems to be under > src/jdk.management/unix/classes or src/solaris/classes/sun/management, > rather than share/classes. > > Your description of the Subsystem.java changes is quite terse. > Can you explain in more detail why the readMatchingLines change > is not needed? > > OperatingSystemImpl.java & OperatingSystemMXBean.java look fine. > > [0] https://wiki.openjdk.java.net/display/jdk8u/Main > > Thanks, > -- > Andrew :) > > Senior 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 Forgot to mention the HotSpot tests look ok other than: + if (!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { + DockerTestUtils.removeDockerImage(imageName); + } seems to be missing in a couple of the files. Why? Thanks, -- Andrew :) Senior 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 From aph at redhat.com Fri Aug 21 08:30:52 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Aug 2020 09:30:52 +0100 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <20200820172003.GD3112706@stopbrexit> References: <20200820172003.GD3112706@stopbrexit> Message-ID: <4b8dedb7-c627-5f5a-97fe-bff618a18a96@redhat.com> On 20/08/2020 18:20, Andrew Hughes wrote: > On 17:26 Wed 19 Aug , Andrew Haley wrote: >>> >>> On 8/5/20 11:54 PM, Andrew Hughes wrote: >>>> I didn't go further with the review of this so far, because >>>> JDK-8144539 is one of the outstanding test backports for the >>>> SQLite patch as well. I intend to return to that bug trail >>>> shortly, and we can reconsider both patches once the test >>>> backports are resolved. >>> >>> I believe that 8144539 should not be a blocker for 8080462 because: >>> the overlap/conflict between them does not appear to be fundamental >>> -and has been addressed in the current backport proposal-; 8144539 >>> does not look like a trivial backport -at least at first glance, >>> given the number of files affected-; and, 8144539 does not seem to >>> have the same priority than 8080462 -so a low priority backport is >>> currently blocking a high priority one-. Looks to me that 8144539 is >>> not even required for compatibility between JDKs, but 8080462 >>> certainly is. >> >> We can't wait any longer for this. Martin, please feel free to commit >> http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.01/ > > I'm working on the dependencies for this right now. A few days is > hardly going to matter. > > I'll then review Martin's fix. It has already been reviewed; it doesn't need another one. As Martin explained, we have a case of priority inversion here, where an important fix with customer need is blocked by a "wouldn't it be nice..." test fix, which doesn't make any sense. Martin may, of course, wait for 8144539 if he wishes. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Aug 21 08:36:46 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Aug 2020 09:36:46 +0100 Subject: [RFR] [8u] 8078334: Mark regression tests using randomness In-Reply-To: <20200820181913.GF3112706@stopbrexit> References: <20200820181913.GF3112706@stopbrexit> Message-ID: <6f3d318f-50b4-b30b-9bc5-0f0e83b5ae32@redhat.com> On 20/08/2020 19:19, Andrew Hughes wrote: > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8078334/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8078334 > > This is a long but simple patch, which tags a number of test cases. It > removes unnecessary differences between the copies of these test cases > in 8u and in later versions, simplifying future backports (in > particular, those for PKCS#11). > > Most of the differences between this patch and the 9u version are due > to differing context and a few missing test cases: > > * The TEST.ROOT change is already present in 8u, thanks to > JDK-8151731: "Add new jtreg keywords to jdk 8" > > * The test/com/oracle/security ucrypto tests are not present in 8u, as > UCrypto wasn't added to OpenJDK until JDK-8046002: "Move Ucrypto to > the open jdk repo". It's a Solaris feature so I see little need to > backport it. > > * test/com/sun/crypto/provider/Cipher/RSA/TestOAEP.java has an > additional bug ID in 8u, changing the context. > > * test/java/io/InputStream/TransferTo.java is not present in 8u, as > the transferTo method is not in 8u (introduced by JDK-8066867: Add > InputStream transferTo to transfer content to an OutputStream) > > * test/java/lang/ClassLoader/Assert.java, test/java/lang/Math/HypotTests.java, > test/java/lang/Math/IeeeRecommendedTests.java, test/java/lang/Math/Log1pTests.java > have slight context differences in 8u. > > * test/java/lang/invoke/MethodHandles/CatchExceptionTest.java does not > have the "intermittent" keyword in 8u. It seems JDK-8055269: > "java/lang/invoke/MethodHandles/CatchExceptionTest.java fails > intermittently" will have fixed this. > > * test/java/math/BigDecimal/StringConstructor.java, > test/java/math/BigInteger/BigIntegerTest.java, > test/java/math/BigInteger/ModPow65537.java, > test/java/math/BigInteger/PrimeTest.java, > test/java/math/BigInteger/SymmetricRangeTests.java, > test/java/util/Arrays/Correct.java, > test/java/util/Base64/TestBase64.java, > test/java/util/BitSet/BSMethods.java have slight > context differences in 8u (fewer bug IDs) > > * test/java/util/logging/FileHandlerLongLimit.java was introduced by > JDK-8059767: "FileHandler should allow 'long' limits and handle > overflow of MeteredStream.written.", which is an enhancement out of > scope for backport. > > * test/java/util/logging/FileHandlerPatternExceptions.java was > introduced by JDK-8025690: "Default FileHandler constructor doesn't > throw NullPointerException if pattern is empty and count > 1" which > changes the behaviour of a public constructor and so too risky for > backport. > > * test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java > was introduced by JDK-8060132: "Handlers configured on abstract > nodes in logging.properties are not always properly closed", which > changes behaviour in a way worthy of a release note, so not suitable > for backport. > > * test/java/util/logging/LoggingDeadlock.java has slight context differences. > > * test/java/util/zip/DeInflate.java already gained the tag in > JDK-8184682: "Upgrade compression library" > > * test/java/util/zip/InflateIn_DeflateOut.java, > test/sun/nio/cs/TestStringCoding.java, > test/java/util/zip/ZipFile/ReadZip.java have additional bug IDs in > 8u. > > * test/java/util/zip/ZipFile/Assortment.java, > test/java/util/zip/ZipFile/MultiThreadedReadTest.java, > test/javax/crypto/KeyGenerator/TestKGParity.java, > test/sun/management/jmxremote/startstop/JMXStartStopTest.java, > test/sun/misc/FloatingDecimal/TestFloatingDecimal.java, > test/sun/security/provider/DSA/TestDSA2.java, > test/sun/security/rsa/TestKeyPairGenerator.java and > test/sun/security/rsa/TestSignatures.java have slight context > differences. > > * test/sun/security/mscapi/PrngSlow.java has an additional @requires > in 8u. > > * test/javax/net/ssl/SSLEngine/LargeBufs.java, > test/sun/security/ssl/GenSSLConfigs/main.java and > test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java can be > found in > test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java, > test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java > and > test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java > in 8u, respectively. Backporting JDK-8032473: "Restructure JSSE > regression test hierarchy in jdk test" seems pointless, given the > imminent import of TLS 1.3. > > Ok for 8u? Looking at https://cr.openjdk.java.net/~andrew/openjdk8/8078334/webrev.01/, all I see is + * @key randomness added to many files. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Aug 21 08:37:34 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Aug 2020 09:37:34 +0100 Subject: [RFR] [8u] 8078334: Mark regression tests using randomness In-Reply-To: <20200820181913.GF3112706@stopbrexit> References: <20200820181913.GF3112706@stopbrexit> Message-ID: On 20/08/2020 19:19, Andrew Hughes wrote: > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8078334/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8078334 > > This is a long but simple patch, which tags a number of test cases. It > removes unnecessary differences between the copies of these test cases > in 8u and in later versions, simplifying future backports (in > particular, those for PKCS#11). > > Most of the differences between this patch and the 9u version are due > to differing context and a few missing test cases: > > * The TEST.ROOT change is already present in 8u, thanks to > JDK-8151731: "Add new jtreg keywords to jdk 8" > > * The test/com/oracle/security ucrypto tests are not present in 8u, as > UCrypto wasn't added to OpenJDK until JDK-8046002: "Move Ucrypto to > the open jdk repo". It's a Solaris feature so I see little need to > backport it. > > * test/com/sun/crypto/provider/Cipher/RSA/TestOAEP.java has an > additional bug ID in 8u, changing the context. > > * test/java/io/InputStream/TransferTo.java is not present in 8u, as > the transferTo method is not in 8u (introduced by JDK-8066867: Add > InputStream transferTo to transfer content to an OutputStream) > > * test/java/lang/ClassLoader/Assert.java, test/java/lang/Math/HypotTests.java, > test/java/lang/Math/IeeeRecommendedTests.java, test/java/lang/Math/Log1pTests.java > have slight context differences in 8u. > > * test/java/lang/invoke/MethodHandles/CatchExceptionTest.java does not > have the "intermittent" keyword in 8u. It seems JDK-8055269: > "java/lang/invoke/MethodHandles/CatchExceptionTest.java fails > intermittently" will have fixed this. > > * test/java/math/BigDecimal/StringConstructor.java, > test/java/math/BigInteger/BigIntegerTest.java, > test/java/math/BigInteger/ModPow65537.java, > test/java/math/BigInteger/PrimeTest.java, > test/java/math/BigInteger/SymmetricRangeTests.java, > test/java/util/Arrays/Correct.java, > test/java/util/Base64/TestBase64.java, > test/java/util/BitSet/BSMethods.java have slight > context differences in 8u (fewer bug IDs) > > * test/java/util/logging/FileHandlerLongLimit.java was introduced by > JDK-8059767: "FileHandler should allow 'long' limits and handle > overflow of MeteredStream.written.", which is an enhancement out of > scope for backport. > > * test/java/util/logging/FileHandlerPatternExceptions.java was > introduced by JDK-8025690: "Default FileHandler constructor doesn't > throw NullPointerException if pattern is empty and count > 1" which > changes the behaviour of a public constructor and so too risky for > backport. > > * test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java > was introduced by JDK-8060132: "Handlers configured on abstract > nodes in logging.properties are not always properly closed", which > changes behaviour in a way worthy of a release note, so not suitable > for backport. > > * test/java/util/logging/LoggingDeadlock.java has slight context differences. > > * test/java/util/zip/DeInflate.java already gained the tag in > JDK-8184682: "Upgrade compression library" > > * test/java/util/zip/InflateIn_DeflateOut.java, > test/sun/nio/cs/TestStringCoding.java, > test/java/util/zip/ZipFile/ReadZip.java have additional bug IDs in > 8u. > > * test/java/util/zip/ZipFile/Assortment.java, > test/java/util/zip/ZipFile/MultiThreadedReadTest.java, > test/javax/crypto/KeyGenerator/TestKGParity.java, > test/sun/management/jmxremote/startstop/JMXStartStopTest.java, > test/sun/misc/FloatingDecimal/TestFloatingDecimal.java, > test/sun/security/provider/DSA/TestDSA2.java, > test/sun/security/rsa/TestKeyPairGenerator.java and > test/sun/security/rsa/TestSignatures.java have slight context > differences. > > * test/sun/security/mscapi/PrngSlow.java has an additional @requires > in 8u. > > * test/javax/net/ssl/SSLEngine/LargeBufs.java, > test/sun/security/ssl/GenSSLConfigs/main.java and > test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java can be > found in > test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java, > test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java > and > test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java > in 8u, respectively. Backporting JDK-8032473: "Restructure JSSE > regression test hierarchy in jdk test" seems pointless, given the > imminent import of TLS 1.3. > > Ok for 8u? Looking at https://cr.openjdk.java.net/~andrew/openjdk8/8078334/webrev.01/, all I see is + * @key randomness added to many files. That's fine. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Fri Aug 21 08:58:06 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 21 Aug 2020 10:58:06 +0200 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <20200820204415.GA3308293@stopbrexit> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> <20200820172233.GE3112706@stopbrexit> <20200820202933.GA3306744@stopbrexit> <20200820204415.GA3308293@stopbrexit> Message-ID: <716b0941fd2cc1134b1fbb6bd4485309223ac7de.camel@redhat.com> On Thu, 2020-08-20 at 21:44 +0100, Andrew Hughes wrote: > Forgot to mention the HotSpot tests look ok other than: > > + if (!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { > + DockerTestUtils.removeDockerImage(imageName); > + } > > seems to be missing in a couple of the files. Why? RETAIN_IMAGE_AFTER_TEST was introduced with JDK-8221710 which isn't in OpenJDK 8u (yet). It's in my queue of docker test fixes. I can re-add those missing hunks with the JDK-8221710 backport. Thanks, Severin From sgehwolf at redhat.com Fri Aug 21 11:08:26 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 21 Aug 2020 13:08:26 +0200 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <20200820202933.GA3306744@stopbrexit> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> <20200820172233.GE3112706@stopbrexit> <20200820202933.GA3306744@stopbrexit> Message-ID: <734e9fba06c99b2b6c3dd6ea8814cb42d35a5315.camel@redhat.com> Hi Andrew, Thanks for the review! On Thu, 2020-08-20 at 21:29 +0100, Andrew Hughes wrote: > On 19:42 Thu 20 Aug , Severin Gehwolf wrote: > > They're unchanged: > > > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012178.html > > > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/01/ > > > > Thanks, > > Severin > > > > Thanks. In future, it would help to tag the issue with jdk8u-needs-review > and link to the RFR there, so it doesn't get lost in the mail. See > the OpenJDK wiki [0] for further information and a link to the 8u review > filter. Fair enough. > The mapping of the native files from 11u to 8u is rather confusing, as > the changes are not 1:1. A conversion mapping would have been helpful. > > From what I can work out, > > * src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c > => src/aix/native/sun/management/AixOperatingSystem.c > > getSystemCpuLoad renamed to getSystemCpuLoad0 as noted. > Copyright line missing. > getHostConfiguredCpuCount0 & getSingleCpuLoad0 missing. > > * src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c > => src/solaris/native/sun/management/LinuxOperatingSystem.c > > getSystemCpuLoad renamed to getSystemCpuLoad0 as noted. > > Looks good, though there is an odd missing whitespace change near > sysconf(_SC_NPROCESSORS_ONLN). > > * src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c > => src/solaris/native/sun/management/MacosxOperatingSystem.c > > getSystemCpuLoad renamed to getSystemCpuLoad0 as noted. > Copyright line missing. > getHostConfiguredCpuCount0 & getSingleCpuLoad0 missing. > > * N/A > => src/solaris/native/sun/management/OperatingSystemImpl.c > > Addition of '0' suffix as noted. > getHostConfiguredCpuCount0 & getSingleCpuLoad0 implemented here under #ifndef linux. > > * src/jdk.management/solaris/native/libmanagement_ext/UnixOperatingSystem.c > => src/solaris/native/sun/management/SolarisOperatingSystem.c > > getSystemCpuLoad renamed to getSystemCpuLoad0 as noted. > Copyright line missing. > getHostConfiguredCpuCount0 & getSingleCpuLoad0 missing. > > * N/A > => src/windows/native/sun/management/OperatingSystemImpl.c > > Addition of '0' suffix as noted. > getHostConfiguredCpuCount0 & getSingleCpuLoad0 implemented here as in UnixOperatingSystem.c > Copyright line missing. > > So AixOperatingSystem.c, MacosxOperatingSystem.c, > LinuxOperatingSystem.c and SolarisOperatingSystem.c share common code > from OperatingSystemImpl.c, and thus the default implementations of > getHostConfiguredCpuCount0 & getSingleCpuLoad0 can be shared rather > than appearing in each individual file. Is this correct? Yes. See lines 290 through 311 which does exclusions for platforms not the target platform: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/ce1f37506608/make/lib/ServiceabilityLibraries.gmk#l290 > Again, clarification on these in the original RFR would have helped > the review. If my assumption is correct, then the only fix needed > for these files is to add the missing copyright updates in the non-Linux > files. Sorry, I didn't remember at the time and didn't take notes. It slipped throught the cracks :( > There is no Windows file in the 11u version. Why is it needed in 8u? > In both, OperatingSystemImpl.java seems to be under > src/jdk.management/unix/classes or src/solaris/classes/sun/management, > rather than share/classes. Good point. There is a Windows specific OperatingSystemImpl.java with references to native methods. I missed that. Note to self: No need to change the native method impls as they've not changed in src/windows/classes/sun/management/OperatingSystemImpl.java either. Reverted in the updated webrev. Latest webrev here: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/02/webrev/ > Your description of the Subsystem.java changes is quite terse. > Can you explain in more detail why the readMatchingLines change > is not needed? OpenJDK 8u doesn't have this bug which introduces readMatchingLines() methods: 8217338: [Containers] Improve systemd slice memory limit support Therefore, hunks which adapted those methods, or rather, refactored them, aren't needed in this patch. Does that make sense? > OperatingSystemImpl.java & OperatingSystemMXBean.java look fine. Tested builds on Windows, AIX, Solaris and Linux with this updated webrev. Thanks, Severin > [0] https://wiki.openjdk.java.net/display/jdk8u/Main > > Thanks, From sgehwolf at redhat.com Fri Aug 21 12:23:05 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 21 Aug 2020 14:23:05 +0200 Subject: [RFR]: JDK-8196196: Headful tests should not be run in headless mode In-Reply-To: References: Message-ID: On Wed, 2020-07-08 at 14:39 +0200, Mario Torre wrote: > Hi all, > > I would like to have a review for the following bug since it doesn't > apply cleanly: > > https://bugs.openjdk.java.net/browse/JDK-8196196 > > I had to rework a number of them, for example a couple of tests don't > exist in JDK8u while other had test code changes that didn't apply to > 8u. The new webrev is here: > > http://cr.openjdk.java.net/~neugens/8196196/webrev.00/ This looks OK to me. Thanks, Severin From neugens at redhat.com Fri Aug 21 13:05:17 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 21 Aug 2020 15:05:17 +0200 Subject: [RFR]: JDK-8196196: Headful tests should not be run in headless mode In-Reply-To: References: Message-ID: Hi Severin, Thanks for the review! Unfortunately I forgot to add the fix-request label, and I just realised that there are some changes like BadDisplayTest.java now is gone. This is a trivial change, but I need to go back at it and see if some of the modifications I did to adapt the patch to 8u are still necessary, I think I'll need to resubmit the patch for review... Cheers, Mario On Fri, Aug 21, 2020 at 2:25 PM Severin Gehwolf wrote: > > On Wed, 2020-07-08 at 14:39 +0200, Mario Torre wrote: > > Hi all, > > > > I would like to have a review for the following bug since it doesn't > > apply cleanly: > > > > https://bugs.openjdk.java.net/browse/JDK-8196196 > > > > I had to rework a number of them, for example a couple of tests don't > > exist in JDK8u while other had test code changes that didn't apply to > > 8u. The new webrev is here: > > > > http://cr.openjdk.java.net/~neugens/8196196/webrev.00/ > > This looks OK to me. > > Thanks, > Severin > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From mbalao at redhat.com Fri Aug 21 16:02:38 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 21 Aug 2020 13:02:38 -0300 Subject: [8u] RFR 8249846: Change of behavior after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: <55a59080-5b52-46ac-d556-43d2ee9760e7@amazon.com> References: <55a59080-5b52-46ac-d556-43d2ee9760e7@amazon.com> Message-ID: Hi David, Thanks for proposing this fix. On 8/18/20 4:10 PM, David Alvarez wrote: > During the backport of JDK-8237117 a regression was added that affected > how the DefaultForkJoinWorkerThreadFactory works. The idea was to change > the context for threads in the commonPool, but it ended up affecting the > threads in all pools created with that factory. This patch decouples the > commonPool from the DefaultForkJoinWorkerThreadFactory > > Bug: https://bugs.openjdk.java.net/browse/JDK-8249846 > Webrev: > http://cr.openjdk.java.net/~alvdavi/webrevs/8249846/webrev.8u.jdk.00/ > > My original intention when writing the patch was to make the CommonPool > use the InnocuousForkJoinWorkerThreadFactory [1] in all cases, > regardless of whether a SecurityManager is installed or not, as we are > already creating threads with an innocuous AccessControlContext for > commonPool threads even when there is no SecurityManager installed. > However, the InnocuousForkJoinWorkerThreadFactory creates > InnocuousForkJoinWorkerThreads [2], which have some more nuances, like > the erase of ThreadLocal variables or avoid setting an > UncaughtExceptionHandler. I was afraid of introducing more regressions > with this change (in fact, one jtreg test [3] did fail because it was > setting an uncaught exception handler), that is why I decided to go for > a new factory (DefaultCommonPoolForkJoinWorkerThreadFactory) that mimics > current behavior, even if it means the behavior of the common pool if a > SecurityManager is installed during initialization is still not the same > as if the SecurityManager is installed after initialization. I suggest to continue this discussion in the context of the Vulnerability Group. Thanks, Martin.- From mbalao at redhat.com Fri Aug 21 16:38:47 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 21 Aug 2020 13:38:47 -0300 Subject: [RFR] [8u] 8078334: Mark regression tests using randomness In-Reply-To: <20200820181913.GF3112706@stopbrexit> References: <20200820181913.GF3112706@stopbrexit> Message-ID: Hi Andrew, Thanks for proposing this backport. On Thu, Aug 20, 2020 at 3:22 PM Andrew Hughes wrote: > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8078334/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8078334 > > This is a long but simple patch, which tags a number of test cases. It > removes unnecessary differences between the copies of these test cases > in 8u and in later versions, simplifying future backports (in > particular, those for PKCS#11). > > Most of the differences between this patch and the 9u version are due > to differing context and a few missing test cases: > > * The TEST.ROOT change is already present in 8u, thanks to > JDK-8151731: "Add new jtreg keywords to jdk 8" > Right. > * The test/com/oracle/security ucrypto tests are not present in 8u, as > UCrypto wasn't added to OpenJDK until JDK-8046002: "Move Ucrypto to > the open jdk repo". It's a Solaris feature so I see little need to > backport it. > Right. > * test/com/sun/crypto/provider/Cipher/RSA/TestOAEP.java has an > additional bug ID in 8u, changing the context. > Right. > * test/java/io/InputStream/TransferTo.java is not present in 8u, as > the transferTo method is not in 8u (introduced by JDK-8066867: Add > InputStream transferTo to transfer content to an OutputStream) > Right. > * test/java/lang/ClassLoader/Assert.java, test/java/lang/Math/HypotTests.java, > test/java/lang/Math/IeeeRecommendedTests.java, test/java/lang/Math/Log1pTests.java > have slight context differences in 8u. > Yes. None of them fundamental to 8078334. > * test/java/lang/invoke/MethodHandles/CatchExceptionTest.java does not > have the "intermittent" keyword in 8u. It seems JDK-8055269: > "java/lang/invoke/MethodHandles/CatchExceptionTest.java fails > intermittently" will have fixed this. Yes. > > * test/java/math/BigDecimal/StringConstructor.java, > test/java/math/BigInteger/BigIntegerTest.java, > test/java/math/BigInteger/ModPow65537.java, > test/java/math/BigInteger/PrimeTest.java, > test/java/math/BigInteger/SymmetricRangeTests.java, > test/java/util/Arrays/Correct.java, > test/java/util/Base64/TestBase64.java, > test/java/util/BitSet/BSMethods.java have slight > context differences in 8u (fewer bug IDs) > Yes. None of them fundamental to 8078334. > * test/java/util/logging/FileHandlerLongLimit.java was introduced by > JDK-8059767: "FileHandler should allow 'long' limits and handle > overflow of MeteredStream.written.", which is an enhancement out of > scope for backport. > Right. > * test/java/util/logging/FileHandlerPatternExceptions.java was > introduced by JDK-8025690: "Default FileHandler constructor doesn't > throw NullPointerException if pattern is empty and count > 1" which > changes the behaviour of a public constructor and so too risky for > backport. > Agree. > * test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java > was introduced by JDK-8060132: "Handlers configured on abstract > nodes in logging.properties are not always properly closed", which > changes behaviour in a way worthy of a release note, so not suitable > for backport. > > * test/java/util/logging/LoggingDeadlock.java has slight context differences. > > * test/java/util/zip/DeInflate.java already gained the tag in > JDK-8184682: "Upgrade compression library" > Right. > * test/java/util/zip/InflateIn_DeflateOut.java, > test/sun/nio/cs/TestStringCoding.java, > test/java/util/zip/ZipFile/ReadZip.java have additional bug IDs in > 8u. Ok. > > * test/java/util/zip/ZipFile/Assortment.java, > test/java/util/zip/ZipFile/MultiThreadedReadTest.java, > test/javax/crypto/KeyGenerator/TestKGParity.java, > test/sun/management/jmxremote/startstop/JMXStartStopTest.java, > test/sun/misc/FloatingDecimal/TestFloatingDecimal.java, > test/sun/security/provider/DSA/TestDSA2.java, > test/sun/security/rsa/TestKeyPairGenerator.java and > test/sun/security/rsa/TestSignatures.java have slight context > differences. > Ok. > * test/sun/security/mscapi/PrngSlow.java has an additional @requires > in 8u. > Ok. > * test/javax/net/ssl/SSLEngine/LargeBufs.java, > test/sun/security/ssl/GenSSLConfigs/main.java and > test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java can be > found in > test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java, > test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java > and > test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java > in 8u, respectively. Backporting JDK-8032473: "Restructure JSSE > regression test hierarchy in jdk test" seems pointless, given the > imminent import of TLS 1.3. I agree with not relocating the tests because of this backport. Even though your decision looks good in the context of this backport, this will bring conflicts with the TLS 1.3 work we are doing. The TLS 1.3 work includes an 8u backport of 8032473. > > Ok for 8u? > May I ask you to undo the changes for LargeBufs.java, LengthCheckTest.java and GenSSLConfigs/main.java? Even though they are correct for this backport, they will bring future conflicts when merging the TLS 1.3 work. My promise is that the TLS 1.3 backport (at Step 11) includes the 'randomness' key for all these files. I've just verified it. Thanks, Martin.- From volker.simonis at gmail.com Fri Aug 21 17:54:56 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Aug 2020 19:54:56 +0200 Subject: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument In-Reply-To: <9c22ade8-67d3-0ddc-6f6f-4bf0108108b4@oracle.com> References: <8B42FF96-373A-4B03-8B93-D4A47D765F3E@amazon.com> <9c22ade8-67d3-0ddc-6f6f-4bf0108108b4@oracle.com> Message-ID: On Thu, Aug 20, 2020 at 10:06 PM serguei.spitsyn at oracle.com wrote: > > Hi Paul, > > I was also wondering if there is a compatibility risk involved with the JMM_VERSION change. > So, thanks to Volker for asking these questions. > > One more question. > I do not see a backport of the src/jdk.management/share/native/libmanagement_ext/management_ext.c change. > Is it intentional, and if so, what is the reason to skip this file? > "libmanagement_ext/management_ext.c" doesn't exist in jdk8. It was introduced with "8042901: Allow com.sun.management to be in a different module to java.lang.management" in jdk9. In jdk8 all the functionality is in "management/management.h" so there's no need to backport the changes from "management_ext.c" . [1] https://bugs.openjdk.java.net/browse/JDK-8042901 > Thanks, > Serguei > > > On 8/20/20 11:30, Volker Simonis wrote: > > On Wed, Aug 19, 2020 at 6:17 PM Hohensee, Paul wrote: > > Please review this backport to jdk8u. I especially need a CSR review, since the CSR approval process can be a bottleneck. The patch significantly reduces fleet profiling overhead, and a version of it has been in production at Amazon for over 3 years. > > > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8185003 > > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 > > Original patch: http://hg.openjdk.java.net/jdk10/master/rev/68d46cb9be45 > > > > Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251494 > > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251498 > > Backport JDK webrev: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.05/ > > JDK part looks good to me. > > Backport Hotspot webrev: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.05/ > > HotSpot part looks good to me but see discussion below. > > > Details of the interface changes needed for the backport are in the Description of the Backport CSR 8251498. The actual functional changes are minimal and low risk. > > I've also reviewed the CSR yesterday which I think is fine. But now, > when looking at the implementation, I'm a little concerned about > changing JMM_VERSION from " 0x20010203" to "0x20020000" in "jmm.h". > > This might be especially problematic in combination with the changes > in "Management::get_jmm_interface()" which is called by > JVM_GetManagement(): > > void* Management::get_jmm_interface(int version) { > #if INCLUDE_MANAGEMENT > - if (version == JMM_VERSION_1_0) { > + if (version == JMM_VERSION) { > return (void*) &jmm_interface; > } > #endif // INCLUDE_MANAGEMENT > return NULL; > } > > You've correctly fixed the single caller of "JVM_GetManagement()" in > the JDK (in "JNI_OnLoad()" in "management.c"): > > - jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION_1_0); > + jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION); > > but I wonder if there are other monitoring/serviceability tools out > there which use this interface and which will break after this change. > A quick search revealed at least two StackOverflow entries which > recommend using "JVM_GetManagement(JMM_VERSION_1_0)" [1,2] and there's > a talk and a blog entry doing the same [3, 4]. > > I'm not sure how relevant this is but I think a much safer and > backwards-compatible way of doing this downport would be the > following: > > - don't change "Management::get_jmm_interface()" (i.e. still check for > "JMM_VERSION_1_0") but return the "new" JMM_VERSION in > "jmm_GetVersion()". This won't break anything but will make it > possible for clients to detect the new version if they want. > > - don't change the signature of "DumpThreads()". Instead add a new > version (e.g. "DumpThreadsMaxDepth()/jmm_DumpThreadsMaxDepth()") to > the "JMMInterface" struct and to "jmm_interface" in "management.cpp". > You can do this in one of the two first, reserved fields of > "JMMInterface" so you won't break binary compatibility. > "jmm_DumpThreads()" will then be a simple wrapper which calls > "jmm_DumpThreadsMaxDepth()" with Integer.MAX_VALUE as depth. > > - in the jdk you then simply call "DumpThreadsMaxDepth()" in > "Java_sun_management_ThreadImpl_dumpThreads0()" > > I think this way we can maintain full binary compatibility while still > using the new feature. What do you think? > > Best regards, > Volker > > [1] https://stackoverflow.com/questions/23632653/generate-java-heap-dump-on-uncaught-exception > [2] https://stackoverflow.com/questions/60887816/jvm-options-printnmtstatistics-save-info-to-file > [3] https://sudonull.com/post/25841-JVM-TI-how-to-make-a-plugin-for-a-virtual-machine-Odnoklassniki-company-blog > [4] https://2019.jpoint.ru/talks/2o8scc5jbaurnqqlsydzxv/ > > Passes the included (suitably modified) test, as well as the tests in > > > > jdk/test/java/lang/management/ThreadMXBean > > jdk/test/com/sun/management/ThreadMXBean > > > > Thanks, > > Paul > > From serguei.spitsyn at oracle.com Fri Aug 21 18:07:59 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 21 Aug 2020 11:07:59 -0700 Subject: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument In-Reply-To: References: <8B42FF96-373A-4B03-8B93-D4A47D765F3E@amazon.com> <9c22ade8-67d3-0ddc-6f6f-4bf0108108b4@oracle.com> Message-ID: Hi Paul, Thank you for explanation. Thanks, Serguei On 8/21/20 10:54, Volker Simonis wrote: > On Thu, Aug 20, 2020 at 10:06 PM serguei.spitsyn at oracle.com > wrote: >> Hi Paul, >> >> I was also wondering if there is a compatibility risk involved with the JMM_VERSION change. >> So, thanks to Volker for asking these questions. >> >> One more question. >> I do not see a backport of the src/jdk.management/share/native/libmanagement_ext/management_ext.c change. >> Is it intentional, and if so, what is the reason to skip this file? >> > "libmanagement_ext/management_ext.c" doesn't exist in jdk8. It was > introduced with "8042901: Allow com.sun.management to be in a > different module to java.lang.management" in jdk9. In jdk8 all the > functionality is in "management/management.h" so there's no need to > backport the changes from "management_ext.c" . > > [1] https://bugs.openjdk.java.net/browse/JDK-8042901 > >> Thanks, >> Serguei >> >> >> On 8/20/20 11:30, Volker Simonis wrote: >> >> On Wed, Aug 19, 2020 at 6:17 PM Hohensee, Paul wrote: >> >> Please review this backport to jdk8u. I especially need a CSR review, since the CSR approval process can be a bottleneck. The patch significantly reduces fleet profiling overhead, and a version of it has been in production at Amazon for over 3 years. >> >> >> >> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8185003 >> >> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 >> >> Original patch: http://hg.openjdk.java.net/jdk10/master/rev/68d46cb9be45 >> >> >> >> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251494 >> >> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251498 >> >> Backport JDK webrev: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.05/ >> >> JDK part looks good to me. >> >> Backport Hotspot webrev: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.05/ >> >> HotSpot part looks good to me but see discussion below. >> >> >> Details of the interface changes needed for the backport are in the Description of the Backport CSR 8251498. The actual functional changes are minimal and low risk. >> >> I've also reviewed the CSR yesterday which I think is fine. But now, >> when looking at the implementation, I'm a little concerned about >> changing JMM_VERSION from " 0x20010203" to "0x20020000" in "jmm.h". >> >> This might be especially problematic in combination with the changes >> in "Management::get_jmm_interface()" which is called by >> JVM_GetManagement(): >> >> void* Management::get_jmm_interface(int version) { >> #if INCLUDE_MANAGEMENT >> - if (version == JMM_VERSION_1_0) { >> + if (version == JMM_VERSION) { >> return (void*) &jmm_interface; >> } >> #endif // INCLUDE_MANAGEMENT >> return NULL; >> } >> >> You've correctly fixed the single caller of "JVM_GetManagement()" in >> the JDK (in "JNI_OnLoad()" in "management.c"): >> >> - jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION_1_0); >> + jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION); >> >> but I wonder if there are other monitoring/serviceability tools out >> there which use this interface and which will break after this change. >> A quick search revealed at least two StackOverflow entries which >> recommend using "JVM_GetManagement(JMM_VERSION_1_0)" [1,2] and there's >> a talk and a blog entry doing the same [3, 4]. >> >> I'm not sure how relevant this is but I think a much safer and >> backwards-compatible way of doing this downport would be the >> following: >> >> - don't change "Management::get_jmm_interface()" (i.e. still check for >> "JMM_VERSION_1_0") but return the "new" JMM_VERSION in >> "jmm_GetVersion()". This won't break anything but will make it >> possible for clients to detect the new version if they want. >> >> - don't change the signature of "DumpThreads()". Instead add a new >> version (e.g. "DumpThreadsMaxDepth()/jmm_DumpThreadsMaxDepth()") to >> the "JMMInterface" struct and to "jmm_interface" in "management.cpp". >> You can do this in one of the two first, reserved fields of >> "JMMInterface" so you won't break binary compatibility. >> "jmm_DumpThreads()" will then be a simple wrapper which calls >> "jmm_DumpThreadsMaxDepth()" with Integer.MAX_VALUE as depth. >> >> - in the jdk you then simply call "DumpThreadsMaxDepth()" in >> "Java_sun_management_ThreadImpl_dumpThreads0()" >> >> I think this way we can maintain full binary compatibility while still >> using the new feature. What do you think? >> >> Best regards, >> Volker >> >> [1] https://urldefense.com/v3/__https://stackoverflow.com/questions/23632653/generate-java-heap-dump-on-uncaught-exception__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-KqVsyaF$ >> [2] https://urldefense.com/v3/__https://stackoverflow.com/questions/60887816/jvm-options-printnmtstatistics-save-info-to-file__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Ip7MAQ5$ >> [3] https://urldefense.com/v3/__https://sudonull.com/post/25841-JVM-TI-how-to-make-a-plugin-for-a-virtual-machine-Odnoklassniki-company-blog__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-ErSjPdD$ >> [4] https://urldefense.com/v3/__https://2019.jpoint.ru/talks/2o8scc5jbaurnqqlsydzxv/__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Oxb5CQ-$ >> >> Passes the included (suitably modified) test, as well as the tests in >> >> >> >> jdk/test/java/lang/management/ThreadMXBean >> >> jdk/test/com/sun/management/ThreadMXBean >> >> >> >> Thanks, >> >> Paul >> >> From gnu.andrew at redhat.com Fri Aug 21 18:19:07 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 21 Aug 2020 19:19:07 +0100 Subject: [RFR] [8u] 8078334: Mark regression tests using randomness In-Reply-To: References: <20200820181913.GF3112706@stopbrexit> Message-ID: <20200821181907.GA31221@stopbrexit> On 13:38 Fri 21 Aug , Martin Balao wrote: > Hi Andrew, > > Thanks for proposing this backport. > You're welcome. Hopefully we can finally get these PKCS#11 fixes resolved between us today. > > > * test/javax/net/ssl/SSLEngine/LargeBufs.java, > > test/sun/security/ssl/GenSSLConfigs/main.java and > > test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java can be > > found in > > test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java, > > test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java > > and > > test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java > > in 8u, respectively. Backporting JDK-8032473: "Restructure JSSE > > regression test hierarchy in jdk test" seems pointless, given the > > imminent import of TLS 1.3. > > I agree with not relocating the tests because of this backport. Even > though your decision looks good in the context of this backport, this > will bring conflicts with the TLS 1.3 work we are doing. The TLS 1.3 > work includes an 8u backport of 8032473. > I take it the TLS 1.3 backport will reference 8032473? > > > > Ok for 8u? > > > > May I ask you to undo the changes for LargeBufs.java, > LengthCheckTest.java and GenSSLConfigs/main.java? Even though they are > correct for this backport, they will bring future conflicts when > merging the TLS 1.3 work. My promise is that the TLS 1.3 backport (at > Step 11) includes the 'randomness' key for all these files. I've just > verified it. > I did wonder about this during the backport. I've reverted those three files: https://cr.openjdk.java.net/~andrew/openjdk8/8078334/webrev.02/ > Thanks, > Martin.- > Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Fri Aug 21 18:22:20 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 21 Aug 2020 19:22:20 +0100 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <716b0941fd2cc1134b1fbb6bd4485309223ac7de.camel@redhat.com> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> <20200820172233.GE3112706@stopbrexit> <20200820202933.GA3306744@stopbrexit> <20200820204415.GA3308293@stopbrexit> <716b0941fd2cc1134b1fbb6bd4485309223ac7de.camel@redhat.com> Message-ID: <20200821182220.GB31221@stopbrexit> On 10:58 Fri 21 Aug , Severin Gehwolf wrote: > On Thu, 2020-08-20 at 21:44 +0100, Andrew Hughes wrote: > > Forgot to mention the HotSpot tests look ok other than: > > > > + if (!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { > > + DockerTestUtils.removeDockerImage(imageName); > > + } > > > > seems to be missing in a couple of the files. Why? > > RETAIN_IMAGE_AFTER_TEST was introduced with JDK-8221710 which isn't in > OpenJDK 8u (yet). It's in my queue of docker test fixes. I can re-add > those missing hunks with the JDK-8221710 backport. > > Thanks, > Severin > Would it not just make more sense to do JDK-8221710 first, retaining the order in 11u? It looks pretty simple. Thanks, -- Andrew :) Senior 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 From mbalao at redhat.com Fri Aug 21 18:23:55 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 21 Aug 2020 15:23:55 -0300 Subject: [RFR] [8u] 8078334: Mark regression tests using randomness In-Reply-To: <20200821181907.GA31221@stopbrexit> References: <20200820181913.GF3112706@stopbrexit> <20200821181907.GA31221@stopbrexit> Message-ID: On Fri, Aug 21, 2020 at 3:19 PM Andrew Hughes wrote: > I take it the TLS 1.3 backport will reference 8032473? > Yes, this was asked as part of the review that backports 8032473. Note: bug is: https://bugs.openjdk.java.net/browse/JDK-8245477. > > > > > > Ok for 8u? > > > > > > > May I ask you to undo the changes for LargeBufs.java, > > LengthCheckTest.java and GenSSLConfigs/main.java? Even though they are > > correct for this backport, they will bring future conflicts when > > merging the TLS 1.3 work. My promise is that the TLS 1.3 backport (at > > Step 11) includes the 'randomness' key for all these files. I've just > > verified it. > > > > I did wonder about this during the backport. I've reverted those three files: > > https://cr.openjdk.java.net/~andrew/openjdk8/8078334/webrev.02/ > Looks good to me. Thanks, Martin.- From gnu.andrew at redhat.com Fri Aug 21 18:37:42 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 21 Aug 2020 19:37:42 +0100 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <734e9fba06c99b2b6c3dd6ea8814cb42d35a5315.camel@redhat.com> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> <20200820172233.GE3112706@stopbrexit> <20200820202933.GA3306744@stopbrexit> <734e9fba06c99b2b6c3dd6ea8814cb42d35a5315.camel@redhat.com> Message-ID: <20200821183742.GC31221@stopbrexit> On 13:08 Fri 21 Aug , Severin Gehwolf wrote: > Hi Andrew, > > Thanks for the review! > No problem. snip... > > > > So AixOperatingSystem.c, MacosxOperatingSystem.c, > > LinuxOperatingSystem.c and SolarisOperatingSystem.c share common code > > from OperatingSystemImpl.c, and thus the default implementations of > > getHostConfiguredCpuCount0 & getSingleCpuLoad0 can be shared rather > > than appearing in each individual file. Is this correct? > > Yes. See lines 290 through 311 which does exclusions for platforms not > the target platform: > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/ce1f37506608/make/lib/ServiceabilityLibraries.gmk#l290 > Thanks. > > Again, clarification on these in the original RFR would have helped > > the review. If my assumption is correct, then the only fix needed > > for these files is to add the missing copyright updates in the non-Linux > > files. > > Sorry, I didn't remember at the time and didn't take notes. It slipped > throught the cracks :( I tend to review backports by comparing the diff between the 11u and 8u version (a pain in this instance where so much has moved). I also try to write my RFRs from the same perspective, explaining why each change is correct. I find you tend to spot these little oddities that way. As I gather you must have worked all this out yourself during the patch, telling the reviewer in the RFR avoids them having to do the same work over again. It also makes it a bit more approachable, so you may get a quicker review and so it helps both people. At least, that's my 2p on the matter. Your own experience may vary. > > > There is no Windows file in the 11u version. Why is it needed in 8u? > > In both, OperatingSystemImpl.java seems to be under > > src/jdk.management/unix/classes or src/solaris/classes/sun/management, > > rather than share/classes. > > Good point. There is a Windows specific OperatingSystemImpl.java with > references to native methods. I missed that. Note to self: No need to > change the native method impls as they've not changed > in src/windows/classes/sun/management/OperatingSystemImpl.java either. > Reverted in the updated webrev. Thanks. It took me a while to spot it as well. At first, I thought Windows was picking it up from one common shared Java file like the others, but then I looked at the paths again and spotted the unix/solaris usage. > > Latest webrev here: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/02/webrev/ > Thanks. JDK side looks good now. I'll wait for your response on whether to do the other change first for the HotSpot side. > > Your description of the Subsystem.java changes is quite terse. > > Can you explain in more detail why the readMatchingLines change > > is not needed? > > OpenJDK 8u doesn't have this bug which introduces readMatchingLines() > methods: > > 8217338: [Containers] Improve systemd slice memory limit support > > Therefore, hunks which adapted those methods, or rather, refactored > them, aren't needed in this patch. Does that make sense? > It does. I think I pretty much got there from the shorter comment, but my brain wasn't sure enough that it had parsed it correctly. > > OperatingSystemImpl.java & OperatingSystemMXBean.java look fine. > > Tested builds on Windows, AIX, Solaris and Linux with this updated > webrev. > You have access to AIX & Solaris builds? That might be useful for other patches. Out of interest, did the original pass on Windows? > Thanks, > Severin > > > [0] https://wiki.openjdk.java.net/display/jdk8u/Main > > > > Thanks, > Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Fri Aug 21 19:09:45 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 21 Aug 2020 20:09:45 +0100 Subject: Additional Labels for Backport Work Message-ID: <20200821190945.GD31221@stopbrexit> Hi all, I've begun using a number of labels to help with 8u backport work, that are documented as part of the OpenJDK 8u contribution process [0]. As few people seem to have noted those additions, I thought it worth an e-mail with more details. I'm also CCing jdk-updates-dev in case maintainers on other OpenJDK update projects want to adopt similar labels. The primary two labels are: 1. jdk8u-needs-review This label should be added after an RFR is posted for a backport to 8u. Please also add a link to the RFR. There is now a link to a filter for bugs marked with this label on the 8u wiki [1]. Those of you who are 8u reviewers are encouraged to regularly triage this list and help with reviewing work submitted for backport. This should avoid RFRs getting lost in mail traffic. You may also notice that if you make a jdk8u-fix-request before there is a completed review, it will be changed to this label. 2. jdk8u- This label is essentially intended to work as a lock on the bug, indicating someone is actively backporting the bug. The intention is to let others know that work is in progress, but is not yet ready for an RFR. When using this label, please keep it on the bug for the minimum possible time. Add it when work is actively started and remove it when the change is pushed. It is not intended as an 'I'm interested' label, as with others such as 'redhat-interest', but to avoid multiple people actively working on the same task. If the label does seem to be present for a long time, other developers are encouraged to query the developer concerned as to whether they are still active on this bug and to take over the work if there is no response for a prolonged period (>2 weeks). A further occasionally used label is jdk8u-needs-deps, which maintainers may use on occasion to indicate that a bug submitted using jdk8u-fix-request needs other fixes to be present before it can be considered. I hope these additional labels prove useful and help in the process of completing 8u backports. Feedback is welcome and, again, 8u reviewers are encouraged to use the jdk8u-needs-review filter to find reviews needing attention. [0] https://wiki.openjdk.java.net/display/jdk8u/Main [1] https://bugs.openjdk.java.net/issues/?filter=39384 Thanks, -- Andrew :) Senior 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 From mbalao at redhat.com Fri Aug 21 19:35:42 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 21 Aug 2020 16:35:42 -0300 Subject: [8u] TLSv1.3 RFR: 8245681: Add TLSv1.3 regression test from 11.0.7 In-Reply-To: <66A03F4D-3EC4-43D2-9B2B-33E1F6BEDFD1@azul.com> References: <7D92607F-B8F0-4E84-B6C2-5E2AB4E42824@azul.com> <04f0d809-2f53-5335-9828-72b198bf369f@azul.com> <0e9f68c6-dd0e-c2f7-50bf-28bf23a3a012@redhat.com> <66A03F4D-3EC4-43D2-9B2B-33E1F6BEDFD1@azul.com> Message-ID: <05795d97-a818-c185-2f16-2940b60e88f0@redhat.com> Hi Alexey, On 8/13/20 6:21 AM, Alexey Bakhtin wrote: >> >>> - javax/net/ssl/HttpsURLConnection/Equals.java >>> This test was added as part of JDK-8055299. Not backported to JDK8 yet >> >> Why? > JDK-8055299 is not backported to JDK8u and not related to TLSv1.3 functionality. > This fix can be backported separately Yes, you're right. >> In addition to the previous, I've noticed that Step 11 adds a few files >> not in previous SSL-related categories: >> >> * test/java/security/testlibrary/CertificateBuilder.java (new) >> * test/java/security/testlibrary/SimpleOCSPServer.java (new) > These classes used by javax/net/ssl/Stapling and sun/security/ssl/Stapling tests > These classes was added as part of JDK-8046321: OCSP Stapling for TLS >> * test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java (new) > This class should be excluded. > It is used by javax/net/ssl/HttpsURLConnection/Equals.java which is not added in this step, so SimpleSSLContext.java is not required > >> >> How did you find them? > > I've found these classes by running and fixing test dependency Ah, right! I've listed the test changes introduced by 8046321 (which we backported to 8u in Step 6 - 8245473): * test/java/security/testlibrary/CertificateBuilder.java (new) * test/java/security/testlibrary/SimpleOCSPServer.java (new) * test/javax/net/ssl/DTLS/NoMacInitialClientHello.java (modified) * test/javax/net/ssl/Stapling/HttpsUrlConnClient.java (new) * test/javax/net/ssl/Stapling/SSLEngineWithStapling.java (new) * test/javax/net/ssl/Stapling/SSLSocketWithStapling.java (new) * test/sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java (new) * test/sun/security/provider/certpath/ResponderId/ResponderIdTests.java (new) * test/sun/security/ssl/ExtensionType/OptimalListSize.java (modified) * test/sun/security/ssl/StatusStapling/BogusStatusRequest.java (new) * test/sun/security/ssl/StatusStapling/CertStatusReqExtensionTests.java (new) * test/sun/security/ssl/StatusStapling/CertStatusReqItemV2Tests.java (new) * test/sun/security/ssl/StatusStapling/CertStatusReqListV2ExtensionTests.java (new) * test/sun/security/ssl/StatusStapling/OCSPStatusRequestTests.java (new) * test/sun/security/ssl/StatusStapling/StatusResponseManagerTests.java (new) * test/sun/security/ssl/StatusStapling/TEST.properties (new) * test/sun/security/ssl/StatusStapling/TestCase.java (new) * test/sun/security/ssl/StatusStapling/TestUtils.java (new) We see there how most of them are already covered by SSL-related test categories. CertificateBuilder.java and SimpleOCSPServer.java are addressed here, in Step 11. Don't we want the following tests for Step 11? * test/sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java (new) * test/sun/security/provider/certpath/ResponderId/ResponderIdTests.java (new) Thanks, Martin.- From serguei.spitsyn at oracle.com Fri Aug 21 20:36:03 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 21 Aug 2020 13:36:03 -0700 Subject: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument In-Reply-To: References: <8B42FF96-373A-4B03-8B93-D4A47D765F3E@amazon.com> <9c22ade8-67d3-0ddc-6f6f-4bf0108108b4@oracle.com> Message-ID: <59b86bfa-ee37-7bee-a144-eb9cf7b6d79e@oracle.com> On 8/21/20 11:07, serguei.spitsyn at oracle.com wrote: > Hi Paul, Sorry, Volker, for using this "indirection". I hope, Paul redirected my "Hi" to you. :) Thanks, Serguei > > Thank you for explanation. > > Thanks, > Serguei > > > On 8/21/20 10:54, Volker Simonis wrote: >> On Thu, Aug 20, 2020 at 10:06 PM serguei.spitsyn at oracle.com >> wrote: >>> Hi Paul, >>> >>> I was also wondering if there is a compatibility risk involved with >>> the JMM_VERSION change. >>> So, thanks to Volker for asking these questions. >>> >>> One more question. >>> I do not see a backport of the >>> src/jdk.management/share/native/libmanagement_ext/management_ext.c >>> change. >>> Is it intentional, and if so, what is the reason to skip this file? >>> >> "libmanagement_ext/management_ext.c" doesn't exist in jdk8. It was >> introduced with "8042901: Allow com.sun.management to be in a >> different module to java.lang.management" in jdk9. In jdk8 all the >> functionality is in "management/management.h" so there's no need to >> backport the changes from "management_ext.c" . >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8042901 >> >>> Thanks, >>> Serguei >>> >>> >>> On 8/20/20 11:30, Volker Simonis wrote: >>> >>> On Wed, Aug 19, 2020 at 6:17 PM Hohensee, Paul >>> wrote: >>> >>> Please review this backport to jdk8u. I especially need a CSR >>> review, since the CSR approval process can be a bottleneck. The >>> patch significantly reduces fleet profiling overhead, and a version >>> of it has been in production at Amazon for over 3 years. >>> >>> >>> >>> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8185003 >>> >>> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 >>> >>> Original patch: >>> http://hg.openjdk.java.net/jdk10/master/rev/68d46cb9be45 >>> >>> >>> >>> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251494 >>> >>> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251498 >>> >>> Backport JDK webrev: >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.05/ >>> >>> JDK part looks good to me. >>> >>> Backport Hotspot webrev: >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.05/ >>> >>> HotSpot part looks good to me but see discussion below. >>> >>> >>> Details of the interface changes needed for the backport are in the >>> Description of the Backport CSR 8251498. The actual functional >>> changes are minimal and low risk. >>> >>> I've also reviewed the CSR yesterday which I think is fine. But now, >>> when looking at the implementation, I'm a little concerned about >>> changing JMM_VERSION from " 0x20010203" to "0x20020000" in "jmm.h". >>> >>> This might be especially problematic in combination with the changes >>> in "Management::get_jmm_interface()" which is called by >>> JVM_GetManagement(): >>> >>> ? void* Management::get_jmm_interface(int version) { >>> ? #if INCLUDE_MANAGEMENT >>> -? if (version == JMM_VERSION_1_0) { >>> +? if (version == JMM_VERSION) { >>> ????? return (void*) &jmm_interface; >>> ??? } >>> ? #endif // INCLUDE_MANAGEMENT >>> ??? return NULL; >>> ? } >>> >>> You've correctly fixed the single caller of "JVM_GetManagement()" in >>> the JDK (in "JNI_OnLoad()" in "management.c"): >>> >>> -??? jmm_interface = (JmmInterface*) >>> JVM_GetManagement(JMM_VERSION_1_0); >>> +??? jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION); >>> >>> but I wonder if there are other monitoring/serviceability tools out >>> there which use this interface and which will break after this change. >>> A quick search revealed at least two StackOverflow entries which >>> recommend using "JVM_GetManagement(JMM_VERSION_1_0)" [1,2] and there's >>> a talk and a blog entry doing the same [3, 4]. >>> >>> I'm not sure how relevant this is but I think a much safer and >>> backwards-compatible way of doing this downport would be the >>> following: >>> >>> - don't change "Management::get_jmm_interface()" (i.e. still check for >>> "JMM_VERSION_1_0") but return the "new" JMM_VERSION in >>> "jmm_GetVersion()". This won't break anything but will make it >>> possible for clients to detect the new version if they want. >>> >>> - don't change the signature of "DumpThreads()". Instead add a new >>> version (e.g. "DumpThreadsMaxDepth()/jmm_DumpThreadsMaxDepth()") to >>> the "JMMInterface" struct and to "jmm_interface" in "management.cpp". >>> You can do this in one of? the two first, reserved fields of >>> "JMMInterface" so you won't break binary compatibility. >>> "jmm_DumpThreads()" will then be a simple wrapper which calls >>> "jmm_DumpThreadsMaxDepth()" with Integer.MAX_VALUE as depth. >>> >>> - in the jdk you then simply call "DumpThreadsMaxDepth()" in >>> "Java_sun_management_ThreadImpl_dumpThreads0()" >>> >>> I think this way we can maintain full binary compatibility while still >>> using the new feature. What do you think? >>> >>> Best regards, >>> Volker >>> >>> [1] >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/23632653/generate-java-heap-dump-on-uncaught-exception__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-KqVsyaF$ >>> [2] >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/60887816/jvm-options-printnmtstatistics-save-info-to-file__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Ip7MAQ5$ >>> [3] >>> https://urldefense.com/v3/__https://sudonull.com/post/25841-JVM-TI-how-to-make-a-plugin-for-a-virtual-machine-Odnoklassniki-company-blog__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-ErSjPdD$ >>> [4] >>> https://urldefense.com/v3/__https://2019.jpoint.ru/talks/2o8scc5jbaurnqqlsydzxv/__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Oxb5CQ-$ >>> >>> Passes the included (suitably modified) test, as well as the tests in >>> >>> >>> >>> jdk/test/java/lang/management/ThreadMXBean >>> >>> jdk/test/com/sun/management/ThreadMXBean >>> >>> >>> >>> Thanks, >>> >>> Paul >>> >>> > From mbalao at redhat.com Fri Aug 21 21:57:34 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 21 Aug 2020 18:57:34 -0300 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <4b8dedb7-c627-5f5a-97fe-bff618a18a96@redhat.com> References: <20200820172003.GD3112706@stopbrexit> <4b8dedb7-c627-5f5a-97fe-bff618a18a96@redhat.com> Message-ID: <59edff20-8aaa-75bc-5a28-d7526981a528@redhat.com> On 8/21/20 5:30 AM, Andrew Haley wrote: > On 20/08/2020 18:20, Andrew Hughes wrote: >> On 17:26 Wed 19 Aug , Andrew Haley wrote: >>>> >>>> On 8/5/20 11:54 PM, Andrew Hughes wrote: >>>>> I didn't go further with the review of this so far, because >>>>> JDK-8144539 is one of the outstanding test backports for the >>>>> SQLite patch as well. I intend to return to that bug trail >>>>> shortly, and we can reconsider both patches once the test >>>>> backports are resolved. >>>> >>>> I believe that 8144539 should not be a blocker for 8080462 because: >>>> the overlap/conflict between them does not appear to be fundamental >>>> -and has been addressed in the current backport proposal-; 8144539 >>>> does not look like a trivial backport -at least at first glance, >>>> given the number of files affected-; and, 8144539 does not seem to >>>> have the same priority than 8080462 -so a low priority backport is >>>> currently blocking a high priority one-. Looks to me that 8144539 is >>>> not even required for compatibility between JDKs, but 8080462 >>>> certainly is. >>> >>> We can't wait any longer for this. Martin, please feel free to commit >>> http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.01/ >> >> I'm working on the dependencies for this right now. A few days is >> hardly going to matter. >> >> I'll then review Martin's fix. > > It has already been reviewed; it doesn't need another one. As Martin > explained, we have a case of priority inversion here, where an > important fix with customer need is blocked by a "wouldn't it be > nice..." test fix, which doesn't make any sense. > > Martin may, of course, wait for 8144539 if he wishes. > Thanks to both of you for having a look at this. As long as we can push 8228835 and 8251117 (blocked by 8080462) before the cut-off date, I'm okay. Please note that 8228835 and 8251117 are not the only backports blocked by 8080462. Yes, it's inversion of priorities in a context where we all have many things with high priority on our backlogs, deadlines coming and users who have been waiting for months. Even if a few more days or a few more dependencies don't seem to make a big difference in cost, everything adds up. I'm making this point not to point anyone but as a call to judge whether a dependency is fundamental to block a backport. I've the impression that other JDKs don't go as deep as we are going with dependencies, and are able to move faster on other -probably more important- backports. That's my view at least. Thanks, Martin.- From gnu.andrew at redhat.com Sat Aug 22 01:41:42 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 22 Aug 2020 02:41:42 +0100 Subject: [RFR] [8u] 8144539: Update PKCS11 tests to run with security manager Message-ID: <20200822014142.GE31221@stopbrexit> Bug: https://bugs.openjdk.java.net/browse/JDK-8144539 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8144539/webrev.01/ This fix expands the test coverage of the PKCS#11 provider, as well as doing a fair amount of cleanup on the tests, which will help later backports. Changes from the 9u version: * test/sun/security/pkcs11/KeyAgreement/TestDH.java: Changes already introduced by JDK-8185292: "Stricter key generation" * test/sun/security/pkcs11/KeyPairGenerator/TestDH2048.java: Copyright header already has a later date. * test/sun/security/pkcs11/PKCS11Test.java: Copyright header already has a later date. The presence of JDK-8186098: "sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed" requires additional imports and causes differences inside the try block. The isBadSolarisSparc method, badSolarisSparc variable and change to the getDistro() method are not required as 8u does not have JDK-8133318: "Exclude intermittent failing PKCS11 tests on Solaris SPARC 11.1 and earlier" Format of "Completed test with provider" line differed due to lack of JDK-7191662: "JCE providers should be located via ServiceLoader" * test/sun/security/pkcs11/Secmod/AddPrivateKey.java, test/sun/security/pkcs11/Secmod/Crypto.java and test/sun/security/pkcs11/Secmod/GetPrivateKey.java don't expect the randomness tag added by JDK-8078334, though other files do. * test/sun/security/pkcs11/Secmod/TrustAnchors.java, test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java: Differing copyright headers. * test/sun/security/pkcs11/Signature/ByteBuffers.java, test/sun/security/pkcs11/Signature/TestDSA.java, test/sun/security/pkcs11/Signature/TestDSAKeyLength.java, test/sun/security/pkcs11/Signature/TestRSAKeyLength.java, test/sun/security/pkcs11/ec/TestCurves.java, test/sun/security/pkcs11/ec/TestECDSA.java, test/sun/security/pkcs11/rsa/TestCACerts.java, test/sun/security/pkcs11/rsa/TestSignatures.java: Differing copyright headers. JDK-8133318 not present in 8u. No @modules line in 8u (for TestCurves) * test/sun/security/pkcs11/ec/TestECDH2.java, test/sun/security/pkcs11/ec/TestECDSA2.java, test/sun/security/pkcs11/fips/TrustManagerTest.java, test/sun/security/pkcs11/tls/TestKeyMaterial.java, test/sun/security/pkcs11/tls/TestMasterSecret.java, test/sun/security/pkcs11/tls/TestPRF.java, test/sun/security/pkcs11/tls/TestPremaster.java: No @modules line in 8u (for TestCurves) * test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java: @run line sets -Djdk.tls.namedGroups in 8u and already sets jdk.tls.disabledAlgorithms & jdk.certpath.disabledAlgorithms Ok for 8u? Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Sat Aug 22 01:52:03 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 22 Aug 2020 02:52:03 +0100 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <4b8dedb7-c627-5f5a-97fe-bff618a18a96@redhat.com> References: <20200820172003.GD3112706@stopbrexit> <4b8dedb7-c627-5f5a-97fe-bff618a18a96@redhat.com> Message-ID: <20200822015203.GF31221@stopbrexit> On 09:30 Fri 21 Aug , Andrew Haley wrote: > On 20/08/2020 18:20, Andrew Hughes wrote: > > On 17:26 Wed 19 Aug , Andrew Haley wrote: > >>> > >>> On 8/5/20 11:54 PM, Andrew Hughes wrote: > >>>> I didn't go further with the review of this so far, because > >>>> JDK-8144539 is one of the outstanding test backports for the > >>>> SQLite patch as well. I intend to return to that bug trail > >>>> shortly, and we can reconsider both patches once the test > >>>> backports are resolved. > >>> > >>> I believe that 8144539 should not be a blocker for 8080462 because: > >>> the overlap/conflict between them does not appear to be fundamental > >>> -and has been addressed in the current backport proposal-; 8144539 > >>> does not look like a trivial backport -at least at first glance, > >>> given the number of files affected-; and, 8144539 does not seem to > >>> have the same priority than 8080462 -so a low priority backport is > >>> currently blocking a high priority one-. Looks to me that 8144539 is > >>> not even required for compatibility between JDKs, but 8080462 > >>> certainly is. > >> > >> We can't wait any longer for this. Martin, please feel free to commit > >> http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.01/ > > > > I'm working on the dependencies for this right now. A few days is > > hardly going to matter. > > > > I'll then review Martin's fix. > > It has already been reviewed; it doesn't need another one. No, what I reviewed previously was an earlier revision, not the current one. > As Martin > explained, we have a case of priority inversion here, where an > important fix with customer need is blocked by a "wouldn't it be > nice..." test fix, which doesn't make any sense. It's a bit more than that. Getting the PKCS#11 testing sorted affects at least one other fix as well, and this is an area where greater test coverage is needed, as PKCS#11 isn't used in most setups. > > Martin may, of course, wait for 8144539 if he wishes. > Martin and I are already working on this together. The RFR for 8144539 is here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012517.html > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > -- Andrew :) Senior 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 From gnu.andrew at redhat.com Sat Aug 22 01:56:24 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 22 Aug 2020 02:56:24 +0100 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <59edff20-8aaa-75bc-5a28-d7526981a528@redhat.com> References: <20200820172003.GD3112706@stopbrexit> <4b8dedb7-c627-5f5a-97fe-bff618a18a96@redhat.com> <59edff20-8aaa-75bc-5a28-d7526981a528@redhat.com> Message-ID: <20200822015624.GG31221@stopbrexit> On 18:57 Fri 21 Aug , Martin Balao wrote: snip... > I've the > impression that other JDKs don't go as deep as we are going with > dependencies, and are able to move faster on other -probably more > important- backports. That's my view at least. > > Thanks, > Martin.- > Which "other JDKs"? The process I use is the same I have used for over a decade and it has worked fine for maintaining previous JDKs, as far as I'm aware. I see no reason to start cutting corners now. The biggest problem for me with 8u at the moment is there are too many patches for a stable release and too few reviewers. That's why it has taken so long to get to this. -- Andrew :) Senior 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 From gnu.andrew at redhat.com Sat Aug 22 02:36:28 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 22 Aug 2020 03:36:28 +0100 Subject: [RFR] [8u] 8251120: HotSpot build assumes ENABLE_JFR is set to either true or false Message-ID: <20200822023628.GB126018@stopbrexit> Bug: https://bugs.openjdk.java.net/browse/JDK-8251120 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8251120/webrev.01/ The HotSpot build on *nix systems currently assumes that ENABLE_JFR is set to either true or false. This is the case when the HotSpot build is invoked via the configure build system, but not otherwise, as nothing in the Makefiles actually sets it. A simple fix is to invert the tests for false, so only true is checked for, and false and undefined are assumed to be the same. Windows already only checks for true, so no changes are needed there. Ok for 8u? Thanks, -- Andrew :) Senior 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 From sgehwolf at redhat.com Mon Aug 24 12:29:23 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 24 Aug 2020 14:29:23 +0200 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <20200821183742.GC31221@stopbrexit> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> <20200820172233.GE3112706@stopbrexit> <20200820202933.GA3306744@stopbrexit> <734e9fba06c99b2b6c3dd6ea8814cb42d35a5315.camel@redhat.com> <20200821183742.GC31221@stopbrexit> Message-ID: <36ee84b15f30d7472a9c722db98c69de7063a329.camel@redhat.com> On Fri, 2020-08-21 at 19:37 +0100, Andrew Hughes wrote: > > > > There is no Windows file in the 11u version. Why is it needed in 8u? > > > In both, OperatingSystemImpl.java seems to be under > > > src/jdk.management/unix/classes or src/solaris/classes/sun/management, > > > rather than share/classes. > > > > Good point. There is a Windows specific OperatingSystemImpl.java with > > references to native methods. I missed that. Note to self: No need to > > change the native method impls as they've not changed > > in src/windows/classes/sun/management/OperatingSystemImpl.java either. > > Reverted in the updated webrev. > > Thanks. It took me a while to spot it as well. At first, I thought Windows > was picking it up from one common shared Java file like the others, but > then I looked at the paths again and spotted the unix/solaris usage. > > > Latest webrev here: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/02/webrev/ > > > > Thanks. JDK side looks good now. Thanks again for the review! > I'll wait for your response on > whether to do the other change first for the HotSpot side. Please, lets not delay this any longer for a nice-to-have test cleanup. > > > Your description of the Subsystem.java changes is quite terse. > > > Can you explain in more detail why the readMatchingLines change > > > is not needed? > > > > OpenJDK 8u doesn't have this bug which introduces readMatchingLines() > > methods: > > > > 8217338: [Containers] Improve systemd slice memory limit support > > > > Therefore, hunks which adapted those methods, or rather, refactored > > them, aren't needed in this patch. Does that make sense? > > > > It does. I think I pretty much got there from the shorter comment, > but my brain wasn't sure enough that it had parsed it correctly. > > > > OperatingSystemImpl.java & OperatingSystemMXBean.java look fine. > > > > Tested builds on Windows, AIX, Solaris and Linux with this updated > > webrev. > > > > You have access to AIX & Solaris builds? That might be useful for > other patches. Yes, I only realized this recently. With help from our friends at Eclipse Adoptium (AdoptOpenJDK). > Out of interest, did the original pass on Windows? I haven't tried, so I don't know. Probably not. Thanks, Severin From sgehwolf at redhat.com Mon Aug 24 12:24:01 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 24 Aug 2020 14:24:01 +0200 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <20200821182220.GB31221@stopbrexit> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> <20200820172233.GE3112706@stopbrexit> <20200820202933.GA3306744@stopbrexit> <20200820204415.GA3308293@stopbrexit> <716b0941fd2cc1134b1fbb6bd4485309223ac7de.camel@redhat.com> <20200821182220.GB31221@stopbrexit> Message-ID: On Fri, 2020-08-21 at 19:22 +0100, Andrew Hughes wrote: > On 10:58 Fri 21 Aug , Severin Gehwolf wrote: > > On Thu, 2020-08-20 at 21:44 +0100, Andrew Hughes wrote: > > > Forgot to mention the HotSpot tests look ok other than: > > > > > > + if (!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { > > > + DockerTestUtils.removeDockerImage(imageName); > > > + } > > > > > > seems to be missing in a couple of the files. Why? > > > > RETAIN_IMAGE_AFTER_TEST was introduced with JDK-8221710 which isn't in > > OpenJDK 8u (yet). It's in my queue of docker test fixes. I can re-add > > those missing hunks with the JDK-8221710 backport. > > > > Thanks, > > Severin > > > > Would it not just make more sense to do JDK-8221710 first, retaining > the order in 11u? It looks pretty simple. No. It would defer JDK-8226575 (high prio) for JDK-8221710 (test-only, low priority). Also, I'm not sure JDK-8221710 has other dependencies. This fix should go in now and then we can amend JDK-8221710 later once it goes in. The earlier we get it in the more testing it can get before 8u272 goes live. It already had to wait for JDK-8203357. Note that the initial RFR of this got sent over a month ago. This all adds up. Thanks, Severin From mbalao at redhat.com Mon Aug 24 16:20:07 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 24 Aug 2020 13:20:07 -0300 Subject: [8u] TLSv1.3 RFR: 8251478: Backport TLSv1.3 regression tests to JDK8u In-Reply-To: <529B5CE4-2055-4015-A6DD-1774E18D1C7A@azul.com> References: <4E845CF2-E84F-413B-8193-64FD521BA647@azul.com> <529B5CE4-2055-4015-A6DD-1774E18D1C7A@azul.com> Message-ID: <23e5a655-e4f9-435c-669d-bb91c7ddc12d@redhat.com> Hi Alexey, On 8/19/20 10:44 AM, Alexey Bakhtin wrote: > Please find updated version of the patch: > Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v1 > Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v1/jdk.git.diff > > This version contains updates for the MFLN Extension tests Thanks for proposing this patch. A few questions: * test/sun/security/ssl/SSLSocketImpl/SSLSocketKeyLimit.java * 8u's equivalent of InputStream::readNBytes is IOUtils.readNBytes * Just out of curiosity, why 'main' method needs to throw Throwable instead of Exception? I've seen this change in other tests too. * test/sun/security/ssl/internal/java.base/sun/security/ssl/TestHkdf.java * test/sun/security/ssl/Stapling/java.base/sun/security/ssl/StatusResponseManagerTests.java * Why did you relocate these tests? I'd keep them in their original location if possible. * test/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java * I've seen the jdk.test.lib.security.SecurityUtils import was removed but looks to me that it's used. I might be overlooking something. * MFLNTest tests * I'd try something different, to minimize the number of changes. Instead of having scripts that build a JAR and include the new MaxPacketSize class in the sun.security.ssl package to access internal fields; I'd only change SSLEngineTestCase::doHandshake method to set the proper max packet size by means of reflection. SSLEngineTestCase::doHandshake has to be edit anyways to reflect the lack of an API to set the max fragment size. This approach should also avoid a change in MFLNTest class. What do you think? Thanks, Martin.- From zgu at redhat.com Mon Aug 24 19:36:54 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 24 Aug 2020 15:36:54 -0400 Subject: [8u] RFR 8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26 Message-ID: <8dd335ec-3366-8865-3b7e-f13b515aa9ad@redhat.com> I would like to backport this to 8u for parity with Oracle 8u281. The original patch does not apply to 8u, as jdk15 and jdk8 record third-party licenses in different ways. The original bug: https://bugs.openjdk.java.net/browse/JDK-8244151 The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a135cb86e111 8u webrev: main: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/main/webrev.00/ corba: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/corba/webrev.00/ hotspot: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/hotspot/webrev.00/ jaxp: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/jaxp/webrev.00/ jaxws: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/jaxws/webrev.00/ jdk: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/jdk/webrev.00/ langtools: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/langtools/webrev.00/ Thanks, -Zhengyu From alexey at azul.com Mon Aug 24 20:18:52 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 24 Aug 2020 20:18:52 +0000 Subject: [8u] TLSv1.3 RFR: 8245681: Add TLSv1.3 regression test from 11.0.7 In-Reply-To: <05795d97-a818-c185-2f16-2940b60e88f0@redhat.com> References: <7D92607F-B8F0-4E84-B6C2-5E2AB4E42824@azul.com> <04f0d809-2f53-5335-9828-72b198bf369f@azul.com> <0e9f68c6-dd0e-c2f7-50bf-28bf23a3a012@redhat.com> <66A03F4D-3EC4-43D2-9B2B-33E1F6BEDFD1@azul.com> <05795d97-a818-c185-2f16-2940b60e88f0@redhat.com> Message-ID: <58A4FEB3-4DD5-4984-A464-C4C6F9F6F480@azul.com> Hi Martin, Thank you for this finding. OCSPNonceExtensionTests.java and ResponderId/ResponderIdTests.java classes are added. New webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v4/ Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v4/jdk.git.diff Regards Alexey > On 21 Aug 2020, at 22:35, Martin Balao wrote: > > Don't we want the following tests for Step 11? > > * > test/sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java > (new) > * test/sun/security/provider/certpath/ResponderId/ResponderIdTests.java > (new) > > Thanks, > Martin.- > From mbalao at redhat.com Mon Aug 24 21:04:15 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 24 Aug 2020 18:04:15 -0300 Subject: [8u] TLSv1.3 RFR: 8245681: Add TLSv1.3 regression test from 11.0.7 In-Reply-To: <58A4FEB3-4DD5-4984-A464-C4C6F9F6F480@azul.com> References: <7D92607F-B8F0-4E84-B6C2-5E2AB4E42824@azul.com> <04f0d809-2f53-5335-9828-72b198bf369f@azul.com> <0e9f68c6-dd0e-c2f7-50bf-28bf23a3a012@redhat.com> <66A03F4D-3EC4-43D2-9B2B-33E1F6BEDFD1@azul.com> <05795d97-a818-c185-2f16-2940b60e88f0@redhat.com> <58A4FEB3-4DD5-4984-A464-C4C6F9F6F480@azul.com> Message-ID: <1c866100-9848-1524-a53c-d566a29cc940@redhat.com> Hi, On 8/24/20 5:18 PM, Alexey Bakhtin wrote: > Hi Martin, > > Thank you for this finding. > OCSPNonceExtensionTests.java and ResponderId/ResponderIdTests.java classes are added. > > New webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v4/ > Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v4/jdk.git.diff In Step 11 - 8245681 we will add the 11.0.7 version of tests removed in Step 10 - 8245653. These SSL-related tests were modified or added with the new SunJSSE TLS engine in 8196584 and related patches. It's still not the expectation to pass all tests in this step, as JDK-8 adjustments may be needed and will be addressed in a later step (Step 15 - 8251478). * Files deleted in Step 10 that were not added as new in Step 11: * test/javax/net/ssl/SSLSession/testEnabledProtocols.java (deleted) * Ok, does not exist in 11.0.7. * test/sun/net/www/protocol/https/HttpsClient/OriginServer.java * Ok, does not exist in 11.0.7. * test/sun/security/ssl/SSLEngineImpl/CloseInboundException.java (deleted) * Ok, does not exist in 11.0.7. * test/sun/security/ssl/SessionIdCollisionTest.java (deleted) * Ok, does not exist in 11.0.7. * Check no file modified in Step 10 is added in Step 11. * Ok * Check that this patch only adds new files * Ok * Check that for each removed test in Step 10 - 8245653, there we have the corresponding test added in this step * Ok * Check that with the new files added in this step (not previously present in JDK-8); there are no differences in the test files for all SSL-related categories, except for tests not supposed to be there such as DTLS: * sun/security/ssl * DTLS tests -> does not apply * Stapling/TEST.properties -> does not apply * internal/TEST.properties -> does not apply * Ok * javax/net/ssl * DTLS tests -> does not apply * HttpsURLConnection/Equals.java * Not TLS specific. Should be addressed separately. * Stapling/TEST.properties -> does not apply * TLS/TEST.properties -> does not apply * TLSv1/TEST.properties -> does not apply * TLSv11/TEST.properties -> does not apply * finalize/SSLSessionFinalizeTest.java -> Not related to TLSv1.3 implementation. Non-trivial backport. Ok. * finalize/security.policy -> Not related to TLSv1.3 implementation. Non-trivial backport. Ok. * Ok * com/sun/net/ssl * Ok * sun/net/www/protocol/https * Ok * sun/security/pkcs11/sslecc * Ok * Check that added new files are not different than their 11.0.7 counterpart: * Ok * Check if Step 11 adds something out of Step 10 SSL-related categories: * test/java/security/testlibrary/CertificateBuilder.java * test/java/security/testlibrary/SimpleOCSPServer.java * test/sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java * test/sun/security/provider/certpath/ResponderId/ResponderIdTests.java * Ok, OCSP stapling related. Coming from 8046321 (backported in Step 6 - 8245473). These files are located in a non SSL-related identified category. For that reason, I separetly verified that no other test in 8046321 is missing. The following comments are part of this review: [1] [2]. With that said, Step 11 - 8245681 Webrev.04 looks good to me. Thanks, Martin.- -- [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012431.html [2] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012514.html From mbalao at redhat.com Tue Aug 25 04:40:20 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 25 Aug 2020 01:40:20 -0300 Subject: [RFR] [8u] 8144539: Update PKCS11 tests to run with security manager In-Reply-To: <20200822014142.GE31221@stopbrexit> References: <20200822014142.GE31221@stopbrexit> Message-ID: Hi, On Fri, Aug 21, 2020 at 10:43 PM Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144539 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8144539/webrev.01/ > > A few comments: * There are a few tabs in PKCS11Test.java. Can we replace them with white spaces? So we make sure that the code shows properly aligned across IDEs. * I've seen several changes in a few files such as TestPRF.java, TestMasterSecret.java, TestKeyMaterial.java, etc. TestKeyMaterial.java was a bit easier for the naked eye. I take from your comment that you didn't have any major conflict there beyond the '@modules' line, right? * test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java and test/sun/security/pkcs11/sslecc/JSSEServer.java changes will create a conflict with the TLS 1.3 backport; affecting Steps 10, 11 and 15. Otherwise, looks good to me. With that said, I believe that this backport (which has low-priority) should wait until the TLS 1.3 backport (high-priority) is merged. Particularly because we are targeting the next release, and should be able to merge this week -so it's not that we are blocking SSL-related tests for a long time-. Otherwise, we would need to rebase and generate + review Steps 10, 11 and 15 again. Note: 15 is still under review, but I was expecting to have it ready in the next couple of days. That's my view. I'll let other Reviewers decide here. Thanks, Martin.- From felix.yang at huawei.com Tue Aug 25 08:05:51 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 25 Aug 2020 08:05:51 +0000 Subject: RFR Backport 8165808: Add release barriers when allocating objects with concurrent collection Message-ID: Hi, As mentioned in [1], JDK-8160369 have not been backported to JDK8u. This is necessary for RMO architectures like aarch64. JDK-8165808 is the first subtask of JDK-8160369. Original bug: https://bugs.openjdk.java.net/browse/JDK-8165808 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fd16b627ebc5 Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-September/024487.html The original patch does not apply cleanly to jdk8u-dev due to path and code refactoring work in jdk9+. Webrev for 8u: http://cr.openjdk.java.net/~fyang/8165808-8u/webrev.00/ 1. The changes in CollectedHeap::post_allocation_setup_class of the original patch is not necessary for backport as this function is not there in jdk8u. For jdk9+, the call chain is: InstanceMirrorKlass::allocate_instance -> CollectedHeap::class_allocate -> CollectedHeap::post_allocation_setup_class -> CollectedHeap::post_allocation_setup_common For jdk8u, we have: InstanceMirrorKlass::allocate_instance -> CollectedHeap::obj_allocate -> CollectedHeap::post_allocation_setup_obj -> CollectedHeap::post_allocation_setup_common 2. Also adapted the way of adding inline keyword for new function oopDesc::release_set_klass. Performed full jtreg test with release & fastdebug builds both on aarch64-linux and x86_64-linux platforms. OK to backport? Thanks, Felix [1] https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030313.html From aph at redhat.com Tue Aug 25 08:17:31 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Aug 2020 09:17:31 +0100 Subject: RFR Backport 8165808: Add release barriers when allocating objects with concurrent collection In-Reply-To: References: Message-ID: <0cbd336a-d3aa-daae-1a65-f8dafebe6ae9@redhat.com> On 25/08/2020 09:05, Yangfei (Felix) wrote: > JDK-8165808 is the first subtask of JDK-8160369. > Original bug:https://bugs.openjdk.java.net/browse/JDK-8165808 > Original patch:http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fd16b627ebc5 > Original review thread:http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-September/024487.html > > The original patch does not apply cleanly to jdk8u-dev due to path and code refactoring work in jdk9+. > Webrev for 8u:http://cr.openjdk.java.net/~fyang/8165808-8u/webrev.00/ > > 1. The changes in CollectedHeap::post_allocation_setup_class of the original patch is not necessary for backport as this function is not there in jdk8u. > For jdk9+, the call chain is: > InstanceMirrorKlass::allocate_instance -> CollectedHeap::class_allocate -> CollectedHeap::post_allocation_setup_class -> CollectedHeap::post_allocation_setup_common > For jdk8u, we have: > InstanceMirrorKlass::allocate_instance -> CollectedHeap::obj_allocate -> CollectedHeap::post_allocation_setup_obj -> CollectedHeap::post_allocation_setup_common > > 2. Also adapted the way of adding inline keyword for new function oopDesc::release_set_klass. > > Performed full jtreg test with release & fastdebug builds both on aarch64-linux and x86_64-linux platforms. > OK to backport? Yes, certainly. Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 25 08:52:59 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Aug 2020 09:52:59 +0100 Subject: [RFR] [8u] 8144539: Update PKCS11 tests to run with security manager In-Reply-To: References: <20200822014142.GE31221@stopbrexit> Message-ID: <7fe48038-759b-fff5-080d-a0aaf6447641@redhat.com> On 25/08/2020 05:40, Martin Balao wrote: > With that said, I believe that this backport (which has low-priority) > should wait until the TLS 1.3 backport (high-priority) is merged. > Particularly because we are targeting the next release, and should be > able to merge this week -so it's not that we are blocking SSL-related > tests for a long time-. Otherwise, we would need to rebase and > generate + review Steps 10, 11 and 15 again. Note: 15 is still under > review, but I was expecting to have it ready in the next couple of > days. That's my view. I'll let other Reviewers decide here. Yes, I agree with Martin. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Tue Aug 25 08:56:43 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 25 Aug 2020 08:56:43 +0000 Subject: RFR Backport 8165808: Add release barriers when allocating objects with concurrent collection In-Reply-To: <0cbd336a-d3aa-daae-1a65-f8dafebe6ae9@redhat.com> References: <0cbd336a-d3aa-daae-1a65-f8dafebe6ae9@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Tuesday, August 25, 2020 4:18 PM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: RFR Backport 8165808: Add release barriers when allocating > objects with concurrent collection > > On 25/08/2020 09:05, Yangfei (Felix) wrote: > > JDK-8165808 is the first subtask of JDK-8160369. > > Original bug:https://bugs.openjdk.java.net/browse/JDK-8165808 > > Original > > patch:http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fd16b627ebc5 > > Original review > > thread:http://mail.openjdk.java.net/pipermail/hotspot-dev/2016- > Septemb > > er/024487.html > > > > The original patch does not apply cleanly to jdk8u-dev due to path and code > refactoring work in jdk9+. > > Webrev for 8u:http://cr.openjdk.java.net/~fyang/8165808-8u/webrev.00/ > > Cut... > > > > Performed full jtreg test with release & fastdebug builds both on aarch64- > linux and x86_64-linux platforms. > > OK to backport? > > Yes, certainly. Thanks. Thanks for quick review. I have add new label jdk8u-fix-request and necessary comment on the issue. Felix From aph at redhat.com Tue Aug 25 09:18:26 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Aug 2020 10:18:26 +0100 Subject: RFR Backport 8165808: Add release barriers when allocating objects with concurrent collection In-Reply-To: References: <0cbd336a-d3aa-daae-1a65-f8dafebe6ae9@redhat.com> Message-ID: On 25/08/2020 09:56, Yangfei (Felix) wrote: >> Yes, certainly. Thanks. > Thanks for quick review. > I have add new label jdk8u-fix-request and necessary comment on the issue. By the way, there are many places where arrays are allocated. Do you know why only this particular one needs a release barrier? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Tue Aug 25 11:37:27 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 25 Aug 2020 13:37:27 +0200 Subject: RFR: Backport: 8222079: Don't use memset to initialize fields decode_env constructor in disassembler.cpp Message-ID: <1c5d18da73694b2cf674eac86096663a7668f5b4.camel@redhat.com> This backports: https://bugs.openjdk.java.net/browse/JDK-8222079 It fixes UB and makes newer compilers happy. It's based on the jdk11u change: http://cr.openjdk.java.net/~rkennke/JDK-8222079-jdk11u/webrev.00/ It is a fairly straight backport and for the most part matches the jdk11u variant, except that in jdk8u, we don't have an _offset field and ctor argument, but we do have an additional _total_ticks field. JDK8u webrev: http://cr.openjdk.java.net/~rkennke/JDK-8222079-jdk8u/webrev.00/ Can I please get a review? Thanks, Roman From felix.yang at huawei.com Tue Aug 25 12:53:19 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 25 Aug 2020 12:53:19 +0000 Subject: RFR Backport 8165808: Add release barriers when allocating objects with concurrent collection In-Reply-To: References: <0cbd336a-d3aa-daae-1a65-f8dafebe6ae9@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Tuesday, August 25, 2020 5:18 PM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: RFR Backport 8165808: Add release barriers when allocating > objects with concurrent collection > > On 25/08/2020 09:56, Yangfei (Felix) wrote: > >> Yes, certainly. Thanks. > > Thanks for quick review. > > I have add new label jdk8u-fix-request and necessary comment on the > issue. > > By the way, there are many places where arrays are allocated. Do you know > why only this particular one needs a release barrier? Not sure if I understand the question correctly. I think the common entry points are CollectedHeap::obj_allocate & CollectedHeap::array_allocate. These functions finally calls CollectedHeap::post_allocation_setup_common. Many places will call these functions to create objects. For example, InstanceKlass::allocate_objArray -> CollectedHeap::array_allocate -> CollectedHeap::post_allocation_setup_array -> CollectedHeap::post_allocation_setup_common Since we do a release store in CollectedHeap::post_allocation_setup_common, so all the places where objects are created will benefit. Hope that explains. Thanks, Felix From sgehwolf at redhat.com Tue Aug 25 13:05:09 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 25 Aug 2020 15:05:09 +0200 Subject: [8u] RFR(s): 8221342: [TESTBUG] Generate Dockerfile for docker testing Message-ID: <921a5acde361aa36cb840cc4ed4a9e3d1ecb29cc.camel@redhat.com> Hi! Please review this 8u backport of this test bug which enhances container testing to automatically generate docker files. This is useful if the development platform is not Oracle Linux 7.X (which is the case for me). The JDK 11 patch applies cleanly (after JDK-8220313 which is in the approval queue) but doesn't compile since Files.writeString() API is not available in JDK 8. Replaced it with: byte[] bytes = dockerFileStr.getBytes(StandardCharsets.UTF_8); Files.write(dockerfile, bytes); The second change needed was to adjust the package name for DockerfileConfig as there are two sets of container tests: one for hotspot and one for jdk. Bug: https://bugs.openjdk.java.net/browse/JDK-8221342 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221342/jdk8/01/ Testing: Docker tests with -Djdk.test.docker.image.name and -Djdk.test.docker.image.version on my F32 which now works. Previously a manual change of Dockerfile-BasicTest was needed. Thoughts? Thanks, Severin From sgehwolf at redhat.com Tue Aug 25 13:27:03 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 25 Aug 2020 15:27:03 +0200 Subject: [8u] RFR 8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26 In-Reply-To: <8dd335ec-3366-8865-3b7e-f13b515aa9ad@redhat.com> References: <8dd335ec-3366-8865-3b7e-f13b515aa9ad@redhat.com> Message-ID: <6c19d4b304725aa52fc3fd357ff13641aa173a55.camel@redhat.com> On Mon, 2020-08-24 at 15:36 -0400, Zhengyu Gu wrote: > I would like to backport this to 8u for parity with Oracle 8u281. > > The original patch does not apply to 8u, as jdk15 and jdk8 record > third-party licenses in different ways. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8244151 > The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a135cb86e111 > > > 8u webrev: > main: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/main/webrev.00/ > corba: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/corba/webrev.00/ > hotspot: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/hotspot/webrev.00/ > jaxp: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/jaxp/webrev.00/ > jaxws: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/jaxws/webrev.00/ > jdk: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/jdk/webrev.00/ > langtools: > http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/langtools/webrev.00/ Looks fine to me. Thanks, Severin From zgu at redhat.com Tue Aug 25 14:24:04 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 25 Aug 2020 10:24:04 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <20200820171607.GC3112706@stopbrexit> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> <78a1c49794afdf13013a4c3d75efab50f4745870.camel@redhat.com> <20200820171607.GC3112706@stopbrexit> Message-ID: <94490d36-9747-4333-6278-a887af28e927@redhat.com> Okay, I restored @since 12. Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.04/ I still don't have a strong opinion on this, but it is not a specific problem for this backport. grep -r "@since" under jdk8u-dev/jdk, you see many versions > 8. If it needs to be addressed, we should address them at once and setup a guideline for future backports. Could I get formal review now? I bet Michael is anxious to get this in. Thanks, -Zhengyu On 8/20/20 1:16 PM, Andrew Hughes wrote: > On 08:51 Wed 19 Aug , Severin Gehwolf wrote: >> On Mon, 2020-08-17 at 06:26 +0100, Andrew Hughes wrote: >>> On 11:51 Thu 13 Aug , Severin Gehwolf wrote: >>>> On Tue, 2020-08-11 at 14:48 -0400, Zhengyu Gu wrote: >>>>> Hi Michael, >>>>> >>>>>> My tests/comments: >>>>>> * @since still says 12. Is that correct? >>>> >>>> I agree. Zhengyu, please remove the @since 12 tags in this backport. It >>>> doesn't make sense to have them in either 11 or 8. >>>> >>> >>> I disagree. Such tags are a useful indicator that this is a backported >>> API that wasn't in 8 GA. >> >> If we are starting to rely on @since tags as an indicator for backports >> then we're in trouble. Instead, the bug system and source control >> should be used for this. Given that, by removing the @since tag we >> don't loose info that it's a backport. >> > > I didn't claim it was the only indicator. > > It is useful to have it there in the source code if you're looking at > the file concerned. It's also easily accessible. Being able to find > the same information in the bug system or source control system > requires you to be aware of their existence and to know to look for > such information there. > > To find the same information as the simple @since tag provides, I > would need a checkout of the code from the source code repository, to > know how to look up when that file was added, and then use the bug ID > to lookup in the bug database in which JDK it was added. All a lot > more complicated than one line of text that only requires the sources > concerned. > >>> What would be the issue with leaving them in? >> >> A couple of reasons: >> >> * It's confusing. Mentioning something related to JDK 12 in a JDK 8 >> tree is, well, confusing. It only wouldn't be so if you are >> intimately familiar with the process and know about this mailing >> list discussion. > > I guess we have to beg to differ on this. I don't find it confusing. > The @since tag has long-term well-defined semantics familiar to any > Java user. I don't think it's that complicated to infer that if > "@since 12" is used in 8u sources, it must have been backported. > > I have used it in this manner for years (e.g. [0] [1]) and never been > aware of anyone finding it confusing before. > > On the contrary, to know to strip this information in a backport does > require the person backporting to have knowledge of the need to do > that and this discussion. > >> * @Since tags are usually used for *publicly* exposed classes as an >> aid for JDK API consumers. "This API is available for JDK 12 and >> onwards". I'm aware there are instances where it was used for >> internal classes too, but they become less prominent these days. It >> makes sense to have them for the original JDK 12 change. For the JDK >> 8u backport, classes have been moved to a private package. It's not >> a 1-to-1 backport. The value of it being preserved regardless makes >> little sense. It's not the original class where it was added to >> begin with. > > It is rare that public API would be backported. The one case where > this has happened (ALPN+RSA-PSS) used "@since 8". I'd have preferred > "@since 8M3" or "@since 8u41". > > It not being publicly exposed actually seems more reason to just leave > it in, as Javadoc won't be generated, so only someone looking at the > source would see it. > >> * The SinceTree.java interface mentions this in its javadoc: "Returns >> the text explaining the availability of the item being documented." >> That's wrong for code in JDK 8. We'd be putting a @since 12 on code >> introduced in an update version of 8u. > > 12 was its first availability. > > You could use @since 8u272 if you like. The main concern is to make it > clear that it wasn't part of 8 GA. > >> >> Overall, the drawbacks outweigh the benefits. >> > > I disagree. It seems mandating this could result in unnecessary > differences between 8u & later sources, and additional work for > backporters, all for no clear benefit. > >> Thanks, >> Severin >> > > [0] https://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/9ab3c966585d > [1] https://openjdk.java.net/jeps/129 > [2] https://jdk.java.net/java-se-ri/8-MR3 > From zgu at redhat.com Tue Aug 25 14:28:10 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 25 Aug 2020 10:28:10 -0400 Subject: [8u] RFR 8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26 In-Reply-To: <6c19d4b304725aa52fc3fd357ff13641aa173a55.camel@redhat.com> References: <8dd335ec-3366-8865-3b7e-f13b515aa9ad@redhat.com> <6c19d4b304725aa52fc3fd357ff13641aa173a55.camel@redhat.com> Message-ID: <3a2f0b7f-5c37-f120-63ae-9e78ef05b64d@redhat.com> Thanks. Added approval request. -Zhengyu On 8/25/20 9:27 AM, Severin Gehwolf wrote: > On Mon, 2020-08-24 at 15:36 -0400, Zhengyu Gu wrote: >> I would like to backport this to 8u for parity with Oracle 8u281. >> >> The original patch does not apply to 8u, as jdk15 and jdk8 record >> third-party licenses in different ways. >> >> The original bug: https://bugs.openjdk.java.net/browse/JDK-8244151 >> The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a135cb86e111 >> >> >> 8u webrev: >> main: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/main/webrev.00/ >> corba: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/corba/webrev.00/ >> hotspot: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/hotspot/webrev.00/ >> jaxp: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/jaxp/webrev.00/ >> jaxws: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/jaxws/webrev.00/ >> jdk: http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/jdk/webrev.00/ >> langtools: >> http://cr.openjdk.java.net/~zgu/JDK-8244151-8u/langtools/webrev.00/ > > Looks fine to me. > > Thanks, > Severin > From zgu at redhat.com Tue Aug 25 14:42:37 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 25 Aug 2020 10:42:37 -0400 Subject: RFR: Backport: 8222079: Don't use memset to initialize fields decode_env constructor in disassembler.cpp In-Reply-To: <1c5d18da73694b2cf674eac86096663a7668f5b4.camel@redhat.com> References: <1c5d18da73694b2cf674eac86096663a7668f5b4.camel@redhat.com> Message-ID: Looks fine to me. -Zhengyu On 8/25/20 7:37 AM, Roman Kennke wrote: > This backports: > https://bugs.openjdk.java.net/browse/JDK-8222079 > > It fixes UB and makes newer compilers happy. > > It's based on the jdk11u change: > http://cr.openjdk.java.net/~rkennke/JDK-8222079-jdk11u/webrev.00/ > > It is a fairly straight backport and for the most part matches the > jdk11u variant, except that in jdk8u, we don't have an _offset field > and ctor argument, but we do have an additional _total_ticks field. > > JDK8u webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8222079-jdk8u/webrev.00/ > > Can I please get a review? > > Thanks, > Roman > > From gnu.andrew at redhat.com Tue Aug 25 15:24:30 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 25 Aug 2020 16:24:30 +0100 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <36ee84b15f30d7472a9c722db98c69de7063a329.camel@redhat.com> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> <20200820172233.GE3112706@stopbrexit> <20200820202933.GA3306744@stopbrexit> <734e9fba06c99b2b6c3dd6ea8814cb42d35a5315.camel@redhat.com> <20200821183742.GC31221@stopbrexit> <36ee84b15f30d7472a9c722db98c69de7063a329.camel@redhat.com> Message-ID: <20200825152430.GA969845@stopbrexit> On 14:29 Mon 24 Aug , Severin Gehwolf wrote: > On Fri, 2020-08-21 at 19:37 +0100, Andrew Hughes wrote: > > > > > > There is no Windows file in the 11u version. Why is it needed in 8u? > > > > In both, OperatingSystemImpl.java seems to be under > > > > src/jdk.management/unix/classes or src/solaris/classes/sun/management, > > > > rather than share/classes. > > > > > > Good point. There is a Windows specific OperatingSystemImpl.java with > > > references to native methods. I missed that. Note to self: No need to > > > change the native method impls as they've not changed > > > in src/windows/classes/sun/management/OperatingSystemImpl.java either. > > > Reverted in the updated webrev. > > > > Thanks. It took me a while to spot it as well. At first, I thought Windows > > was picking it up from one common shared Java file like the others, but > > then I looked at the paths again and spotted the unix/solaris usage. > > > > > Latest webrev here: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/02/webrev/ > > > > > > > Thanks. JDK side looks good now. > > Thanks again for the review! > > > I'll wait for your response on > > whether to do the other change first for the HotSpot side. > > Please, lets not delay this any longer for a nice-to-have test cleanup. > Have you checked if the HotSpot test fix applies cleanly? If it does, we may as well quickly approve it and get it in. If not, there's no advantage to doing it first anyway, as it would need a review with or without these additional changes. My concern is turning a simple patch into one which needs review because it is completed out of order. Incidentally, this RFR may well have been posted a month ago, but it wasn't actionable without the dependent patch first being reviewed and approved. snip... > > > Out of interest, did the original pass on Windows? > > I haven't tried, so I don't know. Probably not. I did wonder, given the native methods no longer matched the Java ones. > > Thanks, > Severin > Thanks, -- Andrew :) Senior 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 From sgehwolf at redhat.com Tue Aug 25 15:42:47 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 25 Aug 2020 17:42:47 +0200 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <20200825152430.GA969845@stopbrexit> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> <20200820172233.GE3112706@stopbrexit> <20200820202933.GA3306744@stopbrexit> <734e9fba06c99b2b6c3dd6ea8814cb42d35a5315.camel@redhat.com> <20200821183742.GC31221@stopbrexit> <36ee84b15f30d7472a9c722db98c69de7063a329.camel@redhat.com> <20200825152430.GA969845@stopbrexit> Message-ID: <736b7706122dad7083ec9d7b1f44204237045eb5.camel@redhat.com> On Tue, 2020-08-25 at 16:24 +0100, Andrew Hughes wrote: > On 14:29 Mon 24 Aug , Severin Gehwolf wrote: > > On Fri, 2020-08-21 at 19:37 +0100, Andrew Hughes wrote: > > > > > There is no Windows file in the 11u version. Why is it needed in 8u? > > > > > In both, OperatingSystemImpl.java seems to be under > > > > > src/jdk.management/unix/classes or src/solaris/classes/sun/management, > > > > > rather than share/classes. > > > > > > > > Good point. There is a Windows specific OperatingSystemImpl.java with > > > > references to native methods. I missed that. Note to self: No need to > > > > change the native method impls as they've not changed > > > > in src/windows/classes/sun/management/OperatingSystemImpl.java either. > > > > Reverted in the updated webrev. > > > > > > Thanks. It took me a while to spot it as well. At first, I thought Windows > > > was picking it up from one common shared Java file like the others, but > > > then I looked at the paths again and spotted the unix/solaris usage. > > > > > > > Latest webrev here: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/02/webrev/ > > > > > > > > > > Thanks. JDK side looks good now. > > > > Thanks again for the review! > > > > > I'll wait for your response on > > > whether to do the other change first for the HotSpot side. > > > > Please, lets not delay this any longer for a nice-to-have test cleanup. > > > > Have you checked if the HotSpot test fix applies cleanly? Yes. It depends on a number of fixes before it. Then it applies cleanly but doesn't compile. Can I consider this patch reviewed? > If it does, we may as well quickly approve it and get it in. Unfortunately not the case. It'll need a review. > If not, there's no advantage to doing it first anyway, as it would > need a review with or without these additional changes. +1 > My concern is turning a simple patch into one which needs review > because it is completed out of order. Fair enough. > Incidentally, this RFR may well have been posted a month ago, but it > wasn't actionable without the dependent patch first being reviewed and > approved. Why? We already knew at the time that we want this patch (parity patch). The initial webrev didn't change (with the dependency in or not). As such, it could have been reviewed in my opinion. Thanks, Severin From gnu.andrew at redhat.com Tue Aug 25 16:19:18 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 25 Aug 2020 17:19:18 +0100 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <736b7706122dad7083ec9d7b1f44204237045eb5.camel@redhat.com> References: <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> <59d8d436dfe74fd3024bcd2a29161ccd546692b6.camel@redhat.com> <20200820172233.GE3112706@stopbrexit> <20200820202933.GA3306744@stopbrexit> <734e9fba06c99b2b6c3dd6ea8814cb42d35a5315.camel@redhat.com> <20200821183742.GC31221@stopbrexit> <36ee84b15f30d7472a9c722db98c69de7063a329.camel@redhat.com> <20200825152430.GA969845@stopbrexit> <736b7706122dad7083ec9d7b1f44204237045eb5.camel@redhat.com> Message-ID: <20200825161918.GB969845@stopbrexit> On 17:42 Tue 25 Aug , Severin Gehwolf wrote: > > Unfortunately not the case. It'll need a review. > Ok, consider this one reviewed then. Tag it for approval and I'll approve. > > > Incidentally, this RFR may well have been posted a month ago, but it > > wasn't actionable without the dependent patch first being reviewed and > > approved. > > Why? We already knew at the time that we want this patch (parity > patch). The initial webrev didn't change (with the dependency in or > not). As such, it could have been reviewed in my opinion. > Well, others may differ, but I would never review a patch that would be applied to some future source code tree that doesn't yet exist (and may never be applied if the dependency ends up being rejected) I understand it may be easier for you to put out RFRs for everything in your queue, but, from the review side, I find this confusing. > Thanks, > Severin > Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Tue Aug 25 16:46:29 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 25 Aug 2020 17:46:29 +0100 Subject: [RFR] [8u] 8144539: Update PKCS11 tests to run with security manager In-Reply-To: References: <20200822014142.GE31221@stopbrexit> Message-ID: <20200825164629.GC969845@stopbrexit> On 01:40 Tue 25 Aug , Martin Balao wrote: > Hi, > > On Fri, Aug 21, 2020 at 10:43 PM Andrew Hughes wrote: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144539 > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8144539/webrev.01/ > > > > > > A few comments: > > * There are a few tabs in PKCS11Test.java. Can we replace them with > white spaces? So we make sure that the code shows properly aligned > across IDEs. > I guess they may have snuck in when I had to bring back that code, as mentioned in the original e-mail. Should be fixed now with the normalizer script and jcheck would have caught it on commit. > * I've seen several changes in a few files such as TestPRF.java, > TestMasterSecret.java, TestKeyMaterial.java, etc. TestKeyMaterial.java > was a bit easier for the naked eye. I take from your comment that you > didn't have any major conflict there beyond the '@modules' line, > right? > I've attached diffs of those three with -b. Most of it is whitespace changes caused by indenting everything for the try block. > * test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java and > test/sun/security/pkcs11/sslecc/JSSEServer.java changes will create a > conflict with the TLS 1.3 backport; affecting Steps 10, 11 and 15. > I've reverted these changes to avoid the conflict as before. > Otherwise, looks good to me. > > With that said, I believe that this backport (which has low-priority) > should wait until the TLS 1.3 backport (high-priority) is merged. > Particularly because we are targeting the next release, and should be > able to merge this week -so it's not that we are blocking SSL-related > tests for a long time-. Otherwise, we would need to rebase and > generate + review Steps 10, 11 and 15 again. Note: 15 is still under > review, but I was expecting to have it ready in the next couple of > days. That's my view. I'll let other Reviewers decide here. > I would prefer we get this in to avoid it being pushed to 8u282, and it also unblocks the other PKCS#11 fixes. Given it is pretty much ready, going by your review, I see no reason to delay it further. New webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8144539/webrev.02/ It would be easier to see what files conflict with the TLS 1.3 work if the work was publicly visible. I don't yet see any changes in: https://hg.openjdk.java.net/jdk8u/jdk8u-jsse-incubator/jdk/ which is a little worrying for something you hope to have merged this weekend. > Thanks, > Martin.- > Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Tue Aug 25 16:48:59 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 25 Aug 2020 17:48:59 +0100 Subject: [RFR] [8u] 8144539: Update PKCS11 tests to run with security manager In-Reply-To: <20200825164629.GC969845@stopbrexit> References: <20200822014142.GE31221@stopbrexit> <20200825164629.GC969845@stopbrexit> Message-ID: <20200825164859.GD969845@stopbrexit> On 17:46 Tue 25 Aug , Andrew Hughes wrote: > On 01:40 Tue 25 Aug , Martin Balao wrote: > > Hi, > > > > On Fri, Aug 21, 2020 at 10:43 PM Andrew Hughes wrote: > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144539 > > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8144539/webrev.01/ > > > > > > > > > > A few comments: > > > > * There are a few tabs in PKCS11Test.java. Can we replace them with > > white spaces? So we make sure that the code shows properly aligned > > across IDEs. > > > > I guess they may have snuck in when I had to bring back that code, as > mentioned in the original e-mail. Should be fixed now with the normalizer > script and jcheck would have caught it on commit. > > > * I've seen several changes in a few files such as TestPRF.java, > > TestMasterSecret.java, TestKeyMaterial.java, etc. TestKeyMaterial.java > > was a bit easier for the naked eye. I take from your comment that you > > didn't have any major conflict there beyond the '@modules' line, > > right? > > > > I've attached diffs of those three with -b. Most of it is whitespace > changes caused by indenting everything for the try block. > > > * test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java and > > test/sun/security/pkcs11/sslecc/JSSEServer.java changes will create a > > conflict with the TLS 1.3 backport; affecting Steps 10, 11 and 15. > > > > I've reverted these changes to avoid the conflict as before. > > > Otherwise, looks good to me. > > > > With that said, I believe that this backport (which has low-priority) > > should wait until the TLS 1.3 backport (high-priority) is merged. > > Particularly because we are targeting the next release, and should be > > able to merge this week -so it's not that we are blocking SSL-related > > tests for a long time-. Otherwise, we would need to rebase and > > generate + review Steps 10, 11 and 15 again. Note: 15 is still under > > review, but I was expecting to have it ready in the next couple of > > days. That's my view. I'll let other Reviewers decide here. > > > > I would prefer we get this in to avoid it being pushed to 8u282, and > it also unblocks the other PKCS#11 fixes. Given it is pretty much ready, > going by your review, I see no reason to delay it further. > > New webrev: > > https://cr.openjdk.java.net/~andrew/openjdk8/8144539/webrev.02/ > > It would be easier to see what files conflict with the TLS 1.3 work if > the work was publicly visible. I don't yet see any changes in: > > https://hg.openjdk.java.net/jdk8u/jdk8u-jsse-incubator/jdk/ > > which is a little worrying for something you hope to have merged this > weekend. > > > Thanks, > > Martin.- > > > > Thanks, > -- > Andrew :) > > Senior 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 Ugh, forgot to attach the files! -- Andrew :) Senior 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 -------------- next part -------------- diff --git a/test/sun/security/pkcs11/tls/TestKeyMaterial.java b/test/sun/security/pkcs11/tls/TestKeyMaterial.java --- a/test/sun/security/pkcs11/tls/TestKeyMaterial.java +++ b/test/sun/security/pkcs11/tls/TestKeyMaterial.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2016, 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 @@ -27,37 +27,39 @@ * @summary Known-answer-test for TlsKeyMaterial generator * @author Andreas Sterbenz * @library .. + * @run main/othervm TestKeyMaterial + * @run main/othervm TestKeyMaterial sm policy */ -import java.io.*; -import java.util.*; - -import java.security.Security; +import java.io.BufferedReader; +import java.nio.file.Files; +import java.nio.file.Paths; import java.security.Provider; - +import java.util.Arrays; import javax.crypto.KeyGenerator; import javax.crypto.SecretKey; - -import javax.crypto.spec.*; - -import sun.security.internal.spec.*; +import javax.crypto.spec.IvParameterSpec; +import javax.crypto.spec.SecretKeySpec; +import sun.security.internal.spec.TlsKeyMaterialParameterSpec; +import sun.security.internal.spec.TlsKeyMaterialSpec; public class TestKeyMaterial extends PKCS11Test { - private static int PREFIX_LENGTH = "km-master: ".length(); + private static final int PREFIX_LENGTH = "km-master: ".length(); public static void main(String[] args) throws Exception { - main(new TestKeyMaterial()); + main(new TestKeyMaterial(), args); } + @Override public void main(Provider provider) throws Exception { if (provider.getService("KeyGenerator", "SunTlsKeyMaterial") == null) { System.out.println("Provider does not support algorithm, skipping"); return; } - InputStream in = new FileInputStream(new File(BASE, "keymatdata.txt")); - BufferedReader reader = new BufferedReader(new InputStreamReader(in)); + try (BufferedReader reader = Files.newBufferedReader( + Paths.get(BASE, "keymatdata.txt"))) { int n = 0; int lineNumber = 0; @@ -154,10 +156,10 @@ if (n == 0) { throw new Exception("no tests"); } - in.close(); System.out.println(); System.out.println("OK: " + n + " tests"); } + } private static void stripParity(byte[] b) { for (int i = 0; i < b.length; i++) { -------------- next part -------------- diff --git a/test/sun/security/pkcs11/tls/TestMasterSecret.java b/test/sun/security/pkcs11/tls/TestMasterSecret.java --- a/test/sun/security/pkcs11/tls/TestMasterSecret.java +++ b/test/sun/security/pkcs11/tls/TestMasterSecret.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2016, 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 @@ -27,37 +27,38 @@ * @summary Known-answer-test for TlsMasterSecret generator * @author Andreas Sterbenz * @library .. + * @run main/othervm TestMasterSecret + * @run main/othervm TestMasterSecret sm TestMasterSecret.policy */ -import java.io.*; -import java.util.*; - -import java.security.Security; +import java.io.BufferedReader; +import java.nio.file.Files; +import java.nio.file.Paths; import java.security.Provider; - +import java.util.Arrays; import javax.crypto.KeyGenerator; import javax.crypto.SecretKey; - -import javax.crypto.spec.*; - -import sun.security.internal.spec.*; +import javax.crypto.spec.SecretKeySpec; import sun.security.internal.interfaces.TlsMasterSecret; +import sun.security.internal.spec.TlsMasterSecretParameterSpec; public class TestMasterSecret extends PKCS11Test { - private static int PREFIX_LENGTH = "m-premaster: ".length(); + private static final int PREFIX_LENGTH = "m-premaster: ".length(); public static void main(String[] args) throws Exception { - main(new TestMasterSecret()); + main(new TestMasterSecret(), args); } + @Override public void main(Provider provider) throws Exception { if (provider.getService("KeyGenerator", "SunTlsMasterSecret") == null) { System.out.println("Not supported by provider, skipping"); return; } - InputStream in = new FileInputStream(new File(BASE, "masterdata.txt")); - BufferedReader reader = new BufferedReader(new InputStreamReader(in)); + + try (BufferedReader reader = Files.newBufferedReader( + Paths.get(BASE, "masterdata.txt"))) { int n = 0; int lineNumber = 0; @@ -129,9 +130,9 @@ if (n == 0) { throw new Exception("no tests"); } - in.close(); System.out.println(); System.out.println("OK: " + n + " tests"); } + } } -------------- next part -------------- diff --git a/test/sun/security/pkcs11/tls/TestPRF.java b/test/sun/security/pkcs11/tls/TestPRF.java --- a/test/sun/security/pkcs11/tls/TestPRF.java +++ b/test/sun/security/pkcs11/tls/TestPRF.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2016, 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 @@ -27,37 +27,37 @@ * @summary Basic known-answer-test for TlsPrf * @author Andreas Sterbenz * @library .. + * @run main/othervm TestPRF + * @run main/othervm TestPRF sm policy */ -import java.io.*; -import java.util.*; - -import java.security.Security; +import java.io.BufferedReader; +import java.nio.file.Files; +import java.nio.file.Paths; import java.security.Provider; - +import java.util.Arrays; import javax.crypto.KeyGenerator; import javax.crypto.SecretKey; - -import javax.crypto.spec.*; - -import sun.security.internal.spec.*; +import javax.crypto.spec.SecretKeySpec; +import sun.security.internal.spec.TlsPrfParameterSpec; public class TestPRF extends PKCS11Test { - private static int PREFIX_LENGTH = "prf-output: ".length(); + private static final int PREFIX_LENGTH = "prf-output: ".length(); public static void main(String[] args) throws Exception { - main(new TestPRF()); + main(new TestPRF(), args); } + @Override public void main(Provider provider) throws Exception { if (provider.getService("KeyGenerator", "SunTlsPrf") == null) { System.out.println("Provider does not support algorithm, skipping"); return; } - InputStream in = new FileInputStream(new File(BASE, "prfdata.txt")); - BufferedReader reader = new BufferedReader(new InputStreamReader(in)); + try (BufferedReader reader = Files.newBufferedReader( + Paths.get(BASE, "prfdata.txt"))) { int n = 0; int lineNumber = 0; @@ -134,9 +134,9 @@ if (n == 0) { throw new Exception("no tests"); } - in.close(); System.out.println(); System.out.println("OK: " + n + " tests"); } + } } From mbalao at redhat.com Tue Aug 25 18:17:21 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 25 Aug 2020 15:17:21 -0300 Subject: [8u] TLSv1.3 RFR: 8245472: Backport JDK-8038893 for TLSv1.3 In-Reply-To: References: <99606DDF-ABD2-4F94-9B6B-3C6CBA3E77E0@azul.com> <2165C249-6694-4BC7-AD5A-92D3337AA11C@azul.com> <0f3678a0-c53d-5101-9d56-61aa5d84ffb1@redhat.com> <669919ac-0dfb-3d43-39d8-4608363d43f7@redhat.com> Message-ID: <9d77a90a-823a-701c-2d08-4beacd9b7d23@redhat.com> Hi Alexey, On 6/5/20 12:14 PM, Martin Balao wrote: > On 6/5/20 3:17 AM, Alexey Bakhtin wrote: >> Please verify the update patch : >> http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245472/webrev.v3/ > > Hi, > > Step 5 (8245472) is the backport of 8038893 to JDK-8. > > Comments here [1] [2] [3] are part of this review. > > V3 looks good to me. > > Please hold-on before pushing until we review the whole series and the > JDK-8 maintainer approves the backport. > I've noticed that the changeset you sent me to push differs from the approved Webrev.03. The reason is apparently a rebase to include 8237592. I'm okay with the change but please let me know of these differences. Thanks, Martin.- From mbalao at redhat.com Tue Aug 25 18:22:07 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 25 Aug 2020 15:22:07 -0300 Subject: [8u] TLSv1.3 RFR: 8245472: Backport JDK-8038893 for TLSv1.3 In-Reply-To: <9d77a90a-823a-701c-2d08-4beacd9b7d23@redhat.com> References: <99606DDF-ABD2-4F94-9B6B-3C6CBA3E77E0@azul.com> <2165C249-6694-4BC7-AD5A-92D3337AA11C@azul.com> <0f3678a0-c53d-5101-9d56-61aa5d84ffb1@redhat.com> <669919ac-0dfb-3d43-39d8-4608363d43f7@redhat.com> <9d77a90a-823a-701c-2d08-4beacd9b7d23@redhat.com> Message-ID: On Tue, Aug 25, 2020 at 3:17 PM Martin Balao wrote: > I've noticed that the changeset you sent me to push differs from the > approved Webrev.03. The reason is apparently a rebase to include > 8237592. I'm okay with the change but please let me know of these > differences. Here we have what would have been Webrev.04: https://hg.openjdk.java.net/jdk8u/jdk8u-jsse-incubator/jdk/rev/b58fdaa80b5a Here it's the change, that includes 8237592: https://hg.openjdk.java.net/jdk8u/jdk8u-jsse-incubator/jdk/rev/b58fdaa80b5a#l3.68 From hohensee at amazon.com Tue Aug 25 20:28:26 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 25 Aug 2020 20:28:26 +0000 Subject: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument Message-ID: :) New webrevs following Volker's suggestion. http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.06/ http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.06/ Passes jdk/test/com/sun/management jdk/test/java/lang/management jdk/test/sun/management jdk/test/javax/management Paul ?On 8/21/20, 1:39 PM, "serguei.spitsyn at oracle.com" wrote: On 8/21/20 11:07, serguei.spitsyn at oracle.com wrote: > Hi Paul, Sorry, Volker, for using this "indirection". I hope, Paul redirected my "Hi" to you. :) Thanks, Serguei > > Thank you for explanation. > > Thanks, > Serguei > > > On 8/21/20 10:54, Volker Simonis wrote: >> On Thu, Aug 20, 2020 at 10:06 PM serguei.spitsyn at oracle.com >> wrote: >>> Hi Paul, >>> >>> I was also wondering if there is a compatibility risk involved with >>> the JMM_VERSION change. >>> So, thanks to Volker for asking these questions. >>> >>> One more question. >>> I do not see a backport of the >>> src/jdk.management/share/native/libmanagement_ext/management_ext.c >>> change. >>> Is it intentional, and if so, what is the reason to skip this file? >>> >> "libmanagement_ext/management_ext.c" doesn't exist in jdk8. It was >> introduced with "8042901: Allow com.sun.management to be in a >> different module to java.lang.management" in jdk9. In jdk8 all the >> functionality is in "management/management.h" so there's no need to >> backport the changes from "management_ext.c" . >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8042901 >> >>> Thanks, >>> Serguei >>> >>> >>> On 8/20/20 11:30, Volker Simonis wrote: >>> >>> On Wed, Aug 19, 2020 at 6:17 PM Hohensee, Paul >>> wrote: >>> >>> Please review this backport to jdk8u. I especially need a CSR >>> review, since the CSR approval process can be a bottleneck. The >>> patch significantly reduces fleet profiling overhead, and a version >>> of it has been in production at Amazon for over 3 years. >>> >>> >>> >>> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8185003 >>> >>> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 >>> >>> Original patch: >>> http://hg.openjdk.java.net/jdk10/master/rev/68d46cb9be45 >>> >>> >>> >>> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251494 >>> >>> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251498 >>> >>> Backport JDK webrev: >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.05/ >>> >>> JDK part looks good to me. >>> >>> Backport Hotspot webrev: >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.05/ >>> >>> HotSpot part looks good to me but see discussion below. >>> >>> >>> Details of the interface changes needed for the backport are in the >>> Description of the Backport CSR 8251498. The actual functional >>> changes are minimal and low risk. >>> >>> I've also reviewed the CSR yesterday which I think is fine. But now, >>> when looking at the implementation, I'm a little concerned about >>> changing JMM_VERSION from " 0x20010203" to "0x20020000" in "jmm.h". >>> >>> This might be especially problematic in combination with the changes >>> in "Management::get_jmm_interface()" which is called by >>> JVM_GetManagement(): >>> >>> void* Management::get_jmm_interface(int version) { >>> #if INCLUDE_MANAGEMENT >>> - if (version == JMM_VERSION_1_0) { >>> + if (version == JMM_VERSION) { >>> return (void*) &jmm_interface; >>> } >>> #endif // INCLUDE_MANAGEMENT >>> return NULL; >>> } >>> >>> You've correctly fixed the single caller of "JVM_GetManagement()" in >>> the JDK (in "JNI_OnLoad()" in "management.c"): >>> >>> - jmm_interface = (JmmInterface*) >>> JVM_GetManagement(JMM_VERSION_1_0); >>> + jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION); >>> >>> but I wonder if there are other monitoring/serviceability tools out >>> there which use this interface and which will break after this change. >>> A quick search revealed at least two StackOverflow entries which >>> recommend using "JVM_GetManagement(JMM_VERSION_1_0)" [1,2] and there's >>> a talk and a blog entry doing the same [3, 4]. >>> >>> I'm not sure how relevant this is but I think a much safer and >>> backwards-compatible way of doing this downport would be the >>> following: >>> >>> - don't change "Management::get_jmm_interface()" (i.e. still check for >>> "JMM_VERSION_1_0") but return the "new" JMM_VERSION in >>> "jmm_GetVersion()". This won't break anything but will make it >>> possible for clients to detect the new version if they want. >>> >>> - don't change the signature of "DumpThreads()". Instead add a new >>> version (e.g. "DumpThreadsMaxDepth()/jmm_DumpThreadsMaxDepth()") to >>> the "JMMInterface" struct and to "jmm_interface" in "management.cpp". >>> You can do this in one of the two first, reserved fields of >>> "JMMInterface" so you won't break binary compatibility. >>> "jmm_DumpThreads()" will then be a simple wrapper which calls >>> "jmm_DumpThreadsMaxDepth()" with Integer.MAX_VALUE as depth. >>> >>> - in the jdk you then simply call "DumpThreadsMaxDepth()" in >>> "Java_sun_management_ThreadImpl_dumpThreads0()" >>> >>> I think this way we can maintain full binary compatibility while still >>> using the new feature. What do you think? >>> >>> Best regards, >>> Volker >>> >>> [1] >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/23632653/generate-java-heap-dump-on-uncaught-exception__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-KqVsyaF$ >>> [2] >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/60887816/jvm-options-printnmtstatistics-save-info-to-file__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Ip7MAQ5$ >>> [3] >>> https://urldefense.com/v3/__https://sudonull.com/post/25841-JVM-TI-how-to-make-a-plugin-for-a-virtual-machine-Odnoklassniki-company-blog__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-ErSjPdD$ >>> [4] >>> https://urldefense.com/v3/__https://2019.jpoint.ru/talks/2o8scc5jbaurnqqlsydzxv/__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Oxb5CQ-$ >>> >>> Passes the included (suitably modified) test, as well as the tests in >>> >>> >>> >>> jdk/test/java/lang/management/ThreadMXBean >>> >>> jdk/test/com/sun/management/ThreadMXBean >>> >>> >>> >>> Thanks, >>> >>> Paul >>> >>> > From alexey at azul.com Tue Aug 25 20:37:09 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 25 Aug 2020 20:37:09 +0000 Subject: [8u] TLSv1.3 RFR: 8251478: Backport TLSv1.3 regression tests to JDK8u In-Reply-To: <23e5a655-e4f9-435c-669d-bb91c7ddc12d@redhat.com> References: <4E845CF2-E84F-413B-8193-64FD521BA647@azul.com> <529B5CE4-2055-4015-A6DD-1774E18D1C7A@azul.com> <23e5a655-e4f9-435c-669d-bb91c7ddc12d@redhat.com> Message-ID: <4C909CB2-4CC3-4C5F-BEAF-93FDE8D93228@azul.com> Hi Martin, Please find my comments below. New webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v2 Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v2/jdk.git.diff Regards Alexey > On 24 Aug 2020, at 19:20, Martin Balao wrote: > > Hi Alexey, > > On 8/19/20 10:44 AM, Alexey Bakhtin wrote: >> Please find updated version of the patch: >> Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v1 >> Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v1/jdk.git.diff >> >> This version contains updates for the MFLN Extension tests > > Thanks for proposing this patch. > > A few questions: > > * test/sun/security/ssl/SSLSocketImpl/SSLSocketKeyLimit.java > * 8u's equivalent of InputStream::readNBytes is IOUtils.readNBytes OK. Fixed. But actually, it does not matter How many bytes read from the stream in this particular case. > * Just out of curiosity, why 'main' method needs to throw Throwable > instead of Exception? I've seen this change in other tests too. In JDK8 jdk.testlibrary.ProcessTools.executeProcess() throws Throwable instead of Exception. This is a reason of this fix. > > * test/sun/security/ssl/internal/java.base/sun/security/ssl/TestHkdf.java > * > test/sun/security/ssl/Stapling/java.base/sun/security/ssl/StatusResponseManagerTests.java > * Why did you relocate these tests? I'd keep them in their original > location if possible. It was part of task to exclude modularisation dependencies. But you are right. It is not necessary. Reverted. > > * test/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java > * I've seen the jdk.test.lib.security.SecurityUtils import was removed > but looks to me that it's used. I might be overlooking something. > JDK8 already has SecurityUtils.java class in the test/lib/security directory. This class is in the unnamed package. So, Distrust.java is updated to use original SecurityUtils.java class > * MFLNTest tests > * I'd try something different, to minimize the number of changes. > Instead of having scripts that build a JAR and include the new > MaxPacketSize class in the sun.security.ssl package to access internal > fields; I'd only change SSLEngineTestCase::doHandshake method to set the > proper max packet size by means of reflection. > SSLEngineTestCase::doHandshake has to be edit anyways to reflect the > lack of an API to set the max fragment size. This approach should also > avoid a change in MFLNTest class. What do you think? Yes, you are right. Thank you. These tests could be simplified by using reflection. Fixed. > > Thanks, > Martin.- > From mbalao at redhat.com Tue Aug 25 21:49:36 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 25 Aug 2020 18:49:36 -0300 Subject: [RFR] [8u] 8144539: Update PKCS11 tests to run with security manager In-Reply-To: <20200825164629.GC969845@stopbrexit> References: <20200822014142.GE31221@stopbrexit> <20200825164629.GC969845@stopbrexit> Message-ID: On Tue, Aug 25, 2020 at 1:46 PM Andrew Hughes wrote: > New webrev: > > https://cr.openjdk.java.net/~andrew/openjdk8/8144539/webrev.02/ > Ok, looks good to me. > It would be easier to see what files conflict with the TLS 1.3 work if > the work was publicly visible. I don't yet see any changes in: > > https://hg.openjdk.java.net/jdk8u/jdk8u-jsse-incubator/jdk/ > > which is a little worrying for something you hope to have merged this > weekend. Step 0 to 14 pushed today: http://hg.openjdk.java.net/jdk8u/jdk8u-jsse-incubator/jdk Only Step missing: 15. I'm expecting to have it pushed later today -if no additional round-trips with the Developer are required- or tomorrow. From mbalao at redhat.com Tue Aug 25 22:22:43 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 25 Aug 2020 19:22:43 -0300 Subject: [8u] TLSv1.3 RFR: 8251478: Backport TLSv1.3 regression tests to JDK8u In-Reply-To: <4C909CB2-4CC3-4C5F-BEAF-93FDE8D93228@azul.com> References: <4E845CF2-E84F-413B-8193-64FD521BA647@azul.com> <529B5CE4-2055-4015-A6DD-1774E18D1C7A@azul.com> <23e5a655-e4f9-435c-669d-bb91c7ddc12d@redhat.com> <4C909CB2-4CC3-4C5F-BEAF-93FDE8D93228@azul.com> Message-ID: <866e2c80-30e9-e14a-c70e-8c5243fb69ea@redhat.com> On 8/25/20 5:37 PM, Alexey Bakhtin wrote: > New webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v2 > Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v2/jdk.git.diff >> * test/sun/security/ssl/SSLSocketImpl/SSLSocketKeyLimit.java >> * 8u's equivalent of InputStream::readNBytes is IOUtils.readNBytes > OK. Fixed. But actually, it does not matter How many bytes > read from the stream in this particular case. In this file you are not throwing "Throwable" anymore (diff between Webrev.01 and 02). Was that intended? >> * Just out of curiosity, why 'main' method needs to throw Throwable >> instead of Exception? I've seen this change in other tests too. > In JDK8 jdk.testlibrary.ProcessTools.executeProcess() throws Throwable instead of Exception. This is a reason of this fix. Ah, okay. >> >> * test/sun/security/ssl/internal/java.base/sun/security/ssl/TestHkdf.java >> * >> test/sun/security/ssl/Stapling/java.base/sun/security/ssl/StatusResponseManagerTests.java >> * Why did you relocate these tests? I'd keep them in their original >> location if possible. > It was part of task to exclude modularisation dependencies. But you are right. It is not necessary. Reverted. Ok. Thanks. >> >> * test/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java >> * I've seen the jdk.test.lib.security.SecurityUtils import was removed >> but looks to me that it's used. I might be overlooking something. >> > JDK8 already has SecurityUtils.java class in the test/lib/security directory. This class is in the unnamed package. So, Distrust.java is updated to use original SecurityUtils.java class > Ah, good. >> * MFLNTest tests >> * I'd try something different, to minimize the number of changes. >> Instead of having scripts that build a JAR and include the new >> MaxPacketSize class in the sun.security.ssl package to access internal >> fields; I'd only change SSLEngineTestCase::doHandshake method to set the >> proper max packet size by means of reflection. >> SSLEngineTestCase::doHandshake has to be edit anyways to reflect the >> lack of an API to set the max fragment size. This approach should also >> avoid a change in MFLNTest class. What do you think? > > Yes, you are right. Thank you. These tests could be simplified by using reflection. Fixed. Good! In test/sun/security/ssl/internal/TestRun.sh, you commented the line that removes the JAR file. Looks to me that you want to revert that change. I'll now run all the SSL-related tests and expect them to pass. Is that expectation correct? Let me know if there is any known failure. Thanks, Martin.- From gnu.andrew at redhat.com Wed Aug 26 02:06:20 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 26 Aug 2020 03:06:20 +0100 Subject: [RFR] [8u] 8144539: Update PKCS11 tests to run with security manager In-Reply-To: References: <20200822014142.GE31221@stopbrexit> <20200825164629.GC969845@stopbrexit> Message-ID: <20200826020620.GE969845@stopbrexit> On 18:49 Tue 25 Aug , Martin Balao wrote: > On Tue, Aug 25, 2020 at 1:46 PM Andrew Hughes wrote: > > New webrev: > > > > https://cr.openjdk.java.net/~andrew/openjdk8/8144539/webrev.02/ > > > > Ok, looks good to me. > Thanks. For the record, there were no test regressions. A common set of 11 tests was failing both before and after the patch: FAILED: sun/security/pkcs11/ec/ReadCertificates.java FAILED: sun/security/pkcs11/ec/ReadPKCS12.java FAILED: sun/security/pkcs11/ec/TestKeyFactory.java FAILED: sun/security/pkcs11/fips/TestTLS12.java FAILED: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh FAILED: sun/security/pkcs11/rsa/TestCACerts.java FAILED: sun/security/pkcs11/rsa/TestKeyPairGenerator.java FAILED: sun/security/pkcs11/Secmod/GetPrivateKey.java FAILED: sun/security/pkcs11/Secmod/JksSetPrivateKey.java FAILED: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java FAILED: sun/security/pkcs11/tls/TestKeyMaterial.java Some of these are due to missing curves in the system NSS. > > It would be easier to see what files conflict with the TLS 1.3 work if > > the work was publicly visible. I don't yet see any changes in: > > > > https://hg.openjdk.java.net/jdk8u/jdk8u-jsse-incubator/jdk/ > > > > which is a little worrying for something you hope to have merged this > > weekend. > > Step 0 to 14 pushed today: > http://hg.openjdk.java.net/jdk8u/jdk8u-jsse-incubator/jdk > > Only Step missing: 15. I'm expecting to have it pushed later today -if > no additional round-trips with the Developer are required- or > tomorrow. > This is good to hear. I'll try and have a look tomorrow. Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Wed Aug 26 03:38:40 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 26 Aug 2020 04:38:40 +0100 Subject: [8u] RFR(s): 8221342: [TESTBUG] Generate Dockerfile for docker testing In-Reply-To: <921a5acde361aa36cb840cc4ed4a9e3d1ecb29cc.camel@redhat.com> References: <921a5acde361aa36cb840cc4ed4a9e3d1ecb29cc.camel@redhat.com> Message-ID: <20200826033840.GF969845@stopbrexit> On 15:05 Tue 25 Aug , Severin Gehwolf wrote: > Hi! > > Please review this 8u backport of this test bug which enhances > container testing to automatically generate docker files. This is > useful if the development platform is not Oracle Linux 7.X (which is > the case for me). > > The JDK 11 patch applies cleanly (after JDK-8220313 which is in the > approval queue) I don't see how this can be said to apply cleanly. Attempting to shuffle the patch fails to find a mapping for test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java and test/lib/jdk/test/lib/containers/docker/DockerfileConfig.java. It is also beyond the scope of a script to know to duplicate these changes between two repositories. So this alone justifies a review. This is beyond the scope of this patch, but the proposed patch for the JDK tests seems wrong. We seem to have duplication in the JDK test tree, caused by the JFR backport. The jdk/test/lib/testlibrary/jdk/testlibrary/containers directory would be the correct location for these tests. The JFR backport seems to have started an alternate tree at jdk/test/lib/jdk/test/lib with duplication of some files in the former directory. This should be resolved in the 8u282 lifecycle. > but doesn't compile since Files.writeString() API is > not available in JDK 8. Replaced it with: > > byte[] bytes = dockerFileStr.getBytes(StandardCharsets.UTF_8); > Files.write(dockerfile, bytes); > Could this not be simplified to: Files.write(dockerfile, dockerFileStr.getBytes(StandardCharsets.UTF_8)); I don't see the need for the intermediate variable. Other changes look fine. Thanks, -- Andrew :) Senior 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 From alexey at azul.com Wed Aug 26 08:55:41 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 26 Aug 2020 08:55:41 +0000 Subject: [8u] TLSv1.3 RFR: 8251478: Backport TLSv1.3 regression tests to JDK8u In-Reply-To: <866e2c80-30e9-e14a-c70e-8c5243fb69ea@redhat.com> References: <4E845CF2-E84F-413B-8193-64FD521BA647@azul.com> <529B5CE4-2055-4015-A6DD-1774E18D1C7A@azul.com> <23e5a655-e4f9-435c-669d-bb91c7ddc12d@redhat.com> <4C909CB2-4CC3-4C5F-BEAF-93FDE8D93228@azul.com> <866e2c80-30e9-e14a-c70e-8c5243fb69ea@redhat.com> Message-ID: <202E4A8D-5476-46C9-A21A-FB9B7CDC93D3@azul.com> Hi Martin, Thank you for review. All tests should pass after this step. Webrev : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v3/ Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v3/jdk.git.diff Regards Alexey > On 26 Aug 2020, at 01:22, Martin Balao wrote: > >>> * test/sun/security/ssl/SSLSocketImpl/SSLSocketKeyLimit.java >>> * 8u's equivalent of InputStream::readNBytes is IOUtils.readNBytes >> OK. Fixed. But actually, it does not matter How many bytes >> read from the stream in this particular case. > > In this file you are not throwing "Throwable" anymore (diff between > Webrev.01 and 02). Was that intended? > Sorry, did not revert experimental change. Fixed > > Good! > > In test/sun/security/ssl/internal/TestRun.sh, you commented the line > that removes the JAR file. Looks to me that you want to revert that change. Good catch. Thank you. jar should be removed. Fixed. > > I'll now run all the SSL-related tests and expect them to pass. Is that > expectation correct? Let me know if there is any known failure. > > Thanks, > Martin.- > From jdowland at redhat.com Wed Aug 26 14:44:38 2020 From: jdowland at redhat.com (Jonathan Dowland) Date: Wed, 26 Aug 2020 15:44:38 +0100 Subject: [8u] RFR: 8229922: correct java.locale.provider to JRE for backported tests Message-ID: <20200826144438.wyurnjoev6cxr5qq@qusp> Hello, Please review the following webrev proposed for jdk8u. This fixes 6 of the backported tests identified as faulty for jdk8u in JDK-8229922: test/java/text/Format/DateFormat/DateFormatTest.java test/java/text/Format/ DateFormat/NonGregorianFormatTest.java test/java/text/Format/MessageFormat/LargeMessageFormat.java test/java/text/For mat/NumberFormat/NumberRegression.java test/java/text/Format/NumberFormat/NumberTest.java test/java/util/TimeZone/HongKong.java The "COMPAT" locale provider was introduced in JDK9 as a synonym for the "JRE" provider, which was deprecated. These tests declare a locale provider list including "COMPAT", the fix is changing them to "JRE". Bug: https://bugs.openjdk.java.net/browse/JDK-8229922 Webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/jdowland/JDK-8229922/ Thanks, -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat From sgehwolf at redhat.com Wed Aug 26 16:07:36 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 26 Aug 2020 18:07:36 +0200 Subject: [8u] RFR: 8229922: correct java.locale.provider to JRE for backported tests In-Reply-To: <20200826144438.wyurnjoev6cxr5qq@qusp> References: <20200826144438.wyurnjoev6cxr5qq@qusp> Message-ID: <0be37a45e3f7e528328ff54dd54d1f82c355976c.camel@redhat.com> Hi Jon, On Wed, 2020-08-26 at 15:44 +0100, Jonathan Dowland wrote: > Hello, > > Please review the following webrev proposed for jdk8u. This fixes 6 of the > backported tests identified as faulty for jdk8u in JDK-8229922: > > test/java/text/Format/DateFormat/DateFormatTest.java > test/java/text/Format/ DateFormat/NonGregorianFormatTest.java > test/java/text/Format/MessageFormat/LargeMessageFormat.java > test/java/text/For mat/NumberFormat/NumberRegression.java > test/java/text/Format/NumberFormat/NumberTest.java > test/java/util/TimeZone/HongKong.java Given that the proposed webrev fixes only part of the failing tests I'd suggest to split this one out into a separate bug and keep JDK-8229922 around as an umbrella bug. I've opened: https://bugs.openjdk.java.net/browse/JDK-8252384 > The "COMPAT" locale provider was introduced in JDK9 as a synonym for the "JRE" > provider, which was deprecated. These tests declare a locale provider list > including "COMPAT", the fix is changing them to "JRE". > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229922 > Webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/jdowland/JDK-8229922/ Lets continue review of this issue via 8252384. Note that RFR threads should follow the bug synopsis. So an RFR for 8252384 should have subject: [8u] RFR: 8252384: [TESTBUG] Some tests refer to COMPAT provider rather than JRE Thanks, Severin From aph at redhat.com Wed Aug 26 16:11:48 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Aug 2020 17:11:48 +0100 Subject: RFR Backport 8165808: Add release barriers when allocating objects with concurrent collection In-Reply-To: References: <0cbd336a-d3aa-daae-1a65-f8dafebe6ae9@redhat.com> Message-ID: <514e040c-52df-2b6d-8626-1d3a4156ce28@redhat.com> Hi, On 25/08/2020 13:53, Yangfei (Felix) wrote: > >> -----Original Message----- >> From: Andrew Haley [mailto:aph at redhat.com] >> Sent: Tuesday, August 25, 2020 5:18 PM >> To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net >> Subject: Re: RFR Backport 8165808: Add release barriers when allocating >> objects with concurrent collection >> >> On 25/08/2020 09:56, Yangfei (Felix) wrote: >>>> Yes, certainly. Thanks. >>> Thanks for quick review. >>> I have add new label jdk8u-fix-request and necessary comment on the >> issue. >> >> By the way, there are many places where arrays are allocated. Do you know >> why only this particular one needs a release barrier? > > Not sure if I understand the question correctly. > I think the common entry points are CollectedHeap::obj_allocate & CollectedHeap::array_allocate. These functions finally calls CollectedHeap::post_allocation_setup_common. > Many places will call these functions to create objects. For example, > InstanceKlass::allocate_objArray -> CollectedHeap::array_allocate -> CollectedHeap::post_allocation_setup_array -> CollectedHeap::post_allocation_setup_common > Since we do a release store in CollectedHeap::post_allocation_setup_common, so all the places where objects are created will benefit. There is code at MacroAssembler::eden_allocate and PhaseMacroExpand::expand_allocate_common which does object allocation. If CollectedHeap::obj_allocate needs release barriers, why don't those places need them too? Is there another patch which adds such release barriers that also needs to be backported? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Wed Aug 26 17:17:32 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Aug 2020 19:17:32 +0200 Subject: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument In-Reply-To: References: Message-ID: Hi Paul, thanks for adapting your change. Please find my comments in-line below: On Tue, Aug 25, 2020 at 10:28 PM Hohensee, Paul wrote: > > :) > > New webrevs following Volker's suggestion. > > http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.06/ Looks good except JNI_OnLoad() in "management.c" where I'd change the call to "JVM_GetManagement(JMM_VERSION)" back to "JVM_GetManagement(JMM_VERSION_1_0)". See discussion below... > http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.06/ > Looks good except Management::get_jmm_interface(): 2396 if (version == JMM_VERSION) { 2397 return (void*) &jmm_interface; 2398 } You still check for "JMM_VERSION" which is now "0x20020000" and thus incompatible with the old value of "JMM_VERSION_1 = 0x20010000". This will break compatibility with clients compiled against jmm.h before this change. It should therefore remain unchanged: if (version == JMM_VERSION_1_0) { return (void*) &jmm_interface; } I think the variant "if (version == JMM_VERSION_1_0 || version == JMM_VERSION)" which we've briefly discussed wouldn't work either because a binary "JMM_VERSION_2" client would expect that "DumpThreads" will have the additional "maxDepths" argument and crash. So we can't have binary compatibility with both, old jdk8 clients and new jdk11 clients. Therefore, contrary to my previous mail, I'd also change "jmm_GetVersion()" to return the "old" JMM VERSION (i.e "0x20010203") because that's really the only one we're compatible with. In fact, this makes the whole addition of "JMM_VERSION_2" questionable, because after the proposed changes it wouldn't be used anymore. And after reasoning about it a little more, I think that's correct because we really only have binary compatibility with previous jdk8 clients and that's how it should be. Thank you and best regards, Volker > Passes > > jdk/test/com/sun/management > jdk/test/java/lang/management > jdk/test/sun/management > jdk/test/javax/management > > Paul > > ?On 8/21/20, 1:39 PM, "serguei.spitsyn at oracle.com" wrote: > > On 8/21/20 11:07, serguei.spitsyn at oracle.com wrote: > > Hi Paul, > > Sorry, Volker, for using this "indirection". > I hope, Paul redirected my "Hi" to you. :) > > Thanks, > Serguei > > > > > Thank you for explanation. > > > > Thanks, > > Serguei > > > > > > On 8/21/20 10:54, Volker Simonis wrote: > >> On Thu, Aug 20, 2020 at 10:06 PM serguei.spitsyn at oracle.com > >> wrote: > >>> Hi Paul, > >>> > >>> I was also wondering if there is a compatibility risk involved with > >>> the JMM_VERSION change. > >>> So, thanks to Volker for asking these questions. > >>> > >>> One more question. > >>> I do not see a backport of the > >>> src/jdk.management/share/native/libmanagement_ext/management_ext.c > >>> change. > >>> Is it intentional, and if so, what is the reason to skip this file? > >>> > >> "libmanagement_ext/management_ext.c" doesn't exist in jdk8. It was > >> introduced with "8042901: Allow com.sun.management to be in a > >> different module to java.lang.management" in jdk9. In jdk8 all the > >> functionality is in "management/management.h" so there's no need to > >> backport the changes from "management_ext.c" . > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8042901 > >> > >>> Thanks, > >>> Serguei > >>> > >>> > >>> On 8/20/20 11:30, Volker Simonis wrote: > >>> > >>> On Wed, Aug 19, 2020 at 6:17 PM Hohensee, Paul > >>> wrote: > >>> > >>> Please review this backport to jdk8u. I especially need a CSR > >>> review, since the CSR approval process can be a bottleneck. The > >>> patch significantly reduces fleet profiling overhead, and a version > >>> of it has been in production at Amazon for over 3 years. > >>> > >>> > >>> > >>> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8185003 > >>> > >>> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 > >>> > >>> Original patch: > >>> http://hg.openjdk.java.net/jdk10/master/rev/68d46cb9be45 > >>> > >>> > >>> > >>> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251494 > >>> > >>> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251498 > >>> > >>> Backport JDK webrev: > >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.05/ > >>> > >>> JDK part looks good to me. > >>> > >>> Backport Hotspot webrev: > >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.05/ > >>> > >>> HotSpot part looks good to me but see discussion below. > >>> > >>> > >>> Details of the interface changes needed for the backport are in the > >>> Description of the Backport CSR 8251498. The actual functional > >>> changes are minimal and low risk. > >>> > >>> I've also reviewed the CSR yesterday which I think is fine. But now, > >>> when looking at the implementation, I'm a little concerned about > >>> changing JMM_VERSION from " 0x20010203" to "0x20020000" in "jmm.h". > >>> > >>> This might be especially problematic in combination with the changes > >>> in "Management::get_jmm_interface()" which is called by > >>> JVM_GetManagement(): > >>> > >>> void* Management::get_jmm_interface(int version) { > >>> #if INCLUDE_MANAGEMENT > >>> - if (version == JMM_VERSION_1_0) { > >>> + if (version == JMM_VERSION) { > >>> return (void*) &jmm_interface; > >>> } > >>> #endif // INCLUDE_MANAGEMENT > >>> return NULL; > >>> } > >>> > >>> You've correctly fixed the single caller of "JVM_GetManagement()" in > >>> the JDK (in "JNI_OnLoad()" in "management.c"): > >>> > >>> - jmm_interface = (JmmInterface*) > >>> JVM_GetManagement(JMM_VERSION_1_0); > >>> + jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION); > >>> > >>> but I wonder if there are other monitoring/serviceability tools out > >>> there which use this interface and which will break after this change. > >>> A quick search revealed at least two StackOverflow entries which > >>> recommend using "JVM_GetManagement(JMM_VERSION_1_0)" [1,2] and there's > >>> a talk and a blog entry doing the same [3, 4]. > >>> > >>> I'm not sure how relevant this is but I think a much safer and > >>> backwards-compatible way of doing this downport would be the > >>> following: > >>> > >>> - don't change "Management::get_jmm_interface()" (i.e. still check for > >>> "JMM_VERSION_1_0") but return the "new" JMM_VERSION in > >>> "jmm_GetVersion()". This won't break anything but will make it > >>> possible for clients to detect the new version if they want. > >>> > >>> - don't change the signature of "DumpThreads()". Instead add a new > >>> version (e.g. "DumpThreadsMaxDepth()/jmm_DumpThreadsMaxDepth()") to > >>> the "JMMInterface" struct and to "jmm_interface" in "management.cpp". > >>> You can do this in one of the two first, reserved fields of > >>> "JMMInterface" so you won't break binary compatibility. > >>> "jmm_DumpThreads()" will then be a simple wrapper which calls > >>> "jmm_DumpThreadsMaxDepth()" with Integer.MAX_VALUE as depth. > >>> > >>> - in the jdk you then simply call "DumpThreadsMaxDepth()" in > >>> "Java_sun_management_ThreadImpl_dumpThreads0()" > >>> > >>> I think this way we can maintain full binary compatibility while still > >>> using the new feature. What do you think? > >>> > >>> Best regards, > >>> Volker > >>> > >>> [1] > >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/23632653/generate-java-heap-dump-on-uncaught-exception__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-KqVsyaF$ > >>> [2] > >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/60887816/jvm-options-printnmtstatistics-save-info-to-file__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Ip7MAQ5$ > >>> [3] > >>> https://urldefense.com/v3/__https://sudonull.com/post/25841-JVM-TI-how-to-make-a-plugin-for-a-virtual-machine-Odnoklassniki-company-blog__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-ErSjPdD$ > >>> [4] > >>> https://urldefense.com/v3/__https://2019.jpoint.ru/talks/2o8scc5jbaurnqqlsydzxv/__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Oxb5CQ-$ > >>> > >>> Passes the included (suitably modified) test, as well as the tests in > >>> > >>> > >>> > >>> jdk/test/java/lang/management/ThreadMXBean > >>> > >>> jdk/test/com/sun/management/ThreadMXBean > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Paul > >>> > >>> > > > > From hohensee at amazon.com Wed Aug 26 19:19:20 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 26 Aug 2020 19:19:20 +0000 Subject: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument Message-ID: +Joe for an opinion. I agree. I've added a comment to the CSR (https://bugs.openjdk.java.net/browse/JDK-8251498) and moved it back to Draft. "Volker Simonis has pointed out in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012557.html that when we backport a JMM feature, we're actually updating the existing JMM version specification rather than transitioning to a new one. There was a bit of recognition of this in https://bugs.openjdk.java.net/browse/JDK-8249101, where the @since javadoc tag was updated to 11.0.9 rather than 14. Imo, Volker makes a good argument for leaving the JMM version alone when doing JMM backports. If we adopt this approach, the JDK 11 JMM version should also be reverted." Thanks, Paul ?On 8/26/20, 10:18 AM, "Volker Simonis" wrote: Hi Paul, thanks for adapting your change. Please find my comments in-line below: On Tue, Aug 25, 2020 at 10:28 PM Hohensee, Paul wrote: > > :) > > New webrevs following Volker's suggestion. > > http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.06/ Looks good except JNI_OnLoad() in "management.c" where I'd change the call to "JVM_GetManagement(JMM_VERSION)" back to "JVM_GetManagement(JMM_VERSION_1_0)". See discussion below... > http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.06/ > Looks good except Management::get_jmm_interface(): 2396 if (version == JMM_VERSION) { 2397 return (void*) &jmm_interface; 2398 } You still check for "JMM_VERSION" which is now "0x20020000" and thus incompatible with the old value of "JMM_VERSION_1 = 0x20010000". This will break compatibility with clients compiled against jmm.h before this change. It should therefore remain unchanged: if (version == JMM_VERSION_1_0) { return (void*) &jmm_interface; } I think the variant "if (version == JMM_VERSION_1_0 || version == JMM_VERSION)" which we've briefly discussed wouldn't work either because a binary "JMM_VERSION_2" client would expect that "DumpThreads" will have the additional "maxDepths" argument and crash. So we can't have binary compatibility with both, old jdk8 clients and new jdk11 clients. Therefore, contrary to my previous mail, I'd also change "jmm_GetVersion()" to return the "old" JMM VERSION (i.e "0x20010203") because that's really the only one we're compatible with. In fact, this makes the whole addition of "JMM_VERSION_2" questionable, because after the proposed changes it wouldn't be used anymore. And after reasoning about it a little more, I think that's correct because we really only have binary compatibility with previous jdk8 clients and that's how it should be. Thank you and best regards, Volker > Passes > > jdk/test/com/sun/management > jdk/test/java/lang/management > jdk/test/sun/management > jdk/test/javax/management > > Paul > > On 8/21/20, 1:39 PM, "serguei.spitsyn at oracle.com" wrote: > > On 8/21/20 11:07, serguei.spitsyn at oracle.com wrote: > > Hi Paul, > > Sorry, Volker, for using this "indirection". > I hope, Paul redirected my "Hi" to you. :) > > Thanks, > Serguei > > > > > Thank you for explanation. > > > > Thanks, > > Serguei > > > > > > On 8/21/20 10:54, Volker Simonis wrote: > >> On Thu, Aug 20, 2020 at 10:06 PM serguei.spitsyn at oracle.com > >> wrote: > >>> Hi Paul, > >>> > >>> I was also wondering if there is a compatibility risk involved with > >>> the JMM_VERSION change. > >>> So, thanks to Volker for asking these questions. > >>> > >>> One more question. > >>> I do not see a backport of the > >>> src/jdk.management/share/native/libmanagement_ext/management_ext.c > >>> change. > >>> Is it intentional, and if so, what is the reason to skip this file? > >>> > >> "libmanagement_ext/management_ext.c" doesn't exist in jdk8. It was > >> introduced with "8042901: Allow com.sun.management to be in a > >> different module to java.lang.management" in jdk9. In jdk8 all the > >> functionality is in "management/management.h" so there's no need to > >> backport the changes from "management_ext.c" . > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8042901 > >> > >>> Thanks, > >>> Serguei > >>> > >>> > >>> On 8/20/20 11:30, Volker Simonis wrote: > >>> > >>> On Wed, Aug 19, 2020 at 6:17 PM Hohensee, Paul > >>> wrote: > >>> > >>> Please review this backport to jdk8u. I especially need a CSR > >>> review, since the CSR approval process can be a bottleneck. The > >>> patch significantly reduces fleet profiling overhead, and a version > >>> of it has been in production at Amazon for over 3 years. > >>> > >>> > >>> > >>> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8185003 > >>> > >>> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 > >>> > >>> Original patch: > >>> http://hg.openjdk.java.net/jdk10/master/rev/68d46cb9be45 > >>> > >>> > >>> > >>> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251494 > >>> > >>> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251498 > >>> > >>> Backport JDK webrev: > >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.05/ > >>> > >>> JDK part looks good to me. > >>> > >>> Backport Hotspot webrev: > >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.05/ > >>> > >>> HotSpot part looks good to me but see discussion below. > >>> > >>> > >>> Details of the interface changes needed for the backport are in the > >>> Description of the Backport CSR 8251498. The actual functional > >>> changes are minimal and low risk. > >>> > >>> I've also reviewed the CSR yesterday which I think is fine. But now, > >>> when looking at the implementation, I'm a little concerned about > >>> changing JMM_VERSION from " 0x20010203" to "0x20020000" in "jmm.h". > >>> > >>> This might be especially problematic in combination with the changes > >>> in "Management::get_jmm_interface()" which is called by > >>> JVM_GetManagement(): > >>> > >>> void* Management::get_jmm_interface(int version) { > >>> #if INCLUDE_MANAGEMENT > >>> - if (version == JMM_VERSION_1_0) { > >>> + if (version == JMM_VERSION) { > >>> return (void*) &jmm_interface; > >>> } > >>> #endif // INCLUDE_MANAGEMENT > >>> return NULL; > >>> } > >>> > >>> You've correctly fixed the single caller of "JVM_GetManagement()" in > >>> the JDK (in "JNI_OnLoad()" in "management.c"): > >>> > >>> - jmm_interface = (JmmInterface*) > >>> JVM_GetManagement(JMM_VERSION_1_0); > >>> + jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION); > >>> > >>> but I wonder if there are other monitoring/serviceability tools out > >>> there which use this interface and which will break after this change. > >>> A quick search revealed at least two StackOverflow entries which > >>> recommend using "JVM_GetManagement(JMM_VERSION_1_0)" [1,2] and there's > >>> a talk and a blog entry doing the same [3, 4]. > >>> > >>> I'm not sure how relevant this is but I think a much safer and > >>> backwards-compatible way of doing this downport would be the > >>> following: > >>> > >>> - don't change "Management::get_jmm_interface()" (i.e. still check for > >>> "JMM_VERSION_1_0") but return the "new" JMM_VERSION in > >>> "jmm_GetVersion()". This won't break anything but will make it > >>> possible for clients to detect the new version if they want. > >>> > >>> - don't change the signature of "DumpThreads()". Instead add a new > >>> version (e.g. "DumpThreadsMaxDepth()/jmm_DumpThreadsMaxDepth()") to > >>> the "JMMInterface" struct and to "jmm_interface" in "management.cpp". > >>> You can do this in one of the two first, reserved fields of > >>> "JMMInterface" so you won't break binary compatibility. > >>> "jmm_DumpThreads()" will then be a simple wrapper which calls > >>> "jmm_DumpThreadsMaxDepth()" with Integer.MAX_VALUE as depth. > >>> > >>> - in the jdk you then simply call "DumpThreadsMaxDepth()" in > >>> "Java_sun_management_ThreadImpl_dumpThreads0()" > >>> > >>> I think this way we can maintain full binary compatibility while still > >>> using the new feature. What do you think? > >>> > >>> Best regards, > >>> Volker > >>> > >>> [1] > >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/23632653/generate-java-heap-dump-on-uncaught-exception__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-KqVsyaF$ > >>> [2] > >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/60887816/jvm-options-printnmtstatistics-save-info-to-file__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Ip7MAQ5$ > >>> [3] > >>> https://urldefense.com/v3/__https://sudonull.com/post/25841-JVM-TI-how-to-make-a-plugin-for-a-virtual-machine-Odnoklassniki-company-blog__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-ErSjPdD$ > >>> [4] > >>> https://urldefense.com/v3/__https://2019.jpoint.ru/talks/2o8scc5jbaurnqqlsydzxv/__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Oxb5CQ-$ > >>> > >>> Passes the included (suitably modified) test, as well as the tests in > >>> > >>> > >>> > >>> jdk/test/java/lang/management/ThreadMXBean > >>> > >>> jdk/test/com/sun/management/ThreadMXBean > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Paul > >>> > >>> > > > > From felix.yang at huawei.com Thu Aug 27 03:20:43 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 27 Aug 2020 03:20:43 +0000 Subject: RFR Backport 8165808: Add release barriers when allocating objects with concurrent collection In-Reply-To: <514e040c-52df-2b6d-8626-1d3a4156ce28@redhat.com> References: <0cbd336a-d3aa-daae-1a65-f8dafebe6ae9@redhat.com> <514e040c-52df-2b6d-8626-1d3a4156ce28@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Thursday, August 27, 2020 12:12 AM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: RFR Backport 8165808: Add release barriers when allocating > objects with concurrent collection Cut ... > >> > >> By the way, there are many places where arrays are allocated. Do you > >> know why only this particular one needs a release barrier? > > > > Not sure if I understand the question correctly. > > I think the common entry points are CollectedHeap::obj_allocate & > CollectedHeap::array_allocate. These functions finally calls > CollectedHeap::post_allocation_setup_common. > > Many places will call these functions to create objects. For example, > > InstanceKlass::allocate_objArray -> CollectedHeap::array_allocate -> > > CollectedHeap::post_allocation_setup_array -> > > CollectedHeap::post_allocation_setup_common > > Since we do a release store in > CollectedHeap::post_allocation_setup_common, so all the places where > objects are created will benefit. > > There is code at MacroAssembler::eden_allocate and > PhaseMacroExpand::expand_allocate_common which does object allocation. > If CollectedHeap::obj_allocate needs release barriers, why don't those places > need them too? Is there another patch which adds such release barriers that > also needs to be backported? That's a good question. I checked the latest jdk/jdk repo and looks like the barrier is not there too. One of the code path looks like: TemplateTable::_new -> MacroAssembler::eden_allocate Consider the fast path in TemplateTable::_new, we do a plain store for klass: 3622 // initialize object header only. 3623 __ bind(initialize_header); 3624 if (UseBiasedLocking) { 3625 __ ldr(rscratch1, Address(r4, Klass::prototype_header_offset())); 3626 } else { 3627 __ mov(rscratch1, (intptr_t)markWord::prototype().value()); 3628 } 3629 __ str(rscratch1, Address(r0, oopDesc::mark_offset_in_bytes())); 3630 __ store_klass_gap(r0, zr); // zero klass gap for compressed oops 3631 __ store_klass(r0, r4); // store klass last <============== Looking at MacroAssembler::store_klass, the same question has been raised early before. 3780 void MacroAssembler::store_klass(Register dst, Register src) { 3781 // FIXME: Should this be a store release? concurrent gcs assumes 3782 // klass length is valid if klass field is not null. 3783 if (UseCompressedClassPointers) { 3784 encode_klass_not_null(src); 3785 strw(src, Address(dst, oopDesc::klass_offset_in_bytes())); 3786 } else { 3787 str(src, Address(dst, oopDesc::klass_offset_in_bytes())); 3788 } 3789 } But the slow path in TemplateTable::_new is different. The call chain looks like: InterpreterRuntime::_new -> InstanceKlass::allocate_instance -> CollectedHeap::obj_allocate -> MemAllocator::allocate -> ObjAllocator::initialize -> MemAllocator::finish -> oopDesc::release_set_klass I don't see a reason why the barrier is not necessary for the fast path. There is a similar issue for PhaseMacroExpand::expand_allocate_common: fast path and slow path are different on the storing of klass. Also C1 uses a plain store for klass too in C1_MacroAssembler::initialize_header. I'm more inclined to think these code paths are missed by the original patch, but that need confirmation. Thanks, Felix From mbalao at redhat.com Thu Aug 27 03:57:29 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 27 Aug 2020 00:57:29 -0300 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <20200806025408.GB318498@stopbrexit> References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com> <3e49958c-f1dc-036d-0edf-e4218dee0cbd@redhat.com> <560d6c0a-1b02-9ae6-65dc-ccc7cd740cf5@redhat.com> <539a1f4f-9e9a-eb71-5980-6f278a58ba16@redhat.com> <20200806025408.GB318498@stopbrexit> Message-ID: <73e7e53d-8eef-a8b1-f978-8c386e244701@redhat.com> Hi, I'd like to propose Webrev.03: * http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.03/ Webrev.03 changes (in comparison to Webrev.01): * Reverted the removal of the 'args' argument in every PKCS11 test (now that 8144539 is in 8u). * test/sun/security/pkcs11/MessageDigest/ByteBuffers.java * Copyright date ends in 2016 before applying the patch because 8144539 is now in 8u and was the latest to update that line. * Hook #2 does not apply cleanly because of 8165689 is not in 8u * Needed to remove "@modules" line from hook and one '*' character from the beginning of the comment * 8165689 is about module dependencies on tests and does not apply to 8u * Hook #3 now applies cleanly because 8144539 is in 8u Testing: * No regressions observed in sun/security/pkcs11 category Thanks, Martin.- From hubert.debordeaux at thalesgroup.com Thu Aug 27 09:26:09 2020 From: hubert.debordeaux at thalesgroup.com (DEBORDEAUX Hubert) Date: Thu, 27 Aug 2020 09:26:09 +0000 Subject: SunPKCS11 connection lost after Decrypt doFinal In-Reply-To: <14993a7d-4f12-35df-50b8-bc5d9b3e7a90@redhat.com> References: <115412fa-7001-feb3-b4d7-e92d64790792@redhat.com> <073918b1-75d1-305e-5054-c663aa360306@oracle.com> <14993a7d-4f12-35df-50b8-bc5d9b3e7a90@redhat.com> Message-ID: Hello, Any news regarding backporting of 8236512 ? Regards, Hubert -----Original Message----- From: jdk8u-dev On Behalf Of Andrew Hughes Sent: Thursday, June 18, 2020 18:49 To: Valerie Peng ; jdk8u-dev at openjdk.java.net Subject: Re: SunPKCS11 connection lost after Decrypt doFinal On 17/06/2020 05:24, Valerie Peng wrote: > Well, JDK-8235215 is relevant to JDK-6946830 but not a duplicate of it. > > I should have added a duplicate-of-issue link to make it clear - > JDK-8235215 is closed as a duplicate of JDK-8236512. > > Sorry for the confusion and hope all is clear now. > > Thanks, > Valerie > Thanks, Valerie. Yes, it is now. I'll look into backporting 8236512. -- Andrew :) Senior Free Java Software Engineer 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 From jdowland at redhat.com Thu Aug 27 15:06:06 2020 From: jdowland at redhat.com (Jonathan Dowland) Date: Thu, 27 Aug 2020 16:06:06 +0100 Subject: [8u] RFR: 8252384: [TESTBUG] Some tests refer to COMPAT provider rather than JRE Message-ID: <20200827150606.bluinrxlprzpdoe2@qusp> Hello again, Please review the following webrev proposed for jdk8u. This fixes 6 backported tests which reference a locale provider name invalid under jdk8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8252384 Webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/jdowland/JDK-8252384/ Thanks, -- Jonathan Dowland From neugens at redhat.com Thu Aug 27 16:21:10 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 27 Aug 2020 18:21:10 +0200 Subject: [RFR] [8u] 8251120: HotSpot build assumes ENABLE_JFR is set to either true or false In-Reply-To: <20200822023628.GB126018@stopbrexit> References: <20200822023628.GB126018@stopbrexit> Message-ID: Looks good to me! Cheers, Mario On Sat, Aug 22, 2020 at 4:41 AM Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251120 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8251120/webrev.01/ > > The HotSpot build on *nix systems currently assumes that ENABLE_JFR is > set to either true or false. This is the case when the HotSpot build > is invoked via the configure build system, but not otherwise, as > nothing in the Makefiles actually sets it. > > A simple fix is to invert the tests for false, so only true is checked > for, and false and undefined are assumed to be the same. Windows > already only checks for true, so no changes are needed there. > > Ok for 8u? > > Thanks, > -- > Andrew :) > > Senior 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 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Thu Aug 27 16:46:16 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Aug 2020 17:46:16 +0100 Subject: [RFR] [8u] 8251120: HotSpot build assumes ENABLE_JFR is set to either true or false In-Reply-To: References: <20200822023628.GB126018@stopbrexit> Message-ID: <20200827164616.GD1117958@stopbrexit> On 18:21 Thu 27 Aug , Mario Torre wrote: > Looks good to me! > > Cheers, > Mario > > > On Sat, Aug 22, 2020 at 4:41 AM Andrew Hughes wrote: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251120 > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8251120/webrev.01/ > > > > The HotSpot build on *nix systems currently assumes that ENABLE_JFR is > > set to either true or false. This is the case when the HotSpot build > > is invoked via the configure build system, but not otherwise, as > > nothing in the Makefiles actually sets it. > > > > A simple fix is to invert the tests for false, so only true is checked > > for, and false and undefined are assumed to be the same. Windows > > already only checks for true, so no changes are needed there. > > > > Ok for 8u? > > > > Thanks, > > -- > > Andrew :) > > > > Senior 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 > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > Thanks! Flagged for approval. Cheers, -- Andrew :) Senior 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 From mbalao at redhat.com Thu Aug 27 19:36:37 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 27 Aug 2020 16:36:37 -0300 Subject: [8u] TLSv1.3 RFR: 8251478: Backport TLSv1.3 regression tests to JDK8u In-Reply-To: <202E4A8D-5476-46C9-A21A-FB9B7CDC93D3@azul.com> References: <4E845CF2-E84F-413B-8193-64FD521BA647@azul.com> <529B5CE4-2055-4015-A6DD-1774E18D1C7A@azul.com> <23e5a655-e4f9-435c-669d-bb91c7ddc12d@redhat.com> <4C909CB2-4CC3-4C5F-BEAF-93FDE8D93228@azul.com> <866e2c80-30e9-e14a-c70e-8c5243fb69ea@redhat.com> <202E4A8D-5476-46C9-A21A-FB9B7CDC93D3@azul.com> Message-ID: <037f073c-0fe9-16fd-265e-d0c5bdff24cf@redhat.com> Hi Alexey, On 8/26/20 5:55 AM, Alexey Bakhtin wrote: > Hi Martin, > > Thank you for review. > All tests should pass after this step. > Webrev : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v3/ > Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v3/jdk.git.diff > Regarding tests regressions, I've observed the following: * sun/security/pkcs11/fips/ClientJSSEServerJSSE.java * Passes in 11.0.7 but fails in jdk8u272-b01 (old SunJSSE engine) and in jdk8u272-b01 with the new SunJSSE engine (Step 15 - webrev.02) * It's an 'ignore' for 8u but don't we want to update this test with JDK-11.0.7 changes? It should be passing with the new SunJSSE engine. No regressions observed in the other SSL-related test categories. So the previous seems to be the only blocker for approving Step 15 now. Thanks, Martin.- From alexey at azul.com Thu Aug 27 20:33:16 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 27 Aug 2020 20:33:16 +0000 Subject: [8u] TLSv1.3 RFR: 8251478: Backport TLSv1.3 regression tests to JDK8u In-Reply-To: <037f073c-0fe9-16fd-265e-d0c5bdff24cf@redhat.com> References: <4E845CF2-E84F-413B-8193-64FD521BA647@azul.com> <529B5CE4-2055-4015-A6DD-1774E18D1C7A@azul.com> <23e5a655-e4f9-435c-669d-bb91c7ddc12d@redhat.com> <4C909CB2-4CC3-4C5F-BEAF-93FDE8D93228@azul.com> <866e2c80-30e9-e14a-c70e-8c5243fb69ea@redhat.com> <202E4A8D-5476-46C9-A21A-FB9B7CDC93D3@azul.com> <037f073c-0fe9-16fd-265e-d0c5bdff24cf@redhat.com> Message-ID: <802EB691-4D3D-44F2-95E9-2A3FE672FA86@azul.com> Hi Martin, You are right. Thank you. test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java test can be enabled now. Fixed by removing @ignore annotation. New Webrev : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v4/ Regards Alexey > On 27 Aug 2020, at 22:36, Martin Balao wrote: > > Hi Alexey, > > On 8/26/20 5:55 AM, Alexey Bakhtin wrote: >> Hi Martin, >> >> Thank you for review. >> All tests should pass after this step. >> Webrev : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v3/ >> Git diff: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v3/jdk.git.diff >> > Regarding tests regressions, I've observed the following: > > * sun/security/pkcs11/fips/ClientJSSEServerJSSE.java > * Passes in 11.0.7 but fails in jdk8u272-b01 (old SunJSSE engine) and > in jdk8u272-b01 with the new SunJSSE engine (Step 15 - webrev.02) > * It's an 'ignore' for 8u but don't we want to update this test with > JDK-11.0.7 changes? It should be passing with the new SunJSSE engine. > > No regressions observed in the other SSL-related test categories. So the > previous seems to be the only blocker for approving Step 15 now. > > Thanks, > Martin.- > From mbalao at redhat.com Thu Aug 27 20:53:23 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 27 Aug 2020 17:53:23 -0300 Subject: [8u] TLSv1.3 RFR: 8251478: Backport TLSv1.3 regression tests to JDK8u In-Reply-To: <802EB691-4D3D-44F2-95E9-2A3FE672FA86@azul.com> References: <4E845CF2-E84F-413B-8193-64FD521BA647@azul.com> <529B5CE4-2055-4015-A6DD-1774E18D1C7A@azul.com> <23e5a655-e4f9-435c-669d-bb91c7ddc12d@redhat.com> <4C909CB2-4CC3-4C5F-BEAF-93FDE8D93228@azul.com> <866e2c80-30e9-e14a-c70e-8c5243fb69ea@redhat.com> <202E4A8D-5476-46C9-A21A-FB9B7CDC93D3@azul.com> <037f073c-0fe9-16fd-265e-d0c5bdff24cf@redhat.com> <802EB691-4D3D-44F2-95E9-2A3FE672FA86@azul.com> Message-ID: Hi, On 8/27/20 5:33 PM, Alexey Bakhtin wrote: > You are right. Thank you. > test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java test can be enabled now. Fixed by removing @ignore annotation. > > New Webrev : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8251478/webrev.v4/ > Step 15 - 8251478 has a set of changes required for tests from JDK 11.0.7 to pass in 8u and jtreg '@modules' tags removed (which are N/A for 8u). * test/javax/net/ssl/FixingJavadocs/ComURLNulls.java (modified) * Ok. 8074531 is not in 8u. This change reverts to the previous test getServerCertificateChain use and removes the modules jtreg header. * test/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java (modified) * Ok * test/javax/net/ssl/SSLSession/RenegotiateTLS13.java (modified) * Ok * test/javax/net/ssl/SSLSession/ResumeTLS13withSNI.java (modified) * Ok * test/javax/net/ssl/SSLSocket/InputStreamClosure.java (modified) * Ok * test/javax/net/ssl/SSLSocket/OutputStreamClosure.java (modified) * Ok * test/javax/net/ssl/SSLSocket/Tls13PacketSize.java (modified) * Ok * test/javax/net/ssl/Stapling/HttpsUrlConnClient.java (modified) * Ok * test/javax/net/ssl/Stapling/SSLEngineWithStapling.java (modified) * Ok * test/javax/net/ssl/Stapling/SSLSocketWithStapling.java (modified) * Ok * test/javax/net/ssl/Stapling/StapleEnableProps.java (modified) * Ok * test/javax/net/ssl/TLS/TLSClientPropertyTest.java (modified) * Ok, TLSv1.3 is disabled by default for clients * test/javax/net/ssl/TLS/TLSDataExchangeTest.java (modified) * Ok * test/javax/net/ssl/TLS/TLSEnginesClosureTest.java (modified) * Ok * test/javax/net/ssl/TLS/TLSHandshakeTest.java (modified) * Ok * test/javax/net/ssl/TLS/TLSMFLNTest.java (modified) * Ok * test/javax/net/ssl/TLS/TLSNotEnabledRC4Test.java (modified) * Ok * test/javax/net/ssl/TLS/TLSRehandshakeTest.java (modified) * Ok * test/javax/net/ssl/TLS/TLSRehandshakeWithCipherChangeTest.java (modified) * Ok * test/javax/net/ssl/TLS/TLSRehandshakeWithDataExTest.java (modified) * Ok * test/javax/net/ssl/TLS/TLSUnsupportedCiphersTest.java (modified) * Ok * test/javax/net/ssl/TLS/TestJSSEClientDefaultProtocol.java (modified) * Ok * test/javax/net/ssl/TLS/TestJSSEClientProtocol.java (modified) * Ok * test/javax/net/ssl/TLS/TestJSSENoCommonProtocols.java (modified) * Ok * test/javax/net/ssl/TLS/TestJSSEServerProtocol.java (modified) * Ok * test/javax/net/ssl/TLSCommon/Protocol.java (modified) * Ok * test/javax/net/ssl/TLSCommon/RehandshakeWithCipherChangeTest.java (modified) * Ok * test/javax/net/ssl/TLSCommon/RehandshakeWithDataExTest.java (modified) * Ok * test/javax/net/ssl/TLSCommon/SSLEngineTestCase.java (modified) * Ok * test/javax/net/ssl/TLSv1/TLSDataExchangeTest.java (modified) * Ok * test/javax/net/ssl/TLSv1/TLSEnginesClosureTest.java (modified) * Ok * test/javax/net/ssl/TLSv1/TLSHandshakeTest.java (modified) * Ok * test/javax/net/ssl/TLSv1/TLSMFLNTest.java (modified) * Ok * test/javax/net/ssl/TLSv1/TLSNotEnabledRC4Test.java (modified) * Ok * test/javax/net/ssl/TLSv1/TLSRehandshakeTest.java (modified) * Ok * test/javax/net/ssl/TLSv1/TLSRehandshakeWithCipherChangeTest.java (modified) * Ok * test/javax/net/ssl/TLSv1/TLSRehandshakeWithDataExTest.java (modified) * Ok * test/javax/net/ssl/TLSv1/TLSUnsupportedCiphersTest.java (modified) * Ok * test/javax/net/ssl/TLSv11/ExportableBlockCipher.java (modified) * Ok * test/javax/net/ssl/TLSv11/ExportableStreamCipher.java (modified) * Ok * test/javax/net/ssl/TLSv11/TLSDataExchangeTest.java (modified) * Ok * test/javax/net/ssl/TLSv11/TLSEnginesClosureTest.java (modified) * Ok * test/javax/net/ssl/TLSv11/TLSHandshakeTest.java (modified) * Ok * test/javax/net/ssl/TLSv11/TLSMFLNTest.java (modified) * Ok * test/javax/net/ssl/TLSv11/TLSNotEnabledRC4Test.java (modified) * Ok * test/javax/net/ssl/TLSv11/TLSRehandshakeTest.java (modified) * Ok * test/javax/net/ssl/TLSv11/TLSRehandshakeWithCipherChangeTest.java (modified) * Ok * test/javax/net/ssl/TLSv11/TLSRehandshakeWithDataExTest.java (modified) * Ok * test/javax/net/ssl/TLSv11/TLSUnsupportedCiphersTest.java (modified) * Ok * test/javax/net/ssl/TLSv12/TLSEnginesClosureTest.java (modified) * Ok * test/javax/net/ssl/ciphersuites/DisabledAlgorithms.java (modified) * Ok * test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java (modified) * Ok * test/javax/net/ssl/interop/ClientHelloBufferUnderflowException.java (modified) * Ok * test/javax/net/ssl/interop/ClientHelloChromeInterOp.java (modified) * Ok * test/javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java (modified) * Ok * test/javax/net/ssl/templates/SSLContextTemplate.java (modified) * Ok, only default methods allowed in 8u interface * test/javax/net/ssl/templates/SSLSocketTemplate.java (modified) * Ok * test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java (modified) * Ok * test/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java (modified) * Ok * test/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java (modified) * Ok, same as before in 8u * test/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java (modified) * Ok * test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java (modified) * Ok * test/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java (modified) * Ok * test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java (modified) * Ok * test/sun/security/ssl/DHKeyExchange/UseStrongDHSizes.java (modified) * Ok * test/sun/security/ssl/SSLContextImpl/CustomizedServerDefaultProtocols.java (modified) * Ok, TLSv1.3 is not by default enabled for clients * test/sun/security/ssl/SSLContextImpl/DefaultEnabledProtocols.java (modified) * Ok, TLSv1.3 is not by default enabled for clients * test/sun/security/ssl/SSLEngineImpl/SSLEngineKeyLimit.java (modified) * Ok * test/sun/security/ssl/SSLEngineImpl/TLS13BeginHandshake.java (modified) * Ok * test/sun/security/ssl/SSLSessionImpl/ResumeChecksClient.java (modified) * Ok * test/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java (modified) * Ok * test/sun/security/ssl/SSLSocketImpl/SSLSocketKeyLimit.java (modified) * Ok * test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java (modified) * Ok * test/sun/security/ssl/Stapling/StatusResponseManager.java (deleted) * Ok, in 8u we build the JAR with a script * test/sun/security/ssl/Stapling/StatusResponseManager.sh (new) * Ok, in 8u we build the JAR with a script * test/sun/security/ssl/X509TrustManagerImpl/ClientServer.java (modified) * Ok * test/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java (modified) * Ok * test/sun/security/ssl/internal/TestRun.java (deleted) * Ok, in 8u we build the JAR with a script * test/sun/security/ssl/internal/TestRun.sh (new) * Ok, in 8u we build the JAR with a script * test/sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java (modified) * Ok * test/sun/security/provider/certpath/ResponderId/ResponderIdTests.java (modified) * Ok In addition to the static analysis, I ran the tests of the following categories (SSL-related): * sun/security/ssl * javax/net/ssl * sun/net/www/protocol/https * sun/security/pkcs11 * sun/security/provider/certpath * com/sun/net/ssl Per-category analysis of tests: * sun/security/ssl * Test results: passed: 94; failed: 1; error: 3 * Failures/errors: * sun/security/ssl/SSLSocketImpl/ClientTimeout.java * Fails in 11.0.7 so this is not a regression - passing in jdk8u272-b01 (old SunJSSE engine) * sun/security/ssl/SSLSocketImpl/NonAutoClose.java * Fails in 11.0.7 so this is not a regression - passing in jdk8u272-b01 (old SunJSSE engine) * sun/security/ssl/SSLSocketImpl/SetClientMode.java * Fails in 11.0.7 so this is not a regression - passing in jdk8u272-b01 (old SunJSSE engine) * sun/security/ssl/SSLSocketImpl/SSLSocketKeyLimit.java * Ok, failed in Webrev.02 but passed in Webrev.03 * javax/net/ssl * Test results: passed: 120; failed: 1; error: 9 * Failures/errors: * javax/net/ssl/compatibility/Compatibility.java * Fails in 11.0.7 so this is not a regression - not available in jdk8u272-b01 (old SunJSSE engine) * javax/net/ssl/sanity/ciphersuites/CipherSuitesInOrder.java * Fails in 11.0.7 so this is not a regression - passing in jdk8u272-b01 (old SunJSSE engine) * javax/net/ssl/SSLEngine/Basics.java * Fails in 11.0.7 and in jdk8u272-b01 (old SunJSSE engine) so this is not a regression * javax/net/ssl/SSLEngine/CheckStatus.java * Fails in 11.0.7 so this is not a regression - passing in jdk8u272-b01 (old SunJSSE engine) * javax/net/ssl/SSLEngine/ConnectionTest.java * Fails in 11.0.7 so this is not a regression - passing in jdk8u272-b01 (old SunJSSE engine) * javax/net/ssl/SSLEngine/EngineCloseOnAlert.java * Fails in 11.0.7 so this is not a regression - not available in jdk8u272-b01 (old SunJSSE engine) * javax/net/ssl/SSLEngine/IllegalHandshakeMessage.java * Fails in 11.0.7 so this is not a regression - not available in jdk8u272-b01 (old SunJSSE engine) * javax/net/ssl/SSLEngine/IllegalRecordVersion.java * Fails in 11.0.7 so this is not a regression - passing in jdk8u272-b01 (old SunJSSE engine) * javax/net/ssl/SSLEngine/TestAllSuites.java * Fails in 11.0.7 so this is not a regression - not available in jdk8u272-b01 (old SunJSSE engine) * javax/net/ssl/SSLSession/CheckMyTrustedKeystore.java * Fails in 11.0.7 so this is not a regression - not available in jdk8u272-b01 (old SunJSSE engine) * sun/net/www/protocol/https * Test results: passed: 27; error: 1 * Failures/errors: * sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java * Fails in 11.0.7 and in jdk8u272-b01 (old SunJSSE engine) so this is not a regression * sun/security/pkcs11 * Test results: passed: 65; failed: 5; error: 1 * Failures/errors: * sun/security/pkcs11/ec/TestKeyFactory.java * Fails in 11.0.7 and in jdk8u272-b01 (old SunJSSE engine) so this is not a regression * sun/security/pkcs11/fips/ClientJSSEServerJSSE.java * Ok, 'ignore' label removed in Webrev.04 and test passes as in 11.0.7 * sun/security/pkcs11/KeyStore/SecretKeysBasic.sh * Fails in 11.0.7 and in jdk8u272-b01 (old SunJSSE engine) so this is not a regression * sun/security/pkcs11/Secmod/GetPrivateKey.java * Failed in my initial batch run and passed when run standalone. Does not seem to be a TLS issue anyways. Ok. * sun/security/pkcs11/Secmod/JksSetPrivateKey.java * Failed in my initial batch run and passed when run standalone. Does not seem to be a TLS issue anyways. Ok. * sun/security/pkcs11/tls/TestKeyMaterial.java * Fails in 11.0.7 and in jdk8u272-b01 (old SunJSSE engine) so this is not a regression * sun/security/provider/certpath * Test results: passed: 11 * com/sun/net/ssl * Test results: passed: 2 I ran all SSL-related tests and observed no regressions. The following comments are part of this review: [1] [2] [3]. With that said, Webrev.04 looks good to me. Thanks, Martin.- -- [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012523.html [2] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012550.html [3] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012565.html From mbalao at redhat.com Thu Aug 27 21:23:53 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 27 Aug 2020 18:23:53 -0300 Subject: [8u] TLS 1.3 to land in 8u soon - start testing now Message-ID: <45e7635d-61a2-d4d3-e281-4e093cd7e838@redhat.com> Hello, As you know, Azul and Red Hat have been working over the last months on the backport of the SunJSSE engine from JDK-11.0.7 to 8u [1] (see CSR in [2]). This new version of the engine brings support for TLS v1.3. We are expecting to include this backport in the next October 2020 release: OpenJDK 8u272. As a result, it would be very valuable to us that the whole community starts building and testing now. We have the 8u-jsse-incubator repository [3] with all patches applied (jdk8u272-b01 based) and the code will soon land on the 8u main line. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8245466 [2] - https://bugs.openjdk.java.net/browse/JDK-8248721 [3] - https://hg.openjdk.java.net/jdk8u/jdk8u-jsse-incubator From gnu.andrew at redhat.com Fri Aug 28 03:27:22 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Aug 2020 04:27:22 +0100 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <73e7e53d-8eef-a8b1-f978-8c386e244701@redhat.com> References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com> <3e49958c-f1dc-036d-0edf-e4218dee0cbd@redhat.com> <560d6c0a-1b02-9ae6-65dc-ccc7cd740cf5@redhat.com> <539a1f4f-9e9a-eb71-5980-6f278a58ba16@redhat.com> <20200806025408.GB318498@stopbrexit> <73e7e53d-8eef-a8b1-f978-8c386e244701@redhat.com> Message-ID: <20200828032722.GE1117958@stopbrexit> On 00:57 Thu 27 Aug , Martin Balao wrote: > Hi, > > I'd like to propose Webrev.03: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.03/ > > Webrev.03 changes (in comparison to Webrev.01): > > * Reverted the removal of the 'args' argument in every PKCS11 test (now > that 8144539 is in 8u). > > * test/sun/security/pkcs11/MessageDigest/ByteBuffers.java > * Copyright date ends in 2016 before applying the patch because > 8144539 is now in 8u and was the latest to update that line. > * Hook #2 does not apply cleanly because of 8165689 is not in 8u > * Needed to remove "@modules" line from hook and one '*' character > from the beginning of the comment > * 8165689 is about module dependencies on tests and does not apply to 8u > * Hook #3 now applies cleanly because 8144539 is in 8u > > Testing: > > * No regressions observed in sun/security/pkcs11 category > > Thanks, > Martin.- > JDK change looks good to me. I assume the THIRD_PARTY_README change will be applied to the other repos as well? Thanks, -- Andrew :) Senior 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 From mbalao at redhat.com Fri Aug 28 04:24:52 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 28 Aug 2020 01:24:52 -0300 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <20200828032722.GE1117958@stopbrexit> References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com> <3e49958c-f1dc-036d-0edf-e4218dee0cbd@redhat.com> <560d6c0a-1b02-9ae6-65dc-ccc7cd740cf5@redhat.com> <539a1f4f-9e9a-eb71-5980-6f278a58ba16@redhat.com> <20200806025408.GB318498@stopbrexit> <73e7e53d-8eef-a8b1-f978-8c386e244701@redhat.com> <20200828032722.GE1117958@stopbrexit> Message-ID: Hi, On 8/28/20 12:27 AM, Andrew Hughes wrote: > > I assume the THIRD_PARTY_README change will be applied to the other > repos as well? Thanks for making me notice that; I was not familiar with the THIRD_PARTY_README files being replicated in every forest repository and would have missed it. Please have a look at the other Webrevs: * http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.corba.webrev.03/ * http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.hotspot.webrev.03/ * http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jaxp.webrev.03/ * http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jaxws.webrev.03/ * http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.langtools.webrev.03/ * http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.nashorn.webrev.03/ * http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.webrev.03/ Thanks, Martin.- From gnu.andrew at redhat.com Fri Aug 28 05:08:43 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Aug 2020 06:08:43 +0100 Subject: [8u] TLS 1.3 to land in 8u soon - start testing now In-Reply-To: <45e7635d-61a2-d4d3-e281-4e093cd7e838@redhat.com> References: <45e7635d-61a2-d4d3-e281-4e093cd7e838@redhat.com> Message-ID: <20200828050843.GA1139317@stopbrexit> On 18:23 Thu 27 Aug , Martin Balao wrote: > Hello, > > As you know, Azul and Red Hat have been working over the last months on > the backport of the SunJSSE engine from JDK-11.0.7 to 8u [1] (see CSR in > [2]). This new version of the engine brings support for TLS v1.3. > > We are expecting to include this backport in the next October 2020 > release: OpenJDK 8u272. > > As a result, it would be very valuable to us that the whole community > starts building and testing now. > > We have the 8u-jsse-incubator repository [3] with all patches applied > (jdk8u272-b01 based) and the code will soon land on the 8u main line. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8245466 > [2] - https://bugs.openjdk.java.net/browse/JDK-8248721 > [3] - https://hg.openjdk.java.net/jdk8u/jdk8u-jsse-incubator > A reminder to all that we rampdown for 8u272 after tomorrow. I will merge the jsse-incubator into 8u-dev (and then the 8u build promotion) at that point, unless there are any objections. Merging at this point gives us the option to roll back to the rampdown point and push TLSv1.3 back to 8u282, should some major blocker be found. I believe the CSR is still pending. Andrew Haley, if you're happy with the CSR in its current state, then I'm happy to proceed with the merge while we wait for formal approval from the CSR team. Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Fri Aug 28 05:09:45 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Aug 2020 06:09:45 +0100 Subject: SunPKCS11 connection lost after Decrypt doFinal In-Reply-To: References: <115412fa-7001-feb3-b4d7-e92d64790792@redhat.com> <073918b1-75d1-305e-5054-c663aa360306@oracle.com> <14993a7d-4f12-35df-50b8-bc5d9b3e7a90@redhat.com> Message-ID: <20200828050945.GB1139317@stopbrexit> On 09:26 Thu 27 Aug , DEBORDEAUX Hubert wrote: > Hello, > > Any news regarding backporting of 8236512 ? > > Regards, > Hubert > > -----Original Message----- > From: jdk8u-dev On Behalf Of Andrew Hughes > Sent: Thursday, June 18, 2020 18:49 > To: Valerie Peng ; jdk8u-dev at openjdk.java.net > Subject: Re: SunPKCS11 connection lost after Decrypt doFinal > > On 17/06/2020 05:24, Valerie Peng wrote: > > Well, JDK-8235215 is relevant to JDK-6946830 but not a duplicate of it. > > > > I should have added a duplicate-of-issue link to make it clear - > > JDK-8235215 is closed as a duplicate of JDK-8236512. > > > > Sorry for the confusion and hope all is clear now. > > > > Thanks, > > Valerie > > > > Thanks, Valerie. Yes, it is now. I'll look into backporting 8236512. > -- > Andrew :) > > Senior Free Java Software Engineer > 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 > Thanks for the reminder; it saved me try to dig out the original mail. This is on my radar and I'll get to it as soon as I can. Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Fri Aug 28 05:12:15 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Aug 2020 06:12:15 +0100 Subject: [8u] RFR: 8252384: [TESTBUG] Some tests refer to COMPAT provider rather than JRE In-Reply-To: <20200827150606.bluinrxlprzpdoe2@qusp> References: <20200827150606.bluinrxlprzpdoe2@qusp> Message-ID: <20200828051215.GC1139317@stopbrexit> On 16:06 Thu 27 Aug , Jonathan Dowland wrote: > Hello again, > > Please review the following webrev proposed for jdk8u. This fixes 6 > backported tests which reference a locale provider name invalid under > jdk8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252384 > Webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/jdowland/JDK-8252384/ > > > Thanks, > > -- > Jonathan Dowland > This looks fine to me. Severin, if you flag this for approval on Jonathan's behalf, I'll approve and push. Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Fri Aug 28 05:21:02 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Aug 2020 06:21:02 +0100 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <94490d36-9747-4333-6278-a887af28e927@redhat.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> <78a1c49794afdf13013a4c3d75efab50f4745870.camel@redhat.com> <20200820171607.GC3112706@stopbrexit> <94490d36-9747-4333-6278-a887af28e927@redhat.com> Message-ID: <20200828052102.GD1139317@stopbrexit> On 10:24 Tue 25 Aug , Zhengyu Gu wrote: > Okay, I restored @since 12. > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.04/ > > I still don't have a strong opinion on this, but it is not a specific > problem for this backport. > > grep -r "@since" under jdk8u-dev/jdk, you see many versions > 8. > > If it needs to be addressed, we should address them at once and setup a > guideline for future backports. > > Could I get formal review now? I bet Michael is anxious to get this in. > > Thanks, > > -Zhengyu > > In LdapDnsProviderService.java, I'd replace List.of() with Collections.emptyList() which gives the same unmodifiable empty list, rather than a new ArrayList<>() call. Other changes (omission of public doc changes, package renaming, additional access requirement) look fine. I am concerned that this is not in 11u yet. Is there some co-ordination between this backport and the 11u backport? Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Fri Aug 28 05:32:22 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Aug 2020 06:32:22 +0100 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com> <3e49958c-f1dc-036d-0edf-e4218dee0cbd@redhat.com> <560d6c0a-1b02-9ae6-65dc-ccc7cd740cf5@redhat.com> <539a1f4f-9e9a-eb71-5980-6f278a58ba16@redhat.com> <20200806025408.GB318498@stopbrexit> <73e7e53d-8eef-a8b1-f978-8c386e244701@redhat.com> <20200828032722.GE1117958@stopbrexit> Message-ID: <20200828053222.GA1140133@stopbrexit> On 01:24 Fri 28 Aug , Martin Balao wrote: > Hi, > > On 8/28/20 12:27 AM, Andrew Hughes wrote: > > > > I assume the THIRD_PARTY_README change will be applied to the other > > repos as well? > > Thanks for making me notice that; I was not familiar with the > THIRD_PARTY_README files being replicated in every forest repository and > would have missed it. > > Please have a look at the other Webrevs: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.corba.webrev.03/ > * > http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.hotspot.webrev.03/ > * > http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jaxp.webrev.03/ > * > http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jaxws.webrev.03/ > * > http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.langtools.webrev.03/ > * > http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.nashorn.webrev.03/ > * http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.webrev.03/ > > Thanks, > Martin.- > > > No problem. I had to do this for the system library updates to OpenJDK 7 recently and my approach was simply along the lines of: 1. In jdk repo, run hg diff THIRD_PARTY_README > readme.patch 2. Commit the jdk change 3. Copy the exported header of the jdk changeset to a file, header.patch 4. cat header.patch readme.patch | hg import on the other repos Having checked this using roughly the same approach, $ for repos in corba jaxp jaxws langtools nashorn hotspot do wget -v http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.${repos}.webrev.03/${repos}.changeset diff -u ${repos}.changeset readme.diff done they look good to me. Thanks, -- Andrew :) Senior 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 From zgu at redhat.com Fri Aug 28 12:34:30 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 28 Aug 2020 08:34:30 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <20200828052102.GD1139317@stopbrexit> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> <78a1c49794afdf13013a4c3d75efab50f4745870.camel@redhat.com> <20200820171607.GC3112706@stopbrexit> <94490d36-9747-4333-6278-a887af28e927@redhat.com> <20200828052102.GD1139317@stopbrexit> Message-ID: <234c952c-ac89-5523-70dd-a60d28877f2e@redhat.com> Hi Andrew, Thanks for reviewing. On 8/28/20 1:21 AM, Andrew Hughes wrote: > On 10:24 Tue 25 Aug , Zhengyu Gu wrote: >> Okay, I restored @since 12. >> >> Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.04/ >> >> I still don't have a strong opinion on this, but it is not a specific >> problem for this backport. >> >> grep -r "@since" under jdk8u-dev/jdk, you see many versions > 8. >> >> If it needs to be addressed, we should address them at once and setup a >> guideline for future backports. >> >> Could I get formal review now? I bet Michael is anxious to get this in. >> >> Thanks, >> >> -Zhengyu >> >> > > In LdapDnsProviderService.java, I'd replace List.of() with Collections.emptyList() > which gives the same unmodifiable empty list, rather than a new ArrayList<>() call. > Good suggestion, updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.05/ > Other changes (omission of public doc changes, package renaming, additional access > requirement) look fine. > > I am concerned that this is not in 11u yet. Is there some co-ordination between this > backport and the 11u backport? > I am aware of that Christoph is working on 11u backport. I don't know about whole story, but it seems that 11u is complicated than 8u, due to module. Christoph, could you give us an update on 11u? Thanks, -Zhengyu > Thanks, > From christoph.langer at sap.com Fri Aug 28 13:41:29 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 28 Aug 2020 13:41:29 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <20200820171607.GC3112706@stopbrexit> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> <78a1c49794afdf13013a4c3d75efab50f4745870.camel@redhat.com> <20200820171607.GC3112706@stopbrexit> Message-ID: Hi, as for these @since 12 tags... While I understand that there are both, arguments pro and con, I'd like to point out one specific thing in the context of this backport: Classes com.sun.jndi.ldap.spi. LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult don't even exist in 12 and probably won't ever. In 12 we have javax.naming.ldap.spi.LdapDnsProvider and javax.naming.ldap.spi.LdapDnsProviderResult. So, given that change of package location, I opt to remove the @since 12 tags which I'm proposing in my webrev for 11u as well. Andrew, does that convice you or you still insist on the tags? Cheers Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of Andrew > Hughes > Sent: Donnerstag, 20. August 2020 19:16 > To: Severin Gehwolf > Cc: Zhengyu Gu ; Michael Osipov <1983-01- > 06 at gmx.net>; Hohensee, Paul ; jdk8u-dev > > Subject: Re: [8u] RFR 8160768: Add capability to custom resolve host/domain > names within the default JNDI LDAP provider > > On 08:51 Wed 19 Aug , Severin Gehwolf wrote: > > On Mon, 2020-08-17 at 06:26 +0100, Andrew Hughes wrote: > > > On 11:51 Thu 13 Aug , Severin Gehwolf wrote: > > > > On Tue, 2020-08-11 at 14:48 -0400, Zhengyu Gu wrote: > > > > > Hi Michael, > > > > > > > > > > > My tests/comments: > > > > > > * @since still says 12. Is that correct? > > > > > > > > I agree. Zhengyu, please remove the @since 12 tags in this backport. It > > > > doesn't make sense to have them in either 11 or 8. > > > > > > > > > > I disagree. Such tags are a useful indicator that this is a backported > > > API that wasn't in 8 GA. > > > > If we are starting to rely on @since tags as an indicator for backports > > then we're in trouble. Instead, the bug system and source control > > should be used for this. Given that, by removing the @since tag we > > don't loose info that it's a backport. > > > > I didn't claim it was the only indicator. > > It is useful to have it there in the source code if you're looking at > the file concerned. It's also easily accessible. Being able to find > the same information in the bug system or source control system > requires you to be aware of their existence and to know to look for > such information there. > > To find the same information as the simple @since tag provides, I > would need a checkout of the code from the source code repository, to > know how to look up when that file was added, and then use the bug ID > to lookup in the bug database in which JDK it was added. All a lot > more complicated than one line of text that only requires the sources > concerned. > > > > What would be the issue with leaving them in? > > > > A couple of reasons: > > > > * It's confusing. Mentioning something related to JDK 12 in a JDK 8 > > tree is, well, confusing. It only wouldn't be so if you are > > intimately familiar with the process and know about this mailing > > list discussion. > > I guess we have to beg to differ on this. I don't find it confusing. > The @since tag has long-term well-defined semantics familiar to any > Java user. I don't think it's that complicated to infer that if > "@since 12" is used in 8u sources, it must have been backported. > > I have used it in this manner for years (e.g. [0] [1]) and never been > aware of anyone finding it confusing before. > > On the contrary, to know to strip this information in a backport does > require the person backporting to have knowledge of the need to do > that and this discussion. > > > * @Since tags are usually used for *publicly* exposed classes as an > > aid for JDK API consumers. "This API is available for JDK 12 and > > onwards". I'm aware there are instances where it was used for > > internal classes too, but they become less prominent these days. It > > makes sense to have them for the original JDK 12 change. For the JDK > > 8u backport, classes have been moved to a private package. It's not > > a 1-to-1 backport. The value of it being preserved regardless makes > > little sense. It's not the original class where it was added to > > begin with. > > It is rare that public API would be backported. The one case where > this has happened (ALPN+RSA-PSS) used "@since 8". I'd have preferred > "@since 8M3" or "@since 8u41". > > It not being publicly exposed actually seems more reason to just leave > it in, as Javadoc won't be generated, so only someone looking at the > source would see it. > > > * The SinceTree.java interface mentions this in its javadoc: "Returns > > the text explaining the availability of the item being documented." > > That's wrong for code in JDK 8. We'd be putting a @since 12 on code > > introduced in an update version of 8u. > > 12 was its first availability. > > You could use @since 8u272 if you like. The main concern is to make it > clear that it wasn't part of 8 GA. > > > > > Overall, the drawbacks outweigh the benefits. > > > > I disagree. It seems mandating this could result in unnecessary > differences between 8u & later sources, and additional work for > backporters, all for no clear benefit. > > > Thanks, > > Severin > > > > [0] https://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/9ab3c966585d > [1] https://openjdk.java.net/jeps/129 > [2] https://jdk.java.net/java-se-ri/8-MR3 > -- > Andrew :) > > Senior 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 From christoph.langer at sap.com Fri Aug 28 14:13:58 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 28 Aug 2020 14:13:58 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <234c952c-ac89-5523-70dd-a60d28877f2e@redhat.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> <78a1c49794afdf13013a4c3d75efab50f4745870.camel@redhat.com> <20200820171607.GC3112706@stopbrexit> <94490d36-9747-4333-6278-a887af28e927@redhat.com> <20200828052102.GD1139317@stopbrexit> <234c952c-ac89-5523-70dd-a60d28877f2e@redhat.com> Message-ID: Hi Zhengyu, > > I am concerned that this is not in 11u yet. Is there some co-ordination > between this > > backport and the 11u backport? > > > > I am aware of that Christoph is working on 11u backport. I don't know > about whole story, but it seems that 11u is complicated than 8u, due to > module. > > Christoph, could you give us an update on 11u? For 11u I just finalized the CSR and a review is still outstanding: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-August/003608.html But I'm planning to get it into 11.0.9, hopefully some time next week. Best regards Christoph From mbalao at redhat.com Fri Aug 28 17:10:59 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 28 Aug 2020 14:10:59 -0300 Subject: [8u] RFR 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite In-Reply-To: <27be5aad-5ec6-6dce-c5ac-f7f2330770e0@redhat.com> References: <2ea4f241-f47e-73df-741c-3889b9e2d87a@redhat.com> <9b04fc7b-752b-784a-ee98-0ec42c8351b2@redhat.com> <27be5aad-5ec6-6dce-c5ac-f7f2330770e0@redhat.com> Message-ID: <47334aa2-d294-b17d-4158-4656c65b165d@redhat.com> Hi, I'd like to propose Webrev.03: * http://cr.openjdk.java.net/~mbalao/webrevs/8165996/8165996.jdk8u.jdk.webrev.03/ Differences with main line patch: * test/jdk/sun/security/pkcs11/PKCS11Test.java * Hook does not apply because 8u does not have 8133318. In my opinion, 8133318 shouldn't be a dependency of 8165996 because it's about intermitent failures of some tests on Solaris 11.1 and earlier, and 8165996 is a fix to a bug related to the SQLite NSS DB format. * test/jdk/sun/security/pkcs11/Secmod/TestNssDbSqlite.java * '@modules' jtreg header do not apply to 8u No test regressions observed in sun/security/pkcs11. Thanks, Martin.- From mbalao at redhat.com Fri Aug 28 18:12:37 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 28 Aug 2020 15:12:37 -0300 Subject: [8u] RFR 8228835: Memory leak in PKCS11 provider when using AES GCM Message-ID: Hi, I'd like to request a review of the 8u backport of 8228835 [1]: * Webrev.00 * http://cr.openjdk.java.net/~mbalao/webrevs/8228835/8228835.jdk8u.jdk.webrev.00/ Main line patch does not apply cleanly because: * src/share/native/sun/security/pkcs11/wrapper/p11_util.c * 8074838 is not in 8u and the Hook #12 expects to see "*ckpLength = (CK_ULONG) strlen(pCharArray);" line around the modified line. In 8u, the line is "*ckpLength = strlen(pCharArray);". 8074838 (Resolve disabled warnings for libj2pkcs11) is not related to the bug that 8228835 fixes (Memory leak in PKCS11 provider when using AES GCM), so I've not considered it as a dependency. Testing: I've observed no regressions in the sun/security/pkcs11 category. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8228835 From gnu.andrew at redhat.com Fri Aug 28 19:38:04 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Aug 2020 20:38:04 +0100 Subject: [8u] RFR 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite In-Reply-To: <47334aa2-d294-b17d-4158-4656c65b165d@redhat.com> References: <2ea4f241-f47e-73df-741c-3889b9e2d87a@redhat.com> <9b04fc7b-752b-784a-ee98-0ec42c8351b2@redhat.com> <27be5aad-5ec6-6dce-c5ac-f7f2330770e0@redhat.com> <47334aa2-d294-b17d-4158-4656c65b165d@redhat.com> Message-ID: <20200828193804.GA1145805@stopbrexit> On 14:10 Fri 28 Aug , Martin Balao wrote: > Hi, > > I'd like to propose Webrev.03: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8165996/8165996.jdk8u.jdk.webrev.03/ > > Differences with main line patch: > > * test/jdk/sun/security/pkcs11/PKCS11Test.java > * Hook does not apply because 8u does not have 8133318. In my opinion, > 8133318 shouldn't be a dependency of 8165996 because it's about > intermitent failures of some tests on Solaris 11.1 and earlier, and > 8165996 is a fix to a bug related to the SQLite NSS DB format. Yes, I made the same decision to leave the two Solaris fixes out of the dependency trail [0] (JDK-8133318 & JDK-8170523) as I don't have a means to test on Solaris easily, never mind this configuration. > > * test/jdk/sun/security/pkcs11/Secmod/TestNssDbSqlite.java > * '@modules' jtreg header do not apply to 8u That's fine. > > No test regressions observed in sun/security/pkcs11. > > Thanks, > Martin.- > > Source changes look good. I'm seeing a difference in the binary diff of the two .db files and, when the patch is applied, they seem to apparently be from a different SQLite version: JDK 16: $ file jdk/test/jdk/sun/security/pkcs11/Secmod/cert9.db ../../jdk/test/jdk/sun/security/pkcs11/Secmod/cert9.db: SQLite 3.x database, last written using SQLite version 3011000 JDK 8u with patch: $ file test/sun/security/pkcs11/Secmod/cert9.db test/sun/security/pkcs11/Secmod/cert9.db: SQLite 3.x database, last written using SQLite version 3014002 Can you please update the webrev with the versions used in 11u? [0] https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3507 Thanks, -- Andrew :) Senior 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 From mbalao at redhat.com Fri Aug 28 20:01:25 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 28 Aug 2020 17:01:25 -0300 Subject: [8u] RFR 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite In-Reply-To: <20200828193804.GA1145805@stopbrexit> References: <2ea4f241-f47e-73df-741c-3889b9e2d87a@redhat.com> <9b04fc7b-752b-784a-ee98-0ec42c8351b2@redhat.com> <27be5aad-5ec6-6dce-c5ac-f7f2330770e0@redhat.com> <47334aa2-d294-b17d-4158-4656c65b165d@redhat.com> <20200828193804.GA1145805@stopbrexit> Message-ID: <06d8b550-efb2-85de-dbb1-452fec9d6260@redhat.com> Hi, Thanks for having a look at this. On 8/28/20 4:38 PM, Andrew Hughes wrote: > I'm seeing a difference in the binary diff of the two .db files > and, when the patch is applied, they seem to apparently be from > a different SQLite version: > > JDK 16: > $ file jdk/test/jdk/sun/security/pkcs11/Secmod/cert9.db > ../../jdk/test/jdk/sun/security/pkcs11/Secmod/cert9.db: SQLite 3.x database, last written using SQLite version 3011000 > > JDK 8u with patch: > $ file test/sun/security/pkcs11/Secmod/cert9.db > test/sun/security/pkcs11/Secmod/cert9.db: SQLite 3.x database, last written using SQLite version 3014002 > > Can you please update the webrev with the versions used in 11u? I'm not completely sure about the binary difference but have generated the patch again including the files directly from 11u. Webrev.04: * http://cr.openjdk.java.net/~mbalao/webrevs/8165996/8165996.jdk8u.jdk.webrev.04/ No regressions in sun/security/pkcs11 observed. Thanks, Martin.- From gnu.andrew at redhat.com Fri Aug 28 20:16:10 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Aug 2020 21:16:10 +0100 Subject: [8u] RFR 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite In-Reply-To: <06d8b550-efb2-85de-dbb1-452fec9d6260@redhat.com> References: <2ea4f241-f47e-73df-741c-3889b9e2d87a@redhat.com> <9b04fc7b-752b-784a-ee98-0ec42c8351b2@redhat.com> <27be5aad-5ec6-6dce-c5ac-f7f2330770e0@redhat.com> <47334aa2-d294-b17d-4158-4656c65b165d@redhat.com> <20200828193804.GA1145805@stopbrexit> <06d8b550-efb2-85de-dbb1-452fec9d6260@redhat.com> Message-ID: <20200828201610.GB1145805@stopbrexit> On 17:01 Fri 28 Aug , Martin Balao wrote: > Hi, > > Thanks for having a look at this. > > On 8/28/20 4:38 PM, Andrew Hughes wrote: > > I'm seeing a difference in the binary diff of the two .db files > > and, when the patch is applied, they seem to apparently be from > > a different SQLite version: > > > > JDK 16: > > $ file jdk/test/jdk/sun/security/pkcs11/Secmod/cert9.db > > ../../jdk/test/jdk/sun/security/pkcs11/Secmod/cert9.db: SQLite 3.x database, last written using SQLite version 3011000 > > > > JDK 8u with patch: > > $ file test/sun/security/pkcs11/Secmod/cert9.db > > test/sun/security/pkcs11/Secmod/cert9.db: SQLite 3.x database, last written using SQLite version 3014002 > > > > Can you please update the webrev with the versions used in 11u? > > I'm not completely sure about the binary difference but have generated > the patch again including the files directly from 11u. > > Webrev.04: > * > http://cr.openjdk.java.net/~mbalao/webrevs/8165996/8165996.jdk8u.jdk.webrev.04/ > > No regressions in sun/security/pkcs11 observed. > > Thanks, > Martin.- > > Thanks. I see no differences in the binaries with this version. Please flag for approval with jdk8u-fix-request. Thanks, -- Andrew :) Senior 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 From gnu.andrew at redhat.com Fri Aug 28 21:07:08 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Aug 2020 22:07:08 +0100 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <234c952c-ac89-5523-70dd-a60d28877f2e@redhat.com> References: <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> <78a1c49794afdf13013a4c3d75efab50f4745870.camel@redhat.com> <20200820171607.GC3112706@stopbrexit> <94490d36-9747-4333-6278-a887af28e927@redhat.com> <20200828052102.GD1139317@stopbrexit> <234c952c-ac89-5523-70dd-a60d28877f2e@redhat.com> Message-ID: <20200828210708.GC1145805@stopbrexit> On 08:34 Fri 28 Aug , Zhengyu Gu wrote: > Hi Andrew, > > Thanks for reviewing. > > On 8/28/20 1:21 AM, Andrew Hughes wrote: > > On 10:24 Tue 25 Aug , Zhengyu Gu wrote: > > > Okay, I restored @since 12. > > > > > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.04/ > > > > > > I still don't have a strong opinion on this, but it is not a specific > > > problem for this backport. > > > > > > grep -r "@since" under jdk8u-dev/jdk, you see many versions > 8. > > > > > > If it needs to be addressed, we should address them at once and setup a > > > guideline for future backports. > > > > > > Could I get formal review now? I bet Michael is anxious to get this in. > > > > > > Thanks, > > > > > > -Zhengyu > > > > > > > > > > In LdapDnsProviderService.java, I'd replace List.of() with Collections.emptyList() > > which gives the same unmodifiable empty list, rather than a new ArrayList<>() call. > > > > Good suggestion, updated: > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.05/ > Thanks. Please flag with jdk8u-fix-request. -- Andrew :) Senior 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 From gnu.andrew at redhat.com Fri Aug 28 21:54:19 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Aug 2020 22:54:19 +0100 Subject: [8u] RFR 8228835: Memory leak in PKCS11 provider when using AES GCM In-Reply-To: References: Message-ID: <20200828215419.GD1145805@stopbrexit> On 15:12 Fri 28 Aug , Martin Balao wrote: > Hi, > > I'd like to request a review of the 8u backport of 8228835 [1]: > > * Webrev.00 > * > http://cr.openjdk.java.net/~mbalao/webrevs/8228835/8228835.jdk8u.jdk.webrev.00/ > > Main line patch does not apply cleanly because: > > * src/share/native/sun/security/pkcs11/wrapper/p11_util.c > * 8074838 is not in 8u and the Hook #12 expects to see "*ckpLength = > (CK_ULONG) strlen(pCharArray);" line around the modified line. In 8u, > the line is "*ckpLength = strlen(pCharArray);". 8074838 (Resolve > disabled warnings for libj2pkcs11) is not related to the bug that > 8228835 fixes (Memory leak in PKCS11 provider when using AES GCM), so > I've not considered it as a dependency. > > Testing: I've observed no regressions in the sun/security/pkcs11 category. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8228835 > Looks fine to me. Please flag with jdk8u-fix-request. Thanks, -- Andrew :) Senior 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 From zgu at redhat.com Sat Aug 29 13:24:53 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Sat, 29 Aug 2020 09:24:53 -0400 Subject: [8u] RFR 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect Message-ID: I would like to backport this patch for parity with Oracle 8u271. The original patch does not apply cleanly. The conflicts on the fixes are minors, can be easily resolved manually. 1) LdapTimeoutTest.java is not in ProblemList.txt in 8u 2) Copyright lines in LdapTimeoutTest.java do not match 3) Import lines in BaseLdapServer.java do not match However, LdapTimeoutTest.java uses some new language features and APIs that do not exist in 8u. It also uses new test library that needs to map back to 8u test library. /* * @test - * @library /test/lib + * @library /lib/testlibrary * lib/ * @run testng/othervm LdapTimeoutTest * @bug 7094377 8000487 6176036 7056489 8151678 @@ -59,7 +59,7 @@ import static java.lang.String.format; import static java.util.concurrent.TimeUnit.MILLISECONDS; import static java.util.concurrent.TimeUnit.NANOSECONDS; -import static jdk.test.lib.Utils.adjustTimeout; +import static jdk.testlibrary.Utils.adjustTimeout; import static org.testng.Assert.assertTrue; import static org.testng.Assert.expectThrows; @@ -120,7 +120,7 @@ executorService.shutdown(); } int failedCount = 0; - for (var f : futures) { + for (Future f : futures) { try { f.get(); } catch (ExecutionException e) { @@ -283,11 +283,14 @@ @Override protected void beforeAcceptingConnections() { - starting.completeAsync(() -> null); + CompletableFuture.supplyAsync(() -> null) + .whenComplete((input, exception) -> { + starting.complete(null); + }); } public CompletableFuture starting() { - return starting.copy(); + return starting.toCompletableFuture(); } } Test: jdk_other Thanks, -Zhengyu From 1983-01-06 at gmx.net Fri Aug 7 09:47:57 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Fri, 07 Aug 2020 09:47:57 -0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> Message-ID: Hi Zhengyu, here is my static review, compilation and tests will follow: The code is the same as with JDK 12+. Good, but you need to move LdapDnsProvider and LdapDnsProviderResult to com.sun.jndi.ldap.spi. Both Oracle JDK 8u and 11u have this integrated in this package because it is not allowed to change the public API. I am also in touch with Christoph Langer regarding a backport to OpenJDK 11u. We have agreed to use the same package as Oracle did in its distributions. With that change you can swap OpenJDK for Oracle JDK and vice versa. My real world code works flawlessly with Oracle JDK 8 and 11 w/o change or recompilation. Michael Am 2020-08-06 um 22:40 schrieb Hohensee, Paul: > In InitialDirContext.java, the new comments use @code instead of the pair prevalent in JDK 8. Would be worth checking the Javadoc to see if there's any real difference. If there is, replace the @code uses with pairs. Fwiw, I've done that when backporting javadoc before. > > I ran the test/com/sun/jndi/ldap/ tests with your patch on my Linux box. Your new tests pass, the old ones perform the same as before the patch. > > ?On 8/5/20, 6:52 AM, "Zhengyu Gu" wrote: > > Hi Paul, > > Sorry for replying late. Somehow, this email slipped through the cracks, > and thanks Michael for bringing it to my attention. > > > On 7/13/20 5:27 PM, Hohensee, Paul wrote: > > The webrev looks it's corrupted. E.g., it includes the changes from 8217606, and not the InitialDirContext.java and CheckConfigs.policy changes you mention. > > It had dependence on 8217606, now it is pushed, so that the webrev is > much cleaner. > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.01/ > > Test: > Reran jdk_other. > > Thanks, > > -Zhengyu > > > > > > > Paul > > > > On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > > > Hi, > > > > I would like to backport this patch to 8u for parity with Oracle 8u261. > > > > The original patch does not apply cleanly. > > > > Other than a couple of minor conflicts: > > > > 1) Comments in InitialDirContext.java did not apply cleanly > > 2) Unpatched CheckConfigs.policy files did not match > > > > I made following modification for 8u: > > > > 1) Removed module-info.java section, it does not apply to 8u. > > 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs > > (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the > > code with ArrayList. > > 3) Removed @modules annotation in LdapDnsProviderTest.java > > > > Additional, I need to modify langtools to get javac to take > > com.sun.jndi.ldap.spi package and complain about it. > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 > > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a > > > > 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.00/ > > 8u langtools webrev: > > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webev.00/ > > > > > > Test: > > jdk_other on Linux x86_64 > > > > Thanks, > > > > -Zhengyu > > > > > > > > From 1983-01-06 at gmx.net Tue Aug 11 18:39:37 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Tue, 11 Aug 2020 18:39:37 -0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> Message-ID: <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> Am 2020-08-11 um 17:01 schrieb Zhengyu Gu: > Hi, > > Webrevs are updated to reflect CSR[1]. > > jdk: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.02/ > langtools: > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webrev.01/ My tests/comments: * @since still says 12. Is that correct? * Should LdapDnsProvider and LdapDnsProviderResult document that they have been moved in 12? I have compiled my code with source/target 8 on Oracle JDK 11.0.8, applied your patch on top of OpenJDK 1.8.0_265 on FreeBSD 12-STABLE. Ran my code: > $ /usr/local/openjdk8-ldap/bin/java -Dorg.slf4j.simpleLogger.showDateTime=true -Djava.util.logging.config.file=logging.properties -jar ad-dns.jar > 30 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Connecting to: ldap://ad001.siemens.net > Aug 11, 2020 8:11:20 PM com.siemens.dynamowerk.ad.ActiveDirectoryDnsLocator locate > FEIN: Looking up SRV RRs for '_ldap._tcp.S-DEBLN-03._sites.ad001.siemens.net' > Aug 11, 2020 8:11:20 PM com.siemens.dynamowerk.ad.ActiveDirectoryDnsLocator locate > FEINER: Found 4 SRV RRs for '_ldap._tcp.S-DEBLN-03._sites.ad001.siemens.net': [SRV RR: 0 100 389 dc1.ad001.siemens.net., SRV RR: 0 100 389 dc3.ad001.siemens.net., SRV RR: 0 100 389 dc2.ad001.siemens.net., SRV RR: 0 100 389 dc4.ad001.siemens.net.] > Aug 11, 2020 8:11:20 PM com.siemens.dynamowerk.ad.ActiveDirectoryDnsLocator locate > FEINER: Selected 4 servers for '_ldap._tcp.S-DEBLN-03._sites.ad001.siemens.net': [dc3.ad001.siemens.net:389, dc2.ad001.siemens.net:389, dc4.ad001.siemens.net:389, dc1.ad001.siemens.net:389] > 268 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - dnsHostName: dc3.ad001.siemens.net > 268 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Closing connection As constrast stock OpenJDK 8u265: > $ /usr/local/openjdk8/bin/java -Dorg.slf4j.simpleLogger.showDateTime=true -Djava.util.logging.config.file=logging.properties -jar ad-dns.jar > 17 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Connecting to: ldap://ad001.siemens.net > 472 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - dnsHostName: dc6.ad001.siemens.net > 472 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Closing connection > 686 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Connecting to: ldap://ad001.siemens.net > 1059 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - dnsHostName: dc6.ad001.siemens.net > 1059 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Closing connection > 1271 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Connecting to: ldap://ad001.siemens.net > 1617 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - dnsHostName: dc6.ad001.siemens.net > 1617 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Closing connection > 1830 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Connecting to: ldap://ad001.siemens.net > 2176 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - dnsHostName: dc6.ad001.siemens.net > 2176 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Closing connection > 2380 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Connecting to: ldap://ad001.siemens.net > 2722 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - dnsHostName: dc6.ad001.siemens.net > 2723 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Closing connection > 2936 [main] INFO com.siemens.dynamowerk.ActiveDirectoryLdapTester - Connecting to: ldap://ad001.siemens.net which relies on A records only and cannot be used to perform GSS-API/Kerberos authentication afterwards. You have my approval. Thank you very much for pursuing this! Michael From 1983-01-06 at gmx.net Thu Aug 13 18:16:11 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Thu, 13 Aug 2020 18:16:11 -0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <75cbaa5f-ce24-9a4b-0b3e-232bc9304e6e@redhat.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <75cbaa5f-ce24-9a4b-0b3e-232bc9304e6e@redhat.com> Message-ID: Am 2020-08-13 um 14:49 schrieb Zhengyu Gu: > > > On 8/13/20 5:51 AM, Severin Gehwolf wrote: >> On Tue, 2020-08-11 at 14:48 -0400, Zhengyu Gu wrote: >>> Hi Michael, >>> >>>> My tests/comments: >>>> * @since still says 12. Is that correct? >> >> I agree. Zhengyu, please remove the @since 12 tags in this backport. It >> doesn't make sense to have them in either 11 or 8. > > Okay, updated: > > http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.03/ > > Could I get formal review? Michael reviewed/tested previous version, but > I don't see him on 8u reviewer list. I am not a JDK reviewer at all, I am just the guy who reported and pursued this for years. Michael From 1983-01-06 at gmx.net Sat Aug 29 08:31:16 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Sat, 29 Aug 2020 10:31:16 +0200 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <94490d36-9747-4333-6278-a887af28e927@redhat.com> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> <78a1c49794afdf13013a4c3d75efab50f4745870.camel@redhat.com> <20200820171607.GC3112706@stopbrexit> <94490d36-9747-4333-6278-a887af28e927@redhat.com> Message-ID: <565acabe-ebec-f81c-a069-3157d56f1115@gmx.net> Am 2020-08-25 um 16:24 schrieb Zhengyu Gu: > Okay, I restored @since 12. > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.04/ > > I still don't have a strong opinion on this, but it is not a specific > problem for this backport. > > grep -r "@since" under jdk8u-dev/jdk, you see many versions > 8. > > If it needs to be addressed, we should address them at once and setup a > guideline for future backports. > > Could I get formal review now? I bet Michael is anxious to get this in. I am not really anxious, I just wanted to point this out. From gnu.andrew at redhat.com Mon Aug 31 06:04:05 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 31 Aug 2020 07:04:05 +0100 Subject: [RAMPDOWN] 8u & 8u-dev Forests FROZEN Message-ID: <20200831060405.GA1345407@stopbrexit> We are now entering rampdown for the 8u272 release. 8u-dev is now frozen until it is switched to make commits for 8u282. Please do not push to 8u-dev until a further notification which states that this process is complete. 8u will be frozen until the promotion of 8u272-b06 is complete later this week. After that, fixes may be pushed to 8u for 8u272 which have jdk8u-critical-yes. Thanks, -- Andrew :) Senior 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 From sgehwolf at redhat.com Mon Aug 31 08:02:11 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 31 Aug 2020 10:02:11 +0200 Subject: [8u] RFR: 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries Message-ID: Hi, Could I get a reivew of this 8u specific bug please? When configured --with-native-debug-symbols=external,zipped the resulting external debuginfo files for binaries (in images/bin folder) aren't there. In OpenJDK 8u there is some special casing involved for bin/java and bin/unpack200. Thus, I had to special case them for the debuginfo variant files too otherwise those files would be missing in the images folders (j2sdk-image, j2re-image). Bug: https://bugs.openjdk.java.net/browse/JDK-8252395 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252395/01/webrev/ Testing: Build in configs --with-native-debugsymbols={zipped,external,internal,none} on Linux x86 and manually debugging some launcher code. Works now with symbols. Symbols were missing before this patch. Thanks, Severin From sgehwolf at redhat.com Mon Aug 31 11:44:32 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 31 Aug 2020 13:44:32 +0200 Subject: [8u] RFR: 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries In-Reply-To: References: Message-ID: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> Sorry, wrong webrev. Now corrected. On Mon, 2020-08-31 at 10:02 +0200, Severin Gehwolf wrote: > Hi, > > Could I get a reivew of this 8u specific bug please? When configured > --with-native-debug-symbols=external,zipped the resulting external > debuginfo files for binaries (in images/bin folder) aren't there. > > In OpenJDK 8u there is some special casing involved for bin/java and > bin/unpack200. Thus, I had to special case them for the debuginfo > variant files too otherwise those files would be missing in the images > folders (j2sdk-image, j2re-image). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252395 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252395/02/webrev/ > > Testing: Build in configs --with-native-debugsymbols={zipped,external,internal,none} > on Linux x86 and manually debugging some launcher code. Works now > with symbols. Symbols were missing before this patch. > Thanks, Severin From sgehwolf at redhat.com Mon Aug 31 14:35:13 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 31 Aug 2020 16:35:13 +0200 Subject: [8u] RFR(s): 8221342: [TESTBUG] Generate Dockerfile for docker testing In-Reply-To: <20200826033840.GF969845@stopbrexit> References: <921a5acde361aa36cb840cc4ed4a9e3d1ecb29cc.camel@redhat.com> <20200826033840.GF969845@stopbrexit> Message-ID: <577f99d006f1e6808872c7f575baae15fca067a7.camel@redhat.com> Hi Andrew, On Wed, 2020-08-26 at 04:38 +0100, Andrew Hughes wrote: > On 15:05 Tue 25 Aug , Severin Gehwolf wrote: > > Hi! > > > > Please review this 8u backport of this test bug which enhances > > container testing to automatically generate docker files. This is > > useful if the development platform is not Oracle Linux 7.X (which is > > the case for me). > > > > The JDK 11 patch applies cleanly (after JDK-8220313 which is in the > > approval queue) > > I don't see how this can be said to apply cleanly. Attempting to > shuffle the patch fails to find a mapping for > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java and > test/lib/jdk/test/lib/containers/docker/DockerfileConfig.java. > > It is also beyond the scope of a script to know to duplicate these > changes between two repositories. So this alone justifies a review. OK. > This is beyond the scope of this patch, but the proposed patch > for the JDK tests seems wrong. We seem to have duplication in the > JDK test tree, caused by the JFR backport. Yes, I've noticed it. Question is whether this is worth fixing. Some tests rely on test/lib/testlibrary/jdk/testlibrary some others on test/lib/jdk/test/lib. > The jdk/test/lib/testlibrary/jdk/testlibrary/containers directory > would be the correct location for these tests. The JFR backport seems > to have started an alternate tree at jdk/test/lib/jdk/test/lib with > duplication of some files in the former directory. This should be > resolved in the 8u282 lifecycle. I'm not sure I agree but wouldn't object a patch which does this. It seems a significant piece of work and would require some re-testing of commonly run tests. Either way, this seems beyond the point of this patch (as you said). > > but doesn't compile since Files.writeString() API is > > not available in JDK 8. Replaced it with: > > > > byte[] bytes = dockerFileStr.getBytes(StandardCharsets.UTF_8); > > Files.write(dockerfile, bytes); > > > > Could this not be simplified to: > > Files.write(dockerfile, dockerFileStr.getBytes(StandardCharsets.UTF_8)); > > I don't see the need for the intermediate variable. Sure. Fixed: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221342/jdk8/02/ > Other changes look fine. Thanks for the review! Cheers, Severin From zgu at redhat.com Mon Aug 31 15:38:34 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 31 Aug 2020 11:38:34 -0400 Subject: [8u] RFR 8u: Windows build failed after 8222079 backport Message-ID: <247e2cb5-bd7a-790e-60ce-242151ff9706@redhat.com> Please review this small fix for Windows build after JDK-8222079 backport. Bug: https://bugs.openjdk.java.net/browse/JDK-8252573 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8252573/webrev.00/ Test: 64-bit and 32-bit builds on Windows Thanks, -Zhengyu From jaroslav.bachorik at datadoghq.com Mon Aug 31 17:11:23 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 31 Aug 2020 19:11:23 +0200 Subject: [8u] RFR 8250928: JFR: Improve hash algorithm for stack traces Message-ID: Please, review this backport of a hash-collision reducing fix in JFR stacktrace values from the main line. JIRA: https://bugs.openjdk.java.net/browse/JDK-8250928 Webrev: http://cr.openjdk.java.net/~jbachorik/8250928/8u/webrev/ The original patch had to be adjusted for the fact that the hash code is calculated in jfrStackTraceRepository.cpp instead of jfrStackTrace.cpp which does not exist in 8u. The gist stays the same - the hash code computation is updated to the algorithm used in the patch. Tests from tier1 and JFR were run. Cheers, -JB- From zgu at redhat.com Mon Aug 31 18:05:35 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 31 Aug 2020 14:05:35 -0400 Subject: [8u] RFR 8221408: Windows 32bit build build errors/warnings in hotspot Message-ID: <5bd307bf-cdc1-0590-9d6e-8fe8acb8f9cf@redhat.com> I would like to backport this patch to 8u for parity with Oracle 8u281. The backport is based on 11u patch and it does not apply cleanly. 1) classFileParser.cpp: change already in 8u via JDK-8205677 2) os_windows_x86.cpp: context is slightly different The original bug: https://bugs.openjdk.java.net/browse/JDK-8221408 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/f03e922bfcb8 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8221408-8u/webrev.00/ Test: Built 32-bit JDKs on Windows (release and fastdebug) Thanks, -Zhengyu From zgu at redhat.com Mon Aug 31 19:40:16 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 31 Aug 2020 15:40:16 -0400 Subject: [8u] RFR 8022535: [TEST BUG] javax/swing/text/html/parser/Test8017492.java fails Message-ID: <674814aa-7ab1-cbf3-9daa-9f3527bd4fa6@redhat.com> I would like to backport this to 8u for parity with Oracle 8u281. The original patch does not apply cleanly. 1) The test is not in 8u ProblemList.txt 2) Copyright line does not match in Test8017492.java The original bug: https://bugs.openjdk.java.net/browse/JDK-8022535 The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/e2dfcc1f04a3 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8022535-8u/webrev.00/ Test: Test8017492.java passed after patch. Thanks, -Zhengyu From ebaron at redhat.com Mon Aug 31 21:15:48 2020 From: ebaron at redhat.com (Elliott Baron) Date: Mon, 31 Aug 2020 17:15:48 -0400 Subject: [8u] RFR Backport 8219013: Update Apache Santuario (XML Signature) to version 2.1.3 Message-ID: <9b695d13-182c-1fb9-ff8f-e38768bf28ae@redhat.com> Hi, I'd like to request a review to backport 8219013 to 8u. Original fix: https://bugs.openjdk.java.net/browse/JDK-8219013 http://hg.openjdk.java.net/jdk/jdk/rev/81de17a33575 The original fix did not apply cleanly, but only required minor cosmetic changes. They are as follows: com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI: - Kept protocol as HTTPS in Javadoc compared to original fix. This was changed to HTTPS by "8068491: Update the protocol for references of docs.oracle.com to HTTPS.", which did not get propagated to JDK 9+. com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP: - Javadoc to be changed already uses HTTPS due to 8068491. org/jcp/xml/dsig/internal/dom/XMLDSigRI: - Omitted indentation fix for line added by "7191662: JCE providers should be located via ServiceLoader", which is not in 8u. legal/santuario.md: - File doesn't exist. I'll update THIRD_PARTY_README accordingly with 8229868: "Update Apache Santuario TPRM version". 8u webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8219013/webrev.00/ Testing: x86_64 build, jdk_tier1, jdk_security tests Thanks, Elliott