From jlahoda at openjdk.java.net Tue Jun 1 07:50:49 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 1 Jun 2021 07:50:49 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v8] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing enum switch with patterns with guards. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/a49b6109..80b1392b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=06-07 Stats: 82 lines in 3 files changed: 80 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From alanb at openjdk.java.net Tue Jun 1 12:50:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Jun 2021 12:50:29 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6] In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> Message-ID: On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > default behavior reverted to allow System.setSecurityManagerDirect looks a bit ugly now. Can this be renamed to implSetSecurityManager and avoid the line break in the middle of the declaration? The usage of System.err usage in setSecurityManager also needs to be re-examined as this will run arbitrary code when System.err can be changed. To fix this will require capturing the stream at startup (as was done with the illegal access logger). It's okay to integrate with what you have for the first push and we can fix this issue with System.err when the warning message is changed to the intended message. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Tue Jun 1 15:06:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 1 Jun 2021 15:06:41 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v7] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: rename setSecurityManagerDirect to implSetSecurityManager ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/8fd09c39..926e4b9a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05-06 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Tue Jun 1 15:21:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 1 Jun 2021 15:21:33 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - merge from master - rename setSecurityManagerDirect to implSetSecurityManager - default behavior reverted to allow - move one annotation to new method - merge from master, two files removed, one needs merge - keep only one systemProperty tag - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java - feedback from Sean, Phil and Alan - add supresswarnings annotations automatically - manual change before automatic annotating - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=07 Stats: 2132 lines in 826 files changed: 1997 ins; 20 del; 115 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From alanb at openjdk.java.net Tue Jun 1 16:05:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Jun 2021 16:05:29 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - merge from master > - rename setSecurityManagerDirect to implSetSecurityManager > - default behavior reverted to allow > - move one annotation to new method > - merge from master, two files removed, one needs merge > - keep only one systemProperty tag > - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > - feedback from Sean, Phil and Alan > - add supresswarnings annotations automatically > - manual change before automatic annotating > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48 Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From joehw at openjdk.java.net Tue Jun 1 16:28:27 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 1 Jun 2021 16:28:27 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - merge from master > - rename setSecurityManagerDirect to implSetSecurityManager > - default behavior reverted to allow > - move one annotation to new method > - merge from master, two files removed, one needs merge > - keep only one systemProperty tag > - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > - feedback from Sean, Phil and Alan > - add supresswarnings annotations automatically > - manual change before automatic annotating > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48 Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From vromero at openjdk.java.net Tue Jun 1 17:04:19 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 1 Jun 2021 17:04:19 GMT Subject: RFR: JDK-8265270: Type.getEnclosingType() may fail with CompletionFailure In-Reply-To: <-ah4gNm7azRuo-7-WA6UFBPTg6lR9x_9V51acObmE_M=.760642c2-02da-47d4-9a66-e008af841573@github.com> References: <-ah4gNm7azRuo-7-WA6UFBPTg6lR9x_9V51acObmE_M=.760642c2-02da-47d4-9a66-e008af841573@github.com> Message-ID: On Thu, 15 Apr 2021 11:29:44 GMT, Jan Lahoda wrote: > The setup is a little bit tricky, but it may happen that user code calls `Type{Mirror}.getEnclosingType()` (or e.g. `Type{Mirror}.toString()` which will in turn invoke `getEnclosingType()`), and the method may throw the `CompletionFailure` (internal) exception. The reason is that the corresponding Symbol is completed using a `complete` method, instead of `apiComplete` method, which is intended to be used in API methods. `apiComplete` does the same as `complete` when running in a javac context, but will suppress the exception when the API method was invoked from a user code, avoiding the exception. > > The proposed change is to use `apiComplete`, as it should be done in implementations of API methods. looks good to me! ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3512 From vromero at openjdk.java.net Tue Jun 1 19:06:17 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 1 Jun 2021 19:06:17 GMT Subject: RFR: JDK-8266281: Assign Symbols to the package selector expression In-Reply-To: References: Message-ID: On Tue, 11 May 2021 14:13:11 GMT, Jan Lahoda wrote: > The proposal in this patch is that package names in the package clause would be attributed with the appropriate PackageSymbols. So when using Trees.getElement on an AST node of some part of the package name, a sensible PackageSymbol would be returned. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3977 From darcy at openjdk.java.net Tue Jun 1 20:11:36 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Jun 2021 20:11:36 GMT Subject: RFR: 8244146: javac changes for JEP 306 [v8] In-Reply-To: References: Message-ID: > 8244146: javac changes for JEP 306 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'master' into 8244146 - Merge branch 'master' into 8244146 - Update GenericStringTest - Merge branch 'master' into 8244146 - Merge branch 'master' into 8244146 - Merge branch 'master' into 8244146 - Respond to review feedback. - Respond to review feedback. - Respond to review feedback. - Add explicit test for warning strictfp suppression. - ... and 10 more: https://git.openjdk.java.net/jdk/compare/c2c0208d...3f1aeecc ------------- Changes: https://git.openjdk.java.net/jdk/pull/3831/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3831&range=07 Stats: 571 lines in 28 files changed: 529 ins; 7 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/3831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3831/head:pull/3831 PR: https://git.openjdk.java.net/jdk/pull/3831 From mcimadamore at openjdk.java.net Tue Jun 1 20:19:19 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 1 Jun 2021 20:19:19 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v8] In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 07:50:49 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing enum switch with patterns with guards. New changes looks good. I suggest to also add tests for strings in switch with guards and numeric with guards, to make sure every kind of switch works well. As discussed offline, we can probably simplify code generation logic for enum switches by leaning on the ConstantBootstraps BSM which allows to create enum constants given a class name and a constant name. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From darcy at openjdk.java.net Tue Jun 1 20:24:34 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Jun 2021 20:24:34 GMT Subject: RFR: 8244146: javac changes for JEP 306 [v9] In-Reply-To: References: Message-ID: > 8244146: javac changes for JEP 306 Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Fix copyright typo. - Update copyrights. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3831/files - new: https://git.openjdk.java.net/jdk/pull/3831/files/3f1aeecc..1d68a284 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3831&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3831&range=07-08 Stats: 14 lines in 14 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3831/head:pull/3831 PR: https://git.openjdk.java.net/jdk/pull/3831 From darcy at openjdk.java.net Tue Jun 1 22:02:44 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Jun 2021 22:02:44 GMT Subject: Integrated: 8244146: javac changes for JEP 306 In-Reply-To: References: Message-ID: On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy wrote: > 8244146: javac changes for JEP 306 This pull request has now been integrated. Changeset: 0ae4ceb4 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/0ae4ceb413a7ea92a41cd55cd338f866098eb9b4 Stats: 585 lines in 28 files changed: 529 ins; 7 del; 49 mod 8244146: javac changes for JEP 306 8266399: Core libs update for JEP 306 Reviewed-by: sadayapalam, bpb, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/3831 From darcy at openjdk.java.net Tue Jun 1 23:41:46 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Jun 2021 23:41:46 GMT Subject: RFR: 8267861: Update SourceVersion with new language features in 16 and 17 Message-ID: Update SourceVersion constants for 16 and 17 with language features for those releases. ------------- Commit messages: - 8267861: Update SourceVersion with new language features in 16 and 17 Changes: https://git.openjdk.java.net/jdk/pull/4294/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4294&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267861 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4294/head:pull/4294 PR: https://git.openjdk.java.net/jdk/pull/4294 From jjg at openjdk.java.net Wed Jun 2 00:25:29 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 00:25:29 GMT Subject: RFR: 8267861: Update SourceVersion with new language features in 16 and 17 In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 23:33:31 GMT, Joe Darcy wrote: > Update SourceVersion constants for 16 and 17 with language features for those releases. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4294 From darcy at openjdk.java.net Wed Jun 2 00:36:34 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 2 Jun 2021 00:36:34 GMT Subject: Integrated: 8267861: Update SourceVersion with new language features in 16 and 17 In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 23:33:31 GMT, Joe Darcy wrote: > Update SourceVersion constants for 16 and 17 with language features for those releases. This pull request has now been integrated. Changeset: 00c7aeee Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/00c7aeee005f08689d0647b460eb55b6a5385f72 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8267861: Update SourceVersion with new language features in 16 and 17 Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4294 From gli at openjdk.java.net Wed Jun 2 04:28:39 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 2 Jun 2021 04:28:39 GMT Subject: Integrated: 8267570: The comment of the class JavacParser is not appropriate In-Reply-To: References: Message-ID: On Sat, 22 May 2021 13:51:10 GMT, Guoxiong Li wrote: > Hi all, > > The following comment of the class JavacParser is not appropriate. > > > It operates by recursive descent, with code derived > systematically from an LL(1) grammar. > > > From the source code, the current javac parser looks like a LL(K) parser instead of LL(1). > This patch revises the comment so that developers won't be confused by it. > > Thank you for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: b98e52a4 Author: Guoxiong Li Committer: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/b98e52a49191cfbb7d954646cd80a6711daeaca6 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8267570: The comment of the class JavacParser is not appropriate Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4153 From vromero at openjdk.java.net Wed Jun 2 04:33:33 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 2 Jun 2021 04:33:33 GMT Subject: RFR: JDK-8267187: Remove deprecated constructor for Log In-Reply-To: References: Message-ID: On Fri, 14 May 2021 20:49:35 GMT, Jonathan Gibbons wrote: > In the course of other work, I came across this deprecated constructor in Log which just existed for a public entry point in javadoc which has already been removed. > > There is one remaining use in javadoc, which can be changed to use an alternate non-deprecated constructor. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4037 From vromero at openjdk.java.net Wed Jun 2 04:43:30 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 2 Jun 2021 04:43:30 GMT Subject: RFR: 8263642: javac emits duplicate checkcast for first bound of intersection type in cast In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 16:29:04 GMT, Guoxiong Li wrote: > Hi all, > > Before the phase `desugar`, the demo `(C1 & I1) o` has **one** type-cast sub-tree, `JCTypeIntersection C1&I1`, at the syntax tree. After the phase `desugar`, the `(C1 & I1) o` becomes **three** type-cast sub-trees: `JCTypeIntersection C1&I1`, `I1`, `C1`. So at phase `Gen`, `javac` generates **three** `checkcast` according to the **three** type-cast sub-trees which causes this bug. > > This patch doesn't generate `checkcast` when the type is `JCTypeIntersection` so that the problem can be solved. And a corresponding test case is added. > > Another way to solve this issue is that the `TransTypes` of the `desugar` should be modified and **two** type-cast sub-trees should be generated instead of **three**. But this way may change more code than my original patch and may cause other regression. > > Thank you for taking the time to review. > > Best Regards. > --Guoxiong Changes requested by vromero (Reviewer). test/langtools/tools/javac/cast/intersection/DuplicatedCheckcastTest.java line 83: > 81: for (Instruction instruction : code_attribute.getInstructions()) { > 82: if ("checkcast".equals(instruction.getMnemonic())) { > 83: checkcastNumber++; I think that the test should check not only for the number of checkcast but also for the type the checkcast is checking against. ------------- PR: https://git.openjdk.java.net/jdk/pull/3399 From vromero at openjdk.java.net Wed Jun 2 04:47:32 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 2 Jun 2021 04:47:32 GMT Subject: RFR: 8263642: javac emits duplicate checkcast for first bound of intersection type in cast In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 16:29:04 GMT, Guoxiong Li wrote: > Hi all, > > Before the phase `desugar`, the demo `(C1 & I1) o` has **one** type-cast sub-tree, `JCTypeIntersection C1&I1`, at the syntax tree. After the phase `desugar`, the `(C1 & I1) o` becomes **three** type-cast sub-trees: `JCTypeIntersection C1&I1`, `I1`, `C1`. So at phase `Gen`, `javac` generates **three** `checkcast` according to the **three** type-cast sub-trees which causes this bug. > > This patch doesn't generate `checkcast` when the type is `JCTypeIntersection` so that the problem can be solved. And a corresponding test case is added. > > Another way to solve this issue is that the `TransTypes` of the `desugar` should be modified and **two** type-cast sub-trees should be generated instead of **three**. But this way may change more code than my original patch and may cause other regression. > > Thank you for taking the time to review. > > Best Regards. > --Guoxiong Changes requested by vromero (Reviewer). src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 2225: > 2223: !types.isSameType(tree.expr.type, tree.clazz.type) && > 2224: types.asSuper(tree.expr.type, tree.clazz.type.tsym) == null && > 2225: tree.clazz.getTag() != TYPEINTERSECTION) { I think that if the right form of the AST is one that have only two type casts, then that's what the fix should be doing ------------- PR: https://git.openjdk.java.net/jdk/pull/3399 From jfranck at openjdk.java.net Wed Jun 2 09:21:40 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Wed, 2 Jun 2021 09:21:40 GMT Subject: RFR: 8226362: langtools ProblemList file contains more than 1 entry for a test Message-ID: Please review this patch that merges problematic lines in the langtools ProblemList.txt ------------- Commit messages: - 8226362: langtools ProblemList file contains more than 1 entry for a test Changes: https://git.openjdk.java.net/jdk/pull/4301/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4301&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8226362 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4301/head:pull/4301 PR: https://git.openjdk.java.net/jdk/pull/4301 From jlahoda at openjdk.java.net Wed Jun 2 09:57:47 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 2 Jun 2021 09:57:47 GMT Subject: Integrated: JDK-8265270: Type.getEnclosingType() may fail with CompletionFailure In-Reply-To: <-ah4gNm7azRuo-7-WA6UFBPTg6lR9x_9V51acObmE_M=.760642c2-02da-47d4-9a66-e008af841573@github.com> References: <-ah4gNm7azRuo-7-WA6UFBPTg6lR9x_9V51acObmE_M=.760642c2-02da-47d4-9a66-e008af841573@github.com> Message-ID: On Thu, 15 Apr 2021 11:29:44 GMT, Jan Lahoda wrote: > The setup is a little bit tricky, but it may happen that user code calls `Type{Mirror}.getEnclosingType()` (or e.g. `Type{Mirror}.toString()` which will in turn invoke `getEnclosingType()`), and the method may throw the `CompletionFailure` (internal) exception. The reason is that the corresponding Symbol is completed using a `complete` method, instead of `apiComplete` method, which is intended to be used in API methods. `apiComplete` does the same as `complete` when running in a javac context, but will suppress the exception when the API method was invoked from a user code, avoiding the exception. > > The proposed change is to use `apiComplete`, as it should be done in implementations of API methods. This pull request has now been integrated. Changeset: 9247630a Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/9247630a0d024550813f651c1ec0ce228ff27210 Stats: 61 lines in 2 files changed: 59 ins; 0 del; 2 mod 8265270: Type.getEnclosingType() may fail with CompletionFailure Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/3512 From jlahoda at openjdk.java.net Wed Jun 2 11:19:30 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 2 Jun 2021 11:19:30 GMT Subject: RFR: 8226362: langtools ProblemList file contains more than 1 entry for a test In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 09:13:27 GMT, Joel Borggr?n-Franck wrote: > Please review this patch that merges problematic lines in the langtools ProblemList.txt Looks good. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4301 From jlahoda at openjdk.java.net Wed Jun 2 11:19:34 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 2 Jun 2021 11:19:34 GMT Subject: Integrated: JDK-8266281: Assign Symbols to the package selector expression In-Reply-To: References: Message-ID: On Tue, 11 May 2021 14:13:11 GMT, Jan Lahoda wrote: > The proposal in this patch is that package names in the package clause would be attributed with the appropriate PackageSymbols. So when using Trees.getElement on an AST node of some part of the package name, a sensible PackageSymbol would be returned. This pull request has now been integrated. Changeset: 19450b99 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/19450b99512ce4ad4ab41be5034806e2c9dbcd59 Stats: 35 lines in 5 files changed: 26 ins; 0 del; 9 mod 8266281: Assign Symbols to the package selector expression Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/3977 From weijun at openjdk.java.net Wed Jun 2 12:01:30 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 12:01:30 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v9] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - copyright years - merge from master, resolve one conflict - Merge branch 'master' - merge from master - rename setSecurityManagerDirect to implSetSecurityManager - default behavior reverted to allow - move one annotation to new method - merge from master, two files removed, one needs merge - keep only one systemProperty tag - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java - ... and 4 more: https://git.openjdk.java.net/jdk/compare/19450b99...331389b5 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=08 Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed Jun 2 12:01:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 12:01:33 GMT Subject: Integrated: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. This pull request has now been integrated. Changeset: 6765f902 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/6765f902505fbdd02f25b599f942437cd805cad1 Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Co-authored-by: Sean Mullan Co-authored-by: Lance Andersen Co-authored-by: Weijun Wang Reviewed-by: erikj, darcy, chegar, naoto, joehw, alanb, mchung, kcr, prr, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From brian.goetz at oracle.com Wed Jun 2 13:04:54 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 2 Jun 2021 09:04:54 -0400 Subject: [External] : Re: Class modifiers in Java 16 In-Reply-To: References: <353152954.793844.1622122368158.JavaMail.zimbra@u-pem.fr> <47D450F0-B71C-435F-BC96-34DFFBB496AB@oracle.com> Message-ID: <8294323d-634a-3539-55b7-0bc40a038d37@oracle.com> Correct, static or access modifier is not (yet) allowed on local members. However, the concept of static is still relevant; interfaces, enums, and records are implicitly static, so local records are static even though you cannot say "static". On 5/30/2021 12:48 AM, Tagir Valeev wrote: > Thank you for the answers. Judging from the javac behavior, 'static' > modifier on local classes is still not allowed, so the sentence 8.1.1 > is wrong, as for Java 16. > > What about my second question, access modifiers? Is this intended > change to allow them inside local/anonymous classes? > > With best regards, > Tagir Valeev. > > On Thu, May 27, 2021 at 8:37 PM Brian Goetz wrote: >> I think there?s a bit of preparing for the future here. There?s the concepts (how static interacts with nesting) which is separate from which exact combinations of those concepts that the language currently supports. We?re moving towards trying to get rid of the arbitrary nest-x-in-y rules, step 1 was defining the concepts separate from the arbitrary restrictions, but we haven?t lifted the restrictions yet. >> >> On May 27, 2021, at 9:32 AM, Remi Forax wrote: >> >> ----- Mail original ----- >> >> De: "Tagir Valeev" >> ?: "compiler-dev" , "amber-dev" >> Envoy?: Jeudi 27 Mai 2021 12:22:48 >> Objet: Class modifiers in Java 16 >> >> >> Hello! >> >> I want to clarify my understanding of Java 16 spec and the >> corresponding compiler behavior regarding class modifiers (8.1.1) >> >> 1. static modifier >> Java 15 spec 8.1.1 [1] says: >> The modifier static pertains only to member classes (?8.5.1), not to >> top level or local or anonymous classes. >> >> Java 16 spec 8.1.1 [2] says: >> The modifier static pertains only to member classes and local classes. >> However, Java 16 spec 14.3 says: >> It is a compile-time error if a local class or interface declaration >> has the modifier static (?8.1.1). >> >> Is it my bad understanding of English or there's some contradiction? >> To me, 8.1.1 says that now, local classes can be declared as static >> while 14.3 says the opposite thing. >> >> >> In JEP 395, under "Static members of inner classes" >> "We relax this restriction in order to allow an inner class to declare members that are either explicitly or implicitly static. In particular, this allows an inner class to declare a static member that is a record class." >> that why 8.1.1 was modified. >> >> Yes, the sentence in 14.3 seems wrong. >> >> Thank you in advance, >> With best regards, >> Tagir Valeev. >> >> >> regards, >> R?mi >> >> >> [1] >> https://docs.oracle.com/javase/specs/jls/se15/html/jls-8.html#jls-ClassModifier >> [2] >> https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-ClassModifier >> [3] https://docs.oracle.com/javase/specs/jls/se16/html/jls-14.html#jls-14.3 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gli at openjdk.java.net Wed Jun 2 15:26:18 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 2 Jun 2021 15:26:18 GMT Subject: RFR: 8263642: javac emits duplicate checkcast for first bound of intersection type in cast [v2] In-Reply-To: References: Message-ID: > Hi all, > > Before the phase `desugar`, the demo `(C1 & I1) o` has **one** type-cast sub-tree, `JCTypeIntersection C1&I1`, at the syntax tree. After the phase `desugar`, the `(C1 & I1) o` becomes **three** type-cast sub-trees: `JCTypeIntersection C1&I1`, `I1`, `C1`. So at phase `Gen`, `javac` generates **three** `checkcast` according to the **three** type-cast sub-trees which causes this bug. > > This patch doesn't generate `checkcast` when the type is `JCTypeIntersection` so that the problem can be solved. And a corresponding test case is added. > > Another way to solve this issue is that the `TransTypes` of the `desugar` should be modified and **two** type-cast sub-trees should be generated instead of **three**. But this way may change more code than my original patch and may cause other regression. > > Thank you for taking the time to review. > > Best Regards. > --Guoxiong Guoxiong Li 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: - Remove the duplicated typecast nodes in the AST instead of ignoring it - Check the type of the checkcast - Merge branch 'master' into JDK-8263642 - 8263642: javac emits duplicate checkcast for first bound of intersection type in cast ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3399/files - new: https://git.openjdk.java.net/jdk/pull/3399/files/f57b0c39..0806d1bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3399&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3399&range=00-01 Stats: 744161 lines in 10367 files changed: 120714 ins; 594378 del; 29069 mod Patch: https://git.openjdk.java.net/jdk/pull/3399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3399/head:pull/3399 PR: https://git.openjdk.java.net/jdk/pull/3399 From gli at openjdk.java.net Wed Jun 2 15:26:29 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 2 Jun 2021 15:26:29 GMT Subject: RFR: 8263642: javac emits duplicate checkcast for first bound of intersection type in cast [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 04:44:21 GMT, Vicente Romero wrote: >> Guoxiong Li 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: >> >> - Remove the duplicated typecast nodes in the AST instead of ignoring it >> - Check the type of the checkcast >> - Merge branch 'master' into JDK-8263642 >> - 8263642: javac emits duplicate checkcast for first bound of intersection type in cast > > Changes requested by vromero (Reviewer). @vicente-romero-oracle Thanks for your review. I updated the patch just now. > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 2225: > >> 2223: !types.isSameType(tree.expr.type, tree.clazz.type) && >> 2224: types.asSuper(tree.expr.type, tree.clazz.type.tsym) == null && >> 2225: tree.clazz.getTag() != TYPEINTERSECTION) { > > I think that if the right form of the AST is one that have only two type casts, then that's what the fix should be doing I revised the patch to adjust the AST. Now it has only two type casts instead of three. > test/langtools/tools/javac/cast/intersection/DuplicatedCheckcastTest.java line 83: > >> 81: for (Instruction instruction : code_attribute.getInstructions()) { >> 82: if ("checkcast".equals(instruction.getMnemonic())) { >> 83: checkcastNumber++; > > I think that the test should check not only for the number of checkcast but also for the type the checkcast is checking against. Added. ------------- PR: https://git.openjdk.java.net/jdk/pull/3399 From vromero at openjdk.java.net Wed Jun 2 16:15:46 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 2 Jun 2021 16:15:46 GMT Subject: RFR: 8263642: javac emits duplicate checkcast for first bound of intersection type in cast [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 15:26:18 GMT, Guoxiong Li wrote: >> Hi all, >> >> Before the phase `desugar`, the demo `(C1 & I1) o` has **one** type-cast sub-tree, `JCTypeIntersection C1&I1`, at the syntax tree. After the phase `desugar`, the `(C1 & I1) o` becomes **three** type-cast sub-trees: `JCTypeIntersection C1&I1`, `I1`, `C1`. So at phase `Gen`, `javac` generates **three** `checkcast` according to the **three** type-cast sub-trees which causes this bug. >> >> This patch doesn't generate `checkcast` when the type is `JCTypeIntersection` so that the problem can be solved. And a corresponding test case is added. >> >> Another way to solve this issue is that the `TransTypes` of the `desugar` should be modified and **two** type-cast sub-trees should be generated instead of **three**. But this way may change more code than my original patch and may cause other regression. >> >> Thank you for taking the time to review. >> >> Best Regards. >> --Guoxiong > > Guoxiong Li 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: > > - Remove the duplicated typecast nodes in the AST instead of ignoring it > - Check the type of the checkcast > - Merge branch 'master' into JDK-8263642 > - 8263642: javac emits duplicate checkcast for first bound of intersection type in cast test/langtools/tools/javac/cast/intersection/DuplicatedCheckcastTest.java line 94: > 92: "Expected number: 2, actual number: " + checkCastList.size()); > 93: } > 94: // first checkcast hi, there is common code in the two sections of code that check for the checkcast I suggest creating a method for the common code ------------- PR: https://git.openjdk.java.net/jdk/pull/3399 From jjg at openjdk.java.net Wed Jun 2 16:25:41 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 16:25:41 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 Message-ID: Please review the change to update to using jtreg 6. The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. ------------- Commit messages: - JDK-8266254: Update to use jtreg 6 Changes: https://git.openjdk.java.net/jdk/pull/4315/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4315&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266254 Stats: 17 lines in 11 files changed: 0 ins; 1 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/4315.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4315/head:pull/4315 PR: https://git.openjdk.java.net/jdk/pull/4315 From lancea at openjdk.java.net Wed Jun 2 16:35:30 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 2 Jun 2021 16:35:30 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From gli at openjdk.java.net Wed Jun 2 16:37:54 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 2 Jun 2021 16:37:54 GMT Subject: RFR: 8263642: javac emits duplicate checkcast for first bound of intersection type in cast [v3] In-Reply-To: References: Message-ID: > Hi all, > > Before the phase `desugar`, the demo `(C1 & I1) o` has **one** type-cast sub-tree, `JCTypeIntersection C1&I1`, at the syntax tree. After the phase `desugar`, the `(C1 & I1) o` becomes **three** type-cast sub-trees: `JCTypeIntersection C1&I1`, `I1`, `C1`. So at phase `Gen`, `javac` generates **three** `checkcast` according to the **three** type-cast sub-trees which causes this bug. > > This patch doesn't generate `checkcast` when the type is `JCTypeIntersection` so that the problem can be solved. And a corresponding test case is added. > > Another way to solve this issue is that the `TransTypes` of the `desugar` should be modified and **two** type-cast sub-trees should be generated instead of **three**. But this way may change more code than my original patch and may cause other regression. > > Thank you for taking the time to review. > > Best Regards. > --Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Encapsulate common code to a method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3399/files - new: https://git.openjdk.java.net/jdk/pull/3399/files/0806d1bd..5f4f5bb7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3399&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3399&range=01-02 Stats: 19 lines in 1 file changed: 5 ins; 8 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3399/head:pull/3399 PR: https://git.openjdk.java.net/jdk/pull/3399 From gli at openjdk.java.net Wed Jun 2 16:38:04 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 2 Jun 2021 16:38:04 GMT Subject: RFR: 8263642: javac emits duplicate checkcast for first bound of intersection type in cast [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:12:40 GMT, Vicente Romero wrote: >> Guoxiong Li 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: >> >> - Remove the duplicated typecast nodes in the AST instead of ignoring it >> - Check the type of the checkcast >> - Merge branch 'master' into JDK-8263642 >> - 8263642: javac emits duplicate checkcast for first bound of intersection type in cast > > test/langtools/tools/javac/cast/intersection/DuplicatedCheckcastTest.java line 94: > >> 92: "Expected number: 2, actual number: " + checkCastList.size()); >> 93: } >> 94: // first checkcast > > hi, there is common code in the two sections of code that check for the checkcast I suggest creating a method for the common code Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3399 From erikj at openjdk.java.net Wed Jun 2 16:52:27 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Jun 2021 16:52:27 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From mchung at openjdk.java.net Wed Jun 2 16:56:30 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 2 Jun 2021 16:56:30 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From vromero at openjdk.java.net Wed Jun 2 16:57:39 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 2 Jun 2021 16:57:39 GMT Subject: RFR: 8263642: javac emits duplicate checkcast for first bound of intersection type in cast [v3] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:37:54 GMT, Guoxiong Li wrote: >> Hi all, >> >> Before the phase `desugar`, the demo `(C1 & I1) o` has **one** type-cast sub-tree, `JCTypeIntersection C1&I1`, at the syntax tree. After the phase `desugar`, the `(C1 & I1) o` becomes **three** type-cast sub-trees: `JCTypeIntersection C1&I1`, `I1`, `C1`. So at phase `Gen`, `javac` generates **three** `checkcast` according to the **three** type-cast sub-trees which causes this bug. >> >> This patch doesn't generate `checkcast` when the type is `JCTypeIntersection` so that the problem can be solved. And a corresponding test case is added. >> >> Another way to solve this issue is that the `TransTypes` of the `desugar` should be modified and **two** type-cast sub-trees should be generated instead of **three**. But this way may change more code than my original patch and may cause other regression. >> >> Thank you for taking the time to review. >> >> Best Regards. >> --Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Encapsulate common code to a method looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3399 From gli at openjdk.java.net Wed Jun 2 17:04:28 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 2 Jun 2021 17:04:28 GMT Subject: RFR: 8263642: javac emits duplicate checkcast for first bound of intersection type in cast [v3] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:54:58 GMT, Vicente Romero wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Encapsulate common code to a method > > looks good @vicente-romero-oracle Thanks for your review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/3399 From naoto at openjdk.java.net Wed Jun 2 17:05:34 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 2 Jun 2021 17:05:34 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Some of the modified files have copyright year left unchanged. `2021` needs to be appended. ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From alanb at openjdk.java.net Wed Jun 2 17:12:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 2 Jun 2021 17:12:29 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Looks good, I had expected we would have more tests depending on the automatic module. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4315 From vromero at openjdk.java.net Wed Jun 2 17:20:37 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 2 Jun 2021 17:20:37 GMT Subject: RFR: 8263642: javac emits duplicate checkcast for first bound of intersection type in cast [v3] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:54:58 GMT, Vicente Romero wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Encapsulate common code to a method > > looks good > @vicente-romero-oracle Thanks for your review. Could I get your help to sponsor this patch? > > /integrate sure, done ------------- PR: https://git.openjdk.java.net/jdk/pull/3399 From gli at openjdk.java.net Wed Jun 2 17:20:39 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 2 Jun 2021 17:20:39 GMT Subject: Integrated: 8263642: javac emits duplicate checkcast for first bound of intersection type in cast In-Reply-To: References: Message-ID: <57vcsoy-cb9f4zdsCn8hKm_OXIWPVZJQINS5btGOImE=.e255b007-d821-439d-80a7-cc90bcb13383@github.com> On Thu, 8 Apr 2021 16:29:04 GMT, Guoxiong Li wrote: > Hi all, > > Before the phase `desugar`, the demo `(C1 & I1) o` has **one** type-cast sub-tree, `JCTypeIntersection C1&I1`, at the syntax tree. After the phase `desugar`, the `(C1 & I1) o` becomes **three** type-cast sub-trees: `JCTypeIntersection C1&I1`, `I1`, `C1`. So at phase `Gen`, `javac` generates **three** `checkcast` according to the **three** type-cast sub-trees which causes this bug. > > This patch doesn't generate `checkcast` when the type is `JCTypeIntersection` so that the problem can be solved. And a corresponding test case is added. > > Another way to solve this issue is that the `TransTypes` of the `desugar` should be modified and **two** type-cast sub-trees should be generated instead of **three**. But this way may change more code than my original patch and may cause other regression. > > Thank you for taking the time to review. > > Best Regards. > --Guoxiong This pull request has now been integrated. Changeset: b7ac705d Author: Guoxiong Li Committer: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/b7ac705dd625c5fb2df714e2faec8d0ffac7301a Stats: 110 lines in 2 files changed: 108 ins; 0 del; 2 mod 8263642: javac emits duplicate checkcast for first bound of intersection type in cast Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/3399 From iris at openjdk.java.net Wed Jun 2 17:51:29 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 2 Jun 2021 17:51:29 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From chegar at openjdk.java.net Wed Jun 2 18:25:29 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 2 Jun 2021 18:25:29 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From jjg at openjdk.java.net Wed Jun 2 20:15:55 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 20:15:55 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 [v2] In-Reply-To: References: Message-ID: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Update copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4315/files - new: https://git.openjdk.java.net/jdk/pull/4315/files/0d1e554a..4ef5614f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4315&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4315&range=00-01 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4315.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4315/head:pull/4315 PR: https://git.openjdk.java.net/jdk/pull/4315 From naoto at openjdk.java.net Wed Jun 2 20:21:38 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 2 Jun 2021 20:21:38 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 20:15:55 GMT, Jonathan Gibbons wrote: >> Please review the change to update to using jtreg 6. >> >> The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. >> >> All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From duke at openjdk.java.net Wed Jun 2 21:23:40 2021 From: duke at openjdk.java.net (duke) Date: Wed, 2 Jun 2021 21:23:40 GMT Subject: Withdrawn: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to an explicit `org.testng`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From vromero at openjdk.java.net Thu Jun 3 05:04:53 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 3 Jun 2021 05:04:53 GMT Subject: RFR: 8267465: remove superfluous preview related annotations and test options Message-ID: <0WEceRgu4UAyTk0nJCtOyA8__hMNfVslEHaFs7n3Hms=.7d6b1d09-a200-436c-a65c-a16bef01b2e8@github.com> Please review this PR which is removing several superfluous `@SuppressWarnings("preview")` annotations from the compiler code and also removing preview related, but not needed anymore, options from regression tests. Please also review the related CSR which covers the only case that modified a public API. TIA ------------- Commit messages: - 8267465: remove superfluous @SuppressWarnings(preview) annotations Changes: https://git.openjdk.java.net/jdk/pull/4330/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4330&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267465 Stats: 111 lines in 33 files changed: 0 ins; 86 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/4330.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4330/head:pull/4330 PR: https://git.openjdk.java.net/jdk/pull/4330 From darcy at openjdk.java.net Thu Jun 3 05:48:51 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 3 Jun 2021 05:48:51 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 In-Reply-To: References: Message-ID: On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy wrote: > 8267630: Start of release updates for JDK 18 JDK 18 is right around the corner, time for the usual start-of-release changeset for review. Typical structure for these kinds of changes. I'll update the symbol file information of JDK 17 b25 after that build is promoted. Usual updates to SourceVersion, javac, HotSpot, and version-oriented tests. Please also review the related CSRs: JDK-8268156: Add SourceVersion.RELEASE_18 https://bugs.openjdk.java.net/browse/JDK-8268156 JDK-8268157: Add source 18 and target 18 to javac https://bugs.openjdk.java.net/browse/JDK-8268157 ------------- PR: https://git.openjdk.java.net/jdk/pull/4175 From darcy at openjdk.java.net Thu Jun 3 05:48:51 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 3 Jun 2021 05:48:51 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 Message-ID: 8267630: Start of release updates for JDK 18 ------------- Commit messages: - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Clean langtools test run. - ... and 1 more: https://git.openjdk.java.net/jdk/compare/ef01e478...9c7c88bf Changes: https://git.openjdk.java.net/jdk/pull/4175/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267630 Stats: 4946 lines in 62 files changed: 4904 ins; 0 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From iris at openjdk.java.net Thu Jun 3 05:58:37 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 3 Jun 2021 05:58:37 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 In-Reply-To: References: Message-ID: On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy wrote: > 8267630: Start of release updates for JDK 18 Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4175 From jlahoda at openjdk.java.net Thu Jun 3 07:39:03 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 3 Jun 2021 07:39:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v9] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Enhancing tests as suggested. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/80b1392b..79e3621b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=07-08 Stats: 44 lines in 1 file changed: 44 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From jfranck at openjdk.java.net Thu Jun 3 07:54:41 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Thu, 3 Jun 2021 07:54:41 GMT Subject: Integrated: 8226362: langtools ProblemList file contains more than 1 entry for a test In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 09:13:27 GMT, Joel Borggr?n-Franck wrote: > Please review this patch that merges problematic lines in the langtools ProblemList.txt This pull request has now been integrated. Changeset: 9bf347bc Author: Joel Borggr?n-Franck URL: https://git.openjdk.java.net/jdk/commit/9bf347bc1f1dc01e27fbf35a05d34e9c5059b63e Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod 8226362: langtools ProblemList file contains more than 1 entry for a test Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/4301 From jlahoda at openjdk.java.net Thu Jun 3 09:05:08 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 3 Jun 2021 09:05:08 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v10] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merging master into JDK-8262891 - Enhancing tests as suggested. - Fixing enum switch with patterns with guards. - Fixing tests. - Total pattern dominates the null pattern. - Properly report errors for pattern+default clash. - Avoiding unnecessary StackMap point. - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. - Correcting LineNumberTable for rule switches. - Merging master into JDK-8262891 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/bdeaeb47...fa50b5fb ------------- Changes: https://git.openjdk.java.net/jdk/pull/3863/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=09 Stats: 4828 lines in 79 files changed: 4509 ins; 118 del; 201 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From erikj at openjdk.java.net Thu Jun 3 12:42:40 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 3 Jun 2021 12:42:40 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 20:15:55 GMT, Jonathan Gibbons wrote: >> Please review the change to update to using jtreg 6. >> >> The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. >> >> All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to an explicit `org.testng`. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years This PR wasn't handled properly when integrated. The change looks like it was pushed correctly and the bug was updated, so we are only missing some book keeping in the PR. I've filed https://bugs.openjdk.java.net/browse/SKARA-1069. ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From erikj at openjdk.java.net Thu Jun 3 12:51:36 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 3 Jun 2021 12:51:36 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 In-Reply-To: References: Message-ID: <94PX9MLJgRcWFUR1VQtRdowvllf6j9JcTPPPLHXh-JM=.822be67f-5513-42a8-9342-78da0b315807@github.com> On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy wrote: > 8267630: Start of release updates for JDK 18 Build change looks good. Please be aware of the incoming change https://bugs.openjdk.java.net/browse/JDK-8263468 which will add another version field to version-numbers.conf, which may need to be updated too. The exact policy around that is still unclear though. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4175 From vromero at openjdk.java.net Thu Jun 3 16:20:09 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 3 Jun 2021 16:20:09 GMT Subject: RFR: 8267465: remove superfluous preview related annotations and test options [v2] In-Reply-To: <0WEceRgu4UAyTk0nJCtOyA8__hMNfVslEHaFs7n3Hms=.7d6b1d09-a200-436c-a65c-a16bef01b2e8@github.com> References: <0WEceRgu4UAyTk0nJCtOyA8__hMNfVslEHaFs7n3Hms=.7d6b1d09-a200-436c-a65c-a16bef01b2e8@github.com> Message-ID: > Please review this PR which is removing several superfluous `@SuppressWarnings("preview")` annotations from the compiler code and also removing preview related, but not needed anymore, options from regression tests. Please also review the related CSR which covers the only case that modified a public API. > > TIA Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8267465 - 8267465: remove superfluous @SuppressWarnings(preview) annotations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4330/files - new: https://git.openjdk.java.net/jdk/pull/4330/files/81162e72..fab606ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4330&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4330&range=00-01 Stats: 34827 lines in 1340 files changed: 25154 ins; 5460 del; 4213 mod Patch: https://git.openjdk.java.net/jdk/pull/4330.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4330/head:pull/4330 PR: https://git.openjdk.java.net/jdk/pull/4330 From darcy at openjdk.java.net Fri Jun 4 00:07:32 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Jun 2021 00:07:32 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v2] In-Reply-To: References: Message-ID: > 8267630: Start of release updates for JDK 18 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 12 additional commits since the last revision: - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/388f8dae...e584c467 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4175/files - new: https://git.openjdk.java.net/jdk/pull/4175/files/9c7c88bf..e584c467 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=00-01 Stats: 428395 lines in 342 files changed: 426299 ins; 917 del; 1179 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From vromero at openjdk.java.net Fri Jun 4 03:05:10 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 4 Jun 2021 03:05:10 GMT Subject: RFR: 8238213: Method resolution should stop on static error Message-ID: Please review this fix that is stopping method resolution if a static error is found. Currently javac rejecting code like: public class Test { public static void main(String[] args) { test(5.0); } void test(double d) {} void test(Double d) {} } but for the wrong reason. Basically it is that the invocation of method `test` is ambiguous as if both were applicable when it should fail at the end of the first overload resolution phase indicating that the non-static method test(double) can't be referred from a static context. This patch is fixing this issue. TIA ------------- Commit messages: - 8238213: Method resolution should stop on static error Changes: https://git.openjdk.java.net/jdk/pull/4351/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4351&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238213 Stats: 23 lines in 3 files changed: 22 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4351.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4351/head:pull/4351 PR: https://git.openjdk.java.net/jdk/pull/4351 From darcy at openjdk.java.net Fri Jun 4 04:47:22 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Jun 2021 04:47:22 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v3] In-Reply-To: References: Message-ID: > 8267630: Start of release updates for JDK 18 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 13 additional commits since the last revision: - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/662de459...fc4d8725 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4175/files - new: https://git.openjdk.java.net/jdk/pull/4175/files/e584c467..fc4d8725 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=01-02 Stats: 112 lines in 5 files changed: 10 ins; 50 del; 52 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From jfranck at openjdk.java.net Fri Jun 4 08:29:15 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Fri, 4 Jun 2021 08:29:15 GMT Subject: RFR: 8232948: javac -h should mangle the overload argument signature Message-ID: When overloaded methods are disambiguated the appended argument signature should be mangled according to the spec. ------------- Commit messages: - 8232948: Appease jcheck - 8232948: javac -h should mangle the overload argument signature Changes: https://git.openjdk.java.net/jdk/pull/4345/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4345&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232948 Stats: 129 lines in 2 files changed: 121 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4345.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4345/head:pull/4345 PR: https://git.openjdk.java.net/jdk/pull/4345 From jlahoda at openjdk.java.net Fri Jun 4 09:01:27 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 09:01:27 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v11] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: - Tweaking SwitchBootstraps javadoc, as suggested. - Improving javadoc. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/fa50b5fb..216b87c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=09-10 Stats: 66 lines in 2 files changed: 40 ins; 9 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From mcimadamore at openjdk.java.net Fri Jun 4 09:38:03 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Jun 2021 09:38:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v11] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 09:01:27 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: > > - Tweaking SwitchBootstraps javadoc, as suggested. > - Improving javadoc. Re-approving to keep the bots happy ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri Jun 4 09:46:31 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 09:46:31 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/216b87c2..8d4c02b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri Jun 4 12:50:14 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 12:50:14 GMT Subject: RFR: 8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec Message-ID: This improves javadoc/specification of several StandardJavaFileManager methods, as requested in these bugs: https://bugs.openjdk.java.net/browse/JDK-8266631 https://bugs.openjdk.java.net/browse/JDK-8266596 https://bugs.openjdk.java.net/browse/JDK-8266591 https://bugs.openjdk.java.net/browse/JDK-8266590 The CSR is here: https://bugs.openjdk.java.net/browse/JDK-8268260 ------------- Commit messages: - 8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec Changes: https://git.openjdk.java.net/jdk/pull/4360/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4360&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266631 Stats: 12 lines in 1 file changed: 2 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4360.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4360/head:pull/4360 PR: https://git.openjdk.java.net/jdk/pull/4360 From vromero at openjdk.java.net Fri Jun 4 15:33:55 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 4 Jun 2021 15:33:55 GMT Subject: RFR: 8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 12:42:35 GMT, Jan Lahoda wrote: > This improves javadoc/specification of several StandardJavaFileManager methods, as requested in these bugs: > https://bugs.openjdk.java.net/browse/JDK-8266631 > https://bugs.openjdk.java.net/browse/JDK-8266596 > https://bugs.openjdk.java.net/browse/JDK-8266591 > https://bugs.openjdk.java.net/browse/JDK-8266590 > > The CSR is here: > https://bugs.openjdk.java.net/browse/JDK-8268260 the patch and the CSR look good to me. I would just inline the spec changes in the specification section of the CSR ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4360 From psandoz at openjdk.java.net Fri Jun 4 15:54:00 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 4 Jun 2021 15:54:00 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing typo. A really nice feature, and a significant amount of work in javac. I mostly focused on the bootstrap and API aspects, and left some minor comments (most of which you can choose to apply or not as you see fit). I suspect the bootstrap might evolve as we get feedback and switch is enhanced with further forms of matching. But, at the moment it looks good. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 87: > 85: * returns {@literal -1}. > 86: *

> 87: * the {@code target} is not {@code null}, then the method of the call site Suggestion: * If the {@code target} is not {@code null}, then the method of the call site src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 92: > 90: *