From prappo at openjdk.java.net Tue Mar 1 13:17:21 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 1 Mar 2022 13:17:21 GMT Subject: RFR: 8282311: Fix a typo in javax.lang.model.type.NullType Message-ID: Please review this trivial fix. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/7646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7646&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282311 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7646/head:pull/7646 PR: https://git.openjdk.java.net/jdk/pull/7646 From jpai at openjdk.java.net Tue Mar 1 13:46:07 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 1 Mar 2022 13:46:07 GMT Subject: RFR: 8281705: SourceLauncherTest.testSystemProperty isn't being run [v2] In-Reply-To: References:

Message-ID: On Wed, 23 Feb 2022 01:42:26 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281705? >> >> The change in this commit adds the `@Test` annotation on the test method to make sure it gets run. Before this change, the test run logs showed that `28 tests` were being run and now after this change, the logs report `29 tests` and I can see `testSystemProperty` in the test run logs. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge latest from master branch > - 8281705: SourceLauncherTest.testSystemProperty isn't being run Any reviews on this one please? ------------- PR: https://git.openjdk.java.net/jdk/pull/7456 From jjg at openjdk.java.net Tue Mar 1 14:54:07 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 1 Mar 2022 14:54:07 GMT Subject: RFR: 8282311: Fix a typo in javax.lang.model.type.NullType In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 13:10:14 GMT, Pavel Rappo wrote: > Please review this trivial fix. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7646 From prappo at openjdk.java.net Tue Mar 1 15:25:07 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 1 Mar 2022 15:25:07 GMT Subject: Integrated: 8282311: Fix a typo in javax.lang.model.type.NullType In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 13:10:14 GMT, Pavel Rappo wrote: > Please review this trivial fix. This pull request has now been integrated. Changeset: 31b61f98 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/31b61f982c41b52ae99bd8ecf1977a6c0de515e2 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8282311: Fix a typo in javax.lang.model.type.NullType Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/7646 From prappo at openjdk.java.net Tue Mar 1 18:23:03 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 1 Mar 2022 18:23:03 GMT Subject: RFR: JDK-8282411: Add useful predicates to ElementKind In-Reply-To: References: Message-ID: <2Abpa_o-LgZzltH-6yM3aS3f83CqWxa401w_EIb6mdE=.2e495236-f26a-44d5-9a5d-31d5d21aba9e@github.com> On Mon, 28 Feb 2022 21:33:22 GMT, Joe Darcy wrote: > Discussion from a recent review in javadoc, adding some more functionality to ElementKind predicates. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282461 Other than unusual indentation in isExecutable and isInitializer, looks good. Thanks! ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7637 From cushon at google.com Tue Mar 1 18:36:06 2022 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 1 Mar 2022 10:36:06 -0800 Subject: Approach for JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries Message-ID: Hello, I'm interested in trying to help with https://bugs.openjdk.java.net/browse/JDK-8225377 (type annotations are not visible to javac plugins across compilation boundaries). The issue described in the bug is that type annotations are not currently associated with some TypeMirrors loaded from the classpath. For example, TypeMirror#getAnnotationMirrors for the return type of a method does not report type annotations if the method was loaded from the classpath, but it does work for elements compiled from source in the current compilation. What I understand so far is: * the ClassReader reads in the full *TypeAnnotations attributes, including type paths * it creates a TypeAnnotationCompleter that saves the type annotations to the associated Symbol using Symbol#setTypeAttributes * the Symbol never associates the type annotations with their corresponding types, e.g. a MethodSymbol does not attach annotations to its return type It seems like there's logic missing to interpret the type paths read from class files and attach them to the appropriate type model element. This would be somewhat similar to the logic in core reflection that handles type paths and deals with reporting type annotations on the correct type [1]. I'm wondering if I'm missing something, is there any prior work in javac to interpret type paths read from class files? If not, would there be interest in accepting that as a contribution? It would add some complexity and potential overhead, but I'm not seeing a good alternative to fix TypeMirror#getAnnotationMirrors for types read from class files. [1] https://github.com/openjdk/jdk/blob/d983d108c565654e717e2811d88aa94d982da2f5/src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java#L194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.java.net Tue Mar 1 18:53:08 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Mar 2022 18:53:08 GMT Subject: RFR: JDK-8282411: Add useful predicates to ElementKind [v2] In-Reply-To: References: Message-ID: <_Gxn9VjggIZz901e9qbBOo4-DmbXaO7kHEXW2UhPDIM=.b6ad3b39-d5c6-4723-b70e-ef7be395acc9@github.com> > Discussion from a recent review in javadoc, adding some more functionality to ElementKind predicates. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282461 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Improve whitespace. - Merge branch 'master' into JDK-8282411 - Add tests. - JDK-8282411: Add useful predicates to ElementKind ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7637/files - new: https://git.openjdk.java.net/jdk/pull/7637/files/7d423d65..c72518b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7637&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7637&range=00-01 Stats: 7179 lines in 217 files changed: 4818 ins; 1227 del; 1134 mod Patch: https://git.openjdk.java.net/jdk/pull/7637.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7637/head:pull/7637 PR: https://git.openjdk.java.net/jdk/pull/7637 From darcy at openjdk.java.net Tue Mar 1 18:53:09 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Mar 2022 18:53:09 GMT Subject: Integrated: JDK-8282411: Add useful predicates to ElementKind In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 21:33:22 GMT, Joe Darcy wrote: > Discussion from a recent review in javadoc, adding some more functionality to ElementKind predicates. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282461 This pull request has now been integrated. Changeset: 732d891f Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/732d891f9f8987edfc188c049eb19de6ba790c42 Stats: 102 lines in 2 files changed: 97 ins; 0 del; 5 mod 8282411: Add useful predicates to ElementKind Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/7637 From valeriep at openjdk.java.net Wed Mar 2 00:21:47 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Mar 2022 00:21:47 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA Message-ID: It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: - SHA-384 for secure hashing - AES-256 for symmetric encryption - RSA with 3072 bit keys for digital signatures and for key exchange - Diffie Hellman (DH) with 3072 bit keys for key exchange - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? Thanks! ------------- Commit messages: - 8267319: Use larger default key sizes and algorithms based on CNSA Changes: https://git.openjdk.java.net/jdk/pull/7652/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267319 Stats: 479 lines in 29 files changed: 321 ins; 6 del; 152 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From ascarpino at openjdk.java.net Wed Mar 2 04:06:00 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Mar 2022 04:06:00 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! I have some compatibility concerns about the AES change breaking code that expects a SecretKeySpec of 16 bytes. I can see situations where '.getEncoded()' returns a byte[32] when user code expects a byte[16]. Also, I'm pretty sure passing a 32 byte SecretKeySpec into an AES_128_GCM op will throw an exception. I haven't looked at other modes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From aturbanov at openjdk.java.net Wed Mar 2 18:50:46 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 2 Mar 2022 18:50:46 GMT Subject: RFR: 8282574: Cleanup unnecessary calls to Throwable.initCause() in jdk.compiler Message-ID: <73RfdVOUXAjoAPOIraO_U6SJfShzociY9O3oV0-AR3g=.8f0c0bb0-ccac-4eac-a9d3-496ddc88339d@github.com> Pass cause exception as constructor parameter is shorter and easier to read. ------------- Commit messages: - [PATCH] Cleanup unnecessary calls to Throwable.initCause() in jdk.compiler module Changes: https://git.openjdk.java.net/jdk/pull/7662/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7662&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282574 Stats: 9 lines in 2 files changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7662.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7662/head:pull/7662 PR: https://git.openjdk.java.net/jdk/pull/7662 From valeriep at openjdk.java.net Wed Mar 2 22:30:07 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Mar 2022 22:30:07 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA In-Reply-To: References:

Message-ID: On Wed, 2 Mar 2022 04:02:45 GMT, Anthony Scarpino wrote: > I have some compatibility concerns about the AES change breaking code that expects a SecretKeySpec of 16 bytes. I can see situations where '.getEncoded()' returns a byte[32] when user code expects a byte[16]. Also, I'm pretty sure passing a 32 byte SecretKeySpec into an AES_128_GCM op will throw an exception. I haven't looked at other modes. Well, I am not sure how specifying a 32-byte SecretKeySpec (instance of a SecretKey) with AES Cipher would trigger AES_128_GCM op? Shouldn't the keysize be detected when Cipher.init() is called and then invoking the right op? True that this default key size change would impact callers who do not specify key size but then made the assumption of key being 16-byte. Well, the key generator javadoc did warn about not setting a default, i.e. different providers may have different default key size and that the default key size may change later for the same provider. So, it's not like we have not warned about it... ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From ascarpino at openjdk.java.net Thu Mar 3 20:14:02 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 3 Mar 2022 20:14:02 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Fair point that the keysize would determine the algorithm used and the default key sizes for keygen. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From darcy at openjdk.java.net Fri Mar 4 06:51:03 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Mar 2022 06:51:03 GMT Subject: RFR: 8282574: Cleanup unnecessary calls to Throwable.initCause() in jdk.compiler In-Reply-To: <73RfdVOUXAjoAPOIraO_U6SJfShzociY9O3oV0-AR3g=.8f0c0bb0-ccac-4eac-a9d3-496ddc88339d@github.com> References: <73RfdVOUXAjoAPOIraO_U6SJfShzociY9O3oV0-AR3g=.8f0c0bb0-ccac-4eac-a9d3-496ddc88339d@github.com> Message-ID: <-tp4rbzz1CwGkbYrLYhrgG4SYmE_5dzwIxf5xpbVpIc=.37a8f780-eb83-4c63-bcdf-3af74880e5c3@github.com> On Wed, 2 Mar 2022 18:43:35 GMT, Andrey Turbanov wrote: > Pass cause exception as constructor parameter is shorter and easier to read. Marked as reviewed by darcy (Reviewer). src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java line 303: > 301: processorIterator = List.of(new PrintingProcessor()).iterator(); > 302: } catch (Throwable t) { > 303: throw new AssertionError("Problem instantiating PrintingProcessor.", t); When this annotation processing code was written in JDK 6, I wondered why we didn't use the other constructor at the time. Turns out, that constructor of AssertionError was only added in JDK 7 under [JDK-6935997](https://bugs.openjdk.java.net/browse/JDK-6935997) :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7662 From duke at openjdk.java.net Fri Mar 4 16:56:25 2022 From: duke at openjdk.java.net (Matteo Baccan) Date: Fri, 4 Mar 2022 16:56:25 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Hi I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted. Now: what is the next step? This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code. ciao matteo ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Fri Mar 4 16:56:25 2022 From: duke at openjdk.java.net (Matteo Baccan) Date: Fri, 4 Mar 2022 16:56:25 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines Message-ID: Hi I have reviewed the code for removing double semicolons at the end of lines all the best matteo ------------- Commit messages: - Removed double semicolon at the end of lines Changes: https://git.openjdk.java.net/jdk/pull/7268/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7268&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282657 Stats: 93 lines in 82 files changed: 0 ins; 0 del; 93 mod Patch: https://git.openjdk.java.net/jdk/pull/7268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7268/head:pull/7268 PR: https://git.openjdk.java.net/jdk/pull/7268 From jwaters at openjdk.java.net Fri Mar 4 16:56:26 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Fri, 4 Mar 2022 16:56:26 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References:

Message-ID: On Fri, 25 Feb 2022 15:40:09 GMT, Matteo Baccan wrote: >> Hi >> >> I have reviewed the code for removing double semicolons at the end of lines >> >> all the best >> matteo > > Hi > > I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted. > Now: what is the next step? > > This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code. > > ciao > matteo Hi @matteobaccan The next step would be to create a relevant issue on the tracker and set it to track this PR. Since you don't have the ability to create new issues on the JBS yet I'll help you create one, please rename your PR title to 8282657 and the system should take care of the rest and automatically mark your PR as ready for review after setting it to track the corresponding JBS entry. Cheers, Julian ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From lancea at openjdk.java.net Fri Mar 4 17:07:59 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 4 Mar 2022 17:07:59 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo The changes look OK. The copyright year probably should be updated as part of this PR ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Fri Mar 4 17:14:05 2022 From: duke at openjdk.java.net (Matteo Baccan) Date: Fri, 4 Mar 2022 17:14:05 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Hi Lance I can make a second commit updating the copyright year Tell me if this is necessary ciao matteo ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From rriggs at openjdk.java.net Fri Mar 4 17:20:05 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Mar 2022 17:20:05 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain. The client modules are usually separated out, as are hotspot. And corresponding tests. This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers. If you had ask ahead of time, I would have suggested finding something with more value. ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From ihse at openjdk.java.net Fri Mar 4 17:50:03 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Mar 2022 17:50:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References:

Message-ID: On Fri, 4 Mar 2022 17:17:12 GMT, Roger Riggs wrote: >> Hi >> >> I have reviewed the code for removing double semicolons at the end of lines >> >> all the best >> matteo > > We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain. The client modules are usually separated out, as are hotspot. > And corresponding tests. > This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers. > If you had ask ahead of time, I would have suggested finding something with more value. @RogerRiggs Otoh, this change is really trivial. I have verified that all changes are replacing trailing ";;" in Java code. These are all clearly typos. I think it's nice that we try to strive for a high quality, and while you are correct this is maybe not the most pressing issue, I think it's nice to get a cleanup like this done. I'd argue that this is a trivial change. If you are worried, let's get a couple of more reviewers. I can't see the need to split this up per area. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From prr at openjdk.java.net Fri Mar 4 19:10:06 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 4 Mar 2022 19:10:06 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Marked as reviewed by prr (Reviewer). Looks like there's only one client source code file touched Most of the client changes are only in jtreg tests - and this is very trivial, so I'm OK with them being included here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From rriggs at openjdk.java.net Fri Mar 4 19:33:06 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Mar 2022 19:33:06 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From iris at openjdk.java.net Fri Mar 4 19:43:03 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 4 Mar 2022 19:43:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Nice tidy of the code. Is there anything that can be done to prevent re-introduction of this trivial problem? Perhaps a new Skara bot jcheck option similar to what is already in place for trailing whitespace? ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From wetmore at openjdk.java.net Fri Mar 4 19:56:03 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 4 Mar 2022 19:56:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: <1X39o4ON1uvbSXAp_r66zAmSy6sWZFKaP7-M54vAqX0=.d6abe0d5-9dd2-409b-91df-255d838196cb@github.com> On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo LGTM also. Similar suggestion for updating copyrights. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From darcy at openjdk.java.net Fri Mar 4 21:33:07 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Mar 2022 21:33:07 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From dholmes at openjdk.java.net Sat Mar 5 05:52:04 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 5 Mar 2022 05:52:04 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: <2NJw-71OOOvNs9519H__uYdXQnJm23L-Ez4jKoAuKrk=.c277d644-fd63-442e-99a1-6d3d66cb3405@github.com> On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo I eyeballed the diff file and all seems okay. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From jwaters at openjdk.java.net Sat Mar 5 06:52:13 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Sat, 5 Mar 2022 06:52:13 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Nice, good work matteo Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change? ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Sat Mar 5 07:22:03 2022 From: duke at openjdk.java.net (Jan =?UTF-8?B?U2NobMO2w59pbg==?=) Date: Sat, 5 Mar 2022 07:22:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo This PR changes a comment in javax/swing/RepaintManager.java. This commented out code should be removed altogether in another PR? Because its an System.out.println and because its commented out code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From erikj at openjdk.java.net Mon Mar 7 13:44:05 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Mar 2022 13:44:05 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References:

Message-ID: On Sat, 5 Mar 2022 06:49:16 GMT, Julian Waters wrote: > Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change? They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From jwaters at openjdk.java.net Mon Mar 7 16:24:00 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Mon, 7 Mar 2022 16:24:00 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References:

Message-ID: On Mon, 7 Mar 2022 13:40:48 GMT, Erik Joelsson wrote: > > Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change? > > They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you. Alright, I can't change the title of the PR, I guess it'll be easier for me to change the issue instead ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From lancea at openjdk.java.net Mon Mar 7 16:43:08 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Mar 2022 16:43:08 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo What problem are you having editing the PR header? You should be able to do so as the author of the PR ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From kcr at openjdk.java.net Mon Mar 7 16:52:07 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Mar 2022 16:52:07 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References:

Message-ID: On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen wrote: > What problem are you having editing the PR header? You should be able to do so as the author of the PR Exactly. You should see an "Edit" button near the right edge of the PR title. See the attached image: ![PR-title](https://user-images.githubusercontent.com/34689748/157079404-eadbe8be-ae94-41e0-b17b-0d1a8026b9da.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From kcr at openjdk.java.net Mon Mar 7 16:56:06 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Mar 2022 16:56:06 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo But as the JBS title and PR title now match, this is a moot point. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From ihse at openjdk.java.net Mon Mar 7 17:18:03 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 7 Mar 2022 17:18:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References:

Message-ID: On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen wrote: >> Hi >> >> I have reviewed the code for removing double semicolons at the end of lines >> >> all the best >> matteo > > What problem are you having editing the PR header? You should be able to do so as the author of the PR @LanceAndersen @kevinrushforth TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From kcr at openjdk.java.net Mon Mar 7 17:18:03 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Mar 2022 17:18:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References:

Message-ID: On Mon, 7 Mar 2022 17:12:25 GMT, Magnus Ihse Bursie wrote: > TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue. Ah, that explains it then. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Mon Mar 7 21:37:05 2022 From: duke at openjdk.java.net (Matteo Baccan) Date: Mon, 7 Mar 2022 21:37:05 GMT Subject: Integrated: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo This pull request has now been integrated. Changeset: ccad3923 Author: Matteo Baccan Committer: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/ccad39237ab860c5c5579537f740177e3f1adcc9 Stats: 93 lines in 82 files changed: 0 ins; 0 del; 93 mod 8282657: Code cleanup: removing double semicolons at the end of lines Reviewed-by: lancea, rriggs, ihse, prr, iris, wetmore, darcy, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From joel.costigliola at gmail.com Tue Mar 1 01:02:26 2022 From: joel.costigliola at gmail.com (Joel Costigliola) Date: Tue, 1 Mar 2022 14:02:26 +1300 Subject: Commenting and voting on JDK-8152289 Message-ID: Hi, I'm one of the core maintainer of AssertJ , the https://github.com/assertj/assertj-core/issues/2385 issue is about slow compile time and might be related to https://bugs.openjdk.java.net/browse/JDK-8152289. I wanted to vote for JDK-8152289 and add a comment to raise awareness that it possibly impacts AssertJ users, but I could not do that and it's not clear what I need to do to be able to. Could you add the comment on my behalf or tell me how to comment on issues? Kind regards, Joel Costigliola -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.bair at hedera.com Tue Mar 8 22:09:32 2022 From: richard.bair at hedera.com (Richard Bair) Date: Tue, 8 Mar 2022 14:09:32 -0800 Subject: Reproducible builds Message-ID: <35723474-993B-4A70-A2DE-2E8770BA0743@hedera.com> Hi! I am wondering whether it is a stated goal or non-legally binding guarantee that the compilation of a program from the same build of OpenJDK will always produce the same binary output? I understand that at the specification level there is no guarantee of reproducible builds, and that different JDKs from different providers may very well produce non-identical binaries. Is there any indeterminism in a run from javac that would produce different binary artifacts? Thanks Richard From jonathan.gibbons at oracle.com Wed Mar 9 01:16:57 2022 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 8 Mar 2022 17:16:57 -0800 Subject: Reproducible builds In-Reply-To: <35723474-993B-4A70-A2DE-2E8770BA0743@hedera.com> References: <35723474-993B-4A70-A2DE-2E8770BA0743@hedera.com> Message-ID: Yes, not only it is true for javac, but it is an aspiration for builds of OpenJDK as a whole. In general, the common problem is timestamps, and for those tools that use timestamps, there is a precedent to support a `--date` option.? This includes jar, javadoc, jlink etc, but not javac, because javac does not put timestamps in generated files. -- Jon On 3/8/22 2:09 PM, Richard Bair wrote: > Hi! > > I am wondering whether it is a stated goal or non-legally binding guarantee that the compilation of a program from the same build of OpenJDK will always produce the same binary output? I understand that at the specification level there is no guarantee of reproducible builds, and that different JDKs from different providers may very well produce non-identical binaries. Is there any indeterminism in a run from javac that would produce different binary artifacts? > > Thanks > Richard From valeriep at openjdk.java.net Wed Mar 9 02:02:51 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 9 Mar 2022 02:02:51 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v2] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to use SHA-384 as long as the keysize permits. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/27e27836..7f6fe4b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=00-01 Stats: 27 lines in 7 files changed: 6 ins; 4 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From joe.darcy at oracle.com Wed Mar 9 13:04:27 2022 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 9 Mar 2022 05:04:27 -0800 Subject: Reproducible builds In-Reply-To: References: <35723474-993B-4A70-A2DE-2E8770BA0743@hedera.com> Message-ID: On a related note, it is allowable for the javac from JDK $N and the javac from JDK $N+$K using --release $N to produce different class files. -Joe On 3/8/2022 5:16 PM, Jonathan Gibbons wrote: > Yes, not only it is true for javac, but it is an aspiration for builds > of OpenJDK as a whole. > > In general, the common problem is timestamps, and for those tools that > use timestamps, there is a precedent to support a `--date` option.? > This includes jar, javadoc, jlink etc, but not javac, because javac > does not put timestamps in generated files. > > -- Jon > > > On 3/8/22 2:09 PM, Richard Bair wrote: >> Hi! >> >> I am wondering whether it is a stated goal or non-legally binding >> guarantee that the compilation of a program from the same build of >> OpenJDK will always produce the same binary output? I understand that >> at the specification level there is no guarantee of reproducible >> builds, and that different JDKs from different providers may very >> well produce non-identical binaries. Is there any indeterminism in a >> run from javac that would produce different binary artifacts? >> >> Thanks >> Richard From weijun at openjdk.java.net Wed Mar 9 16:44:03 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 9 Mar 2022 16:44:03 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v2] In-Reply-To: References:

Message-ID: On Wed, 9 Mar 2022 02:02:51 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Updated to use SHA-384 as long as the keysize permits. The `JarSigner` API is not updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Wed Mar 9 19:15:36 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 9 Mar 2022 19:15:36 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update JarSigner javadoc to make it consistent with previous update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/7f6fe4b5..099a6d92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=01-02 Stats: 16 lines in 2 files changed: 0 ins; 3 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From weijun at openjdk.java.net Wed Mar 9 19:49:45 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 9 Mar 2022 19:49:45 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3] In-Reply-To: References:

Message-ID: On Wed, 9 Mar 2022 19:15:36 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update JarSigner javadoc to make it consistent with previous update Sorry if my previous comment confused you, the code and javadoc are not consistent now. src/java.base/share/classes/sun/security/util/SignatureUtil.java line 561: > 559: return (isDSA || bitLength >= 624 ? "SHA384" : "SHA256"); > 560: } > 561: } In this method, "SHA-384" for 7680-bit key (7680 > 7680 is false). src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 439: > 437: * Specifically, if a DSA or RSA key with a key size no less than 7680 > 438: * bits, or an EC key with a key size no less than 512 bits, > 439: * SHA-512 will be used as the hash function for the signature. In this javadoc, SHA-512 for 7680-bit key (7680 is no less than 7680). ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From achung at openjdk.java.net Wed Mar 9 21:16:48 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Wed, 9 Mar 2022 21:16:48 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 Message-ID: msg drop for jdk19, Mar 9, 2022 ------------- Commit messages: - open jdk19 l10n msg drop Changes: https://git.openjdk.java.net/jdk/pull/7765/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280400 Stats: 13775 lines in 142 files changed: 12170 ins; 1249 del; 356 mod Patch: https://git.openjdk.java.net/jdk/pull/7765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765 PR: https://git.openjdk.java.net/jdk/pull/7765 From valeriep at openjdk.java.net Wed Mar 9 22:13:47 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 9 Mar 2022 22:13:47 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3] In-Reply-To: References:

Message-ID: <1j7YQWGZ5x2PU7aUm7m2gUBkI_BThArGU6qrn5fYPng=.49a446eb-f48f-4276-b326-f1cea296c1cb@github.com> On Wed, 9 Mar 2022 19:44:39 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update JarSigner javadoc to make it consistent with previous update > > src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 439: > >> 437: * Specifically, if a DSA or RSA key with a key size no less than 7680 >> 438: * bits, or an EC key with a key size no less than 512 bits, >> 439: * SHA-512 will be used as the hash function for the signature. > > In this javadoc, SHA-512 for 7680-bit key (7680 is no less than 7680). Right, there are a few places which this is documented. Code and doc aren't closely coupled together plus changed course a few times... I will fix this and double check other files. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From naoto at openjdk.java.net Wed Mar 9 22:29:44 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 9 Mar 2022 22:29:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 `src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties` `src/java.base/share/classes/sun/util/resources/CurrencyNames_ja.properties` `src/java.base/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties` These are part of `jdk.localedata` module. Should be excluded from `java.base` module and apply the diffs to `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_xx.properties` manually. (Note that the first half of it is not necessary when merging). ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From dalibor.topic at oracle.com Wed Mar 9 23:26:16 2022 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 10 Mar 2022 00:26:16 +0100 Subject: Reproducible builds In-Reply-To: References: <35723474-993B-4A70-A2DE-2E8770BA0743@hedera.com>

Message-ID: <19d49bf2-fa57-6674-672f-347c0932bb89@oracle.com> Annotation processors may also be written in such a way to deliberately produce different outputs on each invocation, although one really, really should not do that. cheers, dalibor topic On 09.03.2022 14:04, Joe Darcy wrote: > On a related note, it is allowable for the javac from JDK $N and the > javac from JDK $N+$K using --release $N to produce different class files. > > -Joe > > On 3/8/2022 5:16 PM, Jonathan Gibbons wrote: >> Yes, not only it is true for javac, but it is an aspiration for builds >> of OpenJDK as a whole. >> >> In general, the common problem is timestamps, and for those tools that >> use timestamps, there is a precedent to support a `--date` option. >> This includes jar, javadoc, jlink etc, but not javac, because javac >> does not put timestamps in generated files. >> >> -- Jon >> >> >> On 3/8/22 2:09 PM, Richard Bair wrote: >>> Hi! >>> >>> I am wondering whether it is a stated goal or non-legally binding >>> guarantee that the compilation of a program from the same build of >>> OpenJDK will always produce the same binary output? I understand that >>> at the specification level there is no guarantee of reproducible >>> builds, and that different JDKs from different providers may very >>> well produce non-identical binaries. Is there any indeterminism in a >>> run from javac that would produce different binary artifacts? >>> >>> Thanks >>> Richard -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From valeriep at openjdk.java.net Thu Mar 10 00:20:36 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 10 Mar 2022 00:20:36 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v4] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to match the latest SignatureUtil.ifcFfcStrength() impl ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/099a6d92..f728aa7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From joehw at openjdk.java.net Thu Mar 10 00:46:44 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 10 Mar 2022 00:46:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: <8oYKi_L4IgNDFUfJ9uXlSl47KULO4j1HudfJg3kVeCU=.90fa019e-8b6f-4a69-870b-cd53c8802490@github.com> On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 For the bundles in java.xml: For files with Oracle copyright, update the year to 2022 and @LastModified Mar 2022. Take XPATHErrorResources_ja.java as an example, the copyright year was updated to 2021 and @LastModified: Nov 2021. That's probably the date it was last modified, but as we updating them now along with a number of other files, it would be good to be consistent and change all of them to the current date. For files with the reserved comment block such as SerializerMessages_de.java, do the same as did in XPATHErrorResources_de.java, add the copyright header and LastModified tag with the current date. For files with the Oracle GPL license such as message_zh_CN.properties, do not delete the license header. Instead, update the copyright year to 2022 if there are changes. I don't see any changes were made for many of these files, for example from msg/XMLSchemaMessages_ja.properties to regex/message_zh_CN.properties, the only change was the removal of the header. In the webrev view, some files have the word "undefined" right under the license header, hopefully once the license header is fixed, that would go away as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From dfuchs at openjdk.java.net Thu Mar 10 10:34:43 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 10 Mar 2022 10:34:43 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 For simple webserver resource files - should the copyright year be 2022? ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From magnus.ihse.bursie at oracle.com Thu Mar 10 11:04:00 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 10 Mar 2022 12:04:00 +0100 Subject: Reproducible builds In-Reply-To: <35723474-993B-4A70-A2DE-2E8770BA0743@hedera.com> References: <35723474-993B-4A70-A2DE-2E8770BA0743@hedera.com> Message-ID: On 2022-03-08 23:09, Richard Bair wrote: > Hi! > > I am wondering whether it is a stated goal or non-legally binding guarantee that the compilation of a program from the same build of OpenJDK will always produce the same binary output? I understand that at the specification level there is no guarantee of reproducible builds, and that different JDKs from different providers may very well produce non-identical binaries. Is there any indeterminism in a run from javac that would produce different binary artifacts? > I think the best way to answer this question is that historically, any discovered non-deterministic output from javac has been considered a bug, and fixed. /Magnus From jlahoda at openjdk.java.net Thu Mar 10 12:36:09 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 10 Mar 2022 12:36:09 GMT Subject: RFR: 8282823: javac should constrain more uses of preview APIs Message-ID: Consider a class or interface with a method marked as preview. Subclassing the class or implementing the interface by itself should not cause a preview error/warning (as that would be problematic for Loom), but overriding the method should produce a preview error/warning. This patch adds the error/warning in case a preview method is overridden. ------------- Commit messages: - Improving test. - 8282823: javac should constrain more uses of preview APIs Changes: https://git.openjdk.java.net/jdk/pull/7774/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7774&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282823 Stats: 203 lines in 2 files changed: 203 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7774.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7774/head:pull/7774 PR: https://git.openjdk.java.net/jdk/pull/7774 From jlaskey at openjdk.java.net Thu Mar 10 12:55:42 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 10 Mar 2022 12:55:42 GMT Subject: RFR: 8282823: javac should constrain more uses of preview APIs In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 12:28:27 GMT, Jan Lahoda wrote: > Consider a class or interface with a method marked as preview. Subclassing the class or implementing the interface by itself should not cause a preview error/warning (as that would be problematic for Loom), but overriding the method should produce a preview error/warning. > > This patch adds the error/warning in case a preview method is overridden. LGTM ------------- Marked as reviewed by jlaskey (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7774 From naoto at openjdk.java.net Thu Mar 10 17:03:45 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Mar 2022 17:03:45 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From dfuchs at openjdk.java.net Thu Mar 10 17:09:44 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 10 Mar 2022 17:09:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References:

Message-ID: On Thu, 10 Mar 2022 17:00:09 GMT, Naoto Sato wrote: > IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment. Thanks Naoto! I have no objection then. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From achung at openjdk.java.net Thu Mar 10 17:55:44 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Thu, 10 Mar 2022 17:55:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: > msg drop for jdk19, Mar 9, 2022 Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: moved CurrencyNames changes to jdk.localedata ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7765/files - new: https://git.openjdk.java.net/jdk/pull/7765/files/fb51cf60..4735722d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00-01 Stats: 2807 lines in 6 files changed: 693 ins; 1527 del; 587 mod Patch: https://git.openjdk.java.net/jdk/pull/7765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765 PR: https://git.openjdk.java.net/jdk/pull/7765 From cjplummer at openjdk.java.net Thu Mar 10 19:06:43 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 10 Mar 2022 19:06:43 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References:

Message-ID: On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > moved CurrencyNames changes to jdk.localedata src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP No need for these lines in each localized files, as English bundle contains them. src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP Same here with `de` bundle. src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP and here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From mcimadamore at openjdk.java.net Thu Mar 10 22:05:47 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 10 Mar 2022 22:05:47 GMT Subject: RFR: 8282823: javac should constrain more uses of preview APIs In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 12:28:27 GMT, Jan Lahoda wrote: > Consider a class or interface with a method marked as preview. Subclassing the class or implementing the interface by itself should not cause a preview error/warning (as that would be problematic for Loom), but overriding the method should produce a preview error/warning. > > This patch adds the error/warning in case a preview method is overridden. Question - what happens if you have: class A { void m() { ... } // THIS IS PREVIEW } class B extends A { void m() { ... } // override, ok, classfile polluted } class C extends B { void m() { ... } // ? } My understanding is that C will also get a pollute classfile version - but not because of the override (because javac cannot see that the method being overriden is, in turn, the override of another preview method deep down); instead, I believe C get warning/polluted classfile because it's using B, which has a polluted classfile. But what if both B and C are compiled together? ------------- PR: https://git.openjdk.java.net/jdk/pull/7774 From forax at univ-mlv.fr Thu Mar 10 22:20:45 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 10 Mar 2022 23:20:45 +0100 (CET) Subject: RFR: 8282823: javac should constrain more uses of preview APIs In-Reply-To: References: Message-ID: <935643164.14622512.1646950845646.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Jan Lahoda" > To: "compiler-dev" > Sent: Thursday, March 10, 2022 1:36:09 PM > Subject: RFR: 8282823: javac should constrain more uses of preview APIs Hi Jan, > Consider a class or interface with a method marked as preview. Subclassing the > class or implementing the interface by itself should not cause a preview > error/warning (as that would be problematic for Loom), but overriding the > method should produce a preview error/warning. > > This patch adds the error/warning in case a preview method is overridden. I don't think you can do that because it means that the view at compile time and the view at runtime now disagree. >From the VM POW, a class is in preview mode or not, if a class contains a preview method, this class is marked as in preview mode, so even if javac allows the compilation, it will not work at runtime. R?mi From alex.buckley at oracle.com Thu Mar 10 23:04:16 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 10 Mar 2022 15:04:16 -0800 Subject: RFR: 8282823: javac should constrain more uses of preview APIs In-Reply-To: References:

Message-ID: <96fab0a0-279b-3360-a10a-fe3ad4ef8167@oracle.com> On 3/10/2022 2:05 PM, Maurizio Cimadamore wrote: > On Thu, 10 Mar 2022 12:28:27 GMT, Jan Lahoda wrote: > >> Consider a class or interface with a method marked as preview. Subclassing the class or implementing the interface by itself should not cause a preview error/warning (as that would be problematic for Loom), but overriding the method should produce a preview error/warning. >> >> This patch adds the error/warning in case a preview method is overridden. > > Question - what happens if you have: > > class A { > void m() { ... } // THIS IS PREVIEW > } > > class B extends A { > void m() { ... } // override, ok, classfile polluted > } > > class C extends B { > void m() { ... } // ? > } > > > My understanding is that C will also get a pollute classfile version - but not because of the override (because javac cannot see that the method being overriden is, in turn, the override of another preview method deep down); instead, I believe C get warning/polluted classfile because it's using B, which has a polluted classfile. But what if both B and C are compiled together? B is like a class X that uses a preview language feature somewhere in its declaration. The use of a preview language feature poisons X.class, but other classes can refer to X (and yet more classes can refer to them...) without being poisoned themselves. A large program that uses X deep down might be able to run for a long time even with preview features disabled; only when the program triggers loading of X will the VM complain. B uses a preview API (overrides a preview method) but is not a preview API itself, so C can refer to B without getting poisoned. Of course, C's particular use of B (`extends`) means that loading C causes loading of B and then you'd better have --enable-preview -- but other uses of B are possible that would let C load and run without --enable-preview. Alex From alex.buckley at oracle.com Thu Mar 10 23:19:50 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 10 Mar 2022 15:19:50 -0800 Subject: RFR: 8282823: javac should constrain more uses of preview APIs In-Reply-To: <935643164.14622512.1646950845646.JavaMail.zimbra@u-pem.fr> References: <935643164.14622512.1646950845646.JavaMail.zimbra@u-pem.fr> Message-ID: <4ae13a54-5fe8-0561-ff2c-6abd6c3f2a31@oracle.com> On 3/10/2022 2:20 PM, Remi Forax wrote: >> Consider a class or interface with a method marked as preview. Subclassing the >> class or implementing the interface by itself should not cause a preview >> error/warning (as that would be problematic for Loom), but overriding the >> method should produce a preview error/warning. >> >> This patch adds the error/warning in case a preview method is overridden. > > I don't think you can do that because it means that the view at compile time and the view at runtime now disagree. > > From the VM POW, a class is in preview mode or not, if a class contains a preview method, this class is marked as in preview mode, > so even if javac allows the compilation, it will not work at runtime. I know what you mean, but the Thread class itself is not a preview API and Thread.class is not poisoned. Ordinary code that refers to Thread (e.g., to extend it, or to call its traditional methods) will compile and run without preview warnings/errors. Code that tries out Loom by referring to preview methods in Thread (e.g., Thread::ofVirtual) will require --enable-preview at compile time. The class files generated for such code will get poisoned, and require --enable-preview at run time. Alex From mcimadamore at openjdk.java.net Fri Mar 11 11:30:42 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 11 Mar 2022 11:30:42 GMT Subject: RFR: 8282823: javac should constrain more uses of preview APIs In-Reply-To: References: Message-ID: <37O62uSbvIb7ArJuYiet6CBn1J4yDqMwGHL6-pHmND4=.ebf5ccc2-1518-41c6-85be-39d423dd0b4c@github.com> On Thu, 10 Mar 2022 12:28:27 GMT, Jan Lahoda wrote: > Consider a class or interface with a method marked as preview. Subclassing the class or implementing the interface by itself should not cause a preview error/warning (as that would be problematic for Loom), but overriding the method should produce a preview error/warning. > > This patch adds the error/warning in case a preview method is overridden. If the goal is (as it seems) to detect first override of a preview method, then these changes look good. Thanks Alex for the clarification. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7774 From forax at univ-mlv.fr Fri Mar 11 13:03:34 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 11 Mar 2022 14:03:34 +0100 (CET) Subject: RFR: 8282823: javac should constrain more uses of preview APIs In-Reply-To: <4ae13a54-5fe8-0561-ff2c-6abd6c3f2a31@oracle.com> References: <935643164.14622512.1646950845646.JavaMail.zimbra@u-pem.fr> <4ae13a54-5fe8-0561-ff2c-6abd6c3f2a31@oracle.com> Message-ID: <706505078.15061023.1647003814365.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Alex Buckley" > To: "Remi Forax" , "Jan Lahoda" > Cc: "compiler-dev" > Sent: Friday, March 11, 2022 12:19:50 AM > Subject: Re: RFR: 8282823: javac should constrain more uses of preview APIs > On 3/10/2022 2:20 PM, Remi Forax wrote: >>> Consider a class or interface with a method marked as preview. Subclassing the >>> class or implementing the interface by itself should not cause a preview >>> error/warning (as that would be problematic for Loom), but overriding the >>> method should produce a preview error/warning. >>> >>> This patch adds the error/warning in case a preview method is overridden. >> >> I don't think you can do that because it means that the view at compile time and >> the view at runtime now disagree. >> >> From the VM POW, a class is in preview mode or not, if a class contains a >> preview method, this class is marked as in preview mode, >> so even if javac allows the compilation, it will not work at runtime. > > I know what you mean, but the Thread class itself is not a preview API > and Thread.class is not poisoned. Ordinary code that refers to Thread > (e.g., to extend it, or to call its traditional methods) will compile > and run without preview warnings/errors. > > Code that tries out Loom by referring to preview methods in Thread > (e.g., Thread::ofVirtual) will require --enable-preview at compile time. > The class files generated for such code will get poisoned, and require > --enable-preview at run time. Thanx, i've taken a look to the generated bytecode, the new methods are tagged with ?Feature.VIRTUAL_THREADS but java.lang.Thread is not itself compiled with --enable-preview. > > Alex R?mi From weijun at openjdk.java.net Fri Mar 11 15:32:52 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 11 Mar 2022 15:32:52 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References:

Factory Method

Factory Method