From yan at azul.com Mon Nov 1 12:34:48 2021 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 1 Nov 2021 15:34:48 +0300 Subject: CFV: New JDK Committer: Alexey Bakhtin Message-ID: I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. Alexey is working in the Azul JDK Team and is a Committer in the JDK 8 updates project. A list of some of his contributions to the JDK project see below [3] [4] [5]. Votes are due by 13h00 UTC on Monday, the 15th of November, 2021. Only current JDK Committers (and above) [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. [0] https://openjdk.java.net/census#abakhtin [1] https://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aalexeybakhtin+is%3Aclosed+label%3Aintegrated [4] https://github.com/openjdk/jdk/commits?author=alexeybakhtin [5] https://github.com/openjdk/jdk/commit/14e37ba3df96a6eb2591d1a29a01aa5e12c184fb 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC 8268965: TCP Connection Reset when connecting simple socket to SSL server 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) 8259707: LDAP channel binding does not work with StartTLS extension 8007632: DES/3DES keys support in PKCS12 keystore 8245527: LDAP Channel Binding support for Java GSS/Kerberos 8241960: The SHA3 message digests impl of SUN provider are not thread safe after cloned 8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException 8239787: AArch64: String.indexOf may incorrectly handle empty string Thank you, --yan From mark.reinhold at oracle.com Mon Nov 1 19:40:57 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 01 Nov 2021 12:40:57 -0700 Subject: Proposed schedule for JDK 18 Message-ID: <20211101124057.75000538@eggemoggin.niobe.net> With JDK 17 now enjoying its time the limelight, here?s a proposed schedule for JDK 18: 2021/12/09 Rampdown Phase One 2022/01/20 Rampdown Phase Two 2022/02/10 Initial Release Candidate 2022/02/24 Final Release Candidate 2022/03/22 General Availability The phases are defined in JEP 3 [1]. Comments on this proposal from JDK Committers and Reviewers [2] are welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC next Monday, 8 November, or if they?re raised and satisfactorily answered, then per the JEP 2.0 process proposal [3] this will be the schedule for JDK 18. - Mark [1] https://openjdk.java.net/jeps/3 [2] https://openjdk.java.net/census#jdk [3] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Mon Nov 1 19:57:50 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 1 Nov 2021 12:57:50 -0700 (PDT) Subject: New candidate JEP: 421: Deprecate Finalization for Removal Message-ID: <20211101195750.B5FF14C774E@eggemoggin.niobe.net> https://openjdk.java.net/jeps/421 Summary: Deprecate finalization for removal in a future release. Finalization remains enabled by default for now, but can be disabled to facilitate early testing. In a future release it will be disabled by default, and in a later release it will be removed. Maintainers of libraries and applications that rely upon finalization should consider migrating to other resource management techniques such as the try-with-resources statement and cleaners. - Mark From weijun.wang at oracle.com Mon Nov 1 20:51:34 2021 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Mon, 1 Nov 2021 20:51:34 +0000 Subject: CFV: New JDK Committer: Alexey Bakhtin In-Reply-To: References: Message-ID: Vote: yes --Weijun > On Nov 1, 2021, at 8:34 AM, Yuri Nesterenko wrote: > > I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. > > Alexey is working in the Azul JDK Team and is a Committer in the JDK 8 updates project. > > A list of some of his contributions to the JDK project see below [3] [4] [5]. > > Votes are due by 13h00 UTC on Monday, the 15th of November, 2021. > > Only current JDK Committers (and above) [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > > [0] https://openjdk.java.net/census#abakhtin > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aalexeybakhtin+is%3Aclosed+label%3Aintegrated > [4] https://github.com/openjdk/jdk/commits?author=alexeybakhtin > [5] https://github.com/openjdk/jdk/commit/14e37ba3df96a6eb2591d1a29a01aa5e12c184fb > > 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 > 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC > 8268965: TCP Connection Reset when connecting simple socket to SSL server > 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) > 8259707: LDAP channel binding does not work with StartTLS extension > 8007632: DES/3DES keys support in PKCS12 keystore > 8245527: LDAP Channel Binding support for Java GSS/Kerberos > 8241960: The SHA3 message digests impl of SUN provider are not thread safe after cloned > 8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException > 8239787: AArch64: String.indexOf may incorrectly handle empty string > > Thank you, > --yan From joe.darcy at oracle.com Mon Nov 1 22:48:52 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 1 Nov 2021 15:48:52 -0700 Subject: Reminder: file JDK 18 CSRs well ahead of anticipated December 2021 rampdown 1 deadline Message-ID: Hello, Per the expected JDK 18 schedule (https://mail.openjdk.java.net/pipermail/jdk-dev/2021-November/006199.html), JDK 18's rampdown phase one is coming up in December 2021. An advanced reminder to factor in sufficient review time for any projects needing CSRs before getting pushed into JDK 18. Large projects, including JEPs, should often use the two-phase CSR process (https://wiki.openjdk.java.net/display/csr/Main) rather than the one-phase process. The nominal SLA for each CSR phase is one week. To accommodate the possibility of needing to respond to feedback from the CSR, I recommend a large project plan for at least three weeks of CSR review time ahead of a planned integration date. Specially for JEPs, I recommend a JEP has its initial interaction with CSR no later than when the JEP reaches its Candidate stage. Cheers, -Joe CSR Lead From goetz.lindenmaier at sap.com Tue Nov 2 06:50:37 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Nov 2021 06:50:37 +0000 Subject: CFV: New JDK Committer: Alexey Bakhtin In-Reply-To: References: Message-ID: Vote: yes Best, Goetz. > -----Original Message----- > From: jdk-dev On Behalf Of Yuri > Nesterenko > Sent: Monday, November 1, 2021 1:35 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Alexey Bakhtin > > I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. > > Alexey is working in the Azul JDK Team and is a Committer in the JDK 8 > updates project. > > A list of some of his contributions to the JDK project see below [3] [4] [5]. > > Votes are due by 13h00 UTC on Monday, the 15th of November, 2021. > > Only current JDK Committers (and above) [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > > [0] https://openjdk.java.net/census#abakhtin > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aalexeybakhtin > +is%3Aclosed+label%3Aintegrated > [4] https://github.com/openjdk/jdk/commits?author=alexeybakhtin > [5] > https://github.com/openjdk/jdk/commit/14e37ba3df96a6eb2591d1a29a01a > a5e12c184fb > > 8271199: Mutual TLS handshake fails signing client certificate with custom > sensitive PKCS11 > 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC > 8268965: TCP Connection Reset when connecting simple socket to SSL server > 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) > 8259707: LDAP channel binding does not work with StartTLS extension > 8007632: DES/3DES keys support in PKCS12 keystore > 8245527: LDAP Channel Binding support for Java GSS/Kerberos > 8241960: The SHA3 message digests impl of SUN provider are not thread safe > after cloned > 8239798: SSLSocket closes socket both socket endpoints on a > SocketTimeoutException > 8239787: AArch64: String.indexOf may incorrectly handle empty string > > Thank you, > --yan From yan at azul.com Tue Nov 2 07:02:18 2021 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 2 Nov 2021 10:02:18 +0300 Subject: CFV: New JDK Committer: Alexey Bakhtin In-Reply-To: References: Message-ID: <966f11b6-8126-9653-b261-e48213eae6ea@azul.com> and, Vote: yes --yan On 01.11.2021 15:34, Yuri Nesterenko wrote: > I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. > > Alexey is working in the Azul JDK Team and is a Committer in the JDK 8 updates project. > > A list of some of his contributions to the JDK project see below [3] [4] [5]. > > Votes are due by 13h00 UTC on Monday, the 15th of November, 2021. > > Only current JDK Committers (and above) [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > > [0] https://openjdk.java.net/census#abakhtin > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aalexeybakhtin+is%3Aclosed+label%3Aintegrated > [4] https://github.com/openjdk/jdk/commits?author=alexeybakhtin > [5] https://github.com/openjdk/jdk/commit/14e37ba3df96a6eb2591d1a29a01aa5e12c184fb > > 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 > 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC > 8268965: TCP Connection Reset when connecting simple socket to SSL server > 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) > 8259707: LDAP channel binding does not work with StartTLS extension > 8007632: DES/3DES keys support in PKCS12 keystore > 8245527: LDAP Channel Binding support for Java GSS/Kerberos > 8241960: The SHA3 message digests impl of SUN provider are not thread safe after cloned > 8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException > 8239787: AArch64: String.indexOf may incorrectly handle empty string > > Thank you, > --yan > From sgehwolf at redhat.com Tue Nov 2 09:26:40 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 02 Nov 2021 10:26:40 +0100 Subject: CFV: New JDK Committer: Alexey Bakhtin In-Reply-To: References: Message-ID: Vote: yes On Mon, 2021-11-01 at 15:34 +0300, Yuri Nesterenko wrote: > I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. From abrygin at azul.com Tue Nov 2 10:02:21 2021 From: abrygin at azul.com (Andrew Brygin) Date: Tue, 2 Nov 2021 13:02:21 +0300 Subject: CFV: New JDK Committer: Alexey Bakhtin In-Reply-To: References: Message-ID: Vote: yes Thanks, Andrew On 01/11/2021 15:34, Yuri Nesterenko wrote: > I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. > > Alexey is working in the Azul JDK Team and is a Committer in the JDK 8 updates project. > > A list of some of his contributions to the JDK project see below [3] [4] [5]. > > Votes are due by 13h00 UTC on Monday, the 15th of November, 2021. > > Only current JDK Committers (and above) [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > > [0] https://openjdk.java.net/census#abakhtin > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aalexeybakhtin+is%3Aclosed+label%3Aintegrated > [4] https://github.com/openjdk/jdk/commits?author=alexeybakhtin > [5] https://github.com/openjdk/jdk/commit/14e37ba3df96a6eb2591d1a29a01aa5e12c184fb > > 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 > 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC > 8268965: TCP Connection Reset when connecting simple socket to SSL server > 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) > 8259707: LDAP channel binding does not work with StartTLS extension > 8007632: DES/3DES keys support in PKCS12 keystore > 8245527: LDAP Channel Binding support for Java GSS/Kerberos > 8241960: The SHA3 message digests impl of SUN provider are not thread safe after cloned > 8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException > 8239787: AArch64: String.indexOf may incorrectly handle empty string > > Thank you, > --yan > From aleksej.efimov at oracle.com Tue Nov 2 10:32:27 2021 From: aleksej.efimov at oracle.com (Aleksei Efimov) Date: Tue, 2 Nov 2021 10:32:27 +0000 Subject: CFV: New JDK Committer: Alexey Bakhtin In-Reply-To: References: Message-ID: Vote: yes Best, Aleksei ________________________________ From: jdk-dev on behalf of Yuri Nesterenko Sent: Monday, November 1, 2021 12:34 PM To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Committer: Alexey Bakhtin I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. Alexey is working in the Azul JDK Team and is a Committer in the JDK 8 updates project. A list of some of his contributions to the JDK project see below [3] [4] [5]. Votes are due by 13h00 UTC on Monday, the 15th of November, 2021. Only current JDK Committers (and above) [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. [0] https://openjdk.java.net/census#abakhtin [1] https://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aalexeybakhtin+is%3Aclosed+label%3Aintegrated [4] https://github.com/openjdk/jdk/commits?author=alexeybakhtin [5] https://github.com/openjdk/jdk/commit/14e37ba3df96a6eb2591d1a29a01aa5e12c184fb 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC 8268965: TCP Connection Reset when connecting simple socket to SSL server 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) 8259707: LDAP channel binding does not work with StartTLS extension 8007632: DES/3DES keys support in PKCS12 keystore 8245527: LDAP Channel Binding support for Java GSS/Kerberos 8241960: The SHA3 message digests impl of SUN provider are not thread safe after cloned 8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException 8239787: AArch64: String.indexOf may incorrectly handle empty string Thank you, --yan From daniel.fuchs at oracle.com Tue Nov 2 10:37:19 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 2 Nov 2021 10:37:19 +0000 Subject: CFV: New JDK Committer: Alexey Bakhtin In-Reply-To: References: Message-ID: <38182b68-eaec-427c-2450-3e1a855cabc6@oracle.com> Vote: yes best regards, -- daniel On 01/11/2021 12:34, Yuri Nesterenko wrote: > I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. From martin.doerr at sap.com Tue Nov 2 10:40:36 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 2 Nov 2021 10:40:36 +0000 Subject: CFV: New JDK Committer: Alexey Bakhtin In-Reply-To: References: Message-ID: Vote: yes Best regards, Martin Von: jdk-dev im Auftrag von Yuri Nesterenko Datum: Montag, 1. November 2021 um 13:36 An: jdk-dev at openjdk.java.net Betreff: CFV: New JDK Committer: Alexey Bakhtin I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. Alexey is working in the Azul JDK Team and is a Committer in the JDK 8 updates project. A list of some of his contributions to the JDK project see below [3] [4] [5]. Votes are due by 13h00 UTC on Monday, the 15th of November, 2021. Only current JDK Committers (and above) [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. [0] https://openjdk.java.net/census#abakhtin [1] https://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aalexeybakhtin+is%3Aclosed+label%3Aintegrated [4] https://github.com/openjdk/jdk/commits?author=alexeybakhtin [5] https://github.com/openjdk/jdk/commit/14e37ba3df96a6eb2591d1a29a01aa5e12c184fb 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC 8268965: TCP Connection Reset when connecting simple socket to SSL server 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) 8259707: LDAP channel binding does not work with StartTLS extension 8007632: DES/3DES keys support in PKCS12 keystore 8245527: LDAP Channel Binding support for Java GSS/Kerberos 8241960: The SHA3 message digests impl of SUN provider are not thread safe after cloned 8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException 8239787: AArch64: String.indexOf may incorrectly handle empty string Thank you, --yan From liangchenblue at gmail.com Tue Nov 2 14:00:15 2021 From: liangchenblue at gmail.com (-) Date: Tue, 2 Nov 2021 09:00:15 -0500 Subject: New candidate JEP: 421: Deprecate Finalization for Removal In-Reply-To: <20211101195750.B5FF14C774E@eggemoggin.niobe.net> References: <20211101195750.B5FF14C774E@eggemoggin.niobe.net> Message-ID: On a side note, will the actual removal of finalization become a dependency of the actual removal of the security manager? I recall when the security manager was deprecated for removal, developers pointed out that there can be security risks with finalization in the mailing list. On Mon, Nov 1, 2021 at 2:58 PM wrote: > > https://openjdk.java.net/jeps/421 > > Summary: Deprecate finalization for removal in a future > release. Finalization remains enabled by default for now, but can > be disabled to facilitate early testing. In a future release it > will be disabled by default, and in a later release it will be > removed. Maintainers of libraries and applications that rely upon > finalization should consider migrating to other resource management > techniques such as the try-with-resources statement and cleaners. > > - Mark From Alan.Bateman at oracle.com Tue Nov 2 14:20:32 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Nov 2021 14:20:32 +0000 Subject: New candidate JEP: 421: Deprecate Finalization for Removal In-Reply-To: References: <20211101195750.B5FF14C774E@eggemoggin.niobe.net> Message-ID: <4e160617-05bf-cc12-281e-110c763869f9@oracle.com> On 02/11/2021 14:00, - wrote: > On a side note, will the actual removal of finalization become a > dependency of the actual removal of the security manager? I recall > when the security manager was deprecated for removal, developers > pointed out that there can be security risks with finalization in the > mailing list. > I suspect you may be thinking about classes that specify SM permission checks in their constructors. If so then no SM means the permission check doesn't do anything. If finalization is disabled or removed then the specific attack isn't a concern. So I think independent for that discussion, assuming this is what you mean. -Alan From liangchenblue at gmail.com Tue Nov 2 14:31:19 2021 From: liangchenblue at gmail.com (-) Date: Tue, 2 Nov 2021 09:31:19 -0500 Subject: New candidate JEP: 421: Deprecate Finalization for Removal In-Reply-To: <4e160617-05bf-cc12-281e-110c763869f9@oracle.com> References: <20211101195750.B5FF14C774E@eggemoggin.niobe.net> <4e160617-05bf-cc12-281e-110c763869f9@oracle.com> Message-ID: Indeed. I was reminded of a discussion [1][2] back in July when I saw this JEP candidate. Now looking at it again, I guess we can easily prevent this risk once this JEP is implemented (so finalizers are no-op and attacks cannot happen even if the security manager is disallowed), and we might not need to remove finalizers before security managers as long as we can disable finalizers. https://mail.openjdk.java.net/pipermail/jdk-dev/2021-July/thread.html#5805 https://mail.openjdk.java.net/pipermail/jdk-dev/2021-July/005808.html On Tue, Nov 2, 2021 at 9:20 AM Alan Bateman wrote: > > On 02/11/2021 14:00, - wrote: > > On a side note, will the actual removal of finalization become a > > dependency of the actual removal of the security manager? I recall > > when the security manager was deprecated for removal, developers > > pointed out that there can be security risks with finalization in the > > mailing list. > > > I suspect you may be thinking about classes that specify SM permission > checks in their constructors. If so then no SM means the permission > check doesn't do anything. If finalization is disabled or removed then > the specific attack isn't a concern. So I think independent for that > discussion, assuming this is what you mean. > > -Alan From daniel.fuchs at oracle.com Tue Nov 2 15:14:30 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 2 Nov 2021 15:14:30 +0000 Subject: CFV: New JDK Committer: Andrey Turbanov Message-ID: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Hi, I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. Andrey works for the Devexperts company, and has 10 years of experience with the Java language. Andrey loves using IDEs and their inspection features, which he uses to track potential bugs and improvements in the JDK code base. Andrey has contributed more than 30 changesets [2] to the openjdk repository. Votes are due by 12:00 UTC November 17th, 2021. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, -- daniel [1] https://openjdk.java.net/census#aturbanov [2] https://github.com/openjdk/jdk/commits?author=turbanoff [3] http://openjdk.java.net/census [4] http://openjdk.java.net/bylaws#lazy-consensus From pavel.rappo at oracle.com Tue Nov 2 15:37:13 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 2 Nov 2021 15:37:13 +0000 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: <74F464BA-AFBF-4FE8-91A9-43E5EC128383@oracle.com> Vote: yes > On 2 Nov 2021, at 15:14, Daniel Fuchs wrote: > > Hi, > > I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. > > Andrey works for the Devexperts company, and has 10 years > of experience with the Java language. > > Andrey loves using IDEs and their inspection features, which > he uses to track potential bugs and improvements in the JDK > code base. > > Andrey has contributed more than 30 changesets [2] to the > openjdk repository. > > Votes are due by 12:00 UTC November 17th, 2021. > > Only current JDK Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#aturbanov > [2] https://github.com/openjdk/jdk/commits?author=turbanoff > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus From pankaj.b.bansal at oracle.com Tue Nov 2 15:39:05 2021 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 2 Nov 2021 15:39:05 +0000 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: Vote: yes From: jdk-dev on behalf of Daniel Fuchs Date: Tuesday, 2 November 2021 at 8:44 PM To: jdk-dev Subject: CFV: New JDK Committer: Andrey Turbanov Hi, I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. Andrey works for the Devexperts company, and has 10 years of experience with the Java language. Andrey loves using IDEs and their inspection features, which he uses to track potential bugs and improvements in the JDK code base. Andrey has contributed more than 30 changesets [2] to the openjdk repository. Votes are due by 12:00 UTC November 17th, 2021. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, -- daniel [1] https://openjdk.java.net/census#aturbanov [2] https://github.com/openjdk/jdk/commits?author=turbanoff [3] http://openjdk.java.net/census [4] http://openjdk.java.net/bylaws#lazy-consensus From aleksej.efimov at oracle.com Tue Nov 2 15:41:27 2021 From: aleksej.efimov at oracle.com (Aleksei Efimov) Date: Tue, 2 Nov 2021 15:41:27 +0000 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: Vote: yes Best Regards, Aleksei ________________________________ From: jdk-dev on behalf of Daniel Fuchs Sent: Tuesday, November 2, 2021 3:14 PM To: jdk-dev Subject: CFV: New JDK Committer: Andrey Turbanov Hi, I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. Andrey works for the Devexperts company, and has 10 years of experience with the Java language. Andrey loves using IDEs and their inspection features, which he uses to track potential bugs and improvements in the JDK code base. Andrey has contributed more than 30 changesets [2] to the openjdk repository. Votes are due by 12:00 UTC November 17th, 2021. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, -- daniel [1] https://openjdk.java.net/census#aturbanov [2] https://github.com/openjdk/jdk/commits?author=turbanoff [3] http://openjdk.java.net/census [4] http://openjdk.java.net/bylaws#lazy-consensus From naoto.sato at oracle.com Tue Nov 2 15:59:45 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 2 Nov 2021 08:59:45 -0700 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: <13799ebc-9507-eeab-c827-73f07e2deaf0@oracle.com> Vote: yes Naoto On 11/2/21 8:14 AM, Daniel Fuchs wrote: > Hi, > > I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. > > Andrey works for the Devexperts company, and has 10 years > of experience with the Java language. > > Andrey loves using IDEs and their inspection features, which > he uses to track potential bugs and improvements in the JDK > code base. > > Andrey has contributed more than 30 changesets [2] to the > openjdk repository. > > Votes are due by 12:00 UTC November 17th, 2021. > > Only current JDK Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#aturbanov > [2] https://github.com/openjdk/jdk/commits?author=turbanoff > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus From sean.coffey at oracle.com Tue Nov 2 16:19:17 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 2 Nov 2021 16:19:17 +0000 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: <63c2920d-e32c-0273-107c-4cc07e9fdc2b@oracle.com> Vote: yes regards, Sean. On 02/11/2021 15:14, Daniel Fuchs wrote: > Hi, > > I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. > > Andrey works for the Devexperts company, and has 10 years > of experience with the Java language. > > Andrey loves using IDEs and their inspection features, which > he uses to track potential bugs and improvements in the JDK > code base. > > Andrey has contributed more than 30 changesets [2] to the > openjdk repository. > > Votes are due by 12:00 UTC November 17th, 2021. > > Only current JDK Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#aturbanov > [2] https://github.com/openjdk/jdk/commits?author=turbanoff > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus From chegar999 at gmail.com Tue Nov 2 16:28:06 2021 From: chegar999 at gmail.com (Chris Hegarty) Date: Tue, 2 Nov 2021 16:28:06 +0000 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <63c2920d-e32c-0273-107c-4cc07e9fdc2b@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> <63c2920d-e32c-0273-107c-4cc07e9fdc2b@oracle.com> Message-ID: <857beee9-fbda-87ef-1f52-a0698b49a43b@gmail.com> >> I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. Vote: Yes -Chris. From yan at azul.com Tue Nov 2 16:38:16 2021 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 2 Nov 2021 19:38:16 +0300 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: Vote: yes --yan On 02.11.2021 18:14, Daniel Fuchs wrote: > Hi, > > I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. From roger.riggs at oracle.com Tue Nov 2 17:03:09 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 2 Nov 2021 13:03:09 -0400 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: <60c52f46-9031-1e5b-00e1-013f8c4b621f@oracle.com> Vote: Yes On 11/2/21 11:14 AM, Daniel Fuchs wrote: > I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. From brian.burkhalter at oracle.com Tue Nov 2 17:06:10 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 2 Nov 2021 17:06:10 +0000 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: Vote: Yes On Nov 2, 2021, at 8:14 AM, Daniel FUCHS > wrote: I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. From hohensee at amazon.com Tue Nov 2 17:49:07 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 2 Nov 2021 17:49:07 +0000 Subject: CFV: New JDK Committer: Alexey Bakhtin Message-ID: Vote: yes ?-----Original Message----- From: jdk-dev on behalf of Yuri Nesterenko Date: Monday, November 1, 2021 at 5:36 AM To: "jdk-dev at openjdk.java.net" Subject: CFV: New JDK Committer: Alexey Bakhtin I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. Alexey is working in the Azul JDK Team and is a Committer in the JDK 8 updates project. A list of some of his contributions to the JDK project see below [3] [4] [5]. Votes are due by 13h00 UTC on Monday, the 15th of November, 2021. Only current JDK Committers (and above) [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. [0] https://openjdk.java.net/census#abakhtin [1] https://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aalexeybakhtin+is%3Aclosed+label%3Aintegrated [4] https://github.com/openjdk/jdk/commits?author=alexeybakhtin [5] https://github.com/openjdk/jdk/commit/14e37ba3df96a6eb2591d1a29a01aa5e12c184fb 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC 8268965: TCP Connection Reset when connecting simple socket to SSL server 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) 8259707: LDAP channel binding does not work with StartTLS extension 8007632: DES/3DES keys support in PKCS12 keystore 8245527: LDAP Channel Binding support for Java GSS/Kerberos 8241960: The SHA3 message digests impl of SUN provider are not thread safe after cloned 8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException 8239787: AArch64: String.indexOf may incorrectly handle empty string Thank you, --yan From akozlov at azul.com Tue Nov 2 18:21:27 2021 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 2 Nov 2021 21:21:27 +0300 Subject: CFV: New JDK Committer: Alexey Bakhtin In-Reply-To: References: Message-ID: Vote: yes On 11/1/21 15:34, Yuri Nesterenko wrote: > I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. > > Alexey is working in the Azul JDK Team and is a Committer in the JDK 8 updates project. > > A list of some of his contributions to the JDK project see below [3] [4] [5]. > > Votes are due by 13h00 UTC on Monday, the 15th of November, 2021. > > Only current JDK Committers (and above) [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > > [0] https://openjdk.java.net/census#abakhtin > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aalexeybakhtin+is%3Aclosed+label%3Aintegrated > [4] https://github.com/openjdk/jdk/commits?author=alexeybakhtin > [5] https://github.com/openjdk/jdk/commit/14e37ba3df96a6eb2591d1a29a01aa5e12c184fb > > 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 > 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC > 8268965: TCP Connection Reset when connecting simple socket to SSL server > 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) > 8259707: LDAP channel binding does not work with StartTLS extension > 8007632: DES/3DES keys support in PKCS12 keystore > 8245527: LDAP Channel Binding support for Java GSS/Kerberos > 8241960: The SHA3 message digests impl of SUN provider are not thread safe after cloned > 8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException > 8239787: AArch64: String.indexOf may incorrectly handle empty string > > Thank you, > --yan > From alexey.ivanov at oracle.com Tue Nov 2 19:24:09 2021 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Tue, 2 Nov 2021 19:24:09 +0000 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: Vote: yes On 02/11/2021 15:14, Daniel Fuchs wrote: > > I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. -- Regards, Alexey From lihuaming3 at huawei.com Wed Nov 3 01:07:30 2021 From: lihuaming3 at huawei.com (lihuaming (A)) Date: Wed, 3 Nov 2021 01:07:30 +0000 Subject: =?utf-8?B?562U5aSNOiBOZXcgSkRLIENvbW1pdHRlcjogQW5kcmV5IFR1cmJhbm92?= In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: <338481cd52a747a290cf8704ed6d4918@huawei.com> Vote: yes Hamlin Li From qingfeng.yy at alibaba-inc.com Wed Nov 3 01:43:26 2021 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Wed, 03 Nov 2021 09:43:26 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaQ0ZWOiBOZXcgSkRLIENvbW1pdHRlcjogQW5kcmV5IFR1cmJhbm92?= In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: <769db7ac-d010-454b-b38a-daac9a761cf6.qingfeng.yy@alibaba-inc.com> vote: yes Best regards? Yi Yang ??????????------------------------------------------------------------------ ????Daniel Fuchs ????2021?11?02? 23:14:30 ????jdk-dev ????CFV: New JDK Committer: Andrey Turbanov Hi, I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. Andrey works for the Devexperts company, and has 10 years of experience with the Java language. Andrey loves using IDEs and their inspection features, which he uses to track potential bugs and improvements in the JDK code base. Andrey has contributed more than 30 changesets [2] to the openjdk repository. Votes are due by 12:00 UTC November 17th, 2021. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, -- daniel [1] https://openjdk.java.net/census#aturbanov [2] https://github.com/openjdk/jdk/commits?author=turbanoff [3] http://openjdk.java.net/census [4] http://openjdk.java.net/bylaws#lazy-consensus From jai.forums2013 at gmail.com Wed Nov 3 02:38:59 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 3 Nov 2021 08:08:59 +0530 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: Vote: yes -Jaikiran On 02/11/21 8:44 pm, Daniel Fuchs wrote: > Hi, > > I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. > > Andrey works for the Devexperts company, and has 10 years > of experience with the Java language. > > Andrey loves using IDEs and their inspection features, which > he uses to track potential bugs and improvements in the JDK > code base. > > Andrey has contributed more than 30 changesets [2] to the > openjdk repository. > > Votes are due by 12:00 UTC November 17th, 2021. > > Only current JDK Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#aturbanov > [2] https://github.com/openjdk/jdk/commits?author=turbanoff > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus From roger.riggs at oracle.com Wed Nov 3 14:02:35 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 3 Nov 2021 10:02:35 -0400 Subject: CFV: New JDK Committer: Alexey Bakhtin In-Reply-To: References: Message-ID: Vote: Yes On 11/1/21 8:34 AM, Yuri Nesterenko wrote: > I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. From christoph.langer at sap.com Wed Nov 3 22:42:16 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 3 Nov 2021 22:42:16 +0000 Subject: CFV: New JDK Committer: Alexey Bakhtin In-Reply-To: References: Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Yuri > Nesterenko > Sent: Montag, 1. November 2021 13:35 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Alexey Bakhtin > > I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. > > Alexey is working in the Azul JDK Team and is a Committer in the JDK 8 > updates project. > > A list of some of his contributions to the JDK project see below [3] [4] [5]. > > Votes are due by 13h00 UTC on Monday, the 15th of November, 2021. > > Only current JDK Committers (and above) [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > > [0] https://openjdk.java.net/census#abakhtin > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aalexeybakhtin > +is%3Aclosed+label%3Aintegrated > [4] https://github.com/openjdk/jdk/commits?author=alexeybakhtin > [5] > https://github.com/openjdk/jdk/commit/14e37ba3df96a6eb2591d1a29a01a > a5e12c184fb > > 8271199: Mutual TLS handshake fails signing client certificate with custom > sensitive PKCS11 > 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC > 8268965: TCP Connection Reset when connecting simple socket to SSL server > 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) > 8259707: LDAP channel binding does not work with StartTLS extension > 8007632: DES/3DES keys support in PKCS12 keystore > 8245527: LDAP Channel Binding support for Java GSS/Kerberos > 8241960: The SHA3 message digests impl of SUN provider are not thread safe > after cloned > 8239798: SSLSocket closes socket both socket endpoints on a > SocketTimeoutException > 8239787: AArch64: String.indexOf may incorrectly handle empty string > > Thank you, > --yan From christoph.langer at sap.com Wed Nov 3 22:42:48 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 3 Nov 2021 22:42:48 +0000 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Daniel Fuchs > Sent: Dienstag, 2. November 2021 16:15 > To: jdk-dev > Subject: CFV: New JDK Committer: Andrey Turbanov > > Hi, > > I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. > > Andrey works for the Devexperts company, and has 10 years of experience > with the Java language. > > Andrey loves using IDEs and their inspection features, which he uses to track > potential bugs and improvements in the JDK code base. > > Andrey has contributed more than 30 changesets [2] to the openjdk > repository. > > Votes are due by 12:00 UTC November 17th, 2021. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#aturbanov > [2] https://github.com/openjdk/jdk/commits?author=turbanoff > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus From claes.redestad at oracle.com Wed Nov 3 22:57:20 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 3 Nov 2021 23:57:20 +0100 Subject: CFV: New JDK Committer: Alexey Bakhtin In-Reply-To: References: Message-ID: <1e51e134-2e2c-9a80-31a9-cf64e935bd26@oracle.com> Vote: yes On 2021-11-01 13:34, Yuri Nesterenko wrote: > I hereby nominate Alexey Bakhtin (abakhtin) [0] to JDK Committer. > > Alexey is working in the Azul JDK Team and is a Committer in the JDK 8 updates project. > > A list of some of his contributions to the JDK project see below [3] [4] [5]. > > Votes are due by 13h00 UTC on Monday, the 15th of November, 2021. > > Only current JDK Committers (and above) [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > > [0] https://openjdk.java.net/census#abakhtin > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aalexeybakhtin+is%3Aclosed+label%3Aintegrated > [4] https://github.com/openjdk/jdk/commits?author=alexeybakhtin > [5] https://github.com/openjdk/jdk/commit/14e37ba3df96a6eb2591d1a29a01aa5e12c184fb > > 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 > 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC > 8268965: TCP Connection Reset when connecting simple socket to SSL server > 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) > 8259707: LDAP channel binding does not work with StartTLS extension > 8007632: DES/3DES keys support in PKCS12 keystore > 8245527: LDAP Channel Binding support for Java GSS/Kerberos > 8241960: The SHA3 message digests impl of SUN provider are not thread safe after cloned > 8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException > 8239787: AArch64: String.indexOf may incorrectly handle empty string > > Thank you, > --yan From shade at openjdk.java.net Thu Nov 4 08:23:27 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 4 Nov 2021 08:23:27 GMT Subject: RFR: 8276623: JDK-8275650 accidentally pushed "out" file Message-ID: See the commit: https://github.com/openjdk/jdk/commit/32895ac60949ccceb0a3d25c73ec5e3a00c29593 I think this is a trivial fix to remove the accidental addition. I only found this because my local filesystem also has "out" file, and git complained about that pull is about to overwrite it. ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/6248/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6248&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276623 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6248.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6248/head:pull/6248 PR: https://git.openjdk.java.net/jdk/pull/6248 From tschatzl at openjdk.java.net Thu Nov 4 08:36:16 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 4 Nov 2021 08:36:16 GMT Subject: RFR: 8276623: JDK-8275650 accidentally pushed "out" file In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 08:16:44 GMT, Aleksey Shipilev wrote: > See the commit: https://github.com/openjdk/jdk/commit/32895ac60949ccceb0a3d25c73ec5e3a00c29593 > > I think this is a trivial fix to remove the accidental addition. I only found this because my local filesystem also has "out" file, and git complained about that pull is about to overwrite it. Lgtm and trivial. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6248 From dholmes at openjdk.java.net Thu Nov 4 09:07:19 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 4 Nov 2021 09:07:19 GMT Subject: RFR: 8276623: JDK-8275650 accidentally pushed "out" file In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 08:16:44 GMT, Aleksey Shipilev wrote: > See the commit: https://github.com/openjdk/jdk/commit/32895ac60949ccceb0a3d25c73ec5e3a00c29593 > > I think this is a trivial fix to remove the accidental addition. I only found this because my local filesystem also has "out" file, and git complained about that pull is about to overwrite it. Thanks for fixing this Aleksey. The fact it was considered a binary file made it easy to overlook in the PR. Yes this is a trivial fix. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6248 From shade at openjdk.java.net Thu Nov 4 09:07:19 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 4 Nov 2021 09:07:19 GMT Subject: RFR: 8276623: JDK-8275650 accidentally pushed "out" file In-Reply-To: References: Message-ID: <1J11xoHlyNIKHZxbuvLcNWri1jk43XFq4-rd0dc6FE4=.8407d811-5757-4f23-a1db-093879e46bd7@github.com> On Thu, 4 Nov 2021 08:16:44 GMT, Aleksey Shipilev wrote: > See the commit: https://github.com/openjdk/jdk/commit/32895ac60949ccceb0a3d25c73ec5e3a00c29593 > > I think this is a trivial fix to remove the accidental addition. I only found this because my local filesystem also has "out" file, and git complained about that pull is about to overwrite it. Thanks for quick reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/6248 From shade at openjdk.java.net Thu Nov 4 09:07:20 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 4 Nov 2021 09:07:20 GMT Subject: Integrated: 8276623: JDK-8275650 accidentally pushed "out" file In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 08:16:44 GMT, Aleksey Shipilev wrote: > See the commit: https://github.com/openjdk/jdk/commit/32895ac60949ccceb0a3d25c73ec5e3a00c29593 > > I think this is a trivial fix to remove the accidental addition. I only found this because my local filesystem also has "out" file, and git complained about that pull is about to overwrite it. This pull request has now been integrated. Changeset: c62b3476 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/c62b3476ce12cea633abead0d6376ea0a05f92f9 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod 8276623: JDK-8275650 accidentally pushed "out" file Reviewed-by: tschatzl, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/6248 From magnus.ihse.bursie at oracle.com Thu Nov 4 09:39:32 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Nov 2021 10:39:32 +0100 Subject: CFV: New JDK Committer: Andrey Turbanov In-Reply-To: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> References: <71e77ca9-6930-b621-f9bc-63f6ae5e3708@oracle.com> Message-ID: Vote: yes /Magnus On 2021-11-02 16:14, Daniel Fuchs wrote: > Hi, > > I hereby nominate Andrey Turbanov [1] (aturbanov) to JDK Committer. > > Andrey works for the Devexperts company, and has 10 years > of experience with the Java language. > > Andrey loves using IDEs and their inspection features, which > he uses to track potential bugs and improvements in the JDK > code base. > > Andrey has contributed more than 30 changesets [2] to the > openjdk repository. > > Votes are due by 12:00 UTC November 17th, 2021. > > Only current JDK Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#aturbanov > [2] https://github.com/openjdk/jdk/commits?author=turbanoff > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus From mark.reinhold at oracle.com Fri Nov 5 16:57:52 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 05 Nov 2021 09:57:52 -0700 Subject: JEP proposed to target JDK 18: 418: Internet-Address Resolution SPI In-Reply-To: <20211028204445.CADA14C5BDF@eggemoggin.niobe.net> References: <20211028204445.CADA14C5BDF@eggemoggin.niobe.net> Message-ID: <20211105095752.433890333@eggemoggin.niobe.net> 2021/10/28 13:44:45 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 18: > > 418: Internet-Address Resolution SPI > https://openjdk.java.net/jeps/418 > > Summary: Define a service-provider interface (SPI) for host name > and address resolution, so that java.net.InetAddress can make use of > resolvers other than the platform's built-in resolver. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Thursday, 4 November, or if they?re raised > and then satisfactorily answered, then per the JEP 2.0 process proposal > [2] I?ll target this JEP to JDK 18. Hearing no objections, I?ve targeted this JEP to JDK 18. - Mark From coleen.phillimore at oracle.com Mon Nov 8 16:14:29 2021 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 8 Nov 2021 11:14:29 -0500 Subject: Result: New JDK Reviewer: Patricio Chilano Mateo Message-ID: Voting for Patricio Chilano Mateo [1] is now closed. Yes: 25 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. Coleen Phillimore [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-October/006167.html [2]http://openjdk.java.net/bylaws#lazy-consensus From coleen.phillimore at oracle.com Mon Nov 8 16:15:59 2021 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 8 Nov 2021 11:15:59 -0500 Subject: Result: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <6d997b72-022c-776e-c8c3-7567b9392443@oracle.com> On 11/8/21 11:14 AM, coleen.phillimore at oracle.com wrote: > Voting for Patricio Chilano Mateo [1] is now closed. > > Yes: 25 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus [2], this is > sufficient to approve the nomination. > > Coleen Phillimore > > [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2021-October/006167.html > [2]http://openjdk.java.net/bylaws#lazy-consensus > (resending cc'ing the registrar). From mario.g.pavlov at gmail.com Thu Nov 11 16:33:54 2021 From: mario.g.pavlov at gmail.com (Mario Pavlov) Date: Thu, 11 Nov 2021 18:33:54 +0200 Subject: JDK-8273642: The UUID class does not implement RFC4122 fully (UUID type 5 is missing). Message-ID: Hi friends, I was wondering if we could take one of the low prio enhancements related to the UUID class, like the one mentioned in the subject. I'm a long time user of JDK and I'm looking to start making contributions. I went over OCA and the OpenJDK development pages. What are the next steps? Should I get approval to work on this? Thank you. Cheers, Mario From shade at redhat.com Thu Nov 11 17:00:49 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 11 Nov 2021 18:00:49 +0100 Subject: JDK-8273642: The UUID class does not implement RFC4122 fully (UUID type 5 is missing). In-Reply-To: References: Message-ID: <7f764f7f-7b6d-329d-ba5b-7f45a8535656@redhat.com> On 11/11/21 5:33 PM, Mario Pavlov wrote: > What are the next steps? Should I get approval to work on this? AFAIU, the nature of this work implies extending the UUID spec a little, since we would need to mention Version 5 somewhere, which would require submitting the CSR [1] and working through it. This would require JIRA access privileges that are not granted to first-time contributors. I would suggest to do something that does not require API tweaks first, to get the taste of JDK development. Otherwise, if you have anyone who can help you with CSR, I would say the next step would be doing a PR against mainline that implements the feature. -- Thanks, -Aleksey [1] https://wiki.openjdk.java.net/display/csr/Main From mario.g.pavlov at gmail.com Thu Nov 11 17:17:51 2021 From: mario.g.pavlov at gmail.com (Mario Pavlov) Date: Thu, 11 Nov 2021 19:17:51 +0200 Subject: JDK-8273642: The UUID class does not implement RFC4122 fully (UUID type 5 is missing). In-Reply-To: <7f764f7f-7b6d-329d-ba5b-7f45a8535656@redhat.com> References: <7f764f7f-7b6d-329d-ba5b-7f45a8535656@redhat.com> Message-ID: Hi Aleksey, Thanks for your answer. In that case maybe I should start with something even smaller, e.g. https://bugs.openjdk.java.net/browse/JDK-8192784 What do you think? Cheers, Mario On Thu, Nov 11, 2021 at 7:00 PM Aleksey Shipilev wrote: > On 11/11/21 5:33 PM, Mario Pavlov wrote: > > What are the next steps? Should I get approval to work on this? > > AFAIU, the nature of this work implies extending the UUID spec a little, > since we would need to > mention Version 5 somewhere, which would require submitting the CSR [1] > and working through it. This > would require JIRA access privileges that are not granted to first-time > contributors. I would > suggest to do something that does not require API tweaks first, to get the > taste of JDK development. > > Otherwise, if you have anyone who can help you with CSR, I would say the > next step would be doing a > PR against mainline that implements the feature. > > -- > Thanks, > -Aleksey > > [1] https://wiki.openjdk.java.net/display/csr/Main > > From Alan.Bateman at oracle.com Thu Nov 11 17:44:11 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Nov 2021 17:44:11 +0000 Subject: JDK-8273642: The UUID class does not implement RFC4122 fully (UUID type 5 is missing). In-Reply-To: References: Message-ID: <73ebf423-6f64-ea68-544f-ffee4bf6e161@oracle.com> On 11/11/2021 16:33, Mario Pavlov wrote: > Hi friends, > I was wondering if we could take one of the low prio enhancements related > to the UUID class, like the one mentioned in the subject. > I'm a long time user of JDK and I'm looking to start making contributions. > I went over OCA and the OpenJDK development pages. > What are the next steps? Should I get approval to work on this? > It's probably best to start a discussion on core-libs-dev about this to see whether extending the API to support version 5 is worth doing. It's possible you might have to include security-dev in the discussion due to concerns about version 5 using SHA-1 (SHA-1 is obsolete these days, the JDK recently disabled it uses in signed JARs for example). -Alan. From Alan.Bateman at oracle.com Thu Nov 11 18:02:55 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Nov 2021 18:02:55 +0000 Subject: JDK-8273642: The UUID class does not implement RFC4122 fully (UUID type 5 is missing). In-Reply-To: References: <7f764f7f-7b6d-329d-ba5b-7f45a8535656@redhat.com> Message-ID: <612c8c56-ad28-06f6-e8cc-ff6e118d60b6@oracle.com> On 11/11/2021 17:17, Mario Pavlov wrote: > Hi Aleksey, > Thanks for your answer. > In that case maybe I should start with something even smaller, e.g. > https://bugs.openjdk.java.net/browse/JDK-8192784 > What do you think? UUID.fromString(String) was re-implemented in JDK 15 with a more optimal implementation so I suspect JDK-8192784 can be closed. One thing you could do is do some benchmarks to see if there is any further opportunity and bring it to core-libs-dev for discussion. Note that identifying enhancements in JBS that can be closed is a contribution in itself. -Alan From mario.g.pavlov at gmail.com Thu Nov 11 18:34:05 2021 From: mario.g.pavlov at gmail.com (Mario Pavlov) Date: Thu, 11 Nov 2021 20:34:05 +0200 Subject: JDK-8273642: The UUID class does not implement RFC4122 fully (UUID type 5 is missing). In-Reply-To: <612c8c56-ad28-06f6-e8cc-ff6e118d60b6@oracle.com> References: <7f764f7f-7b6d-329d-ba5b-7f45a8535656@redhat.com> <612c8c56-ad28-06f6-e8cc-ff6e118d60b6@oracle.com> Message-ID: Thank you, Alan. I'll try to see if there is opportunity for further optimization, although I'm currently looking at the implementation in JDK 16 and I don't see obvious things that can be optimized :) Also is https://bugs.openjdk.java.net/browse/JDK-8246516 duplicate of https://bugs.openjdk.java.net/browse/JDK-8273642 ? On Thu, Nov 11, 2021 at 8:03 PM Alan Bateman wrote: > On 11/11/2021 17:17, Mario Pavlov wrote: > > Hi Aleksey, > > Thanks for your answer. > > In that case maybe I should start with something even smaller, e.g. > > https://bugs.openjdk.java.net/browse/JDK-8192784 > > What do you think? > > UUID.fromString(String) was re-implemented in JDK 15 with a more optimal > implementation so I suspect JDK-8192784 can be closed. One thing you > could do is do some benchmarks to see if there is any further > opportunity and bring it to core-libs-dev for discussion. Note that > identifying enhancements in JBS that can be closed is a contribution in > itself. > > -Alan > From roger.riggs at oracle.com Thu Nov 11 22:45:27 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 11 Nov 2021 17:45:27 -0500 Subject: JDK-8273642: The UUID class does not implement RFC4122 fully (UUID type 5 is missing). In-Reply-To: References: <7f764f7f-7b6d-329d-ba5b-7f45a8535656@redhat.com> <612c8c56-ad28-06f6-e8cc-ff6e118d60b6@oracle.com> Message-ID: <139938d9-688f-c11c-acde-bdccf2ed1a14@oracle.com> Hi Mario, I linked and closed https://bugs.openjdk.java.net/browse/JDK-8273642 as a duplicate. The hex string->binary conversions in UUID are already highly optimized. I don't think the any of the recently added support for Hexadecimal in java.util.HexFormat would/could make it any faster. There might be a trivial space gain by refactoring to have a single table used for the digit conversions in both. (UUID.nibbles vs HexFormat.DIGITS) but it would be a very low value change. Thanks, Roger On 11/11/21 1:34 PM, Mario Pavlov wrote: > Thank you, Alan. I'll try to see if there is opportunity for further > optimization, although I'm currently looking at the implementation in JDK > 16 and I don't see obvious things that can be optimized :) > Also is https://bugs.openjdk.java.net/browse/JDK-8246516 duplicate of > https://bugs.openjdk.java.net/browse/JDK-8273642 ? > > On Thu, Nov 11, 2021 at 8:03 PM Alan Bateman > wrote: > >> On 11/11/2021 17:17, Mario Pavlov wrote: >>> Hi Aleksey, >>> Thanks for your answer. >>> In that case maybe I should start with something even smaller, e.g. >>> https://bugs.openjdk.java.net/browse/JDK-8192784 >>> What do you think? >> UUID.fromString(String) was re-implemented in JDK 15 with a more optimal >> implementation so I suspect JDK-8192784 can be closed. One thing you >> could do is do some benchmarks to see if there is any further >> opportunity and bring it to core-libs-dev for discussion. Note that >> identifying enhancements in JBS that can be closed is a contribution in >> itself. >> >> -Alan >> From mark.reinhold at oracle.com Fri Nov 12 17:11:53 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 12 Nov 2021 09:11:53 -0800 Subject: Proposed schedule for JDK 18 In-Reply-To: <20211101124057.75000538@eggemoggin.niobe.net> References: <20211101124057.75000538@eggemoggin.niobe.net> Message-ID: <20211112091153.222102586@eggemoggin.niobe.net> 2021/11/1 12:40:57 -0700, mark.reinhold at oracle.com: > With JDK 17 now enjoying its time the limelight, here?s a proposed > schedule for JDK 18: > > 2021/12/09 Rampdown Phase One > 2022/01/20 Rampdown Phase Two > 2022/02/10 Initial Release Candidate > 2022/02/24 Final Release Candidate > 2022/03/22 General Availability > > The phases are defined in JEP 3 [1]. > > Comments on this proposal from JDK Committers and Reviewers [2] are > welcome, as are reasoned objections. If no such objections are > raised by 23:00 UTC next Monday, 8 November, or if they?re raised > and satisfactorily answered, then per the JEP 2.0 process proposal [3] > this will be the schedule for JDK 18. Hearing no objections, this is now the schedule for JDK 18. - Mark From yan at azul.com Mon Nov 15 14:10:05 2021 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 15 Nov 2021 17:10:05 +0300 Subject: Result: New JDK Committer: Alexey Bakhtin Message-ID: Voting for Alexey Bakhtin [0] is now closed. Yes: 13 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thank you --yan [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-November/006198.html From mark.reinhold at oracle.com Tue Nov 16 00:24:15 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 15 Nov 2021 16:24:15 -0800 (PST) Subject: JEP proposed to target JDK 18: 419: Foreign Function & Memory API (Second Incubator) Message-ID: <20211116002415.361DC4C95A2@eggemoggin.niobe.net> The following JEP is proposed to target JDK 18: 419: Foreign Function & Memory API (Second Incubator) https://openjdk.java.net/jeps/419 Summary: Introduce an API by which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Tuesday, 23 November, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 18. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Tue Nov 16 00:24:17 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 15 Nov 2021 16:24:17 -0800 (PST) Subject: JEP proposed to target JDK 18: 420: Pattern Matching for switch (Second Preview) Message-ID: <20211116002417.6EAD84C95A4@eggemoggin.niobe.net> The following JEP is proposed to target JDK 18: 420: Pattern Matching for switch (Second Preview) https://openjdk.java.net/jeps/420 Summary: Enhance the Java programming language with pattern matching for switch expressions and statements, along with extensions to the language of patterns. Extending pattern matching to switch allows an expression to be tested against a number of patterns, each with a specific action, so that complex data-oriented queries can be expressed concisely and safely. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Tuesday, 23 November, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 18. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.yagnatinsky at barclays.com Tue Nov 16 01:32:06 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Tue, 16 Nov 2021 01:32:06 +0000 Subject: further milling project coin idea: private static fields in interfaces? Message-ID: Now that interfaces can have all sorts of methods, perhaps it makes sense to allow private static fields? My motivating example is loggers: if a method needs to log something, it would be nice to declare a logger without encouraging subclasses to use it. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From daniel.fuchs at oracle.com Fri Nov 19 11:58:22 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 19 Nov 2021 11:58:22 +0000 Subject: Result: New JDK Committer: Andrey Turbanov Message-ID: <7a526fd0-51a7-c778-dc0f-7f79714389d3@oracle.com> Hi, Voting for Andrey Turbanov (aturbanov) [1] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. best regards, -- daniel PS: there were actually 16 yes but one vote didn't have jdk-dev in cc: so I had to discount it. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-November/006213.html From mark.reinhold at oracle.com Fri Nov 19 19:53:51 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 19 Nov 2021 11:53:51 -0800 (PST) Subject: New candidate JEP: 422: Linux/RISC-V Port Message-ID: <20211119195351.C76594C9ED2@eggemoggin.niobe.net> https://openjdk.java.net/jeps/422 Summary: Port the JDK to Linux/RISC-V. - Mark From mrjarviscraft at gmail.com Tue Nov 23 14:59:02 2021 From: mrjarviscraft at gmail.com (Japris Pogrammer) Date: Tue, 23 Nov 2021 17:59:02 +0300 Subject: Shell files in `/bin` can be made executable Message-ID: Currently [1] shell scripts in /bin directory seem to be missing x modifier. I guess that it should be added to them in order to improve their usage experience a bit. Is this assumption right? If yes, then I am ready to propose a simple fix for this [2]. [1]: https://github.com/openjdk/jdk/blob/f4dc03ea6de327425ff265c3d2ec16ea7b0e1634/bin/ [2]: https://github.com/JarvisCraft/jdk/tree/bin-make-shell-files-executable From magnus.ihse.bursie at oracle.com Tue Nov 23 15:04:39 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 23 Nov 2021 16:04:39 +0100 Subject: Shell files in `/bin` can be made executable In-Reply-To: References: Message-ID: <387ec3a9-29ba-5d03-f1ad-9366c570c35c@oracle.com> On 2021-11-23 15:59, Japris Pogrammer wrote: > Currently [1] shell scripts in /bin directory seem to be missing x > modifier. I guess that it should be added to them in order to improve their > usage experience a bit. > Is this assumption right? > If yes, then I am ready to propose a simple fix for this [2]. Traditionally, we have not allowed the execute bit in OpenJDK repositories, out of security concerns. I'm not really sure how much that actually is a valid argument (everyone is just doing "bash ./bin/whatever.sh") and it complicates building somewhat (the standard "./configure" do not work, but "bash configure" is needed instead). I have not seen this practice written down anywhere, but since it's actually been in effect for so long, it will require a discussion to change it. To clarify; I am in favor of dropping that limitation, and I'd like to see some good arguments for why we should keep it. /Magnus From kevin.rushforth at oracle.com Tue Nov 23 15:08:01 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 23 Nov 2021 07:08:01 -0800 Subject: Shell files in `/bin` can be made executable In-Reply-To: References: Message-ID: No, executable files are explicitly prohibited in the jdk repo. This is enforced by jcheck [3]. -- Kevin [3] https://github.com/openjdk/jdk/blob/master/.jcheck/conf#L6 On 11/23/2021 6:59 AM, Japris Pogrammer wrote: > Currently [1] shell scripts in /bin directory seem to be missing x > modifier. I guess that it should be added to them in order to improve their > usage experience a bit. > Is this assumption right? > If yes, then I am ready to propose a simple fix for this [2]. > > [1]: > https://github.com/openjdk/jdk/blob/f4dc03ea6de327425ff265c3d2ec16ea7b0e1634/bin/ > [2]: https://github.com/JarvisCraft/jdk/tree/bin-make-shell-files-executable From mrjarviscraft at gmail.com Tue Nov 23 15:33:34 2021 From: mrjarviscraft at gmail.com (Japris Pogrammer) Date: Tue, 23 Nov 2021 18:33:34 +0300 Subject: Shell files in `/bin` can be made executable In-Reply-To: References: Message-ID: Thanks for your quick responses! Are there any actual reasons for this restriction or is it here just for historical reasons? If there is a possibility of dropping this limitation, as Magnus says, I also would like to support it. ??, 23 ????. 2021 ?. ? 18:08, Kevin Rushforth : > No, executable files are explicitly prohibited in the jdk repo. This is > enforced by jcheck [3]. > > -- Kevin > > [3] https://github.com/openjdk/jdk/blob/master/.jcheck/conf#L6 > > > On 11/23/2021 6:59 AM, Japris Pogrammer wrote: > > Currently [1] shell scripts in /bin directory seem to be missing x > > modifier. I guess that it should be added to them in order to improve > their > > usage experience a bit. > > Is this assumption right? > > If yes, then I am ready to propose a simple fix for this [2]. > > > > [1]: > > > https://github.com/openjdk/jdk/blob/f4dc03ea6de327425ff265c3d2ec16ea7b0e1634/bin/ > > [2]: > https://github.com/JarvisCraft/jdk/tree/bin-make-shell-files-executable > > From kevin.rushforth at oracle.com Tue Nov 23 15:43:03 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 23 Nov 2021 07:43:03 -0800 Subject: [External] : Re: Shell files in `/bin` can be made executable In-Reply-To: References: Message-ID: I sent my reply before I saw Magnus', so I was commenting on the "what" and not the "why". I'm sure others with more standing in the JDK project will chime in, but two reasons that come to mind are: 1. Allowing scripts that are executable could lead to unexpected results if the current directory is in the PATH ahead of some place you expect to get that command. 2. On Windows platforms it is very easy to have a file be accidentally executable depending on how it is created, such that (for example) new source code files end up having the execute bit set. -- Kevin On 11/23/2021 7:33 AM, Japris Pogrammer wrote: > Thanks for your quick?responses! > > Are there any actual reasons for this restriction or is it here just > for historical reasons? > If there is a possibility of dropping this limitation, as Magnus says, > I also would like to support it. > > ??, 23 ????. 2021 ?. ? 18:08, Kevin Rushforth > : > > No, executable files are explicitly prohibited in the jdk repo. > This is > enforced by jcheck [3]. > > -- Kevin > > [3] https://github.com/openjdk/jdk/blob/master/.jcheck/conf#L6 > > > > On 11/23/2021 6:59 AM, Japris Pogrammer wrote: > > Currently [1] shell scripts in /bin directory seem to be missing x > > modifier. I guess that it should be added to them in order to > improve their > > usage experience a bit. > > Is this assumption right? > > If yes, then I am ready to propose a simple fix for this [2]. > > > > [1]: > > > https://github.com/openjdk/jdk/blob/f4dc03ea6de327425ff265c3d2ec16ea7b0e1634/bin/ > > > [2]: > https://github.com/JarvisCraft/jdk/tree/bin-make-shell-files-executable > > From javalists at cbfiddle.com Tue Nov 23 15:59:22 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 23 Nov 2021 07:59:22 -0800 Subject: [External] : Re: Shell files in `/bin` can be made executable In-Reply-To: References: Message-ID: <131CB6CB-2457-4560-98E1-353FE60AB64E@cbfiddle.com> A middle ground might be to set the ?x? bit when creating the packaged JDK. > On Nov 23, 2021, at 7:43 AM, Kevin Rushforth wrote: > > I sent my reply before I saw Magnus', so I was commenting on the "what" and not the "why". > > I'm sure others with more standing in the JDK project will chime in, but two reasons that come to mind are: > > 1. Allowing scripts that are executable could lead to unexpected results if the current directory is in the PATH ahead of some place you expect to get that command. > 2. On Windows platforms it is very easy to have a file be accidentally executable depending on how it is created, such that (for example) new source code files end up having the execute bit set. > > -- Kevin > > > On 11/23/2021 7:33 AM, Japris Pogrammer wrote: >> Thanks for your quick responses! >> >> Are there any actual reasons for this restriction or is it here just for historical reasons? >> If there is a possibility of dropping this limitation, as Magnus says, I also would like to support it. >> >> ??, 23 ????. 2021 ?. ? 18:08, Kevin Rushforth : >> >> No, executable files are explicitly prohibited in the jdk repo. >> This is >> enforced by jcheck [3]. >> >> -- Kevin >> >> [3] https://github.com/openjdk/jdk/blob/master/.jcheck/conf#L6 >> >> >> >> On 11/23/2021 6:59 AM, Japris Pogrammer wrote: >> > Currently [1] shell scripts in /bin directory seem to be missing x >> > modifier. I guess that it should be added to them in order to >> improve their >> > usage experience a bit. >> > Is this assumption right? >> > If yes, then I am ready to propose a simple fix for this [2]. >> > >> > [1]: >> > >> https://github.com/openjdk/jdk/blob/f4dc03ea6de327425ff265c3d2ec16ea7b0e1634/bin/ >> >> > [2]: >> https://github.com/JarvisCraft/jdk/tree/bin-make-shell-files-executable >> >> > From kevin.rushforth at oracle.com Tue Nov 23 17:13:36 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 23 Nov 2021 09:13:36 -0800 Subject: [External] : Re: Shell files in `/bin` can be made executable In-Reply-To: <131CB6CB-2457-4560-98E1-353FE60AB64E@cbfiddle.com> References: <131CB6CB-2457-4560-98E1-353FE60AB64E@cbfiddle.com> Message-ID: <2f403174-f4cf-c104-ad25-652a85d00afd@oracle.com> You mean for the built JDK? That should already be the case. If not, it seems like a bug. -- Kevin On 11/23/2021 7:59 AM, Alan Snyder wrote: > A middle ground might be to set the ?x? bit when creating the packaged JDK. > > >> On Nov 23, 2021, at 7:43 AM, Kevin Rushforth wrote: >> >> I sent my reply before I saw Magnus', so I was commenting on the "what" and not the "why". >> >> I'm sure others with more standing in the JDK project will chime in, but two reasons that come to mind are: >> >> 1. Allowing scripts that are executable could lead to unexpected results if the current directory is in the PATH ahead of some place you expect to get that command. >> 2. On Windows platforms it is very easy to have a file be accidentally executable depending on how it is created, such that (for example) new source code files end up having the execute bit set. >> >> -- Kevin >> >> >> On 11/23/2021 7:33 AM, Japris Pogrammer wrote: >>> Thanks for your quick responses! >>> >>> Are there any actual reasons for this restriction or is it here just for historical reasons? >>> If there is a possibility of dropping this limitation, as Magnus says, I also would like to support it. >>> >>> ??, 23 ????. 2021 ?. ? 18:08, Kevin Rushforth : >>> >>> No, executable files are explicitly prohibited in the jdk repo. >>> This is >>> enforced by jcheck [3]. >>> >>> -- Kevin >>> >>> [3] https://github.com/openjdk/jdk/blob/master/.jcheck/conf#L6 >>> >>> >>> >>> On 11/23/2021 6:59 AM, Japris Pogrammer wrote: >>> > Currently [1] shell scripts in /bin directory seem to be missing x >>> > modifier. I guess that it should be added to them in order to >>> improve their >>> > usage experience a bit. >>> > Is this assumption right? >>> > If yes, then I am ready to propose a simple fix for this [2]. >>> > >>> > [1]: >>> > >>> https://github.com/openjdk/jdk/blob/f4dc03ea6de327425ff265c3d2ec16ea7b0e1634/bin/ >>> >>> > [2]: >>> https://github.com/JarvisCraft/jdk/tree/bin-make-shell-files-executable >>> >>> From mark.reinhold at oracle.com Wed Nov 24 00:20:28 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 23 Nov 2021 16:20:28 -0800 Subject: JEP proposed to target JDK 18: 419: Foreign Function & Memory API (Second Incubator) In-Reply-To: <20211116002415.361DC4C95A2@eggemoggin.niobe.net> References: <20211116002415.361DC4C95A2@eggemoggin.niobe.net> Message-ID: <20211123162028.313388649@eggemoggin.niobe.net> 2021/11/15 16:24:15 -0800, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 18: > > 419: Foreign Function & Memory API (Second Incubator) > https://openjdk.java.net/jeps/419 > > Summary: Introduce an API by which Java programs can interoperate with > code and data outside of the Java runtime. By efficiently invoking > foreign functions (i.e., code outside the JVM), and by safely accessing > foreign memory (i.e., memory not managed by the JVM), the API enables > Java programs to call native libraries and process native data without > the brittleness and danger of JNI. Hearing no objections, I?ve targeted this JEP to JDK 18. - Mark From mark.reinhold at oracle.com Wed Nov 24 00:22:53 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 23 Nov 2021 16:22:53 -0800 Subject: JEP proposed to target JDK 18: 420: Pattern Matching for switch (Second Preview) In-Reply-To: <20211116002417.6EAD84C95A4@eggemoggin.niobe.net> References: <20211116002417.6EAD84C95A4@eggemoggin.niobe.net> Message-ID: <20211123162253.953191330@eggemoggin.niobe.net> 2021/11/15 16:24:17 -0800, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 18: > > 420: Pattern Matching for switch (Second Preview) > https://openjdk.java.net/jeps/420 > > Summary: Enhance the Java programming language with pattern matching > for switch expressions and statements, along with extensions to the > language of patterns. Extending pattern matching to switch allows > an expression to be tested against a number of patterns, each with a > specific action, so that complex data-oriented queries can be expressed > concisely and safely. Hearing no objections, I?ve targeted this JEP to JDK 18. - Mark From jai.forums2013 at gmail.com Wed Nov 24 05:48:11 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 24 Nov 2021 11:18:11 +0530 Subject: Is jdk-submit no longer available for committers? Message-ID: Hello everyone, I have been trying to find a way to run tier2 tests before submitting a change to the JDK project. I don't have the necessary infrastructure to do it locally. I remembered there was the jdk-submit repo during the mercurial repo days. So I checked the Submit Repo page here https://wiki.openjdk.java.net/display/Build/Submit+Repo and it still refers to Mercurial and that repo is no longer accessible at http://hg.openjdk.java.net/jdk/submit/. Is jdk-submit no longer functional? I can't find a git repo for it under the openjdk repo at github. -Jaikiran From shade at redhat.com Wed Nov 24 07:57:45 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Nov 2021 08:57:45 +0100 Subject: Is jdk-submit no longer available for committers? In-Reply-To: References: Message-ID: <5f56f2b6-840d-3467-9b89-c025b7a33e51@redhat.com> Hi, On 11/24/21 6:48 AM, Jaikiran Pai wrote: > I have been trying to find a way to run tier2 tests before submitting a > change to the JDK project. I don't have the necessary infrastructure to > do it locally. IIRC, jdk-submit did not ran tier2? In my experience, tier2 takes about the same time as tier1, so as long as you have capacity to run tier1 (which is recommended for non-trivial integrations anyway), you should be able to run tier2. A decent desktop should complete it within a few hours. > Is jdk-submit no longer functional? I can't find a git repo for it under > the openjdk repo at github. jdk-submit was replaced by GitHub Actions workflows. -- Thanks, -Aleksey From jai.forums2013 at gmail.com Wed Nov 24 09:12:45 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 24 Nov 2021 14:42:45 +0530 Subject: Is jdk-submit no longer available for committers? In-Reply-To: <5f56f2b6-840d-3467-9b89-c025b7a33e51@redhat.com> References: <5f56f2b6-840d-3467-9b89-c025b7a33e51@redhat.com> Message-ID: <7285d93f-e866-105e-bc53-976c45bea7c7@gmail.com> Hello Aleksey, On 24/11/21 1:27 pm, Aleksey Shipilev wrote: > Hi, > > On 11/24/21 6:48 AM, Jaikiran Pai wrote: >> I have been trying to find a way to run tier2 tests before submitting a >> change to the JDK project. I don't have the necessary infrastructure to >> do it locally. > > IIRC, jdk-submit did not ran tier2? I'm not sure. I myself hadn't used it previously. The introduction mail[1] hadn't mentioned any specific tiers/tests so I always assumed that it would run all tests against all the tested platforms. > > In my experience, tier2 takes about the same time as tier1, so as long > as you have capacity to run tier1 (which is recommended for > non-trivial integrations anyway), you should be able to run tier2. A > decent desktop should complete it within a few hours. You are right indeed. Before sending this mail, I had triggered a (subset) of tier2 (specifically jdk:tier2) on my local setup and that just completed a while back. So that indeed is good news for me for any future testing. My previous attempt at running tier2 around a year back wasn't so successful and I had to kill it after multiple hours of it continuing to run. >> Is jdk-submit no longer functional? I can't find a git repo for it under >> the openjdk repo at github. > > jdk-submit was replaced by GitHub Actions workflows. > For tier1 testing GitHub Actions has indeed been very helpful, especially the ability to trigger manual builds of specific branches against specific platforms of choice. I wonder if I can come up with a new GitHub workflow to trigger tier2 tests for all platforms against it - perhaps not for each PR but for manual/on-demand runs. I'll experiment a bit some time soon. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000566.html -Jaikiran From shade at redhat.com Wed Nov 24 09:27:49 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Nov 2021 10:27:49 +0100 Subject: Is jdk-submit no longer available for committers? In-Reply-To: <7285d93f-e866-105e-bc53-976c45bea7c7@gmail.com> References: <5f56f2b6-840d-3467-9b89-c025b7a33e51@redhat.com> <7285d93f-e866-105e-bc53-976c45bea7c7@gmail.com> Message-ID: <23a01405-1d71-15d4-6d22-c675d23a9cd7@redhat.com> On 11/24/21 10:12 AM, Jaikiran Pai wrote: > I'm not sure. I myself hadn't used it previously. The introduction > mail[1] hadn't mentioned any specific tiers/tests so I always assumed > that it would run all tests against all the tested platforms. Running all tests would be prohibitively expensive. On my TR 3970X tier{1,2,3,4} together complete in about 10 hours, and that is _one_ configuration. Pull in different GCs, different JIT compilers, some verification options, and the whole pipeline starts to be over 100 hours on a very large machine. > You are right indeed. Before sending this mail, I had triggered a > (subset) of tier2 (specifically jdk:tier2) on my local setup and that > just completed a while back. So that indeed is good news for me for any > future testing. My previous attempt at running tier2 around a year back > wasn't so successful and I had to kill it after multiple hours of it > continuing to run. Over the years, we did a lot of work to make tiered testing viable. Lower tiers should complete faster and more reliably than higher tiers, so you are advised to run as many tiers as your environment allows. You might want to read the updated docs here: https://github.com/openjdk/jdk/blob/master/doc/testing.md#common-test-groups > For tier1 testing GitHub Actions has indeed been very helpful, > especially the ability to trigger manual builds of specific branches > against specific platforms of choice. I wonder if I can come up with a > new GitHub workflow to trigger tier2 tests for all platforms against it > - perhaps not for each PR but for manual/on-demand runs. I'll experiment > a bit some time soon. Yes, having the GitHub workflow definitions for tier{2,3,4} *might* be nice, as long as they do not trigger automatically. This always runs into the question who actually pays for the GH infra running tests and what are the practical usage limits there. Running tier1 on PRs is already quite expensive CPU-time wise. So, for practical reasons, I would advise to invest in local development machine that could run higher tiers without bothering the shared infrastructure :) Developing non-trivial OpenJDK improvements without substantial CPU resources would always be an exercise in patience otherwise. -- Thanks, -Aleksey From magnus.ihse.bursie at oracle.com Wed Nov 24 13:08:05 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 24 Nov 2021 14:08:05 +0100 Subject: [External] : Re: Shell files in `/bin` can be made executable In-Reply-To: References: Message-ID: <827148da-5490-1964-5541-e1641ad07610@oracle.com> On 2021-11-23 16:43, Kevin Rushforth wrote: > I sent my reply before I saw Magnus', so I was commenting on the > "what" and not the "why". > > I'm sure others with more standing in the JDK project will chime in, > but two reasons that come to mind are: > > 1. Allowing scripts that are executable could lead to unexpected > results if the current directory is in the PATH ahead of some place > you expect to get that command. You mean if the user has configured his/her environment to have like PATH=.:/bin:/usr/bin:..? That is a horrible, horrible security misconfiguration, that will introduce security issues all the time, not only for OpenJDK. I don't think we can or should try to protect against this particular case of bad user configuration. > 2. On Windows platforms it is very easy to have a file be accidentally > executable depending on how it is created, such that (for example) new > source code files end up having the execute bit set. I wonder what tooling produces such files, but sure, let's say that this is something we want to protect ourselves against. I propose that we modify jcheck so it disallows executable files, not over the board, but in the src directory. (Or instead of having a block-list, have an allow-list of directories where executables are allowed, typically "./bin" and the root (for the configure script.) /Magnus > > -- Kevin > > > On 11/23/2021 7:33 AM, Japris Pogrammer wrote: >> Thanks for your quick?responses! >> >> Are there any actual reasons for this restriction or is it here just >> for historical reasons? >> If there is a possibility of dropping this limitation, as Magnus >> says, I also would like to support it. >> >> ??, 23 ????. 2021 ?. ? 18:08, Kevin Rushforth >> : >> >> No, executable files are explicitly prohibited in the jdk repo. >> This is >> enforced by jcheck [3]. >> >> -- Kevin >> >> [3] https://github.com/openjdk/jdk/blob/master/.jcheck/conf#L6 >> >> >> >> On 11/23/2021 6:59 AM, Japris Pogrammer wrote: >> > Currently [1] shell scripts in /bin directory seem to be missing x >> > modifier. I guess that it should be added to them in order to >> improve their >> > usage experience a bit. >> > Is this assumption right? >> > If yes, then I am ready to propose a simple fix for this [2]. >> > >> > [1]: >> > >> https://github.com/openjdk/jdk/blob/f4dc03ea6de327425ff265c3d2ec16ea7b0e1634/bin/ >> >> > [2]: >> https://github.com/JarvisCraft/jdk/tree/bin-make-shell-files-executable >> >> > From alexey.ivanov at oracle.com Wed Nov 24 13:31:14 2021 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Wed, 24 Nov 2021 13:31:14 +0000 Subject: [External] : Re: Shell files in `/bin` can be made executable In-Reply-To: <827148da-5490-1964-5541-e1641ad07610@oracle.com> References: <827148da-5490-1964-5541-e1641ad07610@oracle.com> Message-ID: <632a708b-d1b5-eff9-6c9e-695728e69099@oracle.com> On 24/11/2021 13:08, Magnus Ihse Bursie wrote: > On 2021-11-23 16:43, Kevin Rushforth wrote: > >> 2. On Windows platforms it is very easy to have a file be >> accidentally executable depending on how it is created, such that >> (for example) new source code files end up having the execute bit set. > > I wonder what tooling produces such files, but sure, let's say that > this is something we want to protect ourselves against. I propose that > we modify jcheck so it disallows executable files, not over the board, > but in the src directory. (Or instead of having a block-list, have an > allow-list of directories where executables are allowed, typically > "./bin" and the root (for the configure script.) This happens for me all the time in Cygwin. When I create a new file in the repo using Windows tools, like a new java source file in an IDE, the file has execute bit set for everyone (user, group and other). Basically, Cygwin sees all the files on the drive as having execute permissions. If a file is created with Cygwin tools, it doesn't have executable permissions. -- Regards, Alexey From archana.nogriya at uk.ibm.com Wed Nov 24 13:43:57 2021 From: archana.nogriya at uk.ibm.com (Archana Nogriya) Date: Wed, 24 Nov 2021 14:43:57 +0100 Subject: Copyright Issues : JDK11 - GPLv2 is present but Classpath exception is missing Message-ID: Hi, We have found the copyright issues in JDK11. These following files has GPLv2 present but Classpath exception is missing. Please if this can be fixed. - src/jdk.jfr/share/classes/jdk/jfr/events/X509CertificateEvent.java: GPLv2 is present but Classpath exception is missing - src/java.base/share/classes/sun/security/util/math/intpoly/header.txt: GPLv2 is present but Classpath exception is missing Many Thanks & Regards Archana Nogriya Java Runtimes Development and Project Manager IBM Hursley IBM United Kingdom Ltd internet email: archana.nogriya at uk.ibm.com Working hrs (Mon-Fri)- 9am - 3pm 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 magnus.ihse.bursie at oracle.com Wed Nov 24 13:46:04 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 24 Nov 2021 14:46:04 +0100 Subject: [External] : Re: Shell files in `/bin` can be made executable In-Reply-To: <632a708b-d1b5-eff9-6c9e-695728e69099@oracle.com> References: <827148da-5490-1964-5541-e1641ad07610@oracle.com> <632a708b-d1b5-eff9-6c9e-695728e69099@oracle.com> Message-ID: <8f47a42c-0e3a-82d4-43a0-6d32dcea5991@oracle.com> On 2021-11-24 14:31, Aleksei Ivanov wrote: > On 24/11/2021 13:08, Magnus Ihse Bursie wrote: >> On 2021-11-23 16:43, Kevin Rushforth wrote: >> >>> 2. On Windows platforms it is very easy to have a file be >>> accidentally executable depending on how it is created, such that >>> (for example) new source code files end up having the execute bit set. >> >> I wonder what tooling produces such files, but sure, let's say that >> this is something we want to protect ourselves against. I propose >> that we modify jcheck so it disallows executable files, not over the >> board, but in the src directory. (Or instead of having a block-list, >> have an allow-list of directories where executables are allowed, >> typically "./bin" and the root (for the configure script.) > > This happens for me all the time in Cygwin. When I create a new file > in the repo using Windows tools, like a new java source file in an > IDE, the file has execute bit set for everyone (user, group and > other). Basically, Cygwin sees all the files on the drive as having > execute permissions. > > If a file is created with Cygwin tools, it doesn't have executable > permissions. Have you tried setting CYGWIN=nontsec? /Magnus From kevin.rushforth at oracle.com Wed Nov 24 14:14:42 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Nov 2021 06:14:42 -0800 Subject: [External] : Re: Shell files in `/bin` can be made executable In-Reply-To: <632a708b-d1b5-eff9-6c9e-695728e69099@oracle.com> References: <827148da-5490-1964-5541-e1641ad07610@oracle.com> <632a708b-d1b5-eff9-6c9e-695728e69099@oracle.com> Message-ID: Yes, exactly. Any file created with an IDE or other Windows tool will have its execute bit set. We have a few options for how to proceed: 1. Disallow the executable bit for all files (status quo) 2. Allow the executable bit only for certain files / directories (e.g., support an allow-list) 3. Allow the executable bit for all files except source files (i.e., similar to how the whitespace check works) 4. Allow the executable bit for all files I like the status quo, but I don't have any standing in the jdk project to do more than offer my opinion (FWIW, the OpenJFX project will stick with option 1). I do think #4 would be a poor choice. -- Kevin On 11/24/2021 5:31 AM, Aleksei Ivanov wrote: > On 24/11/2021 13:08, Magnus Ihse Bursie wrote: >> On 2021-11-23 16:43, Kevin Rushforth wrote: >> >>> 2. On Windows platforms it is very easy to have a file be >>> accidentally executable depending on how it is created, such that >>> (for example) new source code files end up having the execute bit set. >> >> I wonder what tooling produces such files, but sure, let's say that >> this is something we want to protect ourselves against. I propose >> that we modify jcheck so it disallows executable files, not over the >> board, but in the src directory. (Or instead of having a block-list, >> have an allow-list of directories where executables are allowed, >> typically "./bin" and the root (for the configure script.) > > This happens for me all the time in Cygwin. When I create a new file > in the repo using Windows tools, like a new java source file in an > IDE, the file has execute bit set for everyone (user, group and > other). Basically, Cygwin sees all the files on the drive as having > execute permissions. > > If a file is created with Cygwin tools, it doesn't have executable > permissions. > From alexey.ivanov at oracle.com Wed Nov 24 14:19:59 2021 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Wed, 24 Nov 2021 14:19:59 +0000 Subject: [External] : Re: Shell files in `/bin` can be made executable In-Reply-To: <8f47a42c-0e3a-82d4-43a0-6d32dcea5991@oracle.com> References: <827148da-5490-1964-5541-e1641ad07610@oracle.com> <632a708b-d1b5-eff9-6c9e-695728e69099@oracle.com> <8f47a42c-0e3a-82d4-43a0-6d32dcea5991@oracle.com> Message-ID: On 24/11/2021 13:46, Magnus Ihse Bursie wrote: > On 2021-11-24 14:31, Aleksei Ivanov wrote: >> On 24/11/2021 13:08, Magnus Ihse Bursie wrote: >>> On 2021-11-23 16:43, Kevin Rushforth wrote: >>> >>>> 2. On Windows platforms it is very easy to have a file be >>>> accidentally executable depending on how it is created, such that >>>> (for example) new source code files end up having the execute bit set. >>> >>> I wonder what tooling produces such files, but sure, let's say that >>> this is something we want to protect ourselves against. I propose >>> that we modify jcheck so it disallows executable files, not over the >>> board, but in the src directory. (Or instead of having a block-list, >>> have an allow-list of directories where executables are allowed, >>> typically "./bin" and the root (for the configure script.) >> >> This happens for me all the time in Cygwin. When I create a new file >> in the repo using Windows tools, like a new java source file in an >> IDE, the file has execute bit set for everyone (user, group and >> other). Basically, Cygwin sees all the files on the drive as having >> execute permissions. >> >> If a file is created with Cygwin tools, it doesn't have executable >> permissions. > Have you tried setting CYGWIN=nontsec? No, I haven't. I haven't known about this option, I've experienced no issues with its default behaviour so far. I use Mercurial from Cygwin and made ./configure script executable; I use Git for Windows rather than Cygwin one, and therefore ./configure script is also executable for me. On the other hand, when I made ./configure executable on Linux, Git reports it as change. -- Alexey From christoph.langer at sap.com Wed Nov 24 15:49:52 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Nov 2021 15:49:52 +0000 Subject: Copyright Issues : JDK11 - GPLv2 is present but Classpath exception is missing In-Reply-To: References: Message-ID: Hi Archana, thanks for reporting this. I just checked quickly and it seems like two of the backports I did lately are somehow broken. At the moment I have no explanation why that happened. I'll have a closer look and repair it. Best regards Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Archana > Nogriya > Sent: Mittwoch, 24. November 2021 14:44 > To: jdk-dev at openjdk.java.net > Cc: Anthony Renaud ; Peter Shipton > ; David Holmes > Subject: Copyright Issues : JDK11 - GPLv2 is present but Classpath exception > is missing > > Hi, > > > We have found the copyright issues in JDK11. > These following files has GPLv2 present but Classpath exception is missing. > Please if this can be fixed. > > - src/jdk.jfr/share/classes/jdk/jfr/events/X509CertificateEvent.java: > GPLv2 is present but Classpath exception is missing > - src/java.base/share/classes/sun/security/util/math/intpoly/header.txt: > GPLv2 is present but Classpath exception is missing > > > > Many Thanks & Regards > Archana Nogriya > Java Runtimes Development and Project Manager IBM Hursley IBM United > Kingdom Ltd internet email: archana.nogriya at uk.ibm.com Working hrs > (Mon-Fri)- 9am - 3pm > > > 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 mark.reinhold at oracle.com Wed Nov 24 17:11:33 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 24 Nov 2021 09:11:33 -0800 Subject: Copyright Issues : JDK11 - GPLv2 is present but Classpath exception is missing In-Reply-To: References: Message-ID: <20211124091133.383825750@eggemoggin.niobe.net> 2021/11/24 5:43:57 -0800, archana.nogriya at uk.ibm.com: > We have found the copyright issues in JDK11. > These following files has GPLv2 present but Classpath exception is > missing. Please if this can be fixed. > > - src/jdk.jfr/share/classes/jdk/jfr/events/X509CertificateEvent.java: > GPLv2 is present but Classpath exception is missing > - src/java.base/share/classes/sun/security/util/math/intpoly/header.txt: > GPLv2 is present but Classpath exception is missing The jdk-dev list is for discussion of general technical issues related to the feature release currently in development, which right now is JDK 18. Please direct requests related to earlier releases to the appropriate update-release list, which for JDK 11 is jdk-updates-dev at openjdk.java.net. - Mark From mark.reinhold at oracle.com Wed Nov 24 17:34:13 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 24 Nov 2021 09:34:13 -0800 Subject: [External] : Re: Shell files in `/bin` can be made executable In-Reply-To: <827148da-5490-1964-5541-e1641ad07610@oracle.com> References: <827148da-5490-1964-5541-e1641ad07610@oracle.com> Message-ID: <20211124093413.712896957@eggemoggin.niobe.net> 2021/11/24 5:08:05 -0800, magnus.ihse.bursie at oracle.com: > On 2021-11-23 16:43, Kevin Rushforth wrote: >> I sent my reply before I saw Magnus', so I was commenting on the >> "what" and not the "why". >> >> I'm sure others with more standing in the JDK project will chime in, >> but two reasons that come to mind are: >> >> 1. Allowing scripts that are executable could lead to unexpected >> results if the current directory is in the PATH ahead of some place >> you expect to get that command. > > You mean if the user has configured his/her environment to have like > PATH=.:/bin:/usr/bin:..? That is a horrible, horrible security > misconfiguration, that will introduce security issues all the time, not > only for OpenJDK. I don't think we can or should try to protect against > this particular case of bad user configuration. Yes, that is a horrible, horrible security misconfiguration, but it is all too common out in the wild. We have never allowed executable files for this reason and, also, to help prevent executable binary files from being checked in. The latter are not only another potential attack vector but also a maintenance nightmare. - Mark From joe.darcy at oracle.com Tue Nov 30 04:59:14 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 29 Nov 2021 20:59:14 -0800 Subject: Reminder: file JDK 18 CSRs well ahead of anticipated December 2021 rampdown 1 deadline In-Reply-To: References: Message-ID: <34d31c74-34f9-a1dc-49fd-05fdb07f991d@oracle.com> Another reminder, the JDK 18 rampdown phase one deadline is Thursday, December 9, 2021: ?? http://openjdk.java.net/projects/jdk/18/ CSRs submitted too close to this deadline may be not reviewed before the deadline has passed. -Joe On 11/1/2021 3:48 PM, Joseph D. Darcy wrote: > Hello, > > Per the expected JDK 18 schedule > (https://mail.openjdk.java.net/pipermail/jdk-dev/2021-November/006199.html), > JDK 18's rampdown phase one is coming up in December 2021. > > An advanced reminder to factor in sufficient review time for any > projects needing CSRs before getting pushed into JDK 18. Large > projects, including JEPs, should often use the two-phase CSR process > (https://wiki.openjdk.java.net/display/csr/Main) rather than the > one-phase process. The nominal SLA for each CSR phase is one week. To > accommodate the possibility of needing to respond to feedback from the > CSR, I recommend a large project plan for at least three weeks of CSR > review time ahead of a planned integration date. > > Specially for JEPs, I recommend a JEP has its initial interaction with > CSR no later than when the JEP reaches its Candidate stage. > > Cheers, > > -Joe > CSR Lead > > From mark.reinhold at oracle.com Tue Nov 30 19:43:38 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 30 Nov 2021 11:43:38 -0800 (PST) Subject: JEP proposed to target JDK 18: 421: Deprecate Finalization for Removal Message-ID: <20211130194338.BC3484CAFF2@eggemoggin.niobe.net> The following JEP is proposed to target JDK 18: 421: Deprecate Finalization for Removal https://openjdk.java.net/jeps/421 Summary: Deprecate finalization for removal in a future release. Finalization remains enabled by default for now, but can be disabled to facilitate early testing. In a future release it will be disabled by default, and in a later release it will be removed. Maintainers of libraries and applications that rely upon finalization should consider migrating to other resource management techniques such as the try-with-resources statement and cleaners. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Tuesday, 7 December, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 18. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html