From Roger.Riggs at oracle.com Fri May 1 15:49:49 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 1 May 2020 11:49:49 -0400 Subject: Result: New JDK Reviewer: Amy Lu Message-ID: <806eccd9-3eca-1d52-a27f-2154e8b9efe2@oracle.com> Voting for Amy Lu [1] is now closed. Yes: 31 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Roger Riggs [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-April/004222.html From mark.reinhold at oracle.com Fri May 1 23:18:19 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 1 May 2020 16:18:19 -0700 (PDT) Subject: JEP proposed to target JDK 15: 374: Disable and Deprecate Biased Locking Message-ID: <20200501231819.058A93333DD@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 374: Disable and Deprecate Biased Locking https://openjdk.java.net/jeps/374 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 Friday, 8 May, 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 15. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mikael.vidstedt at oracle.com Mon May 4 05:28:59 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Sun, 3 May 2020 22:28:59 -0700 Subject: FYI: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports Message-ID: <91715DFA-8FD0-4C93-A620-BC1EFCF1133F@oracle.com> All, FYI - in case you?re not subscribed to all the various OpenJDK mailing lists: A first version of the implementation of JEP 381: Remove the Solaris and SPARC Ports[1] is currently out for review. Given the size of the complete patch and the wide range of areas impacted the patch has been split up in six different pieces, each corresponding to an area, being reviewed on mailing list(s) appropriate for that respective area. In case you?re curious and/or want to help review the patches, below is a list of links to the respective RFR threads. Please provide comments/feedback in the respective threads, on the respective lists, *not* as replies to this thread. Thank you! Cheers, Mikael * build system https://mail.openjdk.java.net/pipermail/build-dev/2020-May/027342.html * client https://mail.openjdk.java.net/pipermail/2d-dev/2020-May/010767.html https://mail.openjdk.java.net/pipermail/awt-dev/2020-May/015885.html https://mail.openjdk.java.net/pipermail/swing-dev/2020-May/010382.html * core libs https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066219.html https://mail.openjdk.java.net/pipermail/net-dev/2020-May/013898.html https://mail.openjdk.java.net/pipermail/nio-dev/2020-May/007233.html * hotspot https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-May/041653.html https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038082.html https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-May/029527.html https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-May/039295.html https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-May/031390.html * security https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021755.html * serviceability https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-May/031390.html [1] https://bugs.openjdk.java.net/browse/JDK-8241787 From mark.reinhold at oracle.com Wed May 6 23:27:17 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 6 May 2020 16:27:17 -0700 (PDT) Subject: New candidate JEP: 384: Records (Second Preview) Message-ID: <20200506232717.026CC33AB69@eggemoggin.niobe.net> https://openjdk.java.net/jeps/384 - Mark From mark.reinhold at oracle.com Thu May 7 20:22:17 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 7 May 2020 13:22:17 -0700 (PDT) Subject: JEP proposed to target JDK 15: 339: Edwards-Curve Digital Signature Algorithm (EdDSA) Message-ID: <20200507202217.ACF3A33C0F3@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 339: Edwards-Curve Digital Signature Algorithm (EdDSA) https://openjdk.java.net/jeps/339 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, 14 May, 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 15. - 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 Thu May 7 20:23:18 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 7 May 2020 13:23:18 -0700 (PDT) Subject: JEP proposed to target JDK 15: 384: Records (Second Preview) Message-ID: <20200507202318.E539133C0FA@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 384: Records (Second Preview) https://openjdk.java.net/jeps/384 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, 14 May, 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 15. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From jesper.wilhelmsson at oracle.com Fri May 8 00:31:48 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 8 May 2020 02:31:48 +0200 Subject: RFR: JDK-8244618 - WinUpgradeUUIDTest.java fails after JDK-8236518 Message-ID: <79FCF932-0C6B-4023-A11E-6CC50CCE4264@oracle.com> Hi. Please review this patch to problemlist WinUpgradeUUIDTest.java that is currently failing in tier 2. Another change is in review to remove the failure but it doesn't seem likely that it will be pushed today, so in the interest of keeping tier 2 green during the non-US timezones Friday I propose to problemlist the test for now. Thanks, /Jesper diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -903,6 +903,7 @@ # core_tools tools/jlink/JLinkReproducibleTest.java 8217166 windows-all +tools/jpackage/windows/WinUpgradeUUIDTest.java#id1 8244620 windows-all ############################################################################ From david.holmes at oracle.com Fri May 8 00:41:03 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 May 2020 10:41:03 +1000 Subject: RFR: JDK-8244618 - WinUpgradeUUIDTest.java fails after JDK-8236518 In-Reply-To: <79FCF932-0C6B-4023-A11E-6CC50CCE4264@oracle.com> References: <79FCF932-0C6B-4023-A11E-6CC50CCE4264@oracle.com> Message-ID: <03a58483-3d5a-fc92-f5a7-26142dc15ab9@oracle.com> Ship it! (though should have gone to core-libs-dev cc'd) Thanks, David On 8/05/2020 10:31 am, Jesper Wilhelmsson wrote: > Hi. > > Please review this patch to problemlist WinUpgradeUUIDTest.java that is currently failing in tier 2. Another change is in review to remove the failure but it doesn't seem likely that it will be pushed today, so in the interest of keeping tier 2 green during the non-US timezones Friday I propose to problemlist the test for now. > > Thanks, > /Jesper > > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -903,6 +903,7 @@ > # core_tools > > tools/jlink/JLinkReproducibleTest.java 8217166 windows-all > +tools/jpackage/windows/WinUpgradeUUIDTest.java#id1 8244620 windows-all > > ############################################################################ > From jesper.wilhelmsson at oracle.com Fri May 8 00:44:42 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 8 May 2020 02:44:42 +0200 Subject: RFR: JDK-8244618 - WinUpgradeUUIDTest.java fails after JDK-8236518 In-Reply-To: <03a58483-3d5a-fc92-f5a7-26142dc15ab9@oracle.com> References: <79FCF932-0C6B-4023-A11E-6CC50CCE4264@oracle.com> <03a58483-3d5a-fc92-f5a7-26142dc15ab9@oracle.com> Message-ID: <77A74D53-C5DF-4D1D-8429-334627311BB9@oracle.com> Thank you! Pushed. /Jesper > On 8 May 2020, at 02:41, David Holmes wrote: > > Ship it! > > (though should have gone to core-libs-dev cc'd) > > Thanks, > David > > On 8/05/2020 10:31 am, Jesper Wilhelmsson wrote: >> Hi. >> Please review this patch to problemlist WinUpgradeUUIDTest.java that is currently failing in tier 2. Another change is in review to remove the failure but it doesn't seem likely that it will be pushed today, so in the interest of keeping tier 2 green during the non-US timezones Friday I propose to problemlist the test for now. >> Thanks, >> /Jesper >> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt >> +++ b/test/jdk/ProblemList.txt >> @@ -903,6 +903,7 @@ >> # core_tools >> tools/jlink/JLinkReproducibleTest.java 8217166 windows-all >> +tools/jpackage/windows/WinUpgradeUUIDTest.java#id1 8244620 windows-all >> ############################################################################ From alexey.semenyuk at oracle.com Fri May 8 00:47:59 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 7 May 2020 20:47:59 -0400 Subject: RFR: JDK-8244618 - WinUpgradeUUIDTest.java fails after JDK-8236518 In-Reply-To: <79FCF932-0C6B-4023-A11E-6CC50CCE4264@oracle.com> References: <79FCF932-0C6B-4023-A11E-6CC50CCE4264@oracle.com> Message-ID: <074b6ec2-a315-f4a5-daa4-bf4338105595@oracle.com> Looks good. - Alexey On 5/7/2020 8:31 PM, Jesper Wilhelmsson wrote: > Hi. > > Please review this patch to problemlist WinUpgradeUUIDTest.java that is currently failing in tier 2. Another change is in review to remove the failure but it doesn't seem likely that it will be pushed today, so in the interest of keeping tier 2 green during the non-US timezones Friday I propose to problemlist the test for now. > > Thanks, > /Jesper > > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -903,6 +903,7 @@ > # core_tools > > tools/jlink/JLinkReproducibleTest.java 8217166 windows-all > +tools/jpackage/windows/WinUpgradeUUIDTest.java#id1 8244620 windows-all > > ############################################################################ > From mark.reinhold at oracle.com Mon May 11 18:52:37 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 May 2020 11:52:37 -0700 Subject: JEP proposed to target JDK 15: 373: Reimplement the Legacy DatagramSocket API In-Reply-To: <20200430220621.D4C3D331A94@eggemoggin.niobe.net> References: <20200430220621.D4C3D331A94@eggemoggin.niobe.net> Message-ID: <20200511115237.190801446@eggemoggin.niobe.net> 2020/4/30 15:06:21 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 15: > > 373: Reimplement the Legacy DatagramSocket API > https://openjdk.java.net/jeps/373 > > 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, 7 May, 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 15. Hearing no objections, I?ve targeted this JEP to JDK 15. - Mark From mark.reinhold at oracle.com Mon May 11 18:52:49 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 May 2020 11:52:49 -0700 Subject: JEP proposed to target JDK 15: 374: Disable and Deprecate Biased Locking In-Reply-To: <20200501231819.058A93333DD@eggemoggin.niobe.net> References: <20200501231819.058A93333DD@eggemoggin.niobe.net> Message-ID: <20200511115249.665472685@eggemoggin.niobe.net> 2020/5/1 16:18:19 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 15: > > 374: Disable and Deprecate Biased Locking > https://openjdk.java.net/jeps/374 > > 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 Friday, 8 May, 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 15. Hearing no objections, I?ve targeted this JEP to JDK 15. - Mark From mark.reinhold at oracle.com Mon May 11 18:53:03 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 May 2020 11:53:03 -0700 Subject: JEP proposed to target JDK 15: 375: Pattern Matching for instanceof (Second Preview) In-Reply-To: <20200430220732.CAD77331A9A@eggemoggin.niobe.net> References: <20200430220732.CAD77331A9A@eggemoggin.niobe.net> Message-ID: <20200511115303.352955531@eggemoggin.niobe.net> 2020/4/30 15:07:32 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 15: > > 375: Pattern Matching for instanceof (Second Preview) > https://openjdk.java.net/jeps/375 > > 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, 7 May, 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 15. Hearing no objections, I?ve targeted this JEP to JDK 15. - Mark From mark.reinhold at oracle.com Wed May 13 23:47:06 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 13 May 2020 16:47:06 -0700 (PDT) Subject: JEP proposed to target JDK 15: 360: Sealed Classes (Preview) Message-ID: <20200513234706.5F5BE3453D5@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 360: Sealed Classes (Preview) https://openjdk.java.net/jeps/360 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 Wednesday, 20 May, 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 15. - 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 Wed May 13 23:48:07 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 13 May 2020 16:48:07 -0700 (PDT) Subject: JEP proposed to target JDK 15: 381: Remove the Solaris and SPARC Ports Message-ID: <20200513234807.958763453DC@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 381: Remove the Solaris and SPARC Ports https://openjdk.java.net/jeps/381 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 Wednesday, 20 May, 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 15. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From andreas at ahlenstorf.ch Thu May 14 17:44:53 2020 From: andreas at ahlenstorf.ch (Andreas Ahlenstorf) Date: Thu, 14 May 2020 19:44:53 +0200 Subject: Missing root CAs in cacerts Message-ID: Hi! At AdoptOpenJDK, we get support requests because root CAs are missing from the bundled cacerts file (lib/security/cacerts). We ship the same cacerts file as OpenJDK. As a result, our users cannot connect to various servers using Java's built-in APIs while their browsers can. An example URL that fails is https://api.insee.fr/catalogue/ (root CA: Certigna). Replacing the bundled cacerts file with one generated from Mozilla's list of trusted CAs [1] fixes the problem. [2] contains the full analysis based on OpenJDK 14.0.1 including an executable test case. Questions: * Does OpenJDK want to do something about that? * Is there interest for a collaboration in that area, especially by other distributors of OpenJDK like Azul, BellSoft? Commentary: >From a end user's perspective, it is inscrutable why it is possible to connect to a website using their browser, curl, but not Java. While there might be some differences because of policy, OpenJDK should strive to match the browser's list of trusted CAs a closely as possible. As of OpenJDK 14.0.1, cacerts contains 93 entries while Mozilla's list contains 138. Best, Andreas [1] https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt [2] https://github.com/AdoptOpenJDK/openjdk-support/issues/13#issuecomment-626147267 From mark.reinhold at oracle.com Thu May 14 22:50:55 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 14 May 2020 15:50:55 -0700 (PDT) Subject: JEP proposed to target JDK 15: 383: Foreign-Memory Access API (Second Incubator) Message-ID: <20200514225055.B205334769F@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 383: Foreign-Memory Access API (Second Incubator) https://openjdk.java.net/jeps/383 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, 21 May, 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 15. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From magnus.ihse.bursie at oracle.com Fri May 15 09:52:14 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 May 2020 11:52:14 +0200 Subject: Missing root CAs in cacerts In-Reply-To: References: Message-ID: <31efdf24-fdd1-49e8-1541-6ec33186aff4@oracle.com> On 2020-05-14 19:44, Andreas Ahlenstorf wrote: > Hi! > > At AdoptOpenJDK, we get support requests because root CAs are missing from the bundled cacerts file (lib/security/cacerts). We ship the same cacerts file as OpenJDK. As a result, our users cannot connect to various servers using Java's built-in APIs while their browsers can. An example URL that fails is https://api.insee.fr/catalogue/ (root CA: Certigna). > > Replacing the bundled cacerts file with one generated from Mozilla's list of trusted CAs [1] fixes the problem. [2] contains the full analysis based on OpenJDK 14.0.1 including an executable test case. > > Questions: > > * Does OpenJDK want to do something about that? > * Is there interest for a collaboration in that area, especially by other distributors of OpenJDK like Azul, BellSoft? > > Commentary: > > From a end user's perspective, it is inscrutable why it is possible to connect to a website using their browser, curl, but not Java. While there might be some differences because of policy, OpenJDK should strive to match the browser's list of trusted CAs a closely as possible. As of OpenJDK 14.0.1, cacerts contains 93 entries while Mozilla's list contains 138. From my personal point of view, it seems to make sense to use the Mozilla list. We already use e.g. the Mozilla Public Suffix List, which is a well-handled curated list. However, a change of the set of root CAs can certainly have user implications. Have you analyzed which CAs Mozilla is shipping that OpenJDK is missing? And -- even more importantly to avoid regressions for OpenJDK users -- is OpenJDK currently shipping any root CA certificates that Mozilla is missing? /Magnus > > Best, > Andreas > > [1] https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt > [2] https://github.com/AdoptOpenJDK/openjdk-support/issues/13#issuecomment-626147267 From bob.vandette at oracle.com Fri May 15 14:41:29 2020 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 15 May 2020 10:41:29 -0400 Subject: First PR integrated in openjdk/mobile In-Reply-To: References: Message-ID: Congratulations Johan, this is a great accomplishment! Bob. > On May 15, 2020, at 10:30 AM, Johan Vos wrote: > > Hi, > > It took a while to get everything ready, but we now have the OpenJDK Mobile > repository at https://github.com/openjdk/mobile capable of creating java > static libraries for iOS and Android. > > https://github.com/openjdk/mobile is auto-synced from openjdk/jdk and thus > contains all the code that is in the JDK. > Today, I merged a PR that enables building the static java libs: > https://github.com/openjdk/mobile/pull/4 > > The next goal is to upstream this PR to openjdk/jdk, but that is a > different story. > > I will update the wiki page with instructions, but configuring and building > is relative straightforward. The JDK build now allows to run > > make static-libs-image > > which creates static JDK libraries (hence no JVM). With the merged PR, you > can build static libraries for iOS and Android. These can be used at > runtime on those devices. > > Going from the java static libraries to apps for mobile requires of course > additional steps. Those steps are not in scope of the OpenJDK Mobile > project, but to give an example: we (Gluon) do this by linking code > generated with GraalVM native-image with the Java static libraries. We do > this in Gluon Substrate, which is open-source at > https://github.com/gluonhq/substrate and samples are given at > https://github.com/gluonhq/client-samples > > Note that we include the JavaFX static libraries in those samples, so that > we have an end-to-end OpenJDK based stack for mobile (including > cross-platform UI). The JavaFX static libraries are built using 100% the > code from OpenJFX. > > The merged PR is remarkably small, and is mainly based on code from Bob > Vandette who did this work for the Java 9 project. > Thanks to the auto-sync from upstream jdk (done by the Skara bot), we now > have the latest JDK code working for mobile. Pretty cool. > > I'd like to thank the Skara team for their innovative work, and the OpenJDK > team at Oracle who helped in achieving this milestone. > > Now we can really move things forward. > > - Johan From mark.reinhold at oracle.com Fri May 15 22:22:18 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 15 May 2020 15:22:18 -0700 Subject: JEP proposed to target JDK 15: 339: Edwards-Curve Digital Signature Algorithm (EdDSA) In-Reply-To: <20200507202217.ACF3A33C0F3@eggemoggin.niobe.net> References: <20200507202217.ACF3A33C0F3@eggemoggin.niobe.net> Message-ID: <20200515152218.184476440@eggemoggin.niobe.net> 2020/5/7 13:22:17 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 15: > > 339: Edwards-Curve Digital Signature Algorithm (EdDSA) > https://openjdk.java.net/jeps/339 > > 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, 14 May, 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 15. Hearing no objections, I?ve targeted this JEP to JDK 15. - Mark From mark.reinhold at oracle.com Fri May 15 22:22:50 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 15 May 2020 15:22:50 -0700 Subject: JEP proposed to target JDK 15: 384: Records (Second Preview) In-Reply-To: <20200507202318.E539133C0FA@eggemoggin.niobe.net> References: <20200507202318.E539133C0FA@eggemoggin.niobe.net> Message-ID: <20200515152250.170174690@eggemoggin.niobe.net> 2020/5/7 13:23:18 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 15: > > 384: Records (Second Preview) > https://openjdk.java.net/jeps/384 > > 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, 14 May, 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 15. Hearing no objections, I?ve targeted this JEP to JDK 15. - Mark From weijun.wang at oracle.com Sat May 16 04:06:28 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 16 May 2020 12:06:28 +0800 Subject: Missing root CAs in cacerts In-Reply-To: <31efdf24-fdd1-49e8-1541-6ec33186aff4@oracle.com> References: <31efdf24-fdd1-49e8-1541-6ec33186aff4@oracle.com> Message-ID: The update-ca-trust command on Red Hat Linux (and Oracle Linux) import certs from multiple sources and is able to generate a Java keystore at /etc/pki/java/cacerts. Last time I checked on one of our machine in OCI, it contains 54 certs not in the OpenJDK's cacerts file and OpenJDK's cacerts has 12 not there. --Max p.s. OpenJDK has 93 certs now. > On May 15, 2020, at 5:52 PM, Magnus Ihse Bursie wrote: > > On 2020-05-14 19:44, Andreas Ahlenstorf wrote: >> Hi! >> >> At AdoptOpenJDK, we get support requests because root CAs are missing from the bundled cacerts file (lib/security/cacerts). We ship the same cacerts file as OpenJDK. As a result, our users cannot connect to various servers using Java's built-in APIs while their browsers can. An example URL that fails is https://api.insee.fr/catalogue/ (root CA: Certigna). >> >> Replacing the bundled cacerts file with one generated from Mozilla's list of trusted CAs [1] fixes the problem. [2] contains the full analysis based on OpenJDK 14.0.1 including an executable test case. >> >> Questions: >> >> * Does OpenJDK want to do something about that? >> * Is there interest for a collaboration in that area, especially by other distributors of OpenJDK like Azul, BellSoft? >> >> Commentary: >> >> From a end user's perspective, it is inscrutable why it is possible to connect to a website using their browser, curl, but not Java. While there might be some differences because of policy, OpenJDK should strive to match the browser's list of trusted CAs a closely as possible. As of OpenJDK 14.0.1, cacerts contains 93 entries while Mozilla's list contains 138. > From my personal point of view, it seems to make sense to use the Mozilla list. We already use e.g. the Mozilla Public Suffix List, which is a well-handled curated list. > > However, a change of the set of root CAs can certainly have user implications. Have you analyzed which CAs Mozilla is shipping that OpenJDK is missing? And -- even more importantly to avoid regressions for OpenJDK users -- is OpenJDK currently shipping any root CA certificates that Mozilla is missing? > > /Magnus >> >> Best, >> Andreas >> >> [1] https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt >> [2] https://github.com/AdoptOpenJDK/openjdk-support/issues/13#issuecomment-626147267 From peter.tribble at gmail.com Sat May 16 08:20:00 2020 From: peter.tribble at gmail.com (Peter Tribble) Date: Sat, 16 May 2020 09:20:00 +0100 Subject: Missing root CAs in cacerts In-Reply-To: <31efdf24-fdd1-49e8-1541-6ec33186aff4@oracle.com> References: <31efdf24-fdd1-49e8-1541-6ec33186aff4@oracle.com> Message-ID: On Fri, May 15, 2020 at 10:54 AM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2020-05-14 19:44, Andreas Ahlenstorf wrote: > > Hi! > > > > At AdoptOpenJDK, we get support requests because root CAs are missing > from the bundled cacerts file (lib/security/cacerts). We ship the same > cacerts file as OpenJDK. As a result, our users cannot connect to various > servers using Java's built-in APIs while their browsers can. An example URL > that fails is https://api.insee.fr/catalogue/ (root CA: Certigna). > > > > Replacing the bundled cacerts file with one generated from Mozilla's > list of trusted CAs [1] fixes the problem. [2] contains the full analysis > based on OpenJDK 14.0.1 including an executable test case. > > > > Questions: > > > > * Does OpenJDK want to do something about that? > > * Is there interest for a collaboration in that area, especially by > other distributors of OpenJDK like Azul, BellSoft? > > > > Commentary: > > > > From a end user's perspective, it is inscrutable why it is possible to > connect to a website using their browser, curl, but not Java. While there > might be some differences because of policy, OpenJDK should strive to match > the browser's list of trusted CAs a closely as possible. As of OpenJDK > 14.0.1, cacerts contains 93 entries while Mozilla's list contains 138. > From my personal point of view, it seems to make sense to use the > Mozilla list. We already use e.g. the Mozilla Public Suffix List, which > is a well-handled curated list. > > However, a change of the set of root CAs can certainly have user > implications. Have you analyzed which CAs Mozilla is shipping that > OpenJDK is missing? And -- even more importantly to avoid regressions > for OpenJDK users -- is OpenJDK currently shipping any root CA > certificates that Mozilla is missing? > This is from a month or so back (I think maybe one of the certs that's in the jdk has since been removed). The following certs are those in jdk that aren't in the current Mozilla bundle. Generally they might expire soon (and have been replaced with newer roots, intermediates having been cross-signed), and there's a bunch of 1024-bit roots that really shouldn't be in use anywhere. # this one expires shortly, should be covered by USERTrust? Issuer: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE Valid from: Tue May 30 11:38:31 BST 2000 until: Sat May 30 11:38:31 BST 2020 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 2048-bit RSA key # this one expires shortly, should be covered by USERTrust? Issuer: CN=AddTrust Qualified CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE Valid from: Tue May 30 11:44:50 BST 2000 until: Sat May 30 11:44:50 BST 2020 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 2048-bit RSA key # Issuer: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL Valid from: Tue Jun 11 11:46:39 BST 2002 until: Fri Jun 11 11:46:39 BST 2027 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 2048-bit RSA key # Issuer: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU Valid from: Tue Sep 30 17:13:43 BST 2003 until: Wed Sep 30 17:13:44 BST 2037 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 2048-bit RSA key # this one expires shortly (replaced by OpenTrust) Issuer: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR Valid from: Tue May 26 01:00:00 BST 2009 until: Tue May 26 01:00:00 BST 2020 Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key # this one expires shortly [there's a new LuxTrust Global Root 2] Issuer: CN=LuxTrust Global Root, O=LuxTrust s.a., C=LU Valid from: Thu Mar 17 09:51:37 GMT 2011 until: Wed Mar 17 09:51:37 GMT 2021 Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key # Issuer: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH Valid from: Wed Oct 25 09:36:00 BST 2006 until: Sat Oct 25 09:36:00 BST 2036 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 4096-bit RSA key # 1024-bit Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA Valid from: Wed Jan 01 00:00:00 GMT 1997 until: Fri Jan 01 23:59:59 GMT 2021 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 1024-bit RSA key # this one has already expired Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US Valid from: Fri Jul 09 19:31:20 BST 1999 until: Tue Jul 09 19:40:36 BST 2019 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 2048-bit RSA key # 1024-bit Issuer: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA Valid from: Thu Aug 01 01:00:00 BST 1996 until: Fri Jan 01 23:59:59 GMT 2021 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 1024-bit RSA key # 1024-bit Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US Valid from: Mon Jan 29 00:00:00 GMT 1996 until: Thu Aug 03 00:59:59 BST 2028 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 1024-bit RSA key # 1024-bit Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US Valid from: Mon May 18 01:00:00 BST 1998 until: Wed Aug 02 00:59:59 BST 2028 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 1024-bit RSA key # 1024-bit Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US Valid from: Mon May 18 01:00:00 BST 1998 until: Wed Aug 02 00:59:59 BST 2028 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 1024-bit RSA key -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From martinrb at google.com Sat May 16 23:09:36 2020 From: martinrb at google.com (Martin Buchholz) Date: Sat, 16 May 2020 16:09:36 -0700 Subject: Missing root CAs in cacerts In-Reply-To: References: <31efdf24-fdd1-49e8-1541-6ec33186aff4@oracle.com> Message-ID: The mozilla team seems to be doing a good job of maintaining their collection of cacerts, and they have become something of an industry standard. openjdk could probably include those cacerts with the openjdk sources; perhaps there is some hesitation about legalities. On Sat, May 16, 2020 at 1:21 AM Peter Tribble wrote: > > On Fri, May 15, 2020 at 10:54 AM Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > > > On 2020-05-14 19:44, Andreas Ahlenstorf wrote: > > > Hi! > > > > > > At AdoptOpenJDK, we get support requests because root CAs are missing > > from the bundled cacerts file (lib/security/cacerts). We ship the same > > cacerts file as OpenJDK. As a result, our users cannot connect to various > > servers using Java's built-in APIs while their browsers can. An example URL > > that fails is https://api.insee.fr/catalogue/ (root CA: Certigna). > > > > > > Replacing the bundled cacerts file with one generated from Mozilla's > > list of trusted CAs [1] fixes the problem. [2] contains the full analysis > > based on OpenJDK 14.0.1 including an executable test case. > > > > > > Questions: > > > > > > * Does OpenJDK want to do something about that? > > > * Is there interest for a collaboration in that area, especially by > > other distributors of OpenJDK like Azul, BellSoft? > > > > > > Commentary: > > > > > > From a end user's perspective, it is inscrutable why it is possible to > > connect to a website using their browser, curl, but not Java. While there > > might be some differences because of policy, OpenJDK should strive to match > > the browser's list of trusted CAs a closely as possible. As of OpenJDK > > 14.0.1, cacerts contains 93 entries while Mozilla's list contains 138. > > From my personal point of view, it seems to make sense to use the > > Mozilla list. We already use e.g. the Mozilla Public Suffix List, which > > is a well-handled curated list. > > > > However, a change of the set of root CAs can certainly have user > > implications. Have you analyzed which CAs Mozilla is shipping that > > OpenJDK is missing? And -- even more importantly to avoid regressions > > for OpenJDK users -- is OpenJDK currently shipping any root CA > > certificates that Mozilla is missing? > > > > This is from a month or so back (I think maybe one of the certs that's in > the jdk has since > been removed). The following certs are those in jdk that aren't in the > current Mozilla bundle. > Generally they might expire soon (and have been replaced with newer roots, > intermediates > having been cross-signed), and there's a bunch of 1024-bit roots that > really shouldn't > be in use anywhere. > > # this one expires shortly, should be covered by USERTrust? > Issuer: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust > AB, C=SE > Valid from: Tue May 30 11:38:31 BST 2000 until: Sat May 30 11:38:31 BST 2020 > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 2048-bit RSA key > > # this one expires shortly, should be covered by USERTrust? > Issuer: CN=AddTrust Qualified CA Root, OU=AddTrust TTP Network, O=AddTrust > AB, C=SE > Valid from: Tue May 30 11:44:50 BST 2000 until: Sat May 30 11:44:50 BST 2020 > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 2048-bit RSA key > > # > Issuer: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL > Valid from: Tue Jun 11 11:46:39 BST 2002 until: Fri Jun 11 11:46:39 BST 2027 > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 2048-bit RSA key > > # > Issuer: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC > Camerfirma SA CIF A82743287, C=EU > Valid from: Tue Sep 30 17:13:43 BST 2003 until: Wed Sep 30 17:13:44 BST 2037 > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 2048-bit RSA key > > # this one expires shortly (replaced by OpenTrust) > Issuer: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR > Valid from: Tue May 26 01:00:00 BST 2009 until: Tue May 26 01:00:00 BST 2020 > Signature algorithm name: SHA256withRSA > Subject Public Key Algorithm: 2048-bit RSA key > > # this one expires shortly [there's a new LuxTrust Global Root 2] > Issuer: CN=LuxTrust Global Root, O=LuxTrust s.a., C=LU > Valid from: Thu Mar 17 09:51:37 GMT 2011 until: Wed Mar 17 09:51:37 GMT 2021 > Signature algorithm name: SHA256withRSA > Subject Public Key Algorithm: 2048-bit RSA key > > # > Issuer: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH > Valid from: Wed Oct 25 09:36:00 BST 2006 until: Sat Oct 25 09:36:00 BST 2036 > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 4096-bit RSA key > > # 1024-bit > Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, > L=Durbanville, ST=Western Cape, C=ZA > Valid from: Wed Jan 01 00:00:00 GMT 1997 until: Fri Jan 01 23:59:59 GMT 2021 > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 1024-bit RSA key > > # this one has already expired > Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The > USERTRUST Network, L=Salt Lake City, ST=UT, C=US > Valid from: Fri Jul 09 19:31:20 BST 1999 until: Tue Jul 09 19:40:36 BST 2019 > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 2048-bit RSA key > > # 1024-bit > Issuer: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server > CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape > Town, ST=Western Cape, C=ZA > Valid from: Thu Aug 01 01:00:00 BST 1996 until: Fri Jan 01 23:59:59 GMT 2021 > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 1024-bit RSA key > > # 1024-bit > Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, > Inc.", C=US > Valid from: Mon Jan 29 00:00:00 GMT 1996 until: Thu Aug 03 00:59:59 BST 2028 > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 1024-bit RSA key > > # 1024-bit > Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For > authorized use only", OU=Class 2 Public Primary Certification Authority - > G2, O="VeriSign, Inc.", C=US > Valid from: Mon May 18 01:00:00 BST 1998 until: Wed Aug 02 00:59:59 BST 2028 > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 1024-bit RSA key > > > # 1024-bit > Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For > authorized use only", OU=Class 3 Public Primary Certification Authority - > G2, O="VeriSign, Inc.", C=US > Valid from: Mon May 18 01:00:00 BST 1998 until: Wed Aug 02 00:59:59 BST 2028 > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 1024-bit RSA key > > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From magnus.ihse.bursie at oracle.com Mon May 18 07:59:40 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 May 2020 09:59:40 +0200 Subject: Missing root CAs in cacerts In-Reply-To: References: <31efdf24-fdd1-49e8-1541-6ec33186aff4@oracle.com> Message-ID: On 2020-05-17 01:09, Martin Buchholz wrote: > The mozilla team seems to be doing a good job of maintaining their > collection of cacerts, and they have become something of an industry > standard. I know wget uses this database as their source for cacarts. Are there more? I've personally run into the issue of missing CAs from Java. It was infuriatingly hard to debug and understand why I was able to access a web resource from the browser, and from wget, but the Java tool designed to download it failed, with a very non-descriptive error message. So I'm all for moving to a industry standard base for cacerts. /Magnus > > openjdk could probably include those cacerts with the openjdk sources; > perhaps there is some hesitation about legalities. > > On Sat, May 16, 2020 at 1:21 AM Peter Tribble wrote: >> On Fri, May 15, 2020 at 10:54 AM Magnus Ihse Bursie < >> magnus.ihse.bursie at oracle.com> wrote: >> >>> On 2020-05-14 19:44, Andreas Ahlenstorf wrote: >>>> Hi! >>>> >>>> At AdoptOpenJDK, we get support requests because root CAs are missing >>> from the bundled cacerts file (lib/security/cacerts). We ship the same >>> cacerts file as OpenJDK. As a result, our users cannot connect to various >>> servers using Java's built-in APIs while their browsers can. An example URL >>> that fails is https://api.insee.fr/catalogue/ (root CA: Certigna). >>>> Replacing the bundled cacerts file with one generated from Mozilla's >>> list of trusted CAs [1] fixes the problem. [2] contains the full analysis >>> based on OpenJDK 14.0.1 including an executable test case. >>>> Questions: >>>> >>>> * Does OpenJDK want to do something about that? >>>> * Is there interest for a collaboration in that area, especially by >>> other distributors of OpenJDK like Azul, BellSoft? >>>> Commentary: >>>> >>>> From a end user's perspective, it is inscrutable why it is possible to >>> connect to a website using their browser, curl, but not Java. While there >>> might be some differences because of policy, OpenJDK should strive to match >>> the browser's list of trusted CAs a closely as possible. As of OpenJDK >>> 14.0.1, cacerts contains 93 entries while Mozilla's list contains 138. >>> From my personal point of view, it seems to make sense to use the >>> Mozilla list. We already use e.g. the Mozilla Public Suffix List, which >>> is a well-handled curated list. >>> >>> However, a change of the set of root CAs can certainly have user >>> implications. Have you analyzed which CAs Mozilla is shipping that >>> OpenJDK is missing? And -- even more importantly to avoid regressions >>> for OpenJDK users -- is OpenJDK currently shipping any root CA >>> certificates that Mozilla is missing? >>> >> This is from a month or so back (I think maybe one of the certs that's in >> the jdk has since >> been removed). The following certs are those in jdk that aren't in the >> current Mozilla bundle. >> Generally they might expire soon (and have been replaced with newer roots, >> intermediates >> having been cross-signed), and there's a bunch of 1024-bit roots that >> really shouldn't >> be in use anywhere. >> >> # this one expires shortly, should be covered by USERTrust? >> Issuer: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust >> AB, C=SE >> Valid from: Tue May 30 11:38:31 BST 2000 until: Sat May 30 11:38:31 BST 2020 >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 2048-bit RSA key >> >> # this one expires shortly, should be covered by USERTrust? >> Issuer: CN=AddTrust Qualified CA Root, OU=AddTrust TTP Network, O=AddTrust >> AB, C=SE >> Valid from: Tue May 30 11:44:50 BST 2000 until: Sat May 30 11:44:50 BST 2020 >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 2048-bit RSA key >> >> # >> Issuer: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL >> Valid from: Tue Jun 11 11:46:39 BST 2002 until: Fri Jun 11 11:46:39 BST 2027 >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 2048-bit RSA key >> >> # >> Issuer: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC >> Camerfirma SA CIF A82743287, C=EU >> Valid from: Tue Sep 30 17:13:43 BST 2003 until: Wed Sep 30 17:13:44 BST 2037 >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 2048-bit RSA key >> >> # this one expires shortly (replaced by OpenTrust) >> Issuer: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR >> Valid from: Tue May 26 01:00:00 BST 2009 until: Tue May 26 01:00:00 BST 2020 >> Signature algorithm name: SHA256withRSA >> Subject Public Key Algorithm: 2048-bit RSA key >> >> # this one expires shortly [there's a new LuxTrust Global Root 2] >> Issuer: CN=LuxTrust Global Root, O=LuxTrust s.a., C=LU >> Valid from: Thu Mar 17 09:51:37 GMT 2011 until: Wed Mar 17 09:51:37 GMT 2021 >> Signature algorithm name: SHA256withRSA >> Subject Public Key Algorithm: 2048-bit RSA key >> >> # >> Issuer: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH >> Valid from: Wed Oct 25 09:36:00 BST 2006 until: Sat Oct 25 09:36:00 BST 2036 >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 4096-bit RSA key >> >> # 1024-bit >> Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, >> L=Durbanville, ST=Western Cape, C=ZA >> Valid from: Wed Jan 01 00:00:00 GMT 1997 until: Fri Jan 01 23:59:59 GMT 2021 >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 1024-bit RSA key >> >> # this one has already expired >> Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The >> USERTRUST Network, L=Salt Lake City, ST=UT, C=US >> Valid from: Fri Jul 09 19:31:20 BST 1999 until: Tue Jul 09 19:40:36 BST 2019 >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 2048-bit RSA key >> >> # 1024-bit >> Issuer: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server >> CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape >> Town, ST=Western Cape, C=ZA >> Valid from: Thu Aug 01 01:00:00 BST 1996 until: Fri Jan 01 23:59:59 GMT 2021 >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 1024-bit RSA key >> >> # 1024-bit >> Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, >> Inc.", C=US >> Valid from: Mon Jan 29 00:00:00 GMT 1996 until: Thu Aug 03 00:59:59 BST 2028 >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 1024-bit RSA key >> >> # 1024-bit >> Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For >> authorized use only", OU=Class 2 Public Primary Certification Authority - >> G2, O="VeriSign, Inc.", C=US >> Valid from: Mon May 18 01:00:00 BST 1998 until: Wed Aug 02 00:59:59 BST 2028 >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 1024-bit RSA key >> >> >> # 1024-bit >> Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For >> authorized use only", OU=Class 3 Public Primary Certification Authority - >> G2, O="VeriSign, Inc.", C=US >> Valid from: Mon May 18 01:00:00 BST 1998 until: Wed Aug 02 00:59:59 BST 2028 >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 1024-bit RSA key >> >> >> -- >> -Peter Tribble >> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From fweimer at redhat.com Mon May 18 09:12:04 2020 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 18 May 2020 11:12:04 +0200 Subject: Missing root CAs in cacerts In-Reply-To: (Magnus Ihse Bursie's message of "Mon, 18 May 2020 09:59:40 +0200") References: <31efdf24-fdd1-49e8-1541-6ec33186aff4@oracle.com> Message-ID: <874ksdfvyz.fsf@oldenburg2.str.redhat.com> * Magnus Ihse Bursie: > On 2020-05-17 01:09, Martin Buchholz wrote: >> The mozilla team seems to be doing a good job of maintaining their >> collection of cacerts, and they have become something of an industry >> standard. > I know wget uses this database as their source for cacarts. Are there > more? Most GNU/Linux distributions use the Mozilla list to populate the system certificate store, and patch OpenJDK to use it. Thanks, Florian From aph at redhat.com Mon May 18 09:42:37 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 May 2020 10:42:37 +0100 Subject: Missing root CAs in cacerts In-Reply-To: References: <31efdf24-fdd1-49e8-1541-6ec33186aff4@oracle.com> Message-ID: On 5/18/20 8:59 AM, Magnus Ihse Bursie wrote: > I've personally run into the issue of missing CAs from Java. It was > infuriatingly hard to debug and understand why I was able to access > a web resource from the browser, and from wget, but the Java tool > designed to download it failed, with a very non-descriptive error > message. So I'm all for moving to a industry standard base for > cacerts. >From a free software distro point of view, this is something best handled by the OS itself: that way the user (or the admin) of the system gets to choose what to trust. Having said that, Red Hat uses https://fedoraproject.org/wiki/CA-Certificates, which is the Mozilla CA root certificate bundle, somewhat modified. As far as I'm aware every distro patches OpenJDK to use its own list, which I guess is why this issue hasn't got much attention on GNU/Linux systems. What does Windows do? Do they have a system-wide list? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From bevans at newrelic.com Mon May 18 10:06:54 2020 From: bevans at newrelic.com (Ben Evans) Date: Mon, 18 May 2020 12:06:54 +0200 Subject: JEP proposed to target JDK 15: 384: Records (Second Preview) In-Reply-To: <20200515152250.170174690@eggemoggin.niobe.net> References: <20200507202318.E539133C0FA@eggemoggin.niobe.net> <20200515152250.170174690@eggemoggin.niobe.net> Message-ID: I'm very happy to see Records moving forwards - I can't wait to start using them more. I am somewhat curious about deconstruction patterns, though. Can someone speak to what happened there? They didn't seem to be part of JEP 375 so I was expecting to see them here, but they're not mentioned. Thanks, Ben On Sat, May 16, 2020 at 12:26 AM wrote: > 2020/5/7 13:23:18 -0700, mark.reinhold at oracle.com: > > The following JEP is proposed to target JDK 15: > > > > 384: Records (Second Preview) > > https://openjdk.java.net/jeps/384 > > > > 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, 14 May, 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 15. > > Hearing no objections, I?ve targeted this JEP to JDK 15. > > - Mark > From andreas at ahlenstorf.ch Mon May 18 10:51:26 2020 From: andreas at ahlenstorf.ch (Andreas Ahlenstorf) Date: Mon, 18 May 2020 12:51:26 +0200 Subject: Missing root CAs in cacerts In-Reply-To: References: <31efdf24-fdd1-49e8-1541-6ec33186aff4@oracle.com> Message-ID: On Mon, May 18, 2020, at 11:42, Andrew Haley wrote: > What does Windows do? Do they have a system-wide list? Both Microsoft and Apple have their own CA root program and system-wide APIs to access the list trusted of CA certificates. From an admin's POV, it would be great if those lists could be reused. Windows: * https://docs.microsoft.com/en-us/security/trusted-root/program-requirements * https://docs.microsoft.com/en-us/windows/win32/seccrypto/example-c-program-certificate-store-operations macOS: * https://www.apple.com/certificateauthority/ca_program.html * https://developer.apple.com/documentation/security/keychain_services Andreas From dalibor.topic at oracle.com Mon May 18 15:17:09 2020 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 18 May 2020 17:17:09 +0200 Subject: Missing root CAs in cacerts In-Reply-To: References: Message-ID: <362bb16a-3b44-8d84-e2d7-3bb6d0e68313@oracle.com> On 14.05.2020 19:44, Andreas Ahlenstorf wrote: > Hi! > > At AdoptOpenJDK, we get support requests because root CAs are missing from the bundled cacerts file (lib/security/cacerts). We ship the same cacerts file as OpenJDK. As a result, our users cannot connect to various servers using Java's built-in APIs while their browsers can. An example URL that fails is https://api.insee.fr/catalogue/ (root CA: Certigna). > > Replacing the bundled cacerts file with one generated from Mozilla's list of trusted CAs [1] fixes the problem. [2] contains the full analysis based on OpenJDK 14.0.1 including an executable test case. > > Questions: > > * Does OpenJDK want to do something about that? Hi, only Mozilla could contribute its code to OpenJDK, so unless that happens, the question is somewhat moot. As far as there being differences between different OpenJDK and different browsers goes, that's always going to be the case, regardless of the preferred source of root CAs. Simply put, there are many differences between what root CAs each browser and OS vendor includes in their products. See https://publications.sba-research.org/publications/SSL.pdf for an example of research looking into that. cheers, dalibor topic > * Is there interest for a collaboration in that area, especially by other distributors of OpenJDK like Azul, BellSoft? > > Commentary: > > From a end user's perspective, it is inscrutable why it is possible to connect to a website using their browser, curl, but not Java. While there might be some differences because of policy, OpenJDK should strive to match the browser's list of trusted CAs a closely as possible. As of OpenJDK 14.0.1, cacerts contains 93 entries while Mozilla's list contains 138. > > Best, > Andreas > > [1] https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt > [2] https://github.com/AdoptOpenJDK/openjdk-support/issues/13#issuecomment-626147267 > -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From sean.mullan at oracle.com Mon May 18 20:11:44 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 18 May 2020 16:11:44 -0400 Subject: Missing root CAs in cacerts In-Reply-To: References: <31efdf24-fdd1-49e8-1541-6ec33186aff4@oracle.com> Message-ID: <687cc545-5ac8-a9e7-d122-c4162e69b593@oracle.com> In case you were not aware, the JDK already supports "Windows-ROOT" and "KeychainStore" KeyStore implementations that can access the root certificates of Windows and MacOS keystores, respectively [1, 2]. However, it doesn't work out of the box -- for TLS, you need to minimally configure the javax.net.ssl.trustStoreType and javax.net.ssl.trustStore properties. Other useful options like "keytool -trustcacerts" assume the cacerts keystore. It would take more thought and some amount of work to make it more seamless across the different security components of the JDK. That said, this would not necessarily address the root CA consistency issues, as these different OSes have their own root CA Programs and thus the set of roots can vary across each platform. --Sean [1] https://docs.oracle.com/en/java/javase/14/security/oracle-providers.html#GUID-4F1737D6-1569-4340-B140-678C70E63CD5 [2] https://docs.oracle.com/en/java/javase/14/security/oracle-providers.html#GUID-3185649A-C316-45F2-A70E-2B3FF6BDC34F On 5/18/20 6:51 AM, Andreas Ahlenstorf wrote: > On Mon, May 18, 2020, at 11:42, Andrew Haley wrote: >> What does Windows do? Do they have a system-wide list? > > Both Microsoft and Apple have their own CA root program and system-wide APIs to access the list trusted of CA certificates. From an admin's POV, it would be great if those lists could be reused. > > Windows: > * https://docs.microsoft.com/en-us/security/trusted-root/program-requirements > * https://docs.microsoft.com/en-us/windows/win32/seccrypto/example-c-program-certificate-store-operations > > macOS: > * https://www.apple.com/certificateauthority/ca_program.html > * https://developer.apple.com/documentation/security/keychain_services > > Andreas > From mark.reinhold at oracle.com Mon May 18 23:18:25 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 18 May 2020 16:18:25 -0700 (PDT) Subject: JEPs proposed to target JDK *16*: 357 (Migrate from Mercurial to Git) & 369 (Migrate to GitHub) Message-ID: <20200518231825.211D834D5C9@eggemoggin.niobe.net> The following JEPs are proposed to target JDK *16*: 357: Migrate from Mercurial to Git https://openjdk.java.net/jeps/357 369: Migrate to GitHub https://openjdk.java.net/jeps/369 Feedback on these proposal from JDK Project Committers and Reviewers [1] are more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Monday, 25 May, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target these JEPs to JDK 16. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From joe.darcy at oracle.com Tue May 19 18:44:28 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 19 May 2020 11:44:28 -0700 Subject: JEPs proposed to target JDK *16*: 357 (Migrate from Mercurial to Git) & 369 (Migrate to GitHub) In-Reply-To: <20200518231825.211D834D5C9@eggemoggin.niobe.net> References: <20200518231825.211D834D5C9@eggemoggin.niobe.net> Message-ID: FYI, assuming the JEPs get targeted, a bit more detail on the Skara team's current SCM transition plans for JDK 16. We are looking at transitioning the jdk/jdk repo hosted on github.com to become the read/write master for JDK 16 sources in early September 2020. This would be a few weeks before the GA date of JDK 15 and after a separate JDK 15 repo is forked off in mid-June per the JDK 15 schedule (http://openjdk.java.net/projects/jdk/15/). The early access JDK 16 builds published on http://jdk.java.net/ may transition to being Git-based rather than Mercurial-based some time ahead of the repo transition. Which SCM is used as a basis for a JDK build can be inferred from the contents of the "release" file in the root of the build. Among other information, the release file records the SCM and the SCM hashes of the sources used for the build. -Joe On 5/18/2020 4:18 PM, mark.reinhold at oracle.com wrote: > The following JEPs are proposed to target JDK *16*: > > 357: Migrate from Mercurial to Git > https://openjdk.java.net/jeps/357 > > 369: Migrate to GitHub > https://openjdk.java.net/jeps/369 > > Feedback on these proposal from JDK Project Committers and Reviewers [1] > are more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Monday, 25 May, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target these JEPs to JDK 16. > > - 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 Thu May 21 00:03:02 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 20 May 2020 17:03:02 -0700 Subject: JEP proposed to target JDK 15: 360: Sealed Classes (Preview) In-Reply-To: <20200513234706.5F5BE3453D5@eggemoggin.niobe.net> References: <20200513234706.5F5BE3453D5@eggemoggin.niobe.net> Message-ID: <20200520170302.365251528@eggemoggin.niobe.net> 2020/5/13 16:47:06 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 15: > > 360: Sealed Classes (Preview) > https://openjdk.java.net/jeps/360 > > 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 Wednesday, 20 May, 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 15. Hearing no objections, I?ve targeted this JEP to JDK 15. - Mark From mark.reinhold at oracle.com Thu May 21 00:03:28 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 20 May 2020 17:03:28 -0700 Subject: JEP proposed to target JDK 15: 381: Remove the Solaris and SPARC Ports In-Reply-To: <20200513234807.958763453DC@eggemoggin.niobe.net> References: <20200513234807.958763453DC@eggemoggin.niobe.net> Message-ID: <20200520170328.79744986@eggemoggin.niobe.net> 2020/5/13 16:48:07 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 15: > > 381: Remove the Solaris and SPARC Ports > https://openjdk.java.net/jeps/381 > > 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 Wednesday, 20 May, 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 15. Hearing no objections, I?ve targeted this JEP to JDK 15. - Mark From mikael.vidstedt at oracle.com Thu May 21 01:50:15 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 20 May 2020 18:50:15 -0700 Subject: FYI: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports In-Reply-To: <91715DFA-8FD0-4C93-A620-BC1EFCF1133F@oracle.com> References: <91715DFA-8FD0-4C93-A620-BC1EFCF1133F@oracle.com> Message-ID: <84AEBF62-84CB-40D9-AA56-7FE31727BA4B@oracle.com> The change has now been integrated[1]. A huge thank you to everybody who was involved in the making, reviewing, and testing of this! I have a list of ~20 follow-ups which I?ll be filing JBS issues for, none of which are critical for JDK 15. Some of them are localized and straightforward, e.g. remove STACK_BIAS from hotspot. Others are a bit more nebulous, in particular things like ?clean up code comments?. Final webrev here for completeness: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.final/open/webrev/ Cheers, Mikael [1] http://hg.openjdk.java.net/jdk/jdk/rev/e4ae92a9c67e > On May 3, 2020, at 10:28 PM, Mikael Vidstedt wrote: > > > All, > > FYI - in case you?re not subscribed to all the various OpenJDK mailing lists: > > A first version of the implementation of JEP 381: Remove the Solaris and SPARC Ports[1] is currently out for review. Given the size of the complete patch and the wide range of areas impacted the patch has been split up in six different pieces, each corresponding to an area, being reviewed on mailing list(s) appropriate for that respective area. > > In case you?re curious and/or want to help review the patches, below is a list of links to the respective RFR threads. Please provide comments/feedback in the respective threads, on the respective lists, *not* as replies to this thread. Thank you! > > Cheers, > Mikael > > * build system > > https://mail.openjdk.java.net/pipermail/build-dev/2020-May/027342.html > > * client > > https://mail.openjdk.java.net/pipermail/2d-dev/2020-May/010767.html > https://mail.openjdk.java.net/pipermail/awt-dev/2020-May/015885.html > https://mail.openjdk.java.net/pipermail/swing-dev/2020-May/010382.html > > * core libs > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066219.html > https://mail.openjdk.java.net/pipermail/net-dev/2020-May/013898.html > https://mail.openjdk.java.net/pipermail/nio-dev/2020-May/007233.html > > * hotspot > > https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-May/041653.html > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038082.html > https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-May/029527.html > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-May/039295.html > https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-May/031390.html > > * security > > https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021755.html > > * serviceability > > https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-May/031390.html > > [1] https://bugs.openjdk.java.net/browse/JDK-8241787 From mark.reinhold at oracle.com Thu May 21 21:27:25 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 21 May 2020 14:27:25 -0700 (PDT) Subject: New candidate JEP: 385: Deprecate RMI Activation for Removal Message-ID: <20200521212725.F35A8351D2C@eggemoggin.niobe.net> https://openjdk.java.net/jeps/385 - Mark From ebresie at gmail.com Fri May 22 15:26:04 2020 From: ebresie at gmail.com (Eric Bresie) Date: Fri, 22 May 2020 10:26:04 -0500 Subject: Missing root CAs in cacerts In-Reply-To: 687cc545-5ac8-a9e7-d122-c4162e69b593@oracle.com References: f7327f45-2a81-46d3-af40-cad1d875bd30@www.fastmail.com 31efdf24-fdd1-49e8-1541-6ec33186aff4@oracle.com CAEgYsbEaTSZE+3La=f=NA+wNfO3v4QXEzcpVz8dR7+XCqUWmCA@mail.gmail.com CA+kOe0-LkKFF_KnG8Zv4BBnF-yD52L1=pmZ97uoVJo6SC4M8_g@mail.gmail.com d8579794-a3a9-2bfe-156c-83c8df129987@oracle.com b8197c67-f091-2b4a-c0d4-baeffbba6f14@redhat.com cbf9c413-c67e-4df5-8d68-01119a3b25e7@www.fastmail.com cbf9c413-c67e-4df5-8d68-01119a3b25e7@www.fastmail.com Message-ID: <56751226-424d-4008-a9b3-12a21eeb828f@Erics-iPhone-X> So as I understand this so far: (1) openjdk has removed or has outdated root ca in its cacerts files (2) possibility of updating it with another source of certificates (i.e. Mozilla [open], MS/Apple [less open] is being suggested (3) there may be differences between sources which may have extra or missing items (4) browsers and more able to reach trusted sites while less so with open JDK (and possible java apps) (5) each OS and application may have its own methods and cert management mechanism which adds to the mix as well. I had a few other comments: (6) I am behind a corporate firewall/ proxy which provides internal certs (With it?s own concerns configured) which adds another use case to consider. I assume part of this may be a concern of the Corp IT management so maybe the problem is new jdks or SW is added outside normal IT expectations which doesn?t account for certs in the same corporate cert:proxy way. (7) Not even sure if fire walls and other security controls may also further confuse things. (8) Based on experiences trying to troubleshoot a basic java IDE download issues (not even taking in to account non IDE apps but would wager there are simple problems elsewhere), the solution was to insure the items were added to the store which while doing this was possible, I would argue this is more an admin/ advanced user activity that normal users would be confused and give up in some way. So for this I think it advisable to make this sort of process of configuring and updating more user friendly to ensure JDK remains acceptable to the community as a whole. Maybe could be added a UI (maybe in console) enhancements to allow easier configuration. Maybe could have some security mechanisms to send/receive security specific updates updates. Maybe make at the JDK level (not app level) to be responsible for this so each app doesn?t have to manage this independently Maybe some form of security consortium could start being source of managing this (this may be out of scope here but figured I?d throw it out while thinking of these things) Eric Bresie Ebresie at gmail.com > On May 18, 2020 at 3:11:44 PM CDT, Sean Mullan wrote: > In case you were not aware, the JDK already supports "Windows-ROOT" and > "KeychainStore" KeyStore implementations that can access the root > certificates of Windows and MacOS keystores, respectively [1, 2]. > However, it doesn't work out of the box -- for TLS, you need to > minimally configure the javax.net.ssl.trustStoreType and > javax.net.ssl.trustStore properties. Other useful options like "keytool > -trustcacerts" assume the cacerts keystore. > > It would take more thought and some amount of work to make it more > seamless across the different security components of the JDK. > > That said, this would not necessarily address the root CA consistency > issues, as these different OSes have their own root CA Programs and thus > the set of roots can vary across each platform. > > --Sean > > [1] > https://docs.oracle.com/en/java/javase/14/security/oracle-providers.html#GUID-4F1737D6-1569-4340-B140-678C70E63CD5 > [2] > https://docs.oracle.com/en/java/javase/14/security/oracle-providers.html#GUID-3185649A-C316-45F2-A70E-2B3FF6BDC34F > > > On 5/18/20 6:51 AM, Andreas Ahlenstorf wrote: > > On Mon, May 18, 2020, at 11:42, Andrew Haley wrote: > > > What does Windows do? Do they have a system-wide list? > > > > Both Microsoft and Apple have their own CA root program and system-wide APIs to access the list trusted of CA certificates. From an admin's POV, it would be great if those lists could be reused. > > > > Windows: > > * https://docs.microsoft.com/en-us/security/trusted-root/program-requirements > > * https://docs.microsoft.com/en-us/windows/win32/seccrypto/example-c-program-certificate-store-operations > > > > macOS: > > * https://www.apple.com/certificateauthority/ca_program.html > > * https://developer.apple.com/documentation/security/keychain_services > > > > Andreas > > From mark.reinhold at oracle.com Fri May 22 16:44:20 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 22 May 2020 09:44:20 -0700 Subject: JEP proposed to target JDK 15: 383: Foreign-Memory Access API (Second Incubator) In-Reply-To: <20200514225055.B205334769F@eggemoggin.niobe.net> References: <20200514225055.B205334769F@eggemoggin.niobe.net> Message-ID: <20200522094420.255252564@eggemoggin.niobe.net> 2020/5/14 15:50:55 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 15: > > 383: Foreign-Memory Access API (Second Incubator) > https://openjdk.java.net/jeps/383 > > 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, 21 May, 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 15. Hearing no objections, I?ve targeted this JEP to JDK 15. - Mark From mark.reinhold at oracle.com Fri May 22 20:54:58 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 22 May 2020 13:54:58 -0700 (PDT) Subject: New candidate JEP: 386: Alpine Linux/x64 Port Message-ID: <20200522205458.AEBB2353520@eggemoggin.niobe.net> https://openjdk.java.net/jeps/386 - Mark From jesper.wilhelmsson at oracle.com Mon May 25 09:12:24 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 May 2020 11:12:24 +0200 Subject: Developers' Guide project initiated Message-ID: <84156CE5-1AE0-4437-864C-3D1D2BF006F2@oracle.com> FYI, since there were some discussion around this: The OpenJDK Developers' Guide project is now up and running. The mailing list to join is guide-dev at openjdk.java.net: http://mail.openjdk.java.net/mailman/listinfo/guide-dev The source repository is available here: https://github.com/openjdk/guide The online version, https://openjdk.java.net/guide/ is now updated from the github repo. Cheers! /Jesper From sgehwolf at redhat.com Mon May 25 09:39:15 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 25 May 2020 11:39:15 +0200 Subject: Developers' Guide project initiated In-Reply-To: <84156CE5-1AE0-4437-864C-3D1D2BF006F2@oracle.com> References: <84156CE5-1AE0-4437-864C-3D1D2BF006F2@oracle.com> Message-ID: <43dfed89282d95d1752ba21b41574b836005a02e.camel@redhat.com> Hi Jesper, On Mon, 2020-05-25 at 11:12 +0200, Jesper Wilhelmsson wrote: > FYI, since there were some discussion around this: The OpenJDK > Developers' Guide project is now up and running. > > The mailing list to join is guide-dev at openjdk.java.net: > http://mail.openjdk.java.net/mailman/listinfo/guide-dev > > The source repository is available here: > https://github.com/openjdk/guide > > The online version, https://openjdk.java.net/guide/ is now updated > from the github repo. Very nice! This will be useful. Thanks for the heads-up! Cheers, Severin From fedor.burdun at azul.com Tue May 26 13:14:04 2020 From: fedor.burdun at azul.com (Fedor) Date: Tue, 26 May 2020 16:14:04 +0300 Subject: suggesting fix: cross-compilation is requiring write permissions to bootstrap jdk Message-ID: <1a893836-4eb5-e314-509c-779d381206e3@azul.com> Hello all! I've tried to crossbuild jdk using current http://hg.openjdk.java.net/jdk/jdk/ sources and noticed that build requires write permissions to bootstrap jdk. The problem is it tries to write/rewrite class list into bootstrap jdk directory. I would like to suggest the fix below to solve this problem: diff --git a/make/GenerateLinkOptData.gmk b/make/GenerateLinkOptData.gmk --- a/make/GenerateLinkOptData.gmk +++ b/make/GenerateLinkOptData.gmk @@ -69,10 +69,10 @@ -Duser.language=en -Duser.country=US \ -cp $(SUPPORT_OUTPUTDIR)/classlist.jar \ build.tools.classlist.HelloClasslist $(LOG_DEBUG) - $(GREP) -v HelloClasslist $@.raw > $(INTERIM_IMAGE_DIR)/lib/classlist - $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java -Xshare:dump \ + $(GREP) -v HelloClasslist $@.raw > $@.classlist + $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java -Xshare:dump -XX:SharedClassListFile=$@.classlist -XX:SharedArchiveFile=$@.jsa \ -Xmx128M -Xms128M $(LOG_INFO) - $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java -XX:DumpLoadedClassList=$@.raw \ + $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java -XX:DumpLoadedClassList=$@.raw -XX:SharedClassListFile=$@.classlist -XX:SharedArchiveFile=$@.jsa \ -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true \ -Duser.language=en -Duser.country=US \ --module-path $(SUPPORT_OUTPUTDIR)/classlist.jar \ Please correct me in case if it is wrong alias, or I need to file bug first, or something else. Best Regards, Fedor From david.holmes at oracle.com Tue May 26 13:32:12 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 May 2020 23:32:12 +1000 Subject: suggesting fix: cross-compilation is requiring write permissions to bootstrap jdk In-Reply-To: <1a893836-4eb5-e314-509c-779d381206e3@azul.com> References: <1a893836-4eb5-e314-509c-779d381206e3@azul.com> Message-ID: Re-directing to the build-dev list. David On 26/05/2020 11:14 pm, Fedor wrote: > Hello all! > > I've tried to crossbuild jdk using current > http://hg.openjdk.java.net/jdk/jdk/ sources and noticed that build > requires write permissions to bootstrap jdk. > The problem is it tries to write/rewrite class list into bootstrap jdk > directory. > I would like to suggest the fix below to solve this problem: > > > diff --git a/make/GenerateLinkOptData.gmk b/make/GenerateLinkOptData.gmk > --- a/make/GenerateLinkOptData.gmk > +++ b/make/GenerateLinkOptData.gmk > @@ -69,10 +69,10 @@ > ??????????? -Duser.language=en -Duser.country=US \ > ??????????? -cp $(SUPPORT_OUTPUTDIR)/classlist.jar \ > ??????????? build.tools.classlist.HelloClasslist $(LOG_DEBUG) > -?????? $(GREP) -v HelloClasslist $@.raw > > $(INTERIM_IMAGE_DIR)/lib/classlist > -?????? $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java -Xshare:dump \ > +?????? $(GREP) -v HelloClasslist $@.raw > $@.classlist > +?????? $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java -Xshare:dump > -XX:SharedClassListFile=$@.classlist -XX:SharedArchiveFile=$@.jsa \ > ??????????? -Xmx128M -Xms128M $(LOG_INFO) > -?????? $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java > -XX:DumpLoadedClassList=$@.raw \ > +?????? $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java > -XX:DumpLoadedClassList=$@.raw -XX:SharedClassListFile=$@.classlist > -XX:SharedArchiveFile=$@.jsa \ > ??????????? -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true \ > ??????????? -Duser.language=en -Duser.country=US \ > ??????????? --module-path $(SUPPORT_OUTPUTDIR)/classlist.jar \ > > Please correct me in case if it is wrong alias, or I need to file bug > first, or something else. > > Best Regards, > Fedor > From igor.ignatyev at oracle.com Tue May 26 20:42:13 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 26 May 2020 13:42:13 -0700 Subject: Changes in gtest building after 8245610(remove in-tree copy on gtest) Message-ID: <786CD25F-36F5-435B-B731-AA0DEF664715@oracle.com> Dear all, The integration of 8245610[1-3] has slightly changed how to enable/disable hotspot Gtest test suite, which might affect some of you and require changes in your build/configure scripts. This email is to notify you about the possible impact and provide with the suggested changes for your `configure` option-set. The patch removed the copy of Gtest framework which was located in `test/fmw/gtest`, now Gtest source code is to be stored separately and provided via `--with-gtest` configure options. Building the JDK[4] documentation has been updated to reflect this new dependency. The patch also deprecated `--(enable|disable)-hotspot-gtest` flags and changed defaults: unless `--with-gtest` points to the source code of Gtest, the test suite won't be built. jib profiles were updated to have Gtest as dependency, so `jib` automatically downloads Gtest source code and properly passes it to `--with-gtest` option. The impacted people can be grouped by their needs to build Gtest test suite, and whether `jib` is used; the suggested changes for each group: - use `jib` and want Gtest test suite to be built: you are all set, no changes are required; - use `jib` and don't need Gtest test suite, i.e. you used to run `jib configure -- --disable-hotspot-gtest`: you need to replace `--disable-hotspot-gtest` by `--without-gtest`; - don't use `jib` and don't need Gtest test suite, i.e. you used to run `./configure --disable-hotspot-gtest`: you just need to remove `--disable-hotspot-gtest`; - don't use `jib` and want Gtest test suite to be built: you need to get Gtest source code and provide its path via `--with-gtest`. Running Tests[5] section gives suggestions on how the source code can be obtained. Thanks, -- Igor [1] https://bugs.openjdk.java.net/browse/JDK-8245610 [2] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-May/041900.html [3] https://hg.openjdk.java.net/jdk/jdk/rev/21c94b6f23e7 [4] http://hg.openjdk.java.net/jdk/jdk/raw-file/21c94b6f23e7/doc/building.html [5] http://hg.openjdk.java.net/jdk/jdk/raw-file/21c94b6f23e7/doc/building.html#running-tests From mark.reinhold at oracle.com Wed May 27 02:14:14 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 26 May 2020 19:14:14 -0700 Subject: JEPs proposed to target JDK *16*: 357 (Migrate from Mercurial to Git) & 369 (Migrate to GitHub) In-Reply-To: <20200518231825.211D834D5C9@eggemoggin.niobe.net> References: <20200518231825.211D834D5C9@eggemoggin.niobe.net> Message-ID: <20200526191414.495048892@eggemoggin.niobe.net> 2020/5/18 16:18:25 -0700, mark.reinhold at oracle.com: > The following JEPs are proposed to target JDK *16*: > > 357: Migrate from Mercurial to Git > https://openjdk.java.net/jeps/357 > > 369: Migrate to GitHub > https://openjdk.java.net/jeps/369 > > Feedback on these proposal from JDK Project Committers and Reviewers [1] > are more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Monday, 25 May, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target these JEPs to JDK 16. Hearing no objections, I?ve targeted these JEPs to JDK 16. - Mark From zoltan.jose at gmail.com Wed May 27 06:51:45 2020 From: zoltan.jose at gmail.com (Timmy Jose) Date: Wed, 27 May 2020 12:21:45 +0530 Subject: JEPs proposed to target JDK *16*: 357 (Migrate from Mercurial to Git) & 369 (Migrate to GitHub) In-Reply-To: References: <20200518231825.211D834D5C9@eggemoggin.niobe.net> Message-ID: That is excellent news! On Wed, May 20, 2020 at 12:17 AM Joe Darcy wrote: > FYI, assuming the JEPs get targeted, a bit more detail on the Skara > team's current SCM transition plans for JDK 16. > > We are looking at transitioning the jdk/jdk repo hosted on github.com to > become the read/write master for JDK 16 sources in early September 2020. > This would be a few weeks before the GA date of JDK 15 and after a > separate JDK 15 repo is forked off in mid-June per the JDK 15 schedule > (http://openjdk.java.net/projects/jdk/15/). > > The early access JDK 16 builds published on http://jdk.java.net/ may > transition to being Git-based rather than Mercurial-based some time > ahead of the repo transition. Which SCM is used as a basis for a JDK > build can be inferred from the contents of the "release" file in the > root of the build. Among other information, the release file records the > SCM and the SCM hashes of the sources used for the build. > > -Joe > > On 5/18/2020 4:18 PM, mark.reinhold at oracle.com wrote: > > The following JEPs are proposed to target JDK *16*: > > > > 357: Migrate from Mercurial to Git > > https://openjdk.java.net/jeps/357 > > > > 369: Migrate to GitHub > > https://openjdk.java.net/jeps/369 > > > > Feedback on these proposal from JDK Project Committers and Reviewers [1] > > are more than welcome, as are reasoned objections. If no such objections > > are raised by 23:59 UTC on Monday, 25 May, or if they?re raised and > > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > > I?ll target these JEPs to JDK 16. > > > > - Mark > > > > > > [1] https://openjdk.java.net/census#jdk > > [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > From gnu.andrew at redhat.com Wed May 27 18:53:25 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 27 May 2020 19:53:25 +0100 Subject: CFV: New OpenJDK Committer: Simon Tooke Message-ID: I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Committer. Simon has done a decent amount of work in the main JDK project [1] and making him a committer would aid further work by avoiding the need for someone else to push his fixes. He is already an 8u and jdk-updates committer. Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. Only current OpenJDK Committers (and above) [2] 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 [3]. [0] https://openjdk.java.net/census#stooke [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge() [2] https://openjdk.java.net/census#jdk [3] http://openjdk.java.net/projects/#committer-vote Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed May 27 19:08:35 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 27 May 2020 20:08:35 +0100 Subject: CFV: New OpenJDK Committer: Simon Tooke In-Reply-To: References: Message-ID: <1e57b7f5-ea6c-ea95-72b6-859c91544ad5@redhat.com> On 27/05/2020 19:53, Andrew Hughes wrote: > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Committer. > > Simon has done a decent amount of work in the main JDK project [1] and > making him a committer would aid further work by avoiding the need for > someone else to push his fixes. He is already an 8u and jdk-updates > committer. > > Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. > > Only current OpenJDK Committers (and above) [2] 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 [3]. > > [0] https://openjdk.java.net/census#stooke > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge() > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#committer-vote > > Thanks, > Vote: Yes -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mikael.vidstedt at oracle.com Wed May 27 19:19:46 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 27 May 2020 12:19:46 -0700 Subject: CFV: New OpenJDK Committer: Simon Tooke In-Reply-To: References: Message-ID: <7845C720-F456-42B4-AA7E-F62342978B36@oracle.com> > On May 27, 2020, at 11:53 AM, Andrew Hughes wrote: > > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Committer. Any particular reason for using ?OpenJDK? instead of a/the project name (?JDK?)? Cheers, Mikael From gnu.andrew at redhat.com Wed May 27 19:31:56 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 27 May 2020 20:31:56 +0100 Subject: CFV: New OpenJDK Committer: Simon Tooke In-Reply-To: <7845C720-F456-42B4-AA7E-F62342978B36@oracle.com> References: <7845C720-F456-42B4-AA7E-F62342978B36@oracle.com> Message-ID: On 27/05/2020 20:19, Mikael Vidstedt wrote: > > >> On May 27, 2020, at 11:53 AM, Andrew Hughes wrote: >> >> I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Committer. > > Any particular reason for using ?OpenJDK? instead of a/the project name (?JDK?)? > > Cheers, > Mikael > I tend to always use OpenJDK for clarity. 'JDK' has a history of association with the Sun/Oracle proprietary project. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From neugens at redhat.com Wed May 27 20:00:36 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 27 May 2020 22:00:36 +0200 Subject: CFV: New OpenJDK Committer: Simon Tooke In-Reply-To: References: Message-ID: Vote: Yes Cheers, Mario On Wednesday, May 27, 2020, Andrew Hughes wrote: > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Committer. > > Simon has done a decent amount of work in the main JDK project [1] and > making him a committer would aid further work by avoiding the need for > someone else to push his fixes. He is already an 8u and jdk-updates > committer. > > Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. > > Only current OpenJDK Committers (and above) [2] 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 [3]. > > [0] https://openjdk.java.net/census#stooke > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=( > author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge() > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#committer-vote > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From zgu at redhat.com Wed May 27 20:03:16 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 27 May 2020 16:03:16 -0400 Subject: CFV: New OpenJDK Committer: Simon Tooke In-Reply-To: References: Message-ID: Vote: yes -Zhengyu On 5/27/20 2:53 PM, Andrew Hughes wrote: > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Committer. > > Simon has done a decent amount of work in the main JDK project [1] and > making him a committer would aid further work by avoiding the need for > someone else to push his fixes. He is already an 8u and jdk-updates > committer. > > Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. > > Only current OpenJDK Committers (and above) [2] 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 [3]. > > [0] https://openjdk.java.net/census#stooke > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge() > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#committer-vote > > Thanks, > From mikael.vidstedt at oracle.com Wed May 27 20:52:59 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 27 May 2020 13:52:59 -0700 Subject: CFV: New OpenJDK Committer: Simon Tooke In-Reply-To: References: <7845C720-F456-42B4-AA7E-F62342978B36@oracle.com> Message-ID: > On May 27, 2020, at 12:31 PM, Andrew Hughes wrote: > > On 27/05/2020 20:19, Mikael Vidstedt wrote: >> >> >>> On May 27, 2020, at 11:53 AM, Andrew Hughes wrote: >>> >>> I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Committer. >> >> Any particular reason for using ?OpenJDK? instead of a/the project name (?JDK?)? >> >> Cheers, >> Mikael >> > > I tend to always use OpenJDK for clarity. 'JDK' has a history of > association with the Sun/Oracle proprietary project. Though it actually makes it less clear :) As mentioned on[1] the email subject and body should use the short name for the project in question (?JDK?), otherwise it?s not really clear which specific project it?s referring to (though we can of course make educated guesses). Cheers, Mikael [1] https://openjdk.java.net/projects/#project-committer From hohensee at amazon.com Wed May 27 21:12:33 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 27 May 2020 21:12:33 +0000 Subject: CFV: New OpenJDK Committer: Simon Tooke Message-ID: <93F3FB8F-B40F-4680-8458-0FDC6BFF9949@amazon.com> Vote: yes ?On 5/27/20, 11:54 AM, "jdk-dev on behalf of Andrew Hughes" wrote: I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Committer. Simon has done a decent amount of work in the main JDK project [1] and making him a committer would aid further work by avoiding the need for someone else to push his fixes. He is already an 8u and jdk-updates committer. Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. Only current OpenJDK Committers (and above) [2] 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 [3]. [0] https://openjdk.java.net/census#stooke [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge() [2] https://openjdk.java.net/census#jdk [3] http://openjdk.java.net/projects/#committer-vote Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From joe.darcy at oracle.com Thu May 28 01:55:12 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 27 May 2020 18:55:12 -0700 Subject: Reminder: submit CSRs for JDK 15 changes ahead of rampdown 1 milestone of June 11, 2020 In-Reply-To: <8f47f1fd-dbe8-a974-093a-a08a60c02660@oracle.com> References: <8f47f1fd-dbe8-a974-093a-a08a60c02660@oracle.com> Message-ID: <2ffb5c41-7883-4470-0d1e-074b666df7b6@oracle.com> Another reminder, JDK 15 rampdown phase one starts in about two weeks. The nominal review SLA for a CSR is one week. This is the latency for request to be reviewed, not necessarily the latency for the request to be approved. If you have outstanding interfaces changes intended for JDK 15 (API changes, command line option changes, etc.) file a CSR soon as possible to increase the likelihood of successfully completing the CSR review before the rampdown starts. Thanks, -Joe On 4/27/2020 3:43 PM, Joe Darcy wrote: > Hello, > > Per the JDK 15 schedule (http://openjdk.java.net/projects/jdk/15/), > rampdown phase one is coming up on June 11, 2020. > > If you have outstanding changes intended to go into JDK 15, please > file any CSRs with sufficient lead time to accommodate both the review > and responses to possible review feedback. More detail about the CSR > process is written up on its wiki: > > ???? https://wiki.openjdk.java.net/display/csr/Main > > Happy coding, > > -Joe > From david.holmes at oracle.com Thu May 28 04:57:40 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 May 2020 21:57:40 -0700 (PDT) Subject: CFV: New OpenJDK Committer: Simon Tooke In-Reply-To: References: Message-ID: Vote: No Sorry Andrew this seems premature. There are only 7 contributions listed, the most recent 6 months ago, only 2 in the last year and most of them I would not consider "significant". If Simon is to be working more on the mainline JDK project then it should not take long to get another 3 or 4 significant contributions in place. And on a point of order, as Mikael notes, the subject should refer to the "JDK" project, not "OpenJDK". Cheers, David On 28/05/2020 4:53 am, Andrew Hughes wrote: > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Committer. > > Simon has done a decent amount of work in the main JDK project [1] and > making him a committer would aid further work by avoiding the need for > someone else to push his fixes. He is already an 8u and jdk-updates > committer. > > Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. > > Only current OpenJDK Committers (and above) [2] 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 [3]. > > [0] https://openjdk.java.net/census#stooke > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge() > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#committer-vote > > Thanks, > From david.holmes at oracle.com Thu May 28 05:06:20 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 May 2020 15:06:20 +1000 Subject: CFV: New OpenJDK Committer: Simon Tooke In-Reply-To: References: Message-ID: <5f8dae97-4ca5-e90f-ff5c-026cf9b570ee@oracle.com> On 28/05/2020 2:57 pm, David Holmes wrote: > Vote: No Vote: Veto Sorry I forgot the terminology. David > Sorry Andrew this seems premature. There are only 7 contributions > listed, the most recent 6 months ago, only 2 in the last year and most > of them I would not consider "significant". If Simon is to be working > more on the mainline JDK project then it should not take long to get > another 3 or 4 significant contributions in place. > > And on a point of order, as Mikael notes, the subject should refer to > the "JDK" project, not "OpenJDK". > > Cheers, > David > > On 28/05/2020 4:53 am, Andrew Hughes wrote: >> I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Committer. >> >> Simon has done a decent amount of work in the main JDK project [1] and >> making him a committer would aid further work by avoiding the need for >> someone else to push his fixes. He is already an 8u and jdk-updates >> committer. >> >> Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. >> >> Only current OpenJDK Committers (and above) [2] 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 [3]. >> >> [0] https://openjdk.java.net/census#stooke >> [1] >> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge() >> >> [2] https://openjdk.java.net/census#jdk >> [3] http://openjdk.java.net/projects/#committer-vote >> >> Thanks, >> From thomas.stuefe at gmail.com Thu May 28 05:11:24 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 May 2020 07:11:24 +0200 Subject: CFV: New OpenJDK Committer: Simon Tooke In-Reply-To: References: Message-ID: Vote: Yes On Wed, May 27, 2020 at 8:53 PM Andrew Hughes wrote: > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Committer. > > Simon has done a decent amount of work in the main JDK project [1] and > making him a committer would aid further work by avoiding the need for > someone else to push his fixes. He is already an 8u and jdk-updates > committer. > > Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. > > Only current OpenJDK Committers (and above) [2] 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 [3]. > > [0] https://openjdk.java.net/census#stooke > [1] > > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge() > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#committer-vote > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > From Alan.Bateman at oracle.com Thu May 28 08:13:02 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 May 2020 09:13:02 +0100 Subject: CFV: New OpenJDK Committer: Simon Tooke In-Reply-To: References: Message-ID: <5a724202-3f12-e4ad-430a-d64112b15f3f@oracle.com> On 27/05/2020 19:53, Andrew Hughes wrote: > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Committer. > > Simon has done a decent amount of work in the main JDK project [1] and > making him a committer would aid further work by avoiding the need for > someone else to push his fixes. It might be a bit premature to nominate Simon as Committer to the "JDK" project as there isn't a history of significant contributions just yet. Sponsoring changes is a pain but if Simon can build up contributions in the few next few weeks/months then it would make it much easier to re-run this vote. -Alan. From mark.reinhold at oracle.com Thu May 28 17:41:45 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 28 May 2020 10:41:45 -0700 (PDT) Subject: JEP proposed to target JDK 15: 385: Deprecate RMI Activation for Removal Message-ID: <20200528174145.2FD4D357FB3@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 385: Deprecate RMI Activation for Removal https://openjdk.java.net/jeps/385 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 June, 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 15. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html