From jjg at openjdk.org Sat Oct 1 01:16:38 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Sat, 1 Oct 2022 01:16:38 GMT Subject: RFR: JDK-8293877: Rewrite MineField test In-Reply-To: <1aVIGSEHuoo2Xs72rAzd6djwF9Lo4RUW4eNIOyAhD50=.53af99b6-f96e-414c-b03d-c40bf8af7547@github.com> References: <1aVIGSEHuoo2Xs72rAzd6djwF9Lo4RUW4eNIOyAhD50=.53af99b6-f96e-414c-b03d-c40bf8af7547@github.com> Message-ID: On Fri, 30 Sep 2022 23:39:48 GMT, Vicente Romero wrote: > I have gone through all the changes, I think semantically the original tests have been preserved as closed as possible. After a first review iteration I think it could make sense to clean up a bit an remove dead code etc Yeah, I'm inclined to agree that the time has come to remove the dead code related to those long-gone options and system properties. ------------- PR: https://git.openjdk.org/jdk/pull/10366 From duke at openjdk.org Sat Oct 1 01:38:28 2022 From: duke at openjdk.org (duke) Date: Sat, 1 Oct 2022 01:38:28 GMT Subject: Withdrawn: 8029633: Raw inner class constructor ref should not perform diamond inference In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 20:20:14 GMT, Vicente Romero wrote: > This PR is synchronizing the compiler with the spec, in particular with this portion of section `15.13.1 Compile-Time Declaration of a Method Reference`: > > > ? If the method reference expression has the form ClassType :: > [TypeArguments] new , then the potentially applicable methods are a set of > notional methods corresponding to the constructors of ClassType. > If ClassType is a raw type, but is not a non- static member type of a raw type, > the candidate notional member methods are those specified in ?15.9.3 for a > class instance creation expression that uses <> to elide the type arguments to a > class. Otherwise, the candidate notional member methods are the constructors > of ClassType, treated as if they were methods with return type ClassType. > > so javac should treat the code below as a raw constructor invocation: > > > class Outer { > class Inner {} > > Supplier.Inner> s = Outer.Inner::new; > } > > currently javac is rejecting this code > > TIA > > PS. Please review the related CSR too This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9784 From weijun at openjdk.org Sat Oct 1 15:02:04 2022 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 1 Oct 2022 15:02:04 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race wrote: >> Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`? > > This is correct. > AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../" Thanks @prrace. And yes, git link is better. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From jjg at openjdk.org Sat Oct 1 15:37:36 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Sat, 1 Oct 2022 15:37:36 GMT Subject: RFR: JDK-8293877: Rewrite MineField test [v2] In-Reply-To: References: Message-ID: > Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code. > > This will be an awkward/difficult/tedious (choose your adjective) review. The old files have been deleted, and the new code is different enough to defeat any `diff` program. That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter. It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together. > > The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience. > > Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`. > > The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation. > > Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature. > > On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed. But any change would be a difference in the old and new code, and should arguably be done separately. So, the existence and use of `cleanup` methods is as before. > > Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code. > > The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort. > > Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests. For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases. > > Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: remove commented-out obsolete code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10366/files - new: https://git.openjdk.org/jdk/pull/10366/files/4b0d8584..32d5a492 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10366&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10366&range=00-01 Stats: 50 lines in 3 files changed: 0 ins; 48 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10366.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10366/head:pull/10366 PR: https://git.openjdk.org/jdk/pull/10366 From vromero at openjdk.org Sat Oct 1 17:13:15 2022 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 1 Oct 2022 17:13:15 GMT Subject: RFR: JDK-8293877: Rewrite MineField test [v2] In-Reply-To: References: Message-ID: On Sat, 1 Oct 2022 15:37:36 GMT, Jonathan Gibbons wrote: >> Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code. >> >> This will be an awkward/difficult/tedious (choose your adjective) review. The old files have been deleted, and the new code is different enough to defeat any `diff` program. That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter. It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together. >> >> The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience. >> >> Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`. >> >> The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation. >> >> Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature. >> >> On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed. But any change would be a difference in the old and new code, and should arguably be done separately. So, the existence and use of `cleanup` methods is as before. >> >> Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code. >> >> The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort. >> >> Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests. For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases. >> >> Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > remove commented-out obsolete code dead code removal looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10366 From aturbanov at openjdk.org Sat Oct 1 17:31:27 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sat, 1 Oct 2022 17:31:27 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v7] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 12:21:58 GMT, Jan Lahoda wrote: >> This is an attempt to improve the performance and scalability of switches with record patterns. >> >> There are two main parts of this patch: >> 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.: >> >> switch (obj) { >> case Box(String s) -> {} >> case Box(Integer i) -> {} >> case Box(Number n) -> {} >> ... >> } >> => >> switch (obj) { >> case Box b -> >> switch (b.o()) { >> case String s -> {} >> case Integer i -> {} >> case Number n -> {} >> default -> continue-with-outer-switch; >> }; >> ... >> } >> >> >> This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible. >> >> 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers. >> >> I ran the new code through a JMH benchmark: >> [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt) >> >> The results are: >> - for "long" testcase (a switch with many cases): >> >> PatternsOptimizationTest.testExistingTranslationLongSwitch thrpt 25 1025740.668 ? 15325.355 ops/s >> PatternsOptimizationTest.testNewTranslationLongSwitch thrpt 25 1588461.471 ? 15315.509 ops/s >> >> - for "short" testcase (a switch with no so many cases): >> >> PatternsOptimizationTest.testExistingTranslationShortSwitch thrpt 25 6418845.624 ? 75981.939 ops/s >> PatternsOptimizationTest.testNewTranslationShortSwitch thrpt 25 6894823.439 ? 67420.858 ops/s >> >> >> So, the performance seems to be improved, at least in these cases. >> >> As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`). > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Merge branch 'master' into JDK-8291769 > - Reflecting review feedback. > - Merge branch 'master' into JDK-8291769 > - Using a custom record instead of a generic Pair. > - Fixing test. > - Properly handle null record components. > - 8291769: Translation of switch with record patterns could be improved src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 480: > 478: : selector)); > 479: VarSymbol index = new VarSymbol(Flags.SYNTHETIC, > 480: names.fromString("index" + target.syntheticNameChar() + variableIndex++), let's remove one redundant space after `target.syntheticNameChar()` ------------- PR: https://git.openjdk.org/jdk/pull/9746 From martin at openjdk.org Sun Oct 2 04:12:20 2022 From: martin at openjdk.org (Martin Buchholz) Date: Sun, 2 Oct 2022 04:12:20 GMT Subject: RFR: JDK-8293877: Rewrite MineField test [v2] In-Reply-To: References: Message-ID: <5o5Tiusvi2jIkTVHDZObIQfqznMSRYxSwu8bCVLV7EA=.d558cc96-5fd5-4384-814e-89c36afe94be@github.com> On Sat, 1 Oct 2022 15:37:36 GMT, Jonathan Gibbons wrote: >> Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code. >> >> This will be an awkward/difficult/tedious (choose your adjective) review. The old files have been deleted, and the new code is different enough to defeat any `diff` program. That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter. It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together. >> >> The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience. >> >> Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`. >> >> The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation. >> >> Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature. >> >> On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed. But any change would be a difference in the old and new code, and should arguably be done separately. So, the existence and use of `cleanup` methods is as before. >> >> Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code. >> >> The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort. >> >> Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests. For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases. >> >> Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > remove commented-out obsolete code It's clear that javac team intends to have ToolProvider and command line invocation be very equivalent (good!) but I have memories of it being quite tricky to convert from one to the other, and I would be wary of lingering bugs, especially in the path handling code. I care more than most about the performance of test runs, but for command line flags, I would always at least test them via subprocess invocation. ------------- PR: https://git.openjdk.org/jdk/pull/10366 From martin at openjdk.org Sun Oct 2 04:31:23 2022 From: martin at openjdk.org (Martin Buchholz) Date: Sun, 2 Oct 2022 04:31:23 GMT Subject: RFR: JDK-8293877: Rewrite MineField test [v2] In-Reply-To: References: Message-ID: On Sat, 1 Oct 2022 15:37:36 GMT, Jonathan Gibbons wrote: >> Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code. >> >> This will be an awkward/difficult/tedious (choose your adjective) review. The old files have been deleted, and the new code is different enough to defeat any `diff` program. That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter. It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together. >> >> The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience. >> >> Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`. >> >> The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation. >> >> Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature. >> >> On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed. But any change would be a difference in the old and new code, and should arguably be done separately. So, the existence and use of `cleanup` methods is as before. >> >> Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code. >> >> The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort. >> >> Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests. For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases. >> >> Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > remove commented-out obsolete code I spent a few nostalgic minutes looking over the translation into java. Looks good. I regret not having added more comments about why particular invocations were expected to pass or fail. I was introduced to junit after writing these. I might have tried to do more junitization if I was doing the translation. Despite having implemented wildcards, I was never keen on the feature, and haven't used it myself in the Real World. ------------- Marked as reviewed by martin (Reviewer). PR: https://git.openjdk.org/jdk/pull/10366 From darcy at openjdk.org Mon Oct 3 01:48:21 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 3 Oct 2022 01:48:21 GMT Subject: RFR: JDK-8293877: Rewrite MineField test [v2] In-Reply-To: References: Message-ID: <7xd8kFGWO4ez7mdWnETn7n9xQ2DnvauoI29ijSCxe-w=.d17b1aef-a960-4e1d-af0e-3d8640078500@github.com> On Sat, 1 Oct 2022 15:37:36 GMT, Jonathan Gibbons wrote: >> Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code. >> >> This will be an awkward/difficult/tedious (choose your adjective) review. The old files have been deleted, and the new code is different enough to defeat any `diff` program. That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter. It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together. >> >> The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience. >> >> Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`. >> >> The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation. >> >> Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature. >> >> On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed. But any change would be a difference in the old and new code, and should arguably be done separately. So, the existence and use of `cleanup` methods is as before. >> >> Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code. >> >> The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort. >> >> Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests. For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases. >> >> Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > remove commented-out obsolete code test/langtools/tools/javac/Paths/ClassPath.java line 39: > 37: * > 38: * For the last version of the original, Class-Path.sh, see > 39: * https://github.com/openjdk/jdk/blob/jdk-19%2B36/test/langtools/tools/javac/Paths/Class-Path.sh Please change this and other github URLs to use "https://git.openjdk.org/jdk" as the prefix, e.g.: https://git.openjdk.org/jdk/blob/jdk-19%2B36/test/langtools/tools/javac/Paths/Class-Path.sh ------------- PR: https://git.openjdk.org/jdk/pull/10366 From darcy at openjdk.org Mon Oct 3 01:53:46 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 3 Oct 2022 01:53:46 GMT Subject: RFR: JDK-8293877: Rewrite MineField test [v2] In-Reply-To: References: Message-ID: On Sat, 1 Oct 2022 15:37:36 GMT, Jonathan Gibbons wrote: >> Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code. >> >> This will be an awkward/difficult/tedious (choose your adjective) review. The old files have been deleted, and the new code is different enough to defeat any `diff` program. That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter. It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together. >> >> The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience. >> >> Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`. >> >> The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation. >> >> Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature. >> >> On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed. But any change would be a difference in the old and new code, and should arguably be done separately. So, the existence and use of `cleanup` methods is as before. >> >> Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code. >> >> The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort. >> >> Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests. For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases. >> >> Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > remove commented-out obsolete code Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10366 From jlahoda at openjdk.org Mon Oct 3 07:24:33 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 3 Oct 2022 07:24:33 GMT Subject: RFR: JDK-8293877: Rewrite MineField test [v2] In-Reply-To: References: Message-ID: On Sat, 1 Oct 2022 15:37:36 GMT, Jonathan Gibbons wrote: >> Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code. >> >> This will be an awkward/difficult/tedious (choose your adjective) review. The old files have been deleted, and the new code is different enough to defeat any `diff` program. That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter. It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together. >> >> The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience. >> >> Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`. >> >> The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation. >> >> Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature. >> >> On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed. But any change would be a difference in the old and new code, and should arguably be done separately. So, the existence and use of `cleanup` methods is as before. >> >> Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code. >> >> The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort. >> >> Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests. For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases. >> >> Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > remove commented-out obsolete code Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.org/jdk/pull/10366 From jlahoda at openjdk.org Mon Oct 3 07:27:23 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 3 Oct 2022 07:27:23 GMT Subject: RFR: 8291769: Translation of switch with record patterns could be improved [v8] In-Reply-To: References: Message-ID: > This is an attempt to improve the performance and scalability of switches with record patterns. > > There are two main parts of this patch: > 1. for cases of consecutive runs of cases with the same record pattern, these are replaced with a single case and a nested switch. E.g.: > > switch (obj) { > case Box(String s) -> {} > case Box(Integer i) -> {} > case Box(Number n) -> {} > ... > } > => > switch (obj) { > case Box b -> > switch (b.o()) { > case String s -> {} > case Integer i -> {} > case Number n -> {} > default -> continue-with-outer-switch; > }; > ... > } > > > This is done by first unrolling the record patterns into simple binding patterns a guards, and then by finding cases with the common binding pattern as a label and a viable guard. Binding patterns are reused as much as possibly, eliminating specialized handling of record patterns as much as possible. > > 2. When a record accessor method fails with an exception, we need to wrap this exception with a `MatchException`. Currently this is being done by introducing a special proxy method which catches the exception and re-throws. The proposed patch here eliminates the need for the accessor methods by producing an appropriate `ExceptionTable` in the classfile, and a separate catch handler. This handler is attached to the innermost usable block, which is either the method block, lambda body, (static or non-static) initializer or a try block. This should ensure correct semantics, while not producing too many unnecessary catch handlers. > > I ran the new code through a JMH benchmark: > [PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/9260707/PatternsOptimizationTest.java.txt) > > The results are: > - for "long" testcase (a switch with many cases): > > PatternsOptimizationTest.testExistingTranslationLongSwitch thrpt 25 1025740.668 ? 15325.355 ops/s > PatternsOptimizationTest.testNewTranslationLongSwitch thrpt 25 1588461.471 ? 15315.509 ops/s > > - for "short" testcase (a switch with no so many cases): > > PatternsOptimizationTest.testExistingTranslationShortSwitch thrpt 25 6418845.624 ? 75981.939 ops/s > PatternsOptimizationTest.testNewTranslationShortSwitch thrpt 25 6894823.439 ? 67420.858 ops/s > > > So, the performance seems to be improved, at least in these cases. > > As a follow-up work, there are several other improvements that may be worth investigating like using if cascades instead of switches with very few cases (but possibly not very trivial for switch expressions, at least for switch expressions of type `boolean`), or improving the code produced by the runtime bootstrap method (`SwitchBootstraps.typeSwitch`). Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Removing extra whitespace. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9746/files - new: https://git.openjdk.org/jdk/pull/9746/files/4f9f7f98..9d8e21c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9746&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9746.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9746/head:pull/9746 PR: https://git.openjdk.org/jdk/pull/9746 From ethan at mccue.dev Mon Oct 3 14:31:44 2022 From: ethan at mccue.dev (Ethan McCue) Date: Mon, 3 Oct 2022 10:31:44 -0400 Subject: Error examples page Message-ID: Hey all, My group stumbled upon this page with a bunch of error examples in a nice presentable format. https://cr.openjdk.java.net/~jjg/diags-examples.html My suspicion is that this was generated by something in the codebase - if so does anyone know the command of the top of their head? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.org Mon Oct 3 15:08:58 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 3 Oct 2022 15:08:58 GMT Subject: RFR: 8294670: Enhanced switch statements have an implicit default which does not complete normally Message-ID: When a synthetic `default` is generated for enhanced switch, it never completes normally, which should be used when detecting liveness after the switch statement, which is what this patch is trying to do. ------------- Commit messages: - 8294670: Enhanced switch statements have an implicit default which does not complete normally Changes: https://git.openjdk.org/jdk/pull/10540/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10540&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294670 Stats: 119 lines in 4 files changed: 114 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10540.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10540/head:pull/10540 PR: https://git.openjdk.org/jdk/pull/10540 From jjg at openjdk.org Mon Oct 3 17:12:39 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 3 Oct 2022 17:12:39 GMT Subject: RFR: JDK-8293877: Rewrite MineField test [v2] In-Reply-To: <5o5Tiusvi2jIkTVHDZObIQfqznMSRYxSwu8bCVLV7EA=.d558cc96-5fd5-4384-814e-89c36afe94be@github.com> References: <5o5Tiusvi2jIkTVHDZObIQfqznMSRYxSwu8bCVLV7EA=.d558cc96-5fd5-4384-814e-89c36afe94be@github.com> Message-ID: <7MWLgH877IW7k5e11w0FsH5JYt91IFTL7SnLMGo5qaI=.d050098b-2416-4bf1-8aa0-22844b91ecd6@github.com> On Sun, 2 Oct 2022 04:08:20 GMT, Martin Buchholz wrote: > It's clear that javac team intends to have ToolProvider and command line invocation be very equivalent (good!) but I have memories of it being quite tricky to convert from one to the other, and I would be wary of lingering bugs, especially in the path handling code. > > I care more than most about the performance of test runs, but for command line flags, I would always at least test them via subprocess invocation. The comment is noted. Generally, the javac code is _much_ better that it has been in times past, with better use of better abstractions. That being said, I agree there are different code paths in the outer layers of `javac` and it is important to be aware of the differences when introducing new options. As for path options, I suspect any differences are more likely to arise when using the `JavaCompiler` (JSR199) API, compared to the `ToolProvider` and native launcher invocation. ------------- PR: https://git.openjdk.org/jdk/pull/10366 From jjg at openjdk.org Mon Oct 3 17:12:39 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 3 Oct 2022 17:12:39 GMT Subject: RFR: JDK-8293877: Rewrite MineField test [v2] In-Reply-To: <7xd8kFGWO4ez7mdWnETn7n9xQ2DnvauoI29ijSCxe-w=.d17b1aef-a960-4e1d-af0e-3d8640078500@github.com> References: <7xd8kFGWO4ez7mdWnETn7n9xQ2DnvauoI29ijSCxe-w=.d17b1aef-a960-4e1d-af0e-3d8640078500@github.com> Message-ID: On Mon, 3 Oct 2022 01:46:07 GMT, Joe Darcy wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> remove commented-out obsolete code > > test/langtools/tools/javac/Paths/ClassPath.java line 39: > >> 37: * >> 38: * For the last version of the original, Class-Path.sh, see >> 39: * https://github.com/openjdk/jdk/blob/jdk-19%2B36/test/langtools/tools/javac/Paths/Class-Path.sh > > Please change this and other github URLs to use "https://git.openjdk.org/jdk" as the prefix, e.g.: > > https://git.openjdk.org/jdk/blob/jdk-19%2B36/test/langtools/tools/javac/Paths/Class-Path.sh Darn! missed this; will have to fix separately ------------- PR: https://git.openjdk.org/jdk/pull/10366 From jjg at openjdk.org Mon Oct 3 17:12:40 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 3 Oct 2022 17:12:40 GMT Subject: Integrated: JDK-8293877: Rewrite MineField test In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 00:57:22 GMT, Jonathan Gibbons wrote: > Please review an update to convert the remaining langtools shell tests, in `test/langtools/tools/javac/Paths/*` from shell to Java code. > > This will be an awkward/difficult/tedious (choose your adjective) review. The old files have been deleted, and the new code is different enough to defeat any `diff` program. That being said, I have done what I can to provide a line-for-line translation as best I can, in the parts of the code that matter. It may help to use tools to display the old code and new code side-by-size, in an ad-hoc fashion, and manually scrolling the versions together. > > The old shell tests were written in a stylized and clever manner to reduce the verbiage of writing in shell script. The new tests are written in a differently stylized manner, using API methods to provide much of the same level of convenience. > > Of the six tests, 5 have an obvious name translation (the hyphen is dropped from `Class-Path.sh` and `Class-Path2.sh`, and the cryptically named `wcMineField.sh` is renamed to the less cryptic `WildcardMineField.java`. > > The supporting API in the new `Util.java` class is somewhat similar to the older `Util.sh` code, but is much less of a line-for-line translation. > > Where possible, tools are invoked using the tool's `ToolProvider` API, as compared to exec-ing a separate process. A separate process is still always necessary for the main Java launcher, and is sometimes needed for Java ... when javac should be executed in a different directory, or with different env variables, or when using the "class path wildcard" feature. > > On the use of `cleanup` methods... all the tests here call a `cleanup()` method as part of initial setup, and after the test is complete. Such cleanup is unnecessary beforehand when using jtreg (because jtreg guarantees an empty scratch directory when a test is run) and can be inconvenient afterwards, if you want to debug why a test-case has failed, although for sure it is arguably good to do if the test has passed. But any change would be a difference in the old and new code, and should arguably be done separately. So, the existence and use of `cleanup` methods is as before. > > Some code was commented out in the original tests, because various options and system properties became unavailable in JDK 9. The commented out code is preserved, if only to provide visual anchors between the old and new versions. It may be desirable to eventually clean out the commented-out code. > > The old code supported use of `${TESTTOOLVMOPTS}` and `${TESTVMOPTS}` although it is not clear how effective such support was, or how much it was used. The new code does _not_ support these environment variables, or their equivalent system properties. Given that the new code uses the `ToolProvider` API where possible, it is not clear how (or how easily) we could integrate support for those options, and whether it is worth the effort. > > Needless to say, all the new tests pass. For positive test cases, that is definitely reassuring. For negative test cases, it is somewhat harder to verify that each new test case fails for the same reason that the old test case failed, not least because of the lack of info provided by the old tests. For this reason, it is assumed it is sufficient to have confidence in the translation of all the test cases. > > Separately, there is a minor fix in ToolBox, to address an NPE. The fix is small enough and obvious enough to include here, as compared to having a separate JBS issue and PR. This pull request has now been integrated. Changeset: e137f9f2 Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/e137f9f2f0e4244307900cd0eadceb9b773e9858 Stats: 3208 lines in 15 files changed: 1931 ins; 1276 del; 1 mod 8293877: Rewrite MineField test Reviewed-by: vromero, martin, darcy, jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/10366 From darcy at openjdk.org Mon Oct 3 17:20:53 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 3 Oct 2022 17:20:53 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 20:25:28 GMT, Joe Darcy wrote: > Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..? Filed a few follow-up bugs: JDK-8294724: Update openjdk.java.net => openjdk.org in tests (umbrella) JDK-8294725: Update openjdk.java.net => openjdk.org in java command man page ------------- PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Mon Oct 3 17:25:30 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 3 Oct 2022 17:25:30 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v6] In-Reply-To: References: Message-ID: <_UYUckHSBcJizYd7JBVbr6evdOrHu9h2MopGUlzrLR8=.b5c6d747-800b-462b-a19a-73a0f5096e3e@github.com> > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update doc directory files. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/fbaf3d4c..6bf7bf61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=04-05 Stats: 38 lines in 4 files changed: 0 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Mon Oct 3 17:29:45 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 3 Oct 2022 17:29:45 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7] In-Reply-To: References: Message-ID: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com> > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update make directory. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/6bf7bf61..224ed7a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=05-06 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Mon Oct 3 17:38:14 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 3 Oct 2022 17:38:14 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 17:17:39 GMT, Joe Darcy wrote: > > Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..? > > Filed a few follow-up bugs: > > JDK-8294724: Update openjdk.java.net => openjdk.org in tests (umbrella) JDK-8294725: Update openjdk.java.net => openjdk.org in java command man page And also filed JDK-8294728: Update openjdk.java.net => openjdk.org in hotspot unit test docs ------------- PR: https://git.openjdk.org/jdk/pull/10501 From jjg at openjdk.org Mon Oct 3 18:09:32 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 3 Oct 2022 18:09:32 GMT Subject: RFR: JDK-8294726: Update URLs in minefield tests Message-ID: <8RSwPoHXslUhF1a3uYRqwjlz86pdxYS0QfPCBJi37B8=.f102fdbc-b733-458d-9f66-130ccf0c9eb3@github.com> Please review a small change to address a suggestion that was accidentally overlooked in PR #10366 The URLs are changed to use `https://git.openjdk.org/` ------------- Commit messages: - JDK-8294726: Update URLs in minefield tests Changes: https://git.openjdk.org/jdk/pull/10542/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10542&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294726 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10542.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10542/head:pull/10542 PR: https://git.openjdk.org/jdk/pull/10542 From darcy at openjdk.org Mon Oct 3 18:25:17 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 3 Oct 2022 18:25:17 GMT Subject: RFR: JDK-8294726: Update URLs in minefield tests In-Reply-To: <8RSwPoHXslUhF1a3uYRqwjlz86pdxYS0QfPCBJi37B8=.f102fdbc-b733-458d-9f66-130ccf0c9eb3@github.com> References: <8RSwPoHXslUhF1a3uYRqwjlz86pdxYS0QfPCBJi37B8=.f102fdbc-b733-458d-9f66-130ccf0c9eb3@github.com> Message-ID: On Mon, 3 Oct 2022 17:59:06 GMT, Jonathan Gibbons wrote: > Please review a small change to address a suggestion that was accidentally overlooked in PR #10366 > > The URLs are changed to use `https://git.openjdk.org/` Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10542 From iris at openjdk.org Mon Oct 3 18:31:21 2022 From: iris at openjdk.org (Iris Clark) Date: Mon, 3 Oct 2022 18:31:21 GMT Subject: RFR: JDK-8294726: Update URLs in minefield tests In-Reply-To: <8RSwPoHXslUhF1a3uYRqwjlz86pdxYS0QfPCBJi37B8=.f102fdbc-b733-458d-9f66-130ccf0c9eb3@github.com> References: <8RSwPoHXslUhF1a3uYRqwjlz86pdxYS0QfPCBJi37B8=.f102fdbc-b733-458d-9f66-130ccf0c9eb3@github.com> Message-ID: On Mon, 3 Oct 2022 17:59:06 GMT, Jonathan Gibbons wrote: > Please review a small change to address a suggestion that was accidentally overlooked in PR #10366 > > The URLs are changed to use `https://git.openjdk.org/` Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10542 From prr at openjdk.org Mon Oct 3 20:08:19 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 3 Oct 2022 20:08:19 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7] In-Reply-To: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com> References: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com> Message-ID: On Mon, 3 Oct 2022 17:29:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Update make directory. src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 36: > 34: * https://git.openjdk.org/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c > 35: * > 36: * Also note that the API is used in the jaccessinspector and jaccesswalker tools. The problem with this is, is that anyone who gets JDK 20 (or 21 the LTS) will be forever more then pointed at the OpenJDK "tip" and if we made an incompatible ABI change, that would be a problem. At this point I'd prefer that this be updated to point to JDK 17, as in https://github.com/openjdk/jdk17/blob/master/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp So it is a defined, known, compatible version. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From jonathan.gibbons at oracle.com Mon Oct 3 20:22:03 2022 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 3 Oct 2022 13:22:03 -0700 Subject: Error examples page In-Reply-To: References: Message-ID: It's generated by the code in open/test/langtools/tools/javac/diags/. There are various classes there, like RunExamples.java, CheckExamples.java etc. You are probably looking for RunExamples.java; there are comments in the code on how to use it. -- Jon On 10/3/22 7:31 AM, Ethan McCue wrote: > Hey all, > > My group stumbled upon this page with a bunch of error examples in a > nice presentable format. > > https://cr.openjdk.java.net/~jjg/diags-examples.html > > > My suspicion is that this was generated by something in the codebase - > if so does anyone know the command of the top of their head? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjg at openjdk.org Mon Oct 3 20:24:21 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 3 Oct 2022 20:24:21 GMT Subject: Integrated: JDK-8294726: Update URLs in minefield tests In-Reply-To: <8RSwPoHXslUhF1a3uYRqwjlz86pdxYS0QfPCBJi37B8=.f102fdbc-b733-458d-9f66-130ccf0c9eb3@github.com> References: <8RSwPoHXslUhF1a3uYRqwjlz86pdxYS0QfPCBJi37B8=.f102fdbc-b733-458d-9f66-130ccf0c9eb3@github.com> Message-ID: On Mon, 3 Oct 2022 17:59:06 GMT, Jonathan Gibbons wrote: > Please review a small change to address a suggestion that was accidentally overlooked in PR #10366 > > The URLs are changed to use `https://git.openjdk.org/` This pull request has now been integrated. Changeset: 090cdfc7 Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/090cdfc7a2e280c620a0926512fb67f0ce7f3c21 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod 8294726: Update URLs in minefield tests Reviewed-by: darcy, iris ------------- PR: https://git.openjdk.org/jdk/pull/10542 From darcy at openjdk.org Mon Oct 3 20:37:11 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 3 Oct 2022 20:37:11 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. 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 11 additional commits since the last revision: - Update accessibility URLs. - Merge branch 'master' into JDK-8294618 - Update make directory. - Update doc directory files. - Update hg URLs to git. - Merge branch 'master' into JDK-8294618 - http -> https - Undo manpage update. - Update copyright. - Revert unintended update to binary file. - ... and 1 more: https://git.openjdk.org/jdk/compare/7a8d31f3...4055f1a6 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/224ed7a0..4055f1a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=06-07 Stats: 5510 lines in 75 files changed: 3554 ins; 1669 del; 287 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Mon Oct 3 20:37:14 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 3 Oct 2022 20:37:14 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7] In-Reply-To: References: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com> Message-ID: On Mon, 3 Oct 2022 20:04:38 GMT, Phil Race wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Update make directory. > > src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 36: > >> 34: * https://git.openjdk.org/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c >> 35: * >> 36: * Also note that the API is used in the jaccessinspector and jaccesswalker tools. > > The problem with this is, is that anyone who gets JDK 20 (or 21 the LTS) will be forever more then pointed at the OpenJDK "tip" and if we made an incompatible ABI change, that would be a problem. > At this point I'd prefer that this be updated to point to JDK 17, as in > https://github.com/openjdk/jdk17/blob/master/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp > So it is a defined, known, compatible version. Updated to refer to JDK 17 specifically. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From sadayapalam at openjdk.org Tue Oct 4 06:29:34 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Tue, 4 Oct 2022 06:29:34 GMT Subject: RFR: 8292975: javac produces code that crashes with LambdaConversionException Message-ID: Ensure that when functional interface parameters involve intersection types, we fold the method reference to a lambda expression to work around limitations/constraints in lambda meta factory. Also fixes JDK-8269983 ------------- Commit messages: - 8292975: javac produces code that crashes with LambdaConversionException Changes: https://git.openjdk.org/jdk/pull/10548/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10548&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292975 Stats: 107 lines in 3 files changed: 106 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10548.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10548/head:pull/10548 PR: https://git.openjdk.org/jdk/pull/10548 From hannesw at openjdk.org Tue Oct 4 14:12:56 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 4 Oct 2022 14:12:56 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors Message-ID: Please review a a new feature to allow `@link`, `@linkplain` and `@see` tags to link to user-defined URL fragments in the generated documentation (including in auxiliary `doc-files` documentation). The changes in module `jdk.compiler` are mostly cleanup changes retained from earlier versions of the patch. The current proposed version uses a very simple change in `ReferenceParser` to avoid parsing the member name section of the reference when a non-member fragment is encountered. The implementation almost exactly follows the plan described in the JBS issue, except that it supports both ways to mark a user defined fragment: - a fragment name containing a `-` character - a fragment starting with double `##` The reason for supporting both ways is that the first option practically imposes itself ('-' not being a valid character for member names and auto-generated header ids making use of this), while the second is necessary to support the existing `id` attributes in JDK and other sources which should be usable with this feature without needing to be changed. Links to auxiliary documentation files follow the same rules. They are recognized by looking for `/` characters in the fragment name. This means that ordinary `id` attribute values must not contain `/`, while auxiliary file paths must contain a `/` character. Both restrictions should be easy to sustain. One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. In contrast to program element names a fragment name does usually not make a good human readable name. The solution is to use the fragment name as default label text. I expect that the feature will usually be used with a user provided label. The CSR for this feature is still unfinished, I hope to get it ready for review within the next few days. ------------- Commit messages: - Remove trailing whitespace - Only support double hash as fragment/path indicator - JDK-8200337: Generalize see and link tags for user-defined anchors Changes: https://git.openjdk.org/jdk/pull/10395/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10395&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8200337 Stats: 388 lines in 10 files changed: 333 ins; 16 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/10395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10395/head:pull/10395 PR: https://git.openjdk.org/jdk/pull/10395 From jjg at openjdk.org Tue Oct 4 14:12:56 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 4 Oct 2022 14:12:56 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 16:51:56 GMT, Hannes Walln?fer wrote: > One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. Generate an error if no label is provided. Now is the time to set the rules. ------------- PR: https://git.openjdk.org/jdk/pull/10395 From jvernee at openjdk.org Tue Oct 4 17:33:05 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 4 Oct 2022 17:33:05 GMT Subject: RFR: 8294368: Java incremental builds broken on Windows after JDK-8293116 Message-ID: This patch fixes incremental builds on Windows. There are 2 parts to this: 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file. 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue. Testing: tested this manually by doing the following: 1. `make clean` 2. `make images` 3. put garbage in one of the files in `java.base` 4. `make images` (incremental) 5. verify that the build reported an error 6. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` 7. revert the changes of 3, and do the same for another file 8. `make images` (incremental) 9. verify that the build reported an error 10. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` 11. remove garbage from file modified by 9 again 12. `make images` (incremental) 13. verify that build succeeds as in 2 I've tested the build on Windows and Linux (WSL) using the above steps. ------------- Commit messages: - review comments - tweak comment in fixpath - fix windows incremental builds Changes: https://git.openjdk.org/jdk/pull/10560/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10560&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294368 Stats: 47 lines in 4 files changed: 39 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10560.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10560/head:pull/10560 PR: https://git.openjdk.org/jdk/pull/10560 From erikj at openjdk.org Tue Oct 4 17:33:10 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 4 Oct 2022 17:33:10 GMT Subject: RFR: 8294368: Java incremental builds broken on Windows after JDK-8293116 In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee wrote: > This patch fixes incremental builds on Windows. > > There are 2 parts to this: > 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file. > 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue. > > Testing: > tested this manually by doing the following: > 1. `make clean` > 2. `make images` > 3. put garbage in one of the files in `java.base` > 4. `make images` (incremental) > 5. verify that the build reported an error > 6. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` > 7. revert the changes of 3, and do the same for another file > 8. `make images` (incremental) > 9. verify that the build reported an error > 10. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` > 11. remove garbage from file modified by 9 again > 12. `make images` (incremental) > 13. verify that build succeeds as in 2 > > I've tested the build on Windows and Linux (WSL) using the above steps. This looks like a good fix. I would probably have done it slightly differently to avoid the redundant copy when it's not needed, but I think this is good enough. Thanks for fixing it! make/common/JavaCompilation.gmk line 473: > 471: $$(eval $$(call ListPathsSafely, $1_MODFILES, $$($1_MODFILELIST))) > 472: > 473: $$($1_MODFILELIST_FIXED): $$($1_MODFILELIST) Could you add a comment about why this is needed? make/common/MakeBase.gmk line 449: > 447: FixPath = \ > 448: $(strip $(subst \,\\, $(shell $(FIXPATH_BASE) print $(patsubst $(FIXPATH), , $1)))) > 449: FixPathFile = \ Could you add a comment on what FixPathFile does exactly? make/scripts/fixpath.sh line 361: > 359: outfile="$2" > 360: if [[ -e $outfile ]] ; then > 361: rm $outfile Please try to match indent length with the rest of the file. ------------- PR: https://git.openjdk.org/jdk/pull/10560 From jvernee at openjdk.org Tue Oct 4 17:33:11 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 4 Oct 2022 17:33:11 GMT Subject: RFR: 8294368: Java incremental builds broken on Windows after JDK-8293116 In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee wrote: > This patch fixes incremental builds on Windows. > > There are 2 parts to this: > 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file. > 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue. > > Testing: > tested this manually by doing the following: > 1. `make clean` > 2. `make images` > 3. put garbage in one of the files in `java.base` > 4. `make images` (incremental) > 5. verify that the build reported an error > 6. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` > 7. revert the changes of 3, and do the same for another file > 8. `make images` (incremental) > 9. verify that the build reported an error > 10. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` > 11. remove garbage from file modified by 9 again > 12. `make images` (incremental) > 13. verify that build succeeds as in 2 > > I've tested the build on Windows and Linux (WSL) using the above steps. Thanks for the review, I've address your comments (https://github.com/openjdk/jdk/pull/10560/commits/35cc2269be8d69841f5641396cece5a1b0c1b2a3). WRT the redundant copy. I wanted to avoid the use site having to have some `if` that checks whether we're running on Windows to decide which file `$1_COMPILE_TARGET` should depend on. Copying allows always depending on the fixed file. ------------- PR: https://git.openjdk.org/jdk/pull/10560 From jvernee at openjdk.org Tue Oct 4 17:33:13 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 4 Oct 2022 17:33:13 GMT Subject: RFR: 8294368: Java incremental builds broken on Windows after JDK-8293116 In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 16:56:52 GMT, Erik Joelsson wrote: >> This patch fixes incremental builds on Windows. >> >> There are 2 parts to this: >> 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file. >> 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue. >> >> Testing: >> tested this manually by doing the following: >> 1. `make clean` >> 2. `make images` >> 3. put garbage in one of the files in `java.base` >> 4. `make images` (incremental) >> 5. verify that the build reported an error >> 6. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` >> 7. revert the changes of 3, and do the same for another file >> 8. `make images` (incremental) >> 9. verify that the build reported an error >> 10. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` >> 11. remove garbage from file modified by 9 again >> 12. `make images` (incremental) >> 13. verify that build succeeds as in 2 >> >> I've tested the build on Windows and Linux (WSL) using the above steps. > > make/scripts/fixpath.sh line 361: > >> 359: outfile="$2" >> 360: if [[ -e $outfile ]] ; then >> 361: rm $outfile > > Please try to match indent length with the rest of the file. Looks like some tabs snuck in. Fixed now ------------- PR: https://git.openjdk.org/jdk/pull/10560 From erikj at openjdk.org Tue Oct 4 17:58:32 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 4 Oct 2022 17:58:32 GMT Subject: RFR: 8294368: Java incremental builds broken on Windows after JDK-8293116 In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee wrote: > This patch fixes incremental builds on Windows. > > There are 2 parts to this: > 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file. > 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue. > > Testing: > tested this manually by doing the following: > 1. `make clean` > 2. `make images` > 3. put garbage in one of the files in `java.base` > 4. `make images` (incremental) > 5. verify that the build reported an error > 6. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` > 7. revert the changes of 3, and do the same for another file > 8. `make images` (incremental) > 9. verify that the build reported an error > 10. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` > 11. remove garbage from file modified by 9 again > 12. `make images` (incremental) > 13. verify that build succeeds as in 2 > > I've tested the build on Windows and Linux (WSL) using the above steps. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10560 From erikj at openjdk.org Tue Oct 4 17:58:33 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 4 Oct 2022 17:58:33 GMT Subject: RFR: 8294368: Java incremental builds broken on Windows after JDK-8293116 In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 17:25:07 GMT, Jorn Vernee wrote: > WRT the redundant copy. I wanted to avoid the use site having to have some `if` that checks whether we're running on Windows to decide which file `$1_COMPILE_TARGET` should depend on. Copying allows always depending on the fixed file. You are indeed correct and having a single code path is also a desirable attribute. Had this been in a more performance sensitive location, I would have still preferred to avoid the copy, but I think once per Java compilation unit is rare enough to not be an issue, especially since it's just unnecessary on non-windows. ------------- PR: https://git.openjdk.org/jdk/pull/10560 From cjplummer at openjdk.org Tue Oct 4 18:23:32 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 4 Oct 2022 18:23:32 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 15:32:11 GMT, Michael Ernst wrote: > The title was edited by someone other than me, as you can see from the PR history. The PR title needs to match the CR synopsis, so update the CR first, and then update the PR. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From prr at openjdk.org Tue Oct 4 18:42:44 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 4 Oct 2022 18:42:44 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8] In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 20:37:11 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > 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 11 additional commits since the last revision: > > - Update accessibility URLs. > - Merge branch 'master' into JDK-8294618 > - Update make directory. > - Update doc directory files. > - Update hg URLs to git. > - Merge branch 'master' into JDK-8294618 > - http -> https > - Undo manpage update. > - Update copyright. > - Revert unintended update to binary file. > - ... and 1 more: https://git.openjdk.org/jdk/compare/571e4932...4055f1a6 Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10501 From jjg at openjdk.org Tue Oct 4 23:11:52 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 4 Oct 2022 23:11:52 GMT Subject: RFR: JDK-8294546: document where javac differs when invoked via launcher and ToolProvider Message-ID: <7iYgg04awBQOW5JQ_ZgsNoZrEFharttH4Ks-NXrD3V0=.79f28a24-44a4-41af-a952-229f111a5727@github.com> Please review a doc-only change to specify the differences between using different ways to invoke javac. ------------- Commit messages: - JDK-8294546: document where javac differs when invoked via launcher and ToolProvider Changes: https://git.openjdk.org/jdk/pull/10566/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10566&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294546 Stats: 75 lines in 1 file changed: 75 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10566.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10566/head:pull/10566 PR: https://git.openjdk.org/jdk/pull/10566 From jjg at openjdk.org Wed Oct 5 01:16:26 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 5 Oct 2022 01:16:26 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 16:51:56 GMT, Hannes Walln?fer wrote: >One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. In contrast to program element names a fragment name does usually not make a good human readable name. The solution is to use the fragment name as default label text. I expect that the feature will usually be used with a user provided label. There's cognitive dissonance here. 1. a fragment name does usually not make a good human readable name 2. the solution is to use the fragment name At a minimum, we should give a warning, or even an error. We can use the `TagletWriterImpl.invalidTagOutput` to display something inline in the page. We should consider updating the spec to require that a label is given. ------------- PR: https://git.openjdk.org/jdk/pull/10395 From ihse at openjdk.org Wed Oct 5 07:43:19 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 5 Oct 2022 07:43:19 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8] In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 20:37:11 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > 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 11 additional commits since the last revision: > > - Update accessibility URLs. > - Merge branch 'master' into JDK-8294618 > - Update make directory. > - Update doc directory files. > - Update hg URLs to git. > - Merge branch 'master' into JDK-8294618 > - http -> https > - Undo manpage update. > - Update copyright. > - Revert unintended update to binary file. > - ... and 1 more: https://git.openjdk.org/jdk/compare/72d7bf5d...4055f1a6 Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10501 From djelinski at openjdk.org Wed Oct 5 07:49:25 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 5 Oct 2022 07:49:25 GMT Subject: RFR: 8294368: Java incremental builds broken on Windows after JDK-8293116 In-Reply-To: References: Message-ID: <2cA71Zn88pojIuGyFBshPY0wL9RiNs9djzy_KMvkNdc=.491ddeb4-b3f0-432d-856a-2069603329a4@github.com> On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee wrote: > This patch fixes incremental builds on Windows. > > There are 2 parts to this: > 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file. > 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue. > > Testing: > tested this manually by doing the following: > 1. `make clean` > 2. `make images` > 3. put garbage in one of the files in `java.base` > 4. `make images` (incremental) > 5. verify that the build reported an error > 6. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` > 7. revert the changes of 3, and do the same for another file > 8. `make images` (incremental) > 9. verify that the build reported an error > 10. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` > 11. remove garbage from file modified by 9 again > 12. `make images` (incremental) > 13. verify that build succeeds as in 2 > > I've tested the build on Windows and Linux (WSL) using the above steps. Also verified that: - changes to public interface trigger full recompilation - changes that do not affect public interface cause minimal recompilation. This was on Cygwin. LGTM! ------------- Marked as reviewed by djelinski (Committer). PR: https://git.openjdk.org/jdk/pull/10560 From jlahoda at openjdk.org Wed Oct 5 10:13:16 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 5 Oct 2022 10:13:16 GMT Subject: RFR: 8294368: Java incremental builds broken on Windows after JDK-8293116 In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee wrote: > This patch fixes incremental builds on Windows. > > There are 2 parts to this: > 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file. > 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue. > > Testing: > tested this manually by doing the following: > 1. `make clean` > 2. `make images` > 3. put garbage in one of the files in `java.base` > 4. `make images` (incremental) > 5. verify that the build reported an error > 6. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` > 7. revert the changes of 3, and do the same for another file > 8. `make images` (incremental) > 9. verify that the build reported an error > 10. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` > 11. remove garbage from file modified by 9 again > 12. `make images` (incremental) > 13. verify that build succeeds as in 2 > > I've tested the build on Windows and Linux (WSL) using the above steps. Thanks a lot for fixing this, and sorry for trouble! ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.org/jdk/pull/10560 From jvernee at openjdk.org Wed Oct 5 10:29:30 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 5 Oct 2022 10:29:30 GMT Subject: Integrated: 8294368: Java incremental builds broken on Windows after JDK-8293116 In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee wrote: > This patch fixes incremental builds on Windows. > > There are 2 parts to this: > 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file. > 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue. > > Testing: > tested this manually by doing the following: > 1. `make clean` > 2. `make images` > 3. put garbage in one of the files in `java.base` > 4. `make images` (incremental) > 5. verify that the build reported an error > 6. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` > 7. revert the changes of 3, and do the same for another file > 8. `make images` (incremental) > 9. verify that the build reported an error > 10. verify the contents of `\jdk\modules\java.base_the.java.base_batch.modfiles.fixed` > 11. remove garbage from file modified by 9 again > 12. `make images` (incremental) > 13. verify that build succeeds as in 2 > > I've tested the build on Windows and Linux (WSL) using the above steps. This pull request has now been integrated. Changeset: 8ebebbce Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/8ebebbce32c7021cc0983dece4bb2644c79e64aa Stats: 47 lines in 4 files changed: 39 ins; 0 del; 8 mod 8294368: Java incremental builds broken on Windows after JDK-8293116 Reviewed-by: erikj, djelinski, jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/10560 From mbaesken at openjdk.org Wed Oct 5 11:11:17 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 5 Oct 2022 11:11:17 GMT Subject: RFR: JDK-8294840: langtools OptionalDependencyTest.java use File.pathSeparator Message-ID: The test/langtools/tools/jdeps/optionalDependency/OptionalDependencyTest.java: introduced with 8293701 needs to use File.pathSeparator instead of ":" to work on all platforms. ------------- Commit messages: - use File.pathSeparator in OptionalDependencyTest Changes: https://git.openjdk.org/jdk/pull/10572/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10572&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294840 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10572.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10572/head:pull/10572 PR: https://git.openjdk.org/jdk/pull/10572 From alanb at openjdk.org Wed Oct 5 12:44:16 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 5 Oct 2022 12:44:16 GMT Subject: RFR: JDK-8294840: langtools OptionalDependencyTest.java use File.pathSeparator In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 11:01:35 GMT, Matthias Baesken wrote: > The test/langtools/tools/jdeps/optionalDependency/OptionalDependencyTest.java: > introduced with 8293701 needs to use File.pathSeparator instead of ":" to work on all platforms. This looks okay and I assume you'll test this on both Windows and some other platform before integrating. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/10572 From aivanov at openjdk.org Wed Oct 5 13:27:29 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 5 Oct 2022 13:27:29 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Changes requested by aivanov (Reviewer). src/hotspot/share/opto/memnode.cpp line 2365: > 2363: if (x != this) return x; > 2364: > 2365: // Take apart the address into an oop and offset. ?and _an_ offset?? src/java.xml/share/classes/org/w3c/dom/Document.java line 293: > 291: * systemId, and notationName attributes are > 292: * copied. If a deep import is requested, the descendants > 293: * of the source Entity are recursively imported and This class may come from a 3rd party library. Anyone from `java.xml` can confirm it? test/hotspot/jtreg/vmTestbase/nsk/share/locks/DeadlockMaker.java line 31: > 29: /* > 30: * Class used to create deadlocked threads. It is possible create 2 or more deadlocked thread, also > 31: * is possible to specify resource of which type should lock each deadlocked thread Suggestion: * it is possible to specify resource of which type should lock each deadlocked thread It doesn't sound right without _?it?_. test/jdk/com/sun/jdi/connect/spi/GeneratedConnectors.java line 28: > 26: * @summary Unit test for "Pluggable Connectors and Transports" feature. > 27: * > 28: * When a transport service is deployed the virtual machine Suggestion: * When a transport service is deployed, the virtual machine Let's add a comma for clarity. test/jdk/java/security/testlibrary/SimpleOCSPServer.java line 445: > 443: > 444: /** > 445: * Check the status database for revocation information on one or more Suggestion: * Check the status database for revocation information of one or more test/jdk/sun/jvmstat/testlibrary/utils.sh line 181: > 179: if [ $? -eq 0 ] > 180: then > 181: # it's still lingering, now it is hard Suggestion: # it's still lingering, now hit it hard ------------- PR: https://git.openjdk.org/jdk/pull/10029 From aivanov at openjdk.org Wed Oct 5 14:17:13 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 5 Oct 2022 14:17:13 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos I agree with everyone who said the PR should be broken to smaller pieces so that it touches code / tests in one or two packages, modules. It would be easier to review, you would need to get an approval from reviewers in a one or two specific areas. At this time, this PR touches files in 11 areas according the number of labels which correspond to a specific mailing list where discussions for the area are held. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From darcy at openjdk.org Wed Oct 5 16:39:20 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 5 Oct 2022 16:39:20 GMT Subject: RFR: JDK-8294546: document where javac differs when invoked via launcher and ToolProvider In-Reply-To: <7iYgg04awBQOW5JQ_ZgsNoZrEFharttH4Ks-NXrD3V0=.79f28a24-44a4-41af-a952-229f111a5727@github.com> References: <7iYgg04awBQOW5JQ_ZgsNoZrEFharttH4Ks-NXrD3V0=.79f28a24-44a4-41af-a952-229f111a5727@github.com> Message-ID: On Tue, 4 Oct 2022 23:06:41 GMT, Jonathan Gibbons wrote: > Please review a doc-only change to specify the differences between using different ways to invoke javac. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10566 From darcy at openjdk.org Wed Oct 5 16:39:32 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 5 Oct 2022 16:39:32 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v9] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. 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 JDK-8294618 - Update accessibility URLs. - Merge branch 'master' into JDK-8294618 - Update make directory. - Update doc directory files. - Update hg URLs to git. - Merge branch 'master' into JDK-8294618 - http -> https - Undo manpage update. - Update copyright. - ... and 2 more: https://git.openjdk.org/jdk/compare/8aa24fec...eba2bd4b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/4055f1a6..eba2bd4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=07-08 Stats: 1452 lines in 87 files changed: 912 ins; 312 del; 228 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Wed Oct 5 16:52:27 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 5 Oct 2022 16:52:27 GMT Subject: Integrated: JDK-8294618: Update openjdk.java.net => openjdk.org In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy wrote: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. This pull request has now been integrated. Changeset: 536c9a51 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/536c9a512ea90d97a1ae5310453410d55db98bdd Stats: 128 lines in 45 files changed: 0 ins; 0 del; 128 mod 8294618: Update openjdk.java.net => openjdk.org Reviewed-by: mikael, iris, joehw, prr, ihse ------------- PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Wed Oct 5 19:24:04 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 5 Oct 2022 19:24:04 GMT Subject: RFR: JDK-8294869: Correct failure of RemovedJDKInternals.java after JDK-8294618 Message-ID: Fix strings matches to updated strings. ------------- Commit messages: - JDK-8294869: Correct failure of RemovedJDKInternals.java after JDK-8294618 Changes: https://git.openjdk.org/jdk/pull/10580/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10580&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294869 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10580.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10580/head:pull/10580 PR: https://git.openjdk.org/jdk/pull/10580 From alanb at openjdk.org Wed Oct 5 19:24:04 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 5 Oct 2022 19:24:04 GMT Subject: RFR: JDK-8294869: Correct failure of RemovedJDKInternals.java after JDK-8294618 In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 19:17:22 GMT, Joe Darcy wrote: > Fix strings matches to updated strings. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10580 From azvegint at openjdk.org Wed Oct 5 19:24:05 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 5 Oct 2022 19:24:05 GMT Subject: RFR: JDK-8294869: Correct failure of RemovedJDKInternals.java after JDK-8294618 In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 19:17:22 GMT, Joe Darcy wrote: > Fix strings matches to updated strings. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10580 From darcy at openjdk.org Wed Oct 5 19:30:37 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 5 Oct 2022 19:30:37 GMT Subject: Integrated: JDK-8294869: Correct failure of RemovedJDKInternals.java after JDK-8294618 In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 19:17:22 GMT, Joe Darcy wrote: > Fix strings matches to updated strings. This pull request has now been integrated. Changeset: 0ec18382 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/0ec18382b74396eec0681f2fdf0dac40f8fe108b Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8294869: Correct failure of RemovedJDKInternals.java after JDK-8294618 Reviewed-by: alanb, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/10580 From hannesw at openjdk.org Thu Oct 6 09:16:37 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 6 Oct 2022 09:16:37 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors [v2] In-Reply-To: References: Message-ID: > Please review a a new feature to allow `@link`, `@linkplain` and `@see` tags to link to arbitrary URI fragments in the generated documentation (including in auxiliary `doc-files` documentation). > > The changes in module `jdk.compiler` are mostly cleanup changes retained from earlier versions of the patch. The current proposed version uses a very simple change in `ReferenceParser` to avoid parsing the member name section of the reference when a non-member fragment is encountered. > > The implementation introduces a new form of reference with a double hash mark (`##`) separator. This is a change from the previous implementation which also auto-recognized URI fragments and documentation paths by looking for `-` characters which are not allowed in member names. This feature was removed upon further consideration because it makes the feature more complex and less recognizable. > > Links to auxiliary documentation files follow the same rules. They are recognized by looking for `/` characters in the fragment name. This means that ordinary `id` attribute values must not contain `/`, while auxiliary file paths must contain a `/` character. Both restrictions should be easy to sustain. > > One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. In contrast to program element names a fragment name does usually not make a good human readable name. The solution is to use the fragment name as default label text. I expect that the feature will usually be used with a user provided label. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Require label for fragment and auxiliary doc references ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10395/files - new: https://git.openjdk.org/jdk/pull/10395/files/0a9561bf..47f85204 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10395&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10395&range=00-01 Stats: 78 lines in 3 files changed: 53 ins; 18 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10395/head:pull/10395 PR: https://git.openjdk.org/jdk/pull/10395 From hannesw at openjdk.org Thu Oct 6 09:23:30 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 6 Oct 2022 09:23:30 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors [v3] In-Reply-To: References: Message-ID: > Please review a a new feature to allow `@link`, `@linkplain` and `@see` tags to link to arbitrary URI fragments in the generated documentation (including in auxiliary `doc-files` documentation). > > The changes in module `jdk.compiler` are mostly cleanup changes retained from earlier versions of the patch. The current proposed version uses a very simple change in `ReferenceParser` to avoid parsing the member name section of the reference when a non-member fragment is encountered. > > The implementation introduces a new form of reference with a double hash mark (`##`) separator. This is a change from the previous implementation which also auto-recognized URI fragments and documentation paths by looking for `-` characters which are not allowed in member names. This feature was removed upon further consideration because it makes the feature more complex and less recognizable. > > Links to auxiliary documentation files follow the same rules. They are recognized by looking for `/` characters in the fragment name. This means that ordinary `id` attribute values must not contain `/`, while auxiliary file paths must contain a `/` character. Both restrictions should be easy to sustain. > > One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. In contrast to program element names a fragment name does usually not make a good human readable name. The solution is to use the fragment name as default label text. I expect that the feature will usually be used with a user provided label. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Add comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10395/files - new: https://git.openjdk.org/jdk/pull/10395/files/47f85204..e0d6f5e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10395&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10395&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10395/head:pull/10395 PR: https://git.openjdk.org/jdk/pull/10395 From dlsmith at openjdk.org Thu Oct 6 16:56:26 2022 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 6 Oct 2022 16:56:26 GMT Subject: RFR: 8292975: javac produces code that crashes with LambdaConversionException In-Reply-To: References: Message-ID: <4DHq3VK7ZKXGAT0K2BjFSHaSucCprZWHgvPX8h5Gm3U=.bbd6822c-c9fa-47c8-8459-50d39e5c8b45@github.com> On Tue, 4 Oct 2022 06:09:10 GMT, Srikanth Adayapalam wrote: > Ensure that when functional interface parameters involve intersection types, > we fold the method reference to a lambda expression to work around > limitations/constraints in lambda meta factory. > > Also fixes JDK-8269983 There may be some LambdaMetafactory changes coming, but not in the near future, and in the mean time, this should definitely be fixed?just a straightforward implementation bug, code not doing what it was intended to do. ------------- PR: https://git.openjdk.org/jdk/pull/10548 From dlsmith at openjdk.org Thu Oct 6 17:00:09 2022 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 6 Oct 2022 17:00:09 GMT Subject: RFR: 8292975: javac produces code that crashes with LambdaConversionException In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 06:09:10 GMT, Srikanth Adayapalam wrote: > Ensure that when functional interface parameters involve intersection types, > we fold the method reference to a lambda expression to work around > limitations/constraints in lambda meta factory. > > Also fixes JDK-8269983 Marked as reviewed by dlsmith (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/10548 From vromero at openjdk.org Thu Oct 6 18:27:07 2022 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 6 Oct 2022 18:27:07 GMT Subject: RFR: 8292975: javac produces code that crashes with LambdaConversionException In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 06:09:10 GMT, Srikanth Adayapalam wrote: > Ensure that when functional interface parameters involve intersection types, > we fold the method reference to a lambda expression to work around > limitations/constraints in lambda meta factory. > > Also fixes JDK-8269983 looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10548 From sadayapalam at openjdk.org Fri Oct 7 04:21:47 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Fri, 7 Oct 2022 04:21:47 GMT Subject: RFR: 8292975: javac produces code that crashes with LambdaConversionException In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 06:09:10 GMT, Srikanth Adayapalam wrote: > Ensure that when functional interface parameters involve intersection types, > we fold the method reference to a lambda expression to work around > limitations/constraints in lambda meta factory. > > Also fixes JDK-8269983 Thanks gentlemen! ------------- PR: https://git.openjdk.org/jdk/pull/10548 From sadayapalam at openjdk.org Fri Oct 7 04:23:29 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Fri, 7 Oct 2022 04:23:29 GMT Subject: Integrated: 8292975: javac produces code that crashes with LambdaConversionException In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 06:09:10 GMT, Srikanth Adayapalam wrote: > Ensure that when functional interface parameters involve intersection types, > we fold the method reference to a lambda expression to work around > limitations/constraints in lambda meta factory. > > Also fixes JDK-8269983 This pull request has now been integrated. Changeset: cf84c8ea Author: Srikanth Adayapalam URL: https://git.openjdk.org/jdk/commit/cf84c8eaf265255b49293650b3919f22e26d48a3 Stats: 107 lines in 3 files changed: 106 ins; 0 del; 1 mod 8292975: javac produces code that crashes with LambdaConversionException 8269983: BootstrapMethodError with method reference and intersection type Reviewed-by: dlsmith, vromero ------------- PR: https://git.openjdk.org/jdk/pull/10548 From alanb at openjdk.org Fri Oct 7 12:53:30 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 7 Oct 2022 12:53:30 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com> On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos src/java.se/share/data/jdwp/jdwp.spec line 101: > 99: "platform thread " > 100: "in the target VM. This includes platform threads created with the Thread " > 101: "API and all native threads attached to the target VM with JNI code." The spec for the JDWP AllThreads command was significantly reworded in Java 19 so this is where this typo crept in. We have JDK-8294672 tracking it to fix for Java 20, maybe you should take it? ------------- PR: https://git.openjdk.org/jdk/pull/10029 From hannesw at openjdk.org Fri Oct 7 13:51:23 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 7 Oct 2022 13:51:23 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors [v4] In-Reply-To: References: Message-ID: > Please review a a new feature to allow `@link`, `@linkplain` and `@see` tags to link to arbitrary URI fragments in the generated documentation (including in auxiliary `doc-files` documentation). > > The changes in module `jdk.compiler` are mostly cleanup changes retained from earlier versions of the patch. The current proposed version uses a very simple change in `ReferenceParser` to avoid parsing the member name section of the reference when a non-member fragment is encountered. > > The implementation introduces a new form of reference with a double hash mark (`##`) separator. This is a change from the previous implementation which also auto-recognized URI fragments and documentation paths by looking for `-` characters which are not allowed in member names. This feature was removed upon further consideration because it makes the feature more complex and less recognizable. > > Links to auxiliary documentation files follow the same rules. They are recognized by looking for `/` characters in the fragment name. This means that ordinary `id` attribute values must not contain `/`, while auxiliary file paths must contain a `/` character. Both restrictions should be easy to sustain. > > One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. In contrast to program element names a fragment name does usually not make a good human readable name. The solution is to use the fragment name as default label text. I expect that the feature will usually be used with a user provided label. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Remove aux doc file reference feature ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10395/files - new: https://git.openjdk.org/jdk/pull/10395/files/e0d6f5e7..d327ed76 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10395&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10395&range=02-03 Stats: 27 lines in 4 files changed: 0 ins; 23 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10395/head:pull/10395 PR: https://git.openjdk.org/jdk/pull/10395 From jjg at openjdk.org Tue Oct 11 14:58:27 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 11 Oct 2022 14:58:27 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors [v4] In-Reply-To: References: Message-ID: On Fri, 7 Oct 2022 13:51:23 GMT, Hannes Walln?fer wrote: >> Please review a a new feature to allow `@link`, `@linkplain` and `@see` tags to link to arbitrary URI fragments in the generated documentation (including in auxiliary `doc-files` documentation). >> >> The changes in module `jdk.compiler` are mostly cleanup changes retained from earlier versions of the patch. The current proposed version uses a very simple change in `ReferenceParser` to avoid parsing the member name section of the reference when a non-member fragment is encountered. >> >> The implementation introduces a new form of reference with a double hash mark (`##`) separator. This is a change from the previous implementation which also auto-recognized URI fragments and documentation paths by looking for `-` characters which are not allowed in member names. This feature was removed upon further consideration because it makes the feature more complex and less recognizable. >> >> Links to auxiliary documentation files follow the same rules. They are recognized by looking for `/` characters in the fragment name. This means that ordinary `id` attribute values must not contain `/`, while auxiliary file paths must contain a `/` character. Both restrictions should be easy to sustain. >> >> One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. In contrast to program element names a fragment name does usually not make a good human readable name. The solution is to use the fragment name as default label text. I expect that the feature will usually be used with a user provided label. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Remove aux doc file reference feature src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 417: > 415: // TODO: improve quality of parse to forbid bad constructions. > 416: @SuppressWarnings("fallthrough") > 417: protected DCReference reference(boolean allowMember) throws ParseException { Why has this been removed? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1234: > 1232: public DCTree parse(int pos) throws ParseException { > 1233: skipWhitespace(); > 1234: DCReference ref = reference(); You seem to be opening up the possibility that `@throws` can be followed by a member, which is a regression. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/ReferenceParser.java line 118: > 116: // A slash following a hash is part of a doc-file path, not a module separator > 117: slash = -1; > 118: } I thought we were backing off file references ... src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 490: > 488: } else if (refFragment != null && refFragment.startsWith("#")) { > 489: if (labelContent.isEmpty()) { > 490: // A non-empty label is required for fragment and auxiliary file links "auxiliary file links" ... ------------- PR: https://git.openjdk.org/jdk/pull/10395 From jjg at openjdk.org Tue Oct 11 15:04:23 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 11 Oct 2022 15:04:23 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors [v4] In-Reply-To: References: Message-ID: On Fri, 7 Oct 2022 13:51:23 GMT, Hannes Walln?fer wrote: >> Please review a a new feature to allow `@link`, `@linkplain` and `@see` tags to link to arbitrary URI fragments in the generated documentation (including in auxiliary `doc-files` documentation). >> >> The changes in module `jdk.compiler` are mostly cleanup changes retained from earlier versions of the patch. The current proposed version uses a very simple change in `ReferenceParser` to avoid parsing the member name section of the reference when a non-member fragment is encountered. >> >> The implementation introduces a new form of reference with a double hash mark (`##`) separator. This is a change from the previous implementation which also auto-recognized URI fragments and documentation paths by looking for `-` characters which are not allowed in member names. This feature was removed upon further consideration because it makes the feature more complex and less recognizable. >> >> Links to auxiliary documentation files follow the same rules. They are recognized by looking for `/` characters in the fragment name. This means that ordinary `id` attribute values must not contain `/`, while auxiliary file paths must contain a `/` character. Both restrictions should be easy to sustain. >> >> One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. In contrast to program element names a fragment name does usually not make a good human readable name. The solution is to use the fragment name as default label text. I expect that the feature will usually be used with a user provided label. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Remove aux doc file reference feature (repeating? after first message was lost...?) I primarily reviewed the `DocCommentParser` level of the code. Removing the `allowMember` parameter from the `reference` method seems like a retrograde step, since there are places where the method is called that require a specific kind of reference, such as requiring a type name after `@throws`. If anything you should honor the `TODO` that you deleted there, and upgrade the `boolean allowMember` parameter into some sort of enum set that allows a caller to specify the kinds of reference that are acceptable in any given syntactic position. After all, the new `##` syntax should only be permitted in `@see` and `{@link}` nodes. ------------- PR: https://git.openjdk.org/jdk/pull/10395 From cpovirk at google.com Tue Oct 11 19:17:31 2022 From: cpovirk at google.com (Chris Povirk) Date: Tue, 11 Oct 2022 15:17:31 -0400 Subject: Surprised that TYPE_USE annotations are accepted on `var` lambda parameters Message-ID: Hi, I was surprised to find that the following code is accepted by javac (as recently as jdk-20-ea+16): import static java.lang.annotation.ElementType.TYPE_USE; import java.lang.annotation.Target; class X { C c = (@Anno var o) -> {}; interface C { void c(Object o); } @Target(TYPE_USE) @interface Anno {} } Since type-use annotations are rejected on var local variables, I would have expected them to be rejected on var lambda parameters, too. As further support, I found that https://openjdk.org/jeps/323 specifically refers to the "uniformity" it produces between "local variables and lambda formals." Yes, the JEP gives an example of using a @NonNull annotation on a var lambda parameter. But the JEP also uses the annotation on a var local variable, so I think we're meant to conclude that it's a declaration annotation. I didn't find a clear statement either way in my browsing of the JLS. On the one hand, JLS 9.7.4 specifically forbids using type-use annotations with var only for local variables: "If the annotation appears before a void method declaration or a local variable declaration that uses var (?14.4), then there is no closest type." On the other hand, I don't think any of the JLS rules for finding the "closest type" would apply in the case of a var lambda parameter. For what it's worth, I haven't found any usages of type-use annotations on var lambda parameters in Google's codebase, with one exception: I found a javac test that uses a TYPE_USE+PARAMETER+LOCAL_VARIABLE annotation and verifies that it doesn't appear as a type-use annotation in the output. (Note that that's contrary to what happens with type-use annotations on *non*-var lambda parameters, which are copied to the generated synthetic method .) https://github.com/openjdk/jdk/blob/d362e16924913207b67b5650ad4cafb6ab019cb1/test/langtools/tools/javac/annotations/typeAnnotations/VariablesDeclaredWithVarTest.java#L76 Based on all that, my best guess is that type-use annotations probably "shouldn't" be accepted on var lambda parameters. I think that would be fine with us, too: The question came up as part of JSpecify nullness discussions, and the main point of discussion has been my surprise that the annotations are accepted today. Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Oct 12 14:32:43 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 12 Oct 2022 14:32:43 GMT Subject: RFR: 8295024: Cyclic constructor error is non-deterministic and inconsistent Message-ID: This patch addresses two related issues that cause javac's reporting of recursive constructor errors to be non-deterministic. The first issue is caused by the use of a `HashMap` when finding cycles in the graph of constructor invocations. This causes non-determinism in which constructor is identified as the "culprit" for the purposes of error reporting. The obvious fix here is to use a `LinkedHashMap` instead. The second problem is caused by how the error's source code location is found via `TreeInfo.diagnosticPositionFor()`. That method searches the AST for a node matching the constructor's `Symbol`, but both the constructor declaration and all of its invocations will match that `Symbol`, and so whichever of those happens first in the source code wins. The fix adds an optional filter parameter to `TreeInfo.diagnosticPositionFor()`, and then uses it to match only the constructor invocation. Reporting the invocation instead of the declaration is preferred because it provides more specific information about exactly how the recursion occurs. Put another way, when identifying a cycle in a graph, reporting an edge is more helpful than reporting a node. ------------- Commit messages: - 8295024: Cyclic constructor error is non-deterministic and inconsistent Changes: https://git.openjdk.org/jdk/pull/10679/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10679&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295024 Stats: 103 lines in 4 files changed: 76 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/10679.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10679/head:pull/10679 PR: https://git.openjdk.org/jdk/pull/10679 From vromero at openjdk.org Thu Oct 13 18:38:14 2022 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 13 Oct 2022 18:38:14 GMT Subject: RFR: 8295024: Cyclic constructor error is non-deterministic and inconsistent In-Reply-To: References: Message-ID: On Wed, 12 Oct 2022 14:22:40 GMT, Archie L. Cobbs wrote: > This patch addresses two related issues that cause javac's reporting of recursive constructor errors to be non-deterministic. > > The first issue is caused by the use of a `HashMap` when finding cycles in the graph of constructor invocations. This causes non-determinism in which constructor is identified as the "culprit" for the purposes of error reporting. The obvious fix here is to use a `LinkedHashMap` instead. > > The second problem is caused by how the error's source code location is found via `TreeInfo.diagnosticPositionFor()`. That method searches the AST for a node matching the constructor's `Symbol`, but both the constructor declaration and all of its invocations will match that `Symbol`, and so whichever of those happens first in the source code wins. > > The fix adds an optional filter parameter to `TreeInfo.diagnosticPositionFor()`, and then uses it to match only the constructor invocation. Reporting the invocation instead of the declaration is preferred because it provides more specific information about exactly how the recursion occurs. Put another way, when identifying a cycle in a graph, reporting an edge is more helpful than reporting a node. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3722: > 3720: if (ctor != null && (ctor.flags_field & ACYCLIC) == 0) { > 3721: if ((ctor.flags_field & LOCKED) != 0) { > 3722: log.error(TreeInfo.diagnosticPositionFor(ctor, tree, JCIdent.class::isInstance, false), here it would be preferable: + log.error(TreeInfo.diagnosticPositionFor(ctor, tree, t -> t.hasTag(IDENT), false), src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 713: > 711: } > 712: > 713: public static DiagnosticPosition diagnosticPositionFor(final Symbol sym, final JCTree tree, I would keep the original declaration and add an overloaded one with the new argument so that only clients using the new declaration get affected ------------- PR: https://git.openjdk.org/jdk/pull/10679 From vromero at openjdk.org Thu Oct 13 18:52:00 2022 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 13 Oct 2022 18:52:00 GMT Subject: RFR: 8295024: Cyclic constructor error is non-deterministic and inconsistent In-Reply-To: References: Message-ID: <9mWVJUP0ko6hU2Gd-G5GDz83-KwzNYVTORM0zBCL_dE=.d45095dd-1a5a-4339-bf44-7521ad52eff3@github.com> On Wed, 12 Oct 2022 14:22:40 GMT, Archie L. Cobbs wrote: > This patch addresses two related issues that cause javac's reporting of recursive constructor errors to be non-deterministic. > > The first issue is caused by the use of a `HashMap` when finding cycles in the graph of constructor invocations. This causes non-determinism in which constructor is identified as the "culprit" for the purposes of error reporting. The obvious fix here is to use a `LinkedHashMap` instead. > > The second problem is caused by how the error's source code location is found via `TreeInfo.diagnosticPositionFor()`. That method searches the AST for a node matching the constructor's `Symbol`, but both the constructor declaration and all of its invocations will match that `Symbol`, and so whichever of those happens first in the source code wins. > > The fix adds an optional filter parameter to `TreeInfo.diagnosticPositionFor()`, and then uses it to match only the constructor invocation. Reporting the invocation instead of the declaration is preferred because it provides more specific information about exactly how the recursion occurs. Put another way, when identifying a cycle in a graph, reporting an edge is more helpful than reporting a node. src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 744: > 742: final Predicate filter; > 743: > 744: DeclScanner(final Symbol sym, Predicate filter) { same here, better to keep the original declaration and add an overloaded one with the new argument, the old method can invoke the new one ------------- PR: https://git.openjdk.org/jdk/pull/10679 From vromero at openjdk.org Thu Oct 13 19:17:51 2022 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 13 Oct 2022 19:17:51 GMT Subject: RFR: 8295024: Cyclic constructor error is non-deterministic and inconsistent In-Reply-To: References: Message-ID: On Wed, 12 Oct 2022 14:22:40 GMT, Archie L. Cobbs wrote: > This patch addresses two related issues that cause javac's reporting of recursive constructor errors to be non-deterministic. > > The first issue is caused by the use of a `HashMap` when finding cycles in the graph of constructor invocations. This causes non-determinism in which constructor is identified as the "culprit" for the purposes of error reporting. The obvious fix here is to use a `LinkedHashMap` instead. > > The second problem is caused by how the error's source code location is found via `TreeInfo.diagnosticPositionFor()`. That method searches the AST for a node matching the constructor's `Symbol`, but both the constructor declaration and all of its invocations will match that `Symbol`, and so whichever of those happens first in the source code wins. > > The fix adds an optional filter parameter to `TreeInfo.diagnosticPositionFor()`, and then uses it to match only the constructor invocation. Reporting the invocation instead of the declaration is preferred because it provides more specific information about exactly how the recursion occurs. Put another way, when identifying a cycle in a graph, reporting an edge is more helpful than reporting a node. test/langtools/tools/javac/Diagnostics/8295024/T8295024.java line 5: > 3: * @bug 8295024 > 4: * @summary Cyclic constructor error is non-deterministic and inconsistent > 5: * @compile T8295024.java both the `@compile` line and the `@run` one can be removed, jtreg will do in this case what you expect ------------- PR: https://git.openjdk.org/jdk/pull/10679 From duke at openjdk.org Thu Oct 13 20:33:36 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 13 Oct 2022 20:33:36 GMT Subject: RFR: 8295024: Cyclic constructor error is non-deterministic and inconsistent [v2] In-Reply-To: References: Message-ID: > This patch addresses two related issues that cause javac's reporting of recursive constructor errors to be non-deterministic. > > The first issue is caused by the use of a `HashMap` when finding cycles in the graph of constructor invocations. This causes non-determinism in which constructor is identified as the "culprit" for the purposes of error reporting. The obvious fix here is to use a `LinkedHashMap` instead. > > The second problem is caused by how the error's source code location is found via `TreeInfo.diagnosticPositionFor()`. That method searches the AST for a node matching the constructor's `Symbol`, but both the constructor declaration and all of its invocations will match that `Symbol`, and so whichever of those happens first in the source code wins. > > The fix adds an optional filter parameter to `TreeInfo.diagnosticPositionFor()`, and then uses it to match only the constructor invocation. Reporting the invocation instead of the declaration is preferred because it provides more specific information about exactly how the recursion occurs. Put another way, when identifying a cycle in a graph, reporting an edge is more helpful than reporting a node. Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Apply several improvements suggested in review. - Add constructor & method variants to lessen impact on existing code. - Remove unnecessary @compile and @run tags from unit test. - Use hasTag(IDENT) instead of JCIdent::isInstance. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10679/files - new: https://git.openjdk.org/jdk/pull/10679/files/06577f1b..b7482f94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10679&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10679&range=00-01 Stats: 15 lines in 4 files changed: 7 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10679.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10679/head:pull/10679 PR: https://git.openjdk.org/jdk/pull/10679 From duke at openjdk.org Thu Oct 13 20:40:14 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 13 Oct 2022 20:40:14 GMT Subject: RFR: 8295024: Cyclic constructor error is non-deterministic and inconsistent In-Reply-To: References: Message-ID: On Wed, 12 Oct 2022 14:22:40 GMT, Archie L. Cobbs wrote: > This patch addresses two related issues that cause javac's reporting of recursive constructor errors to be non-deterministic. > > The first issue is caused by the use of a `HashMap` when finding cycles in the graph of constructor invocations. This causes non-determinism in which constructor is identified as the "culprit" for the purposes of error reporting. The obvious fix here is to use a `LinkedHashMap` instead. > > The second problem is caused by how the error's source code location is found via `TreeInfo.diagnosticPositionFor()`. That method searches the AST for a node matching the constructor's `Symbol`, but both the constructor declaration and all of its invocations will match that `Symbol`, and so whichever of those happens first in the source code wins. > > The fix adds an optional filter parameter to `TreeInfo.diagnosticPositionFor()`, and then uses it to match only the constructor invocation. Reporting the invocation instead of the declaration is preferred because it provides more specific information about exactly how the recursion occurs. Put another way, when identifying a cycle in a graph, reporting an edge is more helpful than reporting a node. Thanks for the helpful comments. They should be addressed in [b7482f9](https://github.com/openjdk/jdk/pull/10679/commits/b7482f949b95b1cff30b7b75f0e9d9a23773b71a) and the patch has gotten cleaner as a result. ------------- PR: https://git.openjdk.org/jdk/pull/10679 From vromero at openjdk.org Thu Oct 13 22:42:58 2022 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 13 Oct 2022 22:42:58 GMT Subject: RFR: 8295024: Cyclic constructor error is non-deterministic and inconsistent [v2] In-Reply-To: References: Message-ID: On Thu, 13 Oct 2022 20:33:36 GMT, Archie L. Cobbs wrote: >> This patch addresses two related issues that cause javac's reporting of recursive constructor errors to be non-deterministic. >> >> The first issue is caused by the use of a `HashMap` when finding cycles in the graph of constructor invocations. This causes non-determinism in which constructor is identified as the "culprit" for the purposes of error reporting. The obvious fix here is to use a `LinkedHashMap` instead. >> >> The second problem is caused by how the error's source code location is found via `TreeInfo.diagnosticPositionFor()`. That method searches the AST for a node matching the constructor's `Symbol`, but both the constructor declaration and all of its invocations will match that `Symbol`, and so whichever of those happens first in the source code wins. >> >> The fix adds an optional filter parameter to `TreeInfo.diagnosticPositionFor()`, and then uses it to match only the constructor invocation. Reporting the invocation instead of the declaration is preferred because it provides more specific information about exactly how the recursion occurs. Put another way, when identifying a cycle in a graph, reporting an edge is more helpful than reporting a node. > > Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Apply several improvements suggested in review. > > - Add constructor & method variants to lessen impact on existing code. > - Remove unnecessary @compile and @run tags from unit test. > - Use hasTag(IDENT) instead of JCIdent::isInstance. looks good to me ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10679 From sadayapalam at openjdk.org Fri Oct 14 04:24:53 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Fri, 14 Oct 2022 04:24:53 GMT Subject: RFR: 8295020: javac emits incorrect code for for-each on an intersection type. Message-ID: Eliminate needless casts and ensure invoked method is looked up against the appropriate receiver type ------------- Commit messages: - 8295020: javac emits incorrect code for for-each on an intersection type. Changes: https://git.openjdk.org/jdk/pull/10710/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10710&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295020 Stats: 88 lines in 2 files changed: 83 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10710.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10710/head:pull/10710 PR: https://git.openjdk.org/jdk/pull/10710 From sadayapalam at openjdk.org Fri Oct 14 04:24:54 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Fri, 14 Oct 2022 04:24:54 GMT Subject: RFR: 8295020: javac emits incorrect code for for-each on an intersection type. In-Reply-To: References: Message-ID: On Fri, 14 Oct 2022 04:16:33 GMT, Srikanth Adayapalam wrote: > Eliminate needless casts and ensure invoked method is looked up against the appropriate receiver type Notes for the reviewer: The loop from the test case viz: for (Object s : (MyIterable & Serializable) null) {} gets transformed by Lower into: for (Iterator i$ = ((Iterable)(Main$MyIterable & Serializable)null).iterator(); i$.hasNext(); ) { Object s = (Object)i$.next(); { } } This transformation is problematic in a couple of ways: The cast of the expression (Main$MyIterable & Serializable)null into (Iterable) is not required at all. After erasure the type of the intersection cast node is actually Main$MyIterable which is already an Iterable. As a matter of Gen#visitTypeCast correctly deduces this to be a redundant cast and does not emit a checkcast in the class file. The iterator() method to be invoked is looked up against the JCEnhancedForLoop#expr.type i.e from Main$MyIterable while the type of the receiver expression for the iterator() method invocation is the casted type of (Iterable)(Main$MyIterable & Serializable)null). As a result, the method com.sun.tools.javac.jvm.Gen#binaryQualifier((Symbol sym, Type site) attempts to coalesce the method iterator() (sym) as owned by Iterator (site) by calling com.sun.tools.javac.code.Symbol.MethodSymbol#clone which simply changes ownership of the method symbol iterator() without accommodating for descriptor difference that arises due to covariant return type. The fix comes in two parts: (a) Ensuring that a cast is inserted only when absolutely necessary and not just because JCEnhancedForLoop#expr.type happens to be an intersection type (b) Ensuring that where a type cast is inserted, the iterator() method is looked up against the modified receiver type. (An open question is whether MethodSymbol#clone should be fixed to not just rewire ownership, but also account for differences in descriptor - if deemed needed this can be followed up in a separate ticket.) ------------- PR: https://git.openjdk.org/jdk/pull/10710 From sadayapalam at openjdk.org Fri Oct 14 04:32:00 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Fri, 14 Oct 2022 04:32:00 GMT Subject: RFR: 8295020: javac emits incorrect code for for-each on an intersection type. In-Reply-To: References: Message-ID: On Fri, 14 Oct 2022 04:16:33 GMT, Srikanth Adayapalam wrote: > Eliminate needless casts and ensure invoked method is looked up against the appropriate receiver type src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3523: > 3521: Type eType = types.skipTypeVars(tree.expr.type, false); > 3522: tree.expr.type = types.erasure(eType); > 3523: if (eType.isCompound()) This check can needlessly insert casts - it should be irrelevant whether tree.expr.type is a compond type. A cast should be required only when the erased tree.expr.type is not an Iterable. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3531: > 3529: VarSymbol itvar = new VarSymbol(SYNTHETIC, names.fromString("i" + target.syntheticNameChar()), > 3530: types.erasure(syms.iteratorType), > 3531: currentMethodSym); The original code seems to be a convoluted way of declaring an Iterator. Replace with a simpler more direct expression ------------- PR: https://git.openjdk.org/jdk/pull/10710 From sadayapalam at openjdk.org Fri Oct 14 04:51:07 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Fri, 14 Oct 2022 04:51:07 GMT Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods [v2] In-Reply-To: References: Message-ID: <8j5v7aDgvXKcL8PFCQQErH-emG4QKDJsFUombBqEIG0=.c3eb2af7-7470-48a2-bde4-d257e3eca627@github.com> On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy wrote: >> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs. >> >> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks. > > 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 three additional commits since the last revision: > > - Update visitor; all langtools regression tests pass. > - Merge branch 'master' into JDK-8042981 > - JDK-8042981: Strip type annotations in Types' utility methods See also JDK-8281235 ------------- PR: https://git.openjdk.org/jdk/pull/8984 From mcimadamore at openjdk.org Fri Oct 14 10:14:07 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 14 Oct 2022 10:14:07 GMT Subject: RFR: 8295020: javac emits incorrect code for for-each on an intersection type. In-Reply-To: References: Message-ID: <911z_-aiQTgDaThmzsdqL8cSccc1B9MtgUoJ1ffPoNg=.dcb06247-9f9b-42c0-9b97-ac041122ad79@github.com> On Fri, 14 Oct 2022 04:16:33 GMT, Srikanth Adayapalam wrote: > Eliminate needless casts and ensure invoked method is looked up against the appropriate receiver type Marked as reviewed by mcimadamore (Reviewer). src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3521: > 3519: if (iterableType.getTypeArguments().nonEmpty()) > 3520: iteratorTarget = types.erasure(iterableType.getTypeArguments().head); > 3521: tree.expr.type = types.erasure(types.skipTypeVars(tree.expr.type, false)); Shouldn't types already be erased by now (Lower runs after TransTypes?) src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3523: > 3521: tree.expr.type = types.erasure(types.skipTypeVars(tree.expr.type, false)); > 3522: if (types.asSuper(tree.expr.type, syms.iterableType.tsym) == null) > 3523: tree.expr = make.TypeCast(types.erasure(iterableType), tree.expr); Can we use the `coerce` function here, which is used to conditionally add a cast if required? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3526: > 3524: Symbol iterator = lookupMethod(tree.expr.pos(), > 3525: names.iterator, > 3526: tree.expr.type, The real problem here is that the target type of the cast (which ends up in tree.expr.type) and the type used for the lookup in the old code (eType) diverge. The latter might still have references to the source type - e.g. in this case to the covariant MyIterable, so looking up a method there will result in an iterator of some unexpected type. This is not wrong per se, but it should be fixed one way or another (e.g. by always using Iterable, as you have done), or by correctly honoring the covariant type. A really unfortunate combination of issues here - there is a latent discrepancy of types (eType != tree.expr.type), but that only results in bugs when a cast to Iterable is added (which only happens for interaction types). ------------- PR: https://git.openjdk.org/jdk/pull/10710 From sadayapalam at openjdk.org Fri Oct 14 10:19:07 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Fri, 14 Oct 2022 10:19:07 GMT Subject: RFR: 8295020: javac emits incorrect code for for-each on an intersection type. In-Reply-To: <911z_-aiQTgDaThmzsdqL8cSccc1B9MtgUoJ1ffPoNg=.dcb06247-9f9b-42c0-9b97-ac041122ad79@github.com> References: <911z_-aiQTgDaThmzsdqL8cSccc1B9MtgUoJ1ffPoNg=.dcb06247-9f9b-42c0-9b97-ac041122ad79@github.com> Message-ID: On Fri, 14 Oct 2022 10:03:20 GMT, Maurizio Cimadamore wrote: >> Eliminate needless casts and ensure invoked method is looked up against the appropriate receiver type > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3521: > >> 3519: if (iterableType.getTypeArguments().nonEmpty()) >> 3520: iteratorTarget = types.erasure(iterableType.getTypeArguments().head); >> 3521: tree.expr.type = types.erasure(types.skipTypeVars(tree.expr.type, false)); > > Shouldn't types already be erased by now (Lower runs after TransTypes?) Perhaps (actually very likely). This transformation is just simplifying existing code. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3523: > >> 3521: tree.expr.type = types.erasure(types.skipTypeVars(tree.expr.type, false)); >> 3522: if (types.asSuper(tree.expr.type, syms.iterableType.tsym) == null) >> 3523: tree.expr = make.TypeCast(types.erasure(iterableType), tree.expr); > > Can we use the `coerce` function here, which is used to conditionally add a cast if required? Sure, I will check out that suggestion, Thanks ------------- PR: https://git.openjdk.org/jdk/pull/10710 From sadayapalam at openjdk.org Fri Oct 14 10:24:00 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Fri, 14 Oct 2022 10:24:00 GMT Subject: RFR: 8295020: javac emits incorrect code for for-each on an intersection type. In-Reply-To: <911z_-aiQTgDaThmzsdqL8cSccc1B9MtgUoJ1ffPoNg=.dcb06247-9f9b-42c0-9b97-ac041122ad79@github.com> References: <911z_-aiQTgDaThmzsdqL8cSccc1B9MtgUoJ1ffPoNg=.dcb06247-9f9b-42c0-9b97-ac041122ad79@github.com> Message-ID: <2YQvS3_RDfEEQH5DukApe5TTRskHz2ocKe78PALI6Bk=.6ce9d092-f195-4e63-a70f-a453c1de0cf3@github.com> On Fri, 14 Oct 2022 10:10:10 GMT, Maurizio Cimadamore wrote: >> Eliminate needless casts and ensure invoked method is looked up against the appropriate receiver type > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3526: > >> 3524: Symbol iterator = lookupMethod(tree.expr.pos(), >> 3525: names.iterator, >> 3526: tree.expr.type, > > The real problem here is that the target type of the cast (which ends up in tree.expr.type) and the type used for the lookup in the old code (eType) diverge. The latter might still have references to the source type - e.g. in this case to the covariant MyIterable, so looking up a method there will result in an iterator of some unexpected type. This is not wrong per se, but it should be fixed one way or another (e.g. by always using Iterable, as you have done), or by correctly honoring the covariant type. > > A really unfortunate combination of issues here - there is a latent discrepancy of types (eType != tree.expr.type), but that only results in bugs when a cast to Iterable is added (which only happens for interaction types). Actually it is not the case that we always lookup iterator() from Iterable. The test case shows two scenarios, one where iterator() comes from expr's erased type (MyIterable) and is called using invokevirtual & returns a covariant type (MyIterable.MyIterator) and another where iterator() comes from Iterable (expr's erased type casted), and will be called by invokeinterface and return Iterator. Right, what the patch is trying hard to avoid is the divergence. ------------- PR: https://git.openjdk.org/jdk/pull/10710 From vromero at openjdk.org Fri Oct 14 13:54:32 2022 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 14 Oct 2022 13:54:32 GMT Subject: RFR: 8295024: Cyclic constructor error is non-deterministic and inconsistent In-Reply-To: References: Message-ID: On Thu, 13 Oct 2022 20:31:55 GMT, Archie L. Cobbs wrote: >> This patch addresses two related issues that cause javac's reporting of recursive constructor errors to be non-deterministic. >> >> The first issue is caused by the use of a `HashMap` when finding cycles in the graph of constructor invocations. This causes non-determinism in which constructor is identified as the "culprit" for the purposes of error reporting. The obvious fix here is to use a `LinkedHashMap` instead. >> >> The second problem is caused by how the error's source code location is found via `TreeInfo.diagnosticPositionFor()`. That method searches the AST for a node matching the constructor's `Symbol`, but both the constructor declaration and all of its invocations will match that `Symbol`, and so whichever of those happens first in the source code wins. >> >> The fix adds an optional filter parameter to `TreeInfo.diagnosticPositionFor()`, and then uses it to match only the constructor invocation. Reporting the invocation instead of the declaration is preferred because it provides more specific information about exactly how the recursion occurs. Put another way, when identifying a cycle in a graph, reporting an edge is more helpful than reporting a node. > > Thanks for the helpful comments. They should be addressed in [b7482f9](https://github.com/openjdk/jdk/pull/10679/commits/b7482f949b95b1cff30b7b75f0e9d9a23773b71a) and the patch has gotten cleaner as a result. @archiecobbs please try integrating again, I just added the `sponsor` command. Thanks for fixing this! ------------- PR: https://git.openjdk.org/jdk/pull/10679 From duke at openjdk.org Fri Oct 14 13:56:07 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 14 Oct 2022 13:56:07 GMT Subject: Integrated: 8295024: Cyclic constructor error is non-deterministic and inconsistent In-Reply-To: References: Message-ID: On Wed, 12 Oct 2022 14:22:40 GMT, Archie L. Cobbs wrote: > This patch addresses two related issues that cause javac's reporting of recursive constructor errors to be non-deterministic. > > The first issue is caused by the use of a `HashMap` when finding cycles in the graph of constructor invocations. This causes non-determinism in which constructor is identified as the "culprit" for the purposes of error reporting. The obvious fix here is to use a `LinkedHashMap` instead. > > The second problem is caused by how the error's source code location is found via `TreeInfo.diagnosticPositionFor()`. That method searches the AST for a node matching the constructor's `Symbol`, but both the constructor declaration and all of its invocations will match that `Symbol`, and so whichever of those happens first in the source code wins. > > The fix adds an optional filter parameter to `TreeInfo.diagnosticPositionFor()`, and then uses it to match only the constructor invocation. Reporting the invocation instead of the declaration is preferred because it provides more specific information about exactly how the recursion occurs. Put another way, when identifying a cycle in a graph, reporting an edge is more helpful than reporting a node. This pull request has now been integrated. Changeset: 786ce1c2 Author: Archie L. Cobbs Committer: Vicente Romero URL: https://git.openjdk.org/jdk/commit/786ce1c27b1da6096ad820170263d6b354e0d41a Stats: 103 lines in 3 files changed: 81 ins; 0 del; 22 mod 8295024: Cyclic constructor error is non-deterministic and inconsistent Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/10679 From duke at openjdk.org Fri Oct 14 14:19:05 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 14 Oct 2022 14:19:05 GMT Subject: RFR: 8295024: Cyclic constructor error is non-deterministic and inconsistent In-Reply-To: References: Message-ID: On Fri, 14 Oct 2022 13:52:13 GMT, Vicente Romero wrote: >> Thanks for the helpful comments. They should be addressed in [b7482f9](https://github.com/openjdk/jdk/pull/10679/commits/b7482f949b95b1cff30b7b75f0e9d9a23773b71a) and the patch has gotten cleaner as a result. > > @archiecobbs please try integrating again, I just added the `sponsor` command. Thanks for fixing this! @vicente-romero-oracle, > @archiecobbs please try integrating again, I just added the sponsor command. Thanks for fixing this! I think the bot is smart enough to handle either ordering of `/integrate` and `/sponsor`. In any case it looks like it worked. Thanks for sponsoring! ------------- PR: https://git.openjdk.org/jdk/pull/10679 From duke at openjdk.org Fri Oct 14 16:38:38 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 14 Oct 2022 16:38:38 GMT Subject: RFR: 8043179: Lambda expression can mutate final field [v5] In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> Message-ID: <0Uq6J1xQ4j8YywZ5CdtrVXFdoYhATgP0M2It6cQw1IA=.137248f7-556a-45b2-859e-99ffbf8663e3@github.com> > (Description revised) > > JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime: > >> _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._ > > This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body. Archie L. Cobbs 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 six additional commits since the last revision: - Fix previously incorrect logic and update unit tests. - Merge remote-tracking branch 'upstream/master' into JDK-8043179 - Fix @author in test to match github username per instructions. - Move unit test into a more appropriate subdirectory. - Use /nodynamiccopyright/ for "golden file" test per instructions. - 8043179: Lambda expression can mutate final field ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10381/files - new: https://git.openjdk.org/jdk/pull/10381/files/b7bc0b6d..703573cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=03-04 Stats: 58115 lines in 1630 files changed: 33001 ins; 16475 del; 8639 mod Patch: https://git.openjdk.org/jdk/pull/10381.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381 PR: https://git.openjdk.org/jdk/pull/10381 From sadayapalam at openjdk.org Mon Oct 17 04:36:45 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Mon, 17 Oct 2022 04:36:45 GMT Subject: RFR: 8295020: javac emits incorrect code for for-each on an intersection type. [v2] In-Reply-To: References: Message-ID: > Eliminate needless casts and ensure invoked method is looked up against the appropriate receiver type Srikanth Adayapalam 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 three additional commits since the last revision: - Merge branch 'master' into JDK-8295020 - Merge branch 'master' into JDK-8295020 - 8295020: javac emits incorrect code for for-each on an intersection type. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10710/files - new: https://git.openjdk.org/jdk/pull/10710/files/ea162848..2ee16e16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10710&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10710&range=00-01 Stats: 2382 lines in 57 files changed: 1226 ins; 785 del; 371 mod Patch: https://git.openjdk.org/jdk/pull/10710.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10710/head:pull/10710 PR: https://git.openjdk.org/jdk/pull/10710 From sadayapalam at openjdk.org Mon Oct 17 05:31:01 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Mon, 17 Oct 2022 05:31:01 GMT Subject: RFR: 8295020: javac emits incorrect code for for-each on an intersection type. [v2] In-Reply-To: References: <911z_-aiQTgDaThmzsdqL8cSccc1B9MtgUoJ1ffPoNg=.dcb06247-9f9b-42c0-9b97-ac041122ad79@github.com> Message-ID: On Fri, 14 Oct 2022 10:16:23 GMT, Srikanth Adayapalam wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3521: >> >>> 3519: if (iterableType.getTypeArguments().nonEmpty()) >>> 3520: iteratorTarget = types.erasure(iterableType.getTypeArguments().head); >>> 3521: tree.expr.type = types.erasure(types.skipTypeVars(tree.expr.type, false)); >> >> Shouldn't types already be erased by now (Lower runs after TransTypes?) > > Perhaps (actually very likely). This transformation is just simplifying existing code. > Shouldn't types already be erased by now (Lower runs after TransTypes?) Consider this case: > void f(T t) { for (String s : t) System.out.println(s); } and the line of code in Lower that reads: tree.expr.type = types.erasure(types.skipTypeVars(tree.expr.type, false)); types.skipTypeVars(tree.expr.type, false) evaluates to: java.lang.Object&A&B and so the erasure call is required. ------------- PR: https://git.openjdk.org/jdk/pull/10710 From sadayapalam at openjdk.org Mon Oct 17 05:50:05 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Mon, 17 Oct 2022 05:50:05 GMT Subject: RFR: 8295020: javac emits incorrect code for for-each on an intersection type. [v3] In-Reply-To: References: Message-ID: > Eliminate needless casts and ensure invoked method is looked up against the appropriate receiver type Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision: Incorporate review comments from Maurizio (Thanks!) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10710/files - new: https://git.openjdk.org/jdk/pull/10710/files/2ee16e16..f3319aa8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10710&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10710&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10710.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10710/head:pull/10710 PR: https://git.openjdk.org/jdk/pull/10710 From sadayapalam at openjdk.org Mon Oct 17 07:45:02 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Mon, 17 Oct 2022 07:45:02 GMT Subject: Integrated: 8295020: javac emits incorrect code for for-each on an intersection type. In-Reply-To: References: Message-ID: On Fri, 14 Oct 2022 04:16:33 GMT, Srikanth Adayapalam wrote: > Eliminate needless casts and ensure invoked method is looked up against the appropriate receiver type This pull request has now been integrated. Changeset: cf07eaeb Author: Srikanth Adayapalam URL: https://git.openjdk.org/jdk/commit/cf07eaeb9291da725181832b8bb1dc54957ba886 Stats: 91 lines in 2 files changed: 85 ins; 2 del; 4 mod 8295020: javac emits incorrect code for for-each on an intersection type. Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/10710 From jlahoda at openjdk.org Mon Oct 17 09:41:54 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 17 Oct 2022 09:41:54 GMT Subject: RFR: 8295176: some langtools test pollutes source tree Message-ID: The `ReleaseOptionThroughAPI.java` test compiles another test source, `ReleaseOption.java`. But it does not specify the output directory, so javac generates the classfile next to the source files into the source directory, causing trouble. The proposed fix is to add `-d .` to the test, so that the classfile is not generated into the working directory. ------------- Commit messages: - 8295176: some langtools test pollutes source tree Changes: https://git.openjdk.org/jdk/pull/10724/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10724&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295176 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10724.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10724/head:pull/10724 PR: https://git.openjdk.org/jdk/pull/10724 From sadayapalam at openjdk.org Mon Oct 17 10:14:12 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Mon, 17 Oct 2022 10:14:12 GMT Subject: RFR: 8295176: some langtools test pollutes source tree In-Reply-To: References: Message-ID: On Mon, 17 Oct 2022 09:35:40 GMT, Jan Lahoda wrote: > The `ReleaseOptionThroughAPI.java` test compiles another test source, `ReleaseOption.java`. But it does not specify the output directory, so javac generates the classfile next to the source files into the source directory, causing trouble. > > The proposed fix is to add `-d .` to the test, so that the classfile is not generated into the working directory. Thanks so much for fixing this. It was beginning to irritate me. The fix is ok, but doing a bit of archaeology, it looks like the fix for JDK-8173605 introduced the problem. JDK-8173605 attempts to remove support for source and target 1.7 option in javac. In so doing, the test ReleaseOption.java whose objective is to "Verify that javac rejects Java 8 program with --release 7" becomes irrelevant and perhaps the whole test could have been deleted rather than making the negative test (that would fail to compile) into a positive test that compiles fine. In particular the Summary line in ReleaseOption.java is stale. It is not clear to me that the test serves any real purpose - compiled directly or through the API. ------------- PR: https://git.openjdk.org/jdk/pull/10724 From sadayapalam at openjdk.org Mon Oct 17 10:24:56 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Mon, 17 Oct 2022 10:24:56 GMT Subject: RFR: 8295176: some langtools test pollutes source tree In-Reply-To: References: Message-ID: <5GSb9vSXH_LBcAB-4cH7WEwisYGf37g61OncwmLDRzk=.34495689-89b7-49e0-8943-8124bff95bce@github.com> On Mon, 17 Oct 2022 09:35:40 GMT, Jan Lahoda wrote: > The `ReleaseOptionThroughAPI.java` test compiles another test source, `ReleaseOption.java`. But it does not specify the output directory, so javac generates the classfile next to the source files into the source directory, causing trouble. > > The proposed fix is to add `-d .` to the test, so that the classfile is not generated into the working directory. Marked as reviewed by sadayapalam (Reviewer). I confirm that the proposed fix solves the problem. I suggest a push either after - cleaning up the Summary of ReleaseOption.java test OR - deleting both the tests ReleaseOption.java and ReleaseOptionThroughAPI.java Looks good to me. ------------- PR: https://git.openjdk.org/jdk/pull/10724 From duke at openjdk.org Mon Oct 17 11:55:46 2022 From: duke at openjdk.org (duke) Date: Mon, 17 Oct 2022 11:55:46 GMT Subject: Withdrawn: 8292022: Issues caused by Unary Plus Operator + and Shift Operators priority In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 07:07:18 GMT, GGGGGHT wrote: > (capacity + capacity>>1) The result of this expression is still capacity. So I guess what the author thought at the time might be (capacity + (capacity >> 1)), see https://bugs.openjdk.org/projects/JDK/issues/JDK-8292022 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9698 From jlahoda at openjdk.org Mon Oct 17 13:49:07 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 17 Oct 2022 13:49:07 GMT Subject: RFR: 8295176: some langtools test pollutes source tree [v2] In-Reply-To: References: Message-ID: > The `ReleaseOptionThroughAPI.java` test compiles another test source, `ReleaseOption.java`. But it does not specify the output directory, so javac generates the classfile next to the source files into the source directory, causing trouble. > > The proposed fix is to add `-d .` to the test, so that the classfile is not generated into the working directory. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Restoring negative --release tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10724/files - new: https://git.openjdk.org/jdk/pull/10724/files/8d452c71..34eb4ed5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10724&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10724&range=00-01 Stats: 9 lines in 3 files changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10724.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10724/head:pull/10724 PR: https://git.openjdk.org/jdk/pull/10724 From sadayapalam at openjdk.org Mon Oct 17 14:39:55 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Mon, 17 Oct 2022 14:39:55 GMT Subject: RFR: 8295176: some langtools test pollutes source tree [v2] In-Reply-To: References: Message-ID: On Mon, 17 Oct 2022 13:49:07 GMT, Jan Lahoda wrote: >> The `ReleaseOptionThroughAPI.java` test compiles another test source, `ReleaseOption.java`. But it does not specify the output directory, so javac generates the classfile next to the source files into the source directory, causing trouble. >> >> The proposed fix is to add `-d .` to the test, so that the classfile is not generated into the working directory. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Restoring negative --release tests. The proposed change restoring the negative nature of the test is better than my suggestions. Thanks, Look good to me. ------------- PR: https://git.openjdk.org/jdk/pull/10724 From jlahoda at openjdk.org Mon Oct 17 14:44:25 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 17 Oct 2022 14:44:25 GMT Subject: RFR: 8295401: Error recovery in module-info.java could be improved Message-ID: Consider an erroneous `module-info.java` like: module m { provides javax.util.; } When javac parses this code, the resulting AST will not contain the (incomplete) directive for provides. This is different from the other directives, which are included, and complicates developing features, like code completion, over the AST. The proposal is to simply include the incomplete provides directive in the list of directives. ------------- Commit messages: - 8295401: Error recovery in module-info.java could be improved Changes: https://git.openjdk.org/jdk/pull/10728/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10728&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295401 Stats: 83 lines in 2 files changed: 77 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10728.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10728/head:pull/10728 PR: https://git.openjdk.org/jdk/pull/10728 From hannesw at openjdk.org Mon Oct 17 15:03:12 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 17 Oct 2022 15:03:12 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors [v5] In-Reply-To: References: Message-ID: > Please review a a new feature to allow `@link`, `@linkplain` and `@see` tags to link to arbitrary URI fragments in the generated documentation (including in auxiliary `doc-files` documentation). > > The changes in module `jdk.compiler` are mostly cleanup changes retained from earlier versions of the patch. The current proposed version uses a very simple change in `ReferenceParser` to avoid parsing the member name section of the reference when a non-member fragment is encountered. > > The implementation introduces a new form of reference with a double hash mark (`##`) separator. This is a change from the previous implementation which also auto-recognized URI fragments and documentation paths by looking for `-` characters which are not allowed in member names. This feature was removed upon further consideration because it makes the feature more complex and less recognizable. > > Links to auxiliary documentation files follow the same rules. They are recognized by looking for `/` characters in the fragment name. This means that ordinary `id` attribute values must not contain `/`, while auxiliary file paths must contain a `/` character. Both restrictions should be easy to sustain. > > One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. In contrast to program element names a fragment name does usually not make a good human readable name. The solution is to use the fragment name as default label text. I expect that the feature will usually be used with a user provided label. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Remove remaining references to aux doc link support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10395/files - new: https://git.openjdk.org/jdk/pull/10395/files/d327ed76..1ea15afc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10395&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10395&range=03-04 Stats: 10 lines in 2 files changed: 2 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10395/head:pull/10395 PR: https://git.openjdk.org/jdk/pull/10395 From hannesw at openjdk.org Mon Oct 17 15:03:13 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 17 Oct 2022 15:03:13 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors [v4] In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 14:49:57 GMT, Jonathan Gibbons wrote: >> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove aux doc file reference feature > > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/ReferenceParser.java line 118: > >> 116: // A slash following a hash is part of a doc-file path, not a module separator >> 117: slash = -1; >> 118: } > > I thought we were backing off file references ... Changed back to old code > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 490: > >> 488: } else if (refFragment != null && refFragment.startsWith("#")) { >> 489: if (labelContent.isEmpty()) { >> 490: // A non-empty label is required for fragment and auxiliary file links > > "auxiliary file links" ... Removed mention of auxiliary files. ------------- PR: https://git.openjdk.org/jdk/pull/10395 From hannesw at openjdk.org Mon Oct 17 15:39:07 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 17 Oct 2022 15:39:07 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors [v5] In-Reply-To: References: Message-ID: On Mon, 17 Oct 2022 15:03:12 GMT, Hannes Walln?fer wrote: >> Please review a a new feature to allow `@link`, `@linkplain` and `@see` tags to link to arbitrary URI fragments in the generated documentation (including in auxiliary `doc-files` documentation). >> >> The changes in module `jdk.compiler` are mostly cleanup changes retained from earlier versions of the patch. The current proposed version uses a very simple change in `ReferenceParser` to avoid parsing the member name section of the reference when a non-member fragment is encountered. >> >> The implementation introduces a new form of reference with a double hash mark (`##`) separator. This is a change from the previous implementation which also auto-recognized URI fragments and documentation paths by looking for `-` characters which are not allowed in member names. This feature was removed upon further consideration because it makes the feature more complex and less recognizable. >> >> Links to auxiliary documentation files follow the same rules. They are recognized by looking for `/` characters in the fragment name. This means that ordinary `id` attribute values must not contain `/`, while auxiliary file paths must contain a `/` character. Both restrictions should be easy to sustain. >> >> One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. In contrast to program element names a fragment name does usually not make a good human readable name. The solution is to use the fragment name as default label text. I expect that the feature will usually be used with a user provided label. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Remove remaining references to aux doc link support The `allowMember` parameter was never used, so this doesn't change existing behaviour. The validity of `@throws` references is checked by doclint, where we have much more context (such as whether a type is throwable). We could enforce restrictions on references at the parser level, but it will affect code down the line such as the doclint `@throws` checks. ------------- PR: https://git.openjdk.org/jdk/pull/10395 From duke at openjdk.org Mon Oct 17 15:45:07 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Mon, 17 Oct 2022 15:45:07 GMT Subject: RFR: 8043179: Lambda expression can mutate final field [v6] In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> Message-ID: > (Description revised) > > JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime: > >> _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._ > > This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body. Archie L. Cobbs 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 seven additional commits since the last revision: - Merge branch 'master' into JDK-8043179 - Fix previously incorrect logic and update unit tests. - Merge remote-tracking branch 'upstream/master' into JDK-8043179 - Fix @author in test to match github username per instructions. - Move unit test into a more appropriate subdirectory. - Use /nodynamiccopyright/ for "golden file" test per instructions. - 8043179: Lambda expression can mutate final field ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10381/files - new: https://git.openjdk.org/jdk/pull/10381/files/703573cf..5d40607c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=04-05 Stats: 2353 lines in 88 files changed: 1632 ins; 336 del; 385 mod Patch: https://git.openjdk.org/jdk/pull/10381.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381 PR: https://git.openjdk.org/jdk/pull/10381 From duke at openjdk.org Mon Oct 17 16:04:05 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Mon, 17 Oct 2022 16:04:05 GMT Subject: RFR: 8043179: Lambda expression can mutate final field [v7] In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> Message-ID: > (Description revised) > > JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime: > >> _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._ > > This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body. Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Add a unit test verifying a change in reported error for final variables. Before this change, compiling this class: class LambdaMutateFinalVar { LambdaMutateFinalVar() { final String x; Runnable r1 = () -> x = "not ok"; x = "ok"; } } would report this error: local variables referenced from a lambda expression must be final or effectively final That error is not really appropriate; after all, the variable IS final. The real problem is that it can't be assigned from within the lambda because it can't be assumed to be DU. After this change, this error is reported instead: variable x might already have been assigned ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10381/files - new: https://git.openjdk.org/jdk/pull/10381/files/5d40607c..9352f989 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=05-06 Stats: 16 lines in 2 files changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10381.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381 PR: https://git.openjdk.org/jdk/pull/10381 From darcy at openjdk.org Mon Oct 17 17:08:05 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 17 Oct 2022 17:08:05 GMT Subject: RFR: 8295176: some langtools test pollutes source tree [v2] In-Reply-To: References: Message-ID: On Mon, 17 Oct 2022 13:49:07 GMT, Jan Lahoda wrote: >> The `ReleaseOptionThroughAPI.java` test compiles another test source, `ReleaseOption.java`. But it does not specify the output directory, so javac generates the classfile next to the source files into the source directory, causing trouble. >> >> The proposed fix is to add `-d .` to the test, so that the classfile is not generated into the working directory. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Restoring negative --release tests. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10724 From vromero at openjdk.org Mon Oct 17 17:21:58 2022 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 17 Oct 2022 17:21:58 GMT Subject: RFR: 8295176: some langtools test pollutes source tree [v2] In-Reply-To: References: Message-ID: On Mon, 17 Oct 2022 13:49:07 GMT, Jan Lahoda wrote: >> The `ReleaseOptionThroughAPI.java` test compiles another test source, `ReleaseOption.java`. But it does not specify the output directory, so javac generates the classfile next to the source files into the source directory, causing trouble. >> >> The proposed fix is to add `-d .` to the test, so that the classfile is not generated into the working directory. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Restoring negative --release tests. Marked as reviewed by vromero (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10724 From jjg at openjdk.org Mon Oct 17 20:21:54 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 17 Oct 2022 20:21:54 GMT Subject: Integrated: JDK-8294546: document where javac differs when invoked via launcher and ToolProvider In-Reply-To: <7iYgg04awBQOW5JQ_ZgsNoZrEFharttH4Ks-NXrD3V0=.79f28a24-44a4-41af-a952-229f111a5727@github.com> References: <7iYgg04awBQOW5JQ_ZgsNoZrEFharttH4Ks-NXrD3V0=.79f28a24-44a4-41af-a952-229f111a5727@github.com> Message-ID: On Tue, 4 Oct 2022 23:06:41 GMT, Jonathan Gibbons wrote: > Please review a doc-only change to specify the differences between using different ways to invoke javac. This pull request has now been integrated. Changeset: f300ec86 Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/f300ec8631b781938e6e96165ba23cda14a20f24 Stats: 75 lines in 1 file changed: 75 ins; 0 del; 0 mod 8294546: document where javac differs when invoked via launcher and ToolProvider Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/10566 From jlahoda at openjdk.org Tue Oct 18 07:45:08 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 18 Oct 2022 07:45:08 GMT Subject: RFR: 8029633: Raw inner class constructor ref should not perform diamond inference In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 20:20:14 GMT, Vicente Romero wrote: > This PR is synchronizing the compiler with the spec, in particular with this portion of section `15.13.1 Compile-Time Declaration of a Method Reference`: > > > ? If the method reference expression has the form ClassType :: > [TypeArguments] new , then the potentially applicable methods are a set of > notional methods corresponding to the constructors of ClassType. > If ClassType is a raw type, but is not a non- static member type of a raw type, > the candidate notional member methods are those specified in ?15.9.3 for a > class instance creation expression that uses <> to elide the type arguments to a > class. Otherwise, the candidate notional member methods are the constructors > of ClassType, treated as if they were methods with return type ClassType. > > so javac should treat the code below as a raw constructor invocation: > > > class Outer { > class Inner {} > > Supplier.Inner> s = Outer.Inner::new; > } > > currently javac is rejecting this code > > TIA > > PS. Please review the related CSR too Just to verify I understand it correctly, having something along the lines: `... = Outer.Inner::new` (where `Inner` is a parameterized type) based on some conditions, we either use diamond inference, and will produce a parameterized type as the type of the `Outer.Inner::new` expression; or we will produce a raw type as the type of the expression. Is that correct? I think this patch is in the right direction, but I am not sure about this case: class Outer2 { class Inner1 {} class Inner2 {} Supplier> s4 = Outer2.Inner2::new; } Note that here: `Outer2.Inner2` is a raw type, is a non-static member type, but the enclosing type is not raw, and hence, based on the conditions: > If ClassType is a raw type, but is not a non- static member type of a raw type, it seems it should get the diamond inference here? Should the new condition be `!site.tsym.isInner() || !site.getEnclosingType().isRaw()` instead of `!site.tsym.isInner()`, or possibly (to mimic the spec) something like `!(site.tsym.isInner() && site.getEnclosingType().isRaw())`? (The difference is observable as an unchecked warning.) Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9784 From jlahoda at openjdk.org Tue Oct 18 07:46:16 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 18 Oct 2022 07:46:16 GMT Subject: RFR: 8295176: some langtools test pollutes source tree [v2] In-Reply-To: References: Message-ID: <5rKyLm_xZ0Jhw3zy9SQSVqAphcER9bv6LZvEooRpsaQ=.e5de92ba-bb74-4a5b-a266-3b3078eca48b@github.com> On Mon, 17 Oct 2022 13:49:07 GMT, Jan Lahoda wrote: >> The `ReleaseOptionThroughAPI.java` test compiles another test source, `ReleaseOption.java`. But it does not specify the output directory, so javac generates the classfile next to the source files into the source directory, causing trouble. >> >> The proposed fix is to add `-d .` to the test, so that the classfile is not generated into the working directory. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Restoring negative --release tests. Thanks for the reviews! ------------- PR: https://git.openjdk.org/jdk/pull/10724 From jlahoda at openjdk.org Tue Oct 18 07:48:12 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 18 Oct 2022 07:48:12 GMT Subject: Integrated: 8295176: some langtools test pollutes source tree In-Reply-To: References: Message-ID: On Mon, 17 Oct 2022 09:35:40 GMT, Jan Lahoda wrote: > The `ReleaseOptionThroughAPI.java` test compiles another test source, `ReleaseOption.java`. But it does not specify the output directory, so javac generates the classfile next to the source files into the source directory, causing trouble. > > The proposed fix is to add `-d .` to the test, so that the classfile is not generated into the working directory. This pull request has now been integrated. Changeset: 71aa8210 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/71aa8210910dbafe30eccc772eaa7747f46be0cd Stats: 9 lines in 3 files changed: 5 ins; 0 del; 4 mod 8295176: some langtools test pollutes source tree Reviewed-by: sadayapalam, darcy, vromero ------------- PR: https://git.openjdk.org/jdk/pull/10724 From sadayapalam at openjdk.org Tue Oct 18 08:00:46 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Tue, 18 Oct 2022 08:00:46 GMT Subject: RFR: 8292159: TYPE_USE annotations on generic type arguments of record components discarded Message-ID: Handle carryover of type annotations to record components in a place which will be reached regardless of whether there are any annotations in a SE5 annotation location. ------------- Commit messages: - Merge branch 'master' into JDK-8292159 - 8292159: TYPE_USE annotations on generic type arguments of record components discarded Changes: https://git.openjdk.org/jdk/pull/10741/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10741&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292159 Stats: 85 lines in 3 files changed: 82 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10741/head:pull/10741 PR: https://git.openjdk.org/jdk/pull/10741 From ihse at openjdk.org Tue Oct 18 15:45:01 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 18 Oct 2022 15:45:01 GMT Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test code Message-ID: This is a continuation of the effort to update all our URLs to the new top-level domain. This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace. I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos. ------------- Commit messages: - 8295470: Update openjdk.java.net => openjdk.org URLs in test code Changes: https://git.openjdk.org/jdk/pull/10744/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10744&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295470 Stats: 138 lines in 45 files changed: 46 ins; 0 del; 92 mod Patch: https://git.openjdk.org/jdk/pull/10744.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10744/head:pull/10744 PR: https://git.openjdk.org/jdk/pull/10744 From ihse at openjdk.org Tue Oct 18 15:45:02 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 18 Oct 2022 15:45:02 GMT Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test code In-Reply-To: References: Message-ID: On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie wrote: > This is a continuation of the effort to update all our URLs to the new top-level domain. > > This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace. > > I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos. I noticed that a couple of files where missing copyright headers, when I tried to update those. I did some code archaeology and found out which year they were created, and added a copyright header. Just to be reasonably sure that I did not affect any tests, I have let this go through the GHA and our internal CI testing tier1-3. The failed GHA test is `SuperWaitTest`, which I did not modify. ------------- PR: https://git.openjdk.org/jdk/pull/10744 From michaelm at openjdk.org Tue Oct 18 16:03:57 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 18 Oct 2022 16:03:57 GMT Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test code In-Reply-To: References: Message-ID: On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie wrote: > This is a continuation of the effort to update all our URLs to the new top-level domain. > > This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace. > > I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos. net changes look fine ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.org/jdk/pull/10744 From prr at openjdk.org Tue Oct 18 16:51:10 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 18 Oct 2022 16:51:10 GMT Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test code In-Reply-To: References: Message-ID: On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie wrote: > This is a continuation of the effort to update all our URLs to the new top-level domain. > > This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace. > > I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10744 From duke at openjdk.org Tue Oct 18 17:14:49 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Tue, 18 Oct 2022 17:14:49 GMT Subject: RFR: 8043179: Lambda expression can mutate final field [v8] In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> Message-ID: <6BR2kYlapg7XaYf2nEMjuv-vZECtri9CgjRpa8ZKSbA=.c1e327f2-069b-41ff-8f1b-e57a43b4d541@github.com> > (Description revised) > > JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime: > >> _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._ > > This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body. Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Add a unit test verifying a change in reported error for final variables. Before this change, compiling this class: class LambdaMutateFinalVar { LambdaMutateFinalVar() { final String x; Runnable r1 = () -> x = "not ok"; x = "ok"; } } would report this error: local variables referenced from a lambda expression must be final or effectively final That error is not really appropriate; after all, the variable IS final. The real problem is that it can't be assigned from within the lambda because it can't be assumed to be DU. After this change, this error is reported instead: variable x might already have been assigned - Fix previously incorrect logic and update unit tests. - Fix @author in test to match github username per instructions. - Move unit test into a more appropriate subdirectory. - Use /nodynamiccopyright/ for "golden file" test per instructions. - 8043179: Lambda expression can mutate final field ------------- Changes: https://git.openjdk.org/jdk/pull/10381/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=07 Stats: 37 lines in 5 files changed: 37 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10381.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381 PR: https://git.openjdk.org/jdk/pull/10381 From darcy at openjdk.org Tue Oct 18 17:24:02 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 18 Oct 2022 17:24:02 GMT Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test code In-Reply-To: References: Message-ID: On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie wrote: > This is a continuation of the effort to update all our URLs to the new top-level domain. > > This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace. > > I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10744 From vromero at openjdk.org Tue Oct 18 17:48:07 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 18 Oct 2022 17:48:07 GMT Subject: RFR: 8294670: Enhanced switch statements have an implicit default which does not complete normally In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 14:48:57 GMT, Jan Lahoda wrote: > When a synthetic `default` is generated for enhanced switch, it never completes normally, which should be used when detecting liveness after the switch statement, which is what this patch is trying to do. looks good to me ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10540 From vromero at openjdk.org Tue Oct 18 18:25:22 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 18 Oct 2022 18:25:22 GMT Subject: RFR: 8029633: Raw inner class constructor ref should not perform diamond inference [v2] In-Reply-To: References: Message-ID: <_9DoBvgIl0xrb1Aeb9KbhDyJWRY187cCGNmPdfwK2Xg=.8a8c5fd8-36e1-435f-a36b-e08bf7bfa158@github.com> > This PR is synchronizing the compiler with the spec, in particular with this portion of section `15.13.1 Compile-Time Declaration of a Method Reference`: > > > ? If the method reference expression has the form ClassType :: > [TypeArguments] new , then the potentially applicable methods are a set of > notional methods corresponding to the constructors of ClassType. > If ClassType is a raw type, but is not a non- static member type of a raw type, > the candidate notional member methods are those specified in ?15.9.3 for a > class instance creation expression that uses <> to elide the type arguments to a > class. Otherwise, the candidate notional member methods are the constructors > of ClassType, treated as if they were methods with return type ClassType. > > so javac should treat the code below as a raw constructor invocation: > > > class Outer { > class Inner {} > > Supplier.Inner> s = Outer.Inner::new; > } > > currently javac is rejecting this code > > TIA > > PS. Please review the related CSR too 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-8029633 - 8029633: Raw inner class constructor ref should not perform diamond inference ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9784/files - new: https://git.openjdk.org/jdk/pull/9784/files/6c87afef..d8867430 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9784&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9784&range=00-01 Stats: 210566 lines in 3986 files changed: 106516 ins; 80840 del; 23210 mod Patch: https://git.openjdk.org/jdk/pull/9784.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9784/head:pull/9784 PR: https://git.openjdk.org/jdk/pull/9784 From archie.cobbs at gmail.com Tue Oct 18 18:58:06 2022 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 18 Oct 2022 13:58:06 -0500 Subject: Bugs that are inadvertently fixed Message-ID: I've been browsing some of the old javac bugs. As one would expect, some of them have been "inadvertently" fixed over the years, but they are still marked open in the bug tracker (example: JDK-6608961 ). What should I do when coming across these, if anything? As a non-committer I don't have write access to the bug tracker. So I could just email them to this mailing list, but that might get annoying. Or I could just leave them alone. Please advise. Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From vromero at openjdk.org Tue Oct 18 19:17:18 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 18 Oct 2022 19:17:18 GMT Subject: RFR: 8029633: Raw inner class constructor ref should not perform diamond inference [v3] In-Reply-To: References: Message-ID: <-ak8DZi7hubkOPjqykSl0vgElJ0VaKBIj-VMGJjm2sE=.3e33fb26-5dd1-4ad4-9d26-32d6cd3d867a@github.com> > This PR is synchronizing the compiler with the spec, in particular with this portion of section `15.13.1 Compile-Time Declaration of a Method Reference`: > > > ? If the method reference expression has the form ClassType :: > [TypeArguments] new , then the potentially applicable methods are a set of > notional methods corresponding to the constructors of ClassType. > If ClassType is a raw type, but is not a non- static member type of a raw type, > the candidate notional member methods are those specified in ?15.9.3 for a > class instance creation expression that uses <> to elide the type arguments to a > class. Otherwise, the candidate notional member methods are the constructors > of ClassType, treated as if they were methods with return type ClassType. > > so javac should treat the code below as a raw constructor invocation: > > > class Outer { > class Inner {} > > Supplier.Inner> s = Outer.Inner::new; > } > > currently javac is rejecting this code > > TIA > > PS. Please review the related CSR too Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9784/files - new: https://git.openjdk.org/jdk/pull/9784/files/d8867430..80b90ac6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9784&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9784&range=01-02 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9784.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9784/head:pull/9784 PR: https://git.openjdk.org/jdk/pull/9784 From vromero at openjdk.org Tue Oct 18 19:17:23 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 18 Oct 2022 19:17:23 GMT Subject: RFR: 8029633: Raw inner class constructor ref should not perform diamond inference [v2] In-Reply-To: <_9DoBvgIl0xrb1Aeb9KbhDyJWRY187cCGNmPdfwK2Xg=.8a8c5fd8-36e1-435f-a36b-e08bf7bfa158@github.com> References: <_9DoBvgIl0xrb1Aeb9KbhDyJWRY187cCGNmPdfwK2Xg=.8a8c5fd8-36e1-435f-a36b-e08bf7bfa158@github.com> Message-ID: On Tue, 18 Oct 2022 18:25:22 GMT, Vicente Romero wrote: >> This PR is synchronizing the compiler with the spec, in particular with this portion of section `15.13.1 Compile-Time Declaration of a Method Reference`: >> >> >> ? If the method reference expression has the form ClassType :: >> [TypeArguments] new , then the potentially applicable methods are a set of >> notional methods corresponding to the constructors of ClassType. >> If ClassType is a raw type, but is not a non- static member type of a raw type, >> the candidate notional member methods are those specified in ?15.9.3 for a >> class instance creation expression that uses <> to elide the type arguments to a >> class. Otherwise, the candidate notional member methods are the constructors >> of ClassType, treated as if they were methods with return type ClassType. >> >> so javac should treat the code below as a raw constructor invocation: >> >> >> class Outer { >> class Inner {} >> >> Supplier.Inner> s = Outer.Inner::new; >> } >> >> currently javac is rejecting this code >> >> TIA >> >> PS. Please review the related CSR too > > 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-8029633 > - 8029633: Raw inner class constructor ref should not perform diamond inference > @lahodaj I think you are right. Good catch! I have updated the PR, thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9784 From vromero at openjdk.org Tue Oct 18 19:54:05 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 18 Oct 2022 19:54:05 GMT Subject: RFR: 8292159: TYPE_USE annotations on generic type arguments of record components discarded In-Reply-To: References: Message-ID: On Tue, 18 Oct 2022 07:54:02 GMT, Srikanth Adayapalam wrote: > Handle carryover of type annotations to record components in a place which will be > reached regardless of whether there are any annotations in a SE5 annotation location. test/langtools/tools/javac/records/RecordCompilationTests.java line 1584: > 1582: """; > 1583: > 1584: String[] generalOptions = { for completeness I think that the test should be run with and without annotation processor ------------- PR: https://git.openjdk.org/jdk/pull/10741 From vicente.romero at oracle.com Tue Oct 18 20:39:47 2022 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 18 Oct 2022 16:39:47 -0400 Subject: Bugs that are inadvertently fixed In-Reply-To: References: Message-ID: I have closed it, thanks! Vicente On 10/18/22 14:58, Archie Cobbs wrote: > I've been browsing some of the old javac bugs. As one would expect, > some of them have been "inadvertently" fixed over the years, but they > are still marked open in the bug tracker (example: JDK-6608961 > ). > > What should I do when coming across these, if anything? > > As a non-committer I don't have write access to the bug tracker. So I > could just email them to this mailing list, but that might get annoying. > > Or I could just leave them alone. > > Please advise. > > Thanks, > -Archie > > -- > Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.trudeau at oracle.com Tue Oct 18 20:45:01 2022 From: michel.trudeau at oracle.com (Michel Trudeau) Date: Tue, 18 Oct 2022 20:45:01 +0000 Subject: Bugs that are inadvertently fixed In-Reply-To: References: Message-ID: Please keep reporting. It?s useful info. Thank you for letting us know. -Michel From: compiler-dev on behalf of Archie Cobbs Date: Tuesday, October 18, 2022 at 11:58 AM To: compiler-dev at openjdk.org Subject: Bugs that are inadvertently fixed I've been browsing some of the old javac bugs. As one would expect, some of them have been "inadvertently" fixed over the years, but they are still marked open in the bug tracker (example: JDK-6608961). What should I do when coming across these, if anything? As a non-committer I don't have write access to the bug tracker. So I could just email them to this mailing list, but that might get annoying. Or I could just leave them alone. Please advise. Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.org Tue Oct 18 21:02:11 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 18 Oct 2022 21:02:11 GMT Subject: RFR: 8029633: Raw inner class constructor ref should not perform diamond inference [v3] In-Reply-To: <-ak8DZi7hubkOPjqykSl0vgElJ0VaKBIj-VMGJjm2sE=.3e33fb26-5dd1-4ad4-9d26-32d6cd3d867a@github.com> References: <-ak8DZi7hubkOPjqykSl0vgElJ0VaKBIj-VMGJjm2sE=.3e33fb26-5dd1-4ad4-9d26-32d6cd3d867a@github.com> Message-ID: On Tue, 18 Oct 2022 19:17:18 GMT, Vicente Romero wrote: >> This PR is synchronizing the compiler with the spec, in particular with this portion of section `15.13.1 Compile-Time Declaration of a Method Reference`: >> >> >> ? If the method reference expression has the form ClassType :: >> [TypeArguments] new , then the potentially applicable methods are a set of >> notional methods corresponding to the constructors of ClassType. >> If ClassType is a raw type, but is not a non- static member type of a raw type, >> the candidate notional member methods are those specified in ?15.9.3 for a >> class instance creation expression that uses <> to elide the type arguments to a >> class. Otherwise, the candidate notional member methods are the constructors >> of ClassType, treated as if they were methods with return type ClassType. >> >> so javac should treat the code below as a raw constructor invocation: >> >> >> class Outer { >> class Inner {} >> >> Supplier.Inner> s = Outer.Inner::new; >> } >> >> currently javac is rejecting this code >> >> TIA >> >> PS. Please review the related CSR too > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments Looks good to me, thanks! ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.org/jdk/pull/9784 From vromero at openjdk.org Tue Oct 18 21:52:05 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 18 Oct 2022 21:52:05 GMT Subject: RFR: 8029633: Raw inner class constructor ref should not perform diamond inference [v3] In-Reply-To: References: <-ak8DZi7hubkOPjqykSl0vgElJ0VaKBIj-VMGJjm2sE=.3e33fb26-5dd1-4ad4-9d26-32d6cd3d867a@github.com> Message-ID: On Tue, 18 Oct 2022 20:58:17 GMT, Jan Lahoda wrote: > Looks good to me, thanks! thanks for the review ------------- PR: https://git.openjdk.org/jdk/pull/9784 From duke at openjdk.org Tue Oct 18 22:01:31 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Tue, 18 Oct 2022 22:01:31 GMT Subject: RFR: 7039014: Confusing error message for method conflict Message-ID: This fixes a confusing error message. Currently, this input: interface A { byte m(String x); char m(T x); } interface B extends A { } produces this error: A.java:6: error: types A and A are incompatible; interface B extends A { ^ both define m(String), but with unrelated return types 1 error This patch detects when the two types are actually the same type and gives this error message instead: A.java:6: error: type A defines m(String) more than once with unrelated return types interface B extends A { ^ 1 error ------------- Commit messages: - 7039014: Confusing error message for method conflict Changes: https://git.openjdk.org/jdk/pull/10752/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10752&range=00 Issue: https://bugs.openjdk.org/browse/JDK-7039014 Stats: 44 lines in 4 files changed: 41 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10752.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10752/head:pull/10752 PR: https://git.openjdk.org/jdk/pull/10752 From alex.buckley at oracle.com Tue Oct 18 23:07:26 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 18 Oct 2022 16:07:26 -0700 Subject: RFR: 7039014: Confusing error message for method conflict In-Reply-To: References: Message-ID: <924c9359-d7ce-e520-849a-9a64529bc51e@oracle.com> I like the new error message. Although the problem lies in the methods of the type A, the error is technically due to a rule about the inheritance of those methods by B. (JLS 9.4.1.3: "One of the inherited methods must be return-type substitutable for every other inherited method, or else a compile-time error occurs.") Since whether a method is default or private has bearing on the rules of inheritance in interfaces, I recommend adding tests with these variations of A: // Error when B extends A interface A { default byte m(String x) { return 0; } char m(T x); } // No error when B extends A interface A { private byte m(String x) { return 0; } char m(T x); } Alex On 10/18/2022 3:01 PM, Archie L. Cobbs wrote: > This fixes a confusing error message. > > Currently, this input: > > interface A { > byte m(String x); > char m(T x); > } > > interface B extends A { > } > > produces this error: > > A.java:6: error: types A and A are incompatible; > interface B extends A { > ^ > both define m(String), but with unrelated return types > 1 error > > This patch detects when the two types are actually the same type and gives this error message instead: > > A.java:6: error: type A defines m(String) more than once with unrelated return types > interface B extends A { > ^ > 1 error > > ------------- > > Commit messages: > - 7039014: Confusing error message for method conflict > > Changes: https://git.openjdk.org/jdk/pull/10752/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10752&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-7039014 > Stats: 44 lines in 4 files changed: 41 ins; 0 del; 3 mod > Patch: https://git.openjdk.org/jdk/pull/10752.diff > Fetch: git fetch https://git.openjdk.org/jdk pull/10752/head:pull/10752 > > PR: https://git.openjdk.org/jdk/pull/10752 From duke at openjdk.org Wed Oct 19 00:55:55 2022 From: duke at openjdk.org (duke) Date: Wed, 19 Oct 2022 00:55:55 GMT Subject: Withdrawn: 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch In-Reply-To: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com> References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com> Message-ID: On Fri, 19 Aug 2022 03:08:31 GMT, SUN Guoyun wrote: > make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9934 From archie.cobbs at gmail.com Wed Oct 19 02:05:41 2022 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 18 Oct 2022 21:05:41 -0500 Subject: RFR: 7039014: Confusing error message for method conflict In-Reply-To: <924c9359-d7ce-e520-849a-9a64529bc51e@oracle.com> References: <924c9359-d7ce-e520-849a-9a64529bc51e@oracle.com> Message-ID: On Tue, Oct 18, 2022 at 6:07 PM Alex Buckley wrote: > I recommend adding tests with these variations of A: > Thanks for the comments. I've added those examples as additional unit tests. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Oct 19 02:08:55 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 19 Oct 2022 02:08:55 GMT Subject: RFR: 7039014: Confusing error message for method conflict [v2] In-Reply-To: References: Message-ID: > This fixes a confusing error message. > > Currently, this input: > > interface A { > byte m(String x); > char m(T x); > } > > interface B extends A { > } > > produces this error: > > A.java:6: error: types A and A are incompatible; > interface B extends A { > ^ > both define m(String), but with unrelated return types > 1 error > > This patch detects when the two types are actually the same type and gives this error message instead: > > A.java:6: error: type A defines m(String) more than once with unrelated return types > interface B extends A { > ^ > 1 error Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Add a few more unit tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10752/files - new: https://git.openjdk.org/jdk/pull/10752/files/a233f6de..4404568c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10752&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10752&range=00-01 Stats: 83 lines in 5 files changed: 83 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10752.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10752/head:pull/10752 PR: https://git.openjdk.org/jdk/pull/10752 From vromero at openjdk.org Wed Oct 19 04:25:59 2022 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 19 Oct 2022 04:25:59 GMT Subject: RFR: 7039014: Confusing error message for method conflict [v2] In-Reply-To: References: Message-ID: <2LTcIpi_-tX4rRobTIAZxsDNYznzsgvjNl_6mHaagIM=.887d9582-f0a8-4c07-9e5a-023ce8945a12@github.com> On Wed, 19 Oct 2022 02:08:55 GMT, Archie L. Cobbs wrote: >> This fixes a confusing error message. >> >> Currently, this input: >> >> interface A { >> byte m(String x); >> char m(T x); >> } >> >> interface B extends A { >> } >> >> produces this error: >> >> A.java:6: error: types A and A are incompatible; >> interface B extends A { >> ^ >> both define m(String), but with unrelated return types >> 1 error >> >> This patch detects when the two types are actually the same type and gives this error message instead: >> >> A.java:6: error: type A defines m(String) more than once with unrelated return types >> interface B extends A { >> ^ >> 1 error > > Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add a few more unit tests. test/langtools/tools/javac/Diagnostics/7039014/T7039014a.java line 5: > 3: * @bug 7039014 > 4: * @summary Confusing error message for method conflict > 5: * @author archiecobbs nit: we don't add the `@author` tag anymore, it has been kept only if the original test had it, usually very old tests. ------------- PR: https://git.openjdk.org/jdk/pull/10752 From vromero at openjdk.org Wed Oct 19 04:30:10 2022 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 19 Oct 2022 04:30:10 GMT Subject: RFR: 7039014: Confusing error message for method conflict [v2] In-Reply-To: References: Message-ID: On Wed, 19 Oct 2022 02:08:55 GMT, Archie L. Cobbs wrote: >> This fixes a confusing error message. >> >> Currently, this input: >> >> interface A { >> byte m(String x); >> char m(T x); >> } >> >> interface B extends A { >> } >> >> produces this error: >> >> A.java:6: error: types A and A are incompatible; >> interface B extends A { >> ^ >> both define m(String), but with unrelated return types >> 1 error >> >> This patch detects when the two types are actually the same type and gives this error message instead: >> >> A.java:6: error: type A defines m(String) more than once with unrelated return types >> interface B extends A { >> ^ >> 1 error > > Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add a few more unit tests. test/langtools/tools/javac/Diagnostics/7039014/T7039014a.java line 9: > 7: * @compile/fail/ref=T7039014a.out -XDrawDiagnostics T7039014a.java > 8: */ > 9: public class T7039014a { I think that T7039014(a,b,c) should be combined into only one test ------------- PR: https://git.openjdk.org/jdk/pull/10752 From vromero at openjdk.org Wed Oct 19 04:57:44 2022 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 19 Oct 2022 04:57:44 GMT Subject: RFR: 8291914: generated constructors are considered compact when they shouldn't Message-ID: javac is considering all record generated constructors as compact constructors. According to the spec compact constructors should be declared explicitly. This constructor is compact: record R1(int i) { R1 {} } here there is no explicit constructor so the compiler is providing one but it shouldn't be considered a compact constructor: record R2(int i) {} this PR is fixing the current compiler bug so that for declarations like record R2 the compiler generated constructor is not considered a compact one. TIA ------------- Commit messages: - 8291914: generated constructors are considered compact when they shouldn't Changes: https://git.openjdk.org/jdk/pull/10756/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10756&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291914 Stats: 9 lines in 4 files changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10756.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10756/head:pull/10756 PR: https://git.openjdk.org/jdk/pull/10756 From darcy at openjdk.org Wed Oct 19 05:06:44 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 19 Oct 2022 05:06:44 GMT Subject: RFR: 8291914: generated constructors are considered compact when they shouldn't In-Reply-To: References: Message-ID: <1td2IC5T1YEvZxW3PdgYvRZ4Gn-PTviWy2CKlsCQbmM=.98a4eb21-4c82-457e-8ab3-583658ca3b90@github.com> On Wed, 19 Oct 2022 04:52:29 GMT, Vicente Romero wrote: > javac is considering all record generated constructors as compact constructors. According to the spec compact constructors should be declared explicitly. This constructor is compact: > > record R1(int i) { > R1 {} > } > > here there is no explicit constructor so the compiler is providing one but it shouldn't be considered a compact constructor: > > record R2(int i) {} > > this PR is fixing the current compiler bug so that for declarations like record R2 the compiler generated constructor is not considered a compact one. > > TIA Test changes look good. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.org/jdk/pull/10756 From cpovirk at google.com Wed Oct 19 11:09:07 2022 From: cpovirk at google.com (Chris Povirk) Date: Wed, 19 Oct 2022 04:09:07 -0700 Subject: Surprised that TYPE_USE annotations are accepted on `var` lambda parameters In-Reply-To: References: Message-ID: > > Since type-use annotations are rejected on var local variables, I would > have expected them to be rejected on var lambda parameters, too. > That position fits with the idea that, when we use var, we're expecting the full type to be inferred. In contrast, if it *were* possible to put annotations on var, there would be ambiguity about what the *absence* of an annotation means: Does it mean "Please infer whether an annotation should be present on the inferred type," or does it mean "Behave as if no annotation is present on the inferred type?" The conservative approach for developers would be to annotate *every* var declaration. But, in addition to being verbose, that approach is possible for our nullness work only if every type is either nullable or non-null?and that's not the case, since a type-variable usage T has a nullness that will depend on the type argument. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Wed Oct 19 13:41:46 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Oct 2022 13:41:46 GMT Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test code In-Reply-To: References: Message-ID: On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie wrote: > This is a continuation of the effort to update all our URLs to the new top-level domain. > > This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace. > > I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos. This updates several tests that are also in Doug Lea's CVS for j.u.concurrent. That should be okay, just need to get them in sync at some point. ------------- PR: https://git.openjdk.org/jdk/pull/10744 From vromero at openjdk.org Wed Oct 19 14:06:07 2022 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 19 Oct 2022 14:06:07 GMT Subject: RFR: 8291914: generated constructors are considered compact when they shouldn't In-Reply-To: <1td2IC5T1YEvZxW3PdgYvRZ4Gn-PTviWy2CKlsCQbmM=.98a4eb21-4c82-457e-8ab3-583658ca3b90@github.com> References: <1td2IC5T1YEvZxW3PdgYvRZ4Gn-PTviWy2CKlsCQbmM=.98a4eb21-4c82-457e-8ab3-583658ca3b90@github.com> Message-ID: <7a0sMlGLxbdCilP2mDjDuITOBDW9Lgt86QkD_m_YhOQ=.3ab7e672-854d-4eed-a788-26cf4c923e3a@github.com> On Wed, 19 Oct 2022 05:03:29 GMT, Joe Darcy wrote: > Test changes look good. thanks for the review, and for the test :) ------------- PR: https://git.openjdk.org/jdk/pull/10756 From duke at openjdk.org Wed Oct 19 15:08:51 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 19 Oct 2022 15:08:51 GMT Subject: RFR: 8043179: Lambda expression can mutate final field [v9] In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> Message-ID: > (Description revised) > > JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime: > >> _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._ > > This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body. Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Remove @author tags from tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10381/files - new: https://git.openjdk.org/jdk/pull/10381/files/06b39a59..b1d5b3c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=07-08 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10381.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381 PR: https://git.openjdk.org/jdk/pull/10381 From duke at openjdk.org Wed Oct 19 15:22:51 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 19 Oct 2022 15:22:51 GMT Subject: RFR: 7039014: Confusing error message for method conflict [v3] In-Reply-To: References: Message-ID: > This fixes a confusing error message. > > Currently, this input: > > interface A { > byte m(String x); > char m(T x); > } > > interface B extends A { > } > > produces this error: > > A.java:6: error: types A and A are incompatible; > interface B extends A { > ^ > both define m(String), but with unrelated return types > 1 error > > This patch detects when the two types are actually the same type and gives this error message instead: > > A.java:6: error: type A defines m(String) more than once with unrelated return types > interface B extends A { > ^ > 1 error Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Remove obsolete @author tags and combine tests into one file. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10752/files - new: https://git.openjdk.org/jdk/pull/10752/files/4404568c..34957acb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10752&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10752&range=01-02 Stats: 125 lines in 7 files changed: 42 ins; 83 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10752.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10752/head:pull/10752 PR: https://git.openjdk.org/jdk/pull/10752 From duke at openjdk.org Wed Oct 19 15:22:55 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 19 Oct 2022 15:22:55 GMT Subject: RFR: 7039014: Confusing error message for method conflict [v2] In-Reply-To: <2LTcIpi_-tX4rRobTIAZxsDNYznzsgvjNl_6mHaagIM=.887d9582-f0a8-4c07-9e5a-023ce8945a12@github.com> References: <2LTcIpi_-tX4rRobTIAZxsDNYznzsgvjNl_6mHaagIM=.887d9582-f0a8-4c07-9e5a-023ce8945a12@github.com> Message-ID: On Wed, 19 Oct 2022 04:22:17 GMT, Vicente Romero wrote: >> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a few more unit tests. > > test/langtools/tools/javac/Diagnostics/7039014/T7039014a.java line 5: > >> 3: * @bug 7039014 >> 4: * @summary Confusing error message for method conflict >> 5: * @author archiecobbs > > nit: we don't add the `@author` tag anymore, it has been kept only if the original test had it, usually very old tests. Thanks - removed. > test/langtools/tools/javac/Diagnostics/7039014/T7039014a.java line 9: > >> 7: * @compile/fail/ref=T7039014a.out -XDrawDiagnostics T7039014a.java >> 8: */ >> 9: public class T7039014a { > > I think that T7039014(a,b,c) should be combined into only one test Good idea, thanks - done. ------------- PR: https://git.openjdk.org/jdk/pull/10752 From darcy at openjdk.org Wed Oct 19 18:26:00 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 19 Oct 2022 18:26:00 GMT Subject: RFR: 8292159: TYPE_USE annotations on generic type arguments of record components discarded In-Reply-To: References: Message-ID: On Tue, 18 Oct 2022 07:54:02 GMT, Srikanth Adayapalam wrote: > Handle carryover of type annotations to record components in a place which will be > reached regardless of whether there are any annotations in a SE5 annotation location. > /csr needed I agree it is reasonable to have a CSR to note the behavioral change; thanks, ------------- PR: https://git.openjdk.org/jdk/pull/10741 From cushon at google.com Wed Oct 19 19:52:53 2022 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 19 Oct 2022 12:52:53 -0700 Subject: Surprised that TYPE_USE annotations are accepted on `var` lambda parameters In-Reply-To: References: Message-ID: This feels like a bug to me too, I'd expect type annotations on var lambda parameters to either be rejected, or accepted and included in the output, but not accepted and then ignored. I wonder if this could have been an oversight, and JLS 9.7.4 should be updated to include lambda parameters that use var. Does anyone on the list remember discussion about this type annotation edge case from JEP 323? Looking at the handling of var locals in javac, I think the reason it doesn't also reject var lambda parameters is that their type is inferred earlier, so the check for `s.type.hasTag(NONE)` is false: https://github.com/openjdk/jdk/blob/f872467d69a6d8442f8004609ce819641cab568b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java#L3425 On Wed, Oct 19, 2022 at 4:09 AM Chris Povirk wrote: > Since type-use annotations are rejected on var local variables, I would >> have expected them to be rejected on var lambda parameters, too. >> > > That position fits with the idea that, when we use var, we're expecting > the full type to be inferred. > > In contrast, if it *were* possible to put annotations on var, there would > be ambiguity about what the *absence* of an annotation means: Does it mean > "Please infer whether an annotation should be present on the inferred > type," or does it mean "Behave as if no annotation is present on the > inferred type?" > > The conservative approach for developers would be to annotate *every* var > declaration. But, in addition to being verbose, that approach is possible > for our nullness work only if every type is either nullable or non-null?and > that's not the case, since a type-variable usage T has a nullness that will > depend on the type argument. > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Oct 20 00:40:15 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 20 Oct 2022 00:40:15 GMT Subject: RFR: 8043179: Lambda expression can mutate final field [v10] In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com> Message-ID: <8pLQqzGAe1hJtquD-edJqS5WX5IJDRILNCowpD7HZYM=.7330429d-3583-45b7-a314-aacf757fa80f@github.com> > (Description revised) > > JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime: > >> _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._ > > This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body. Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Update failed test output line numbers after removing @author tags. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10381/files - new: https://git.openjdk.org/jdk/pull/10381/files/b1d5b3c9..0081d190 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=08-09 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10381.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10381/head:pull/10381 PR: https://git.openjdk.org/jdk/pull/10381 From duke at openjdk.org Thu Oct 20 02:49:34 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 20 Oct 2022 02:49:34 GMT Subject: RFR: 8064931: tools/javac/scope/DupUnsharedTest.java needs to be updated to add the bug id Message-ID: 8064931: tools/javac/scope/DupUnsharedTest.java needs to be updated to add the bug id ------------- Commit messages: - Add missing @bug tag to unit test. Changes: https://git.openjdk.org/jdk/pull/10777/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10777&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8064931 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10777.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10777/head:pull/10777 PR: https://git.openjdk.org/jdk/pull/10777 From sadayapalam at openjdk.org Thu Oct 20 04:46:33 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Thu, 20 Oct 2022 04:46:33 GMT Subject: RFR: 8292159: TYPE_USE annotations on generic type arguments of record components discarded [v2] In-Reply-To: References: Message-ID: <-ZSfoU5gFGAhSsCXcoaBGm8QZIeRN3YUmi571T3NLtc=.dd05057f-09c1-4a7b-a95f-375b25b70c7e@github.com> > Handle carryover of type annotations to record components in a place which will be > reached regardless of whether there are any annotations in a SE5 annotation location. Srikanth Adayapalam 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 three additional commits since the last revision: - Merge branch 'master' into JDK-8292159 - Merge branch 'master' into JDK-8292159 - 8292159: TYPE_USE annotations on generic type arguments of record components discarded ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10741/files - new: https://git.openjdk.org/jdk/pull/10741/files/21c91fc3..46378d32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10741&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10741&range=00-01 Stats: 11247 lines in 794 files changed: 4409 ins; 4262 del; 2576 mod Patch: https://git.openjdk.org/jdk/pull/10741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10741/head:pull/10741 PR: https://git.openjdk.org/jdk/pull/10741 From vromero at openjdk.org Thu Oct 20 04:50:53 2022 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 20 Oct 2022 04:50:53 GMT Subject: RFR: 7039014: Confusing error message for method conflict [v3] In-Reply-To: References: Message-ID: <6olTcVT2eDBEu8MJh56kzXCr9-RiAI5GHjc2SkIeiYg=.0d7cb8bd-4278-4d66-870d-f2284af08281@github.com> On Wed, 19 Oct 2022 15:22:51 GMT, Archie L. Cobbs wrote: >> This fixes a confusing error message. >> >> Currently, this input: >> >> interface A { >> byte m(String x); >> char m(T x); >> } >> >> interface B extends A { >> } >> >> produces this error: >> >> A.java:6: error: types A and A are incompatible; >> interface B extends A { >> ^ >> both define m(String), but with unrelated return types >> 1 error >> >> This patch detects when the two types are actually the same type and gives this error message instead: >> >> A.java:6: error: type A defines m(String) more than once with unrelated return types >> interface B extends A { >> ^ >> 1 error > > Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete @author tags and combine tests into one file. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10752 From sadayapalam at openjdk.org Thu Oct 20 05:28:10 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Thu, 20 Oct 2022 05:28:10 GMT Subject: RFR: 8292159: TYPE_USE annotations on generic type arguments of record components discarded [v3] In-Reply-To: References: Message-ID: > Handle carryover of type annotations to record components in a place which will be > reached regardless of whether there are any annotations in a SE5 annotation location. Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision: Incorporate review comments from Vicente (Thanks!) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10741/files - new: https://git.openjdk.org/jdk/pull/10741/files/46378d32..231f7401 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10741&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10741&range=01-02 Stats: 59 lines in 1 file changed: 0 ins; 13 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/10741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10741/head:pull/10741 PR: https://git.openjdk.org/jdk/pull/10741 From jlahoda at openjdk.org Thu Oct 20 06:16:07 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Oct 2022 06:16:07 GMT Subject: RFR: 8291914: generated constructors are considered compact when they shouldn't In-Reply-To: References: Message-ID: On Wed, 19 Oct 2022 04:52:29 GMT, Vicente Romero wrote: > javac is considering all record generated constructors as compact constructors. According to the spec compact constructors should be declared explicitly. This constructor is compact: > > record R1(int i) { > R1 {} > } > > here there is no explicit constructor so the compiler is providing one but it shouldn't be considered a compact constructor: > > record R2(int i) {} > > this PR is fixing the current compiler bug so that for declarations like record R2 the compiler generated constructor is not considered a compact one. > > TIA Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.org/jdk/pull/10756 From sadayapalam at openjdk.org Thu Oct 20 08:28:51 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Thu, 20 Oct 2022 08:28:51 GMT Subject: RFR: 8292159: TYPE_USE annotations on generic type arguments of record components discarded [v3] In-Reply-To: References: Message-ID: <9KYNeQAwhqwPJbS2qfDBZSgCxe3wq-T0XKJLWmG5Oqw=.78cb0203-a814-4b47-bf00-9289c230a787@github.com> On Thu, 20 Oct 2022 05:28:10 GMT, Srikanth Adayapalam wrote: >> Handle carryover of type annotations to record components in a place which will be >> reached regardless of whether there are any annotations in a SE5 annotation location. > > Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments from Vicente (Thanks!) For the record(sic!) , javac's implementation seems to use terminology that differs from JLS (but still may be producing fully equivalent implementation) See that JLS 8.10.1 says: The record components of a record class, if any, are specified in the header of a record declaration. Each record component consists of a type (optionally preceded by one or more annotations) and an identifier that specifies the name of the record component. A record component corresponds to two members of the record class: a private field declared implicitly, and a public accessor method declared explicitly or implicitly (?8.10.3). Javac implementation treats the declaration in the record header as a component field and generates record component from that. In doing so, it is aligning with terminology used by JDK, which treats the components of the record attribute as Record components. The following is from Class.java /* * Returns an array containing the components of the Record attribute, * or null if the attribute is not present. * * Note that this method returns non-null array on a class with * the Record attribute even if this class is not a record. */ private native RecordComponent[] getRecordComponents0(); This may be just splitting hairs - but at least initially it is a bit confusing that we go from components fields to record components in javac implementation rather than vice versa. As called out before, the net effect may be that a totally equivalent implementation results. ------------- PR: https://git.openjdk.org/jdk/pull/10741 From sadayapalam at openjdk.org Thu Oct 20 09:03:10 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Thu, 20 Oct 2022 09:03:10 GMT Subject: RFR: 8292159: TYPE_USE annotations on generic type arguments of record components discarded [v4] In-Reply-To: References: Message-ID: > Handle carryover of type annotations to record components in a place which will be > reached regardless of whether there are any annotations in a SE5 annotation location. Srikanth Adayapalam 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 five additional commits since the last revision: - Merge branch 'master' into JDK-8292159 - Incorporate review comments from Vicente (Thanks!) - Merge branch 'master' into JDK-8292159 - Merge branch 'master' into JDK-8292159 - 8292159: TYPE_USE annotations on generic type arguments of record components discarded ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10741/files - new: https://git.openjdk.org/jdk/pull/10741/files/231f7401..1f9085e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10741&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10741&range=02-03 Stats: 754 lines in 17 files changed: 672 ins; 21 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/10741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10741/head:pull/10741 PR: https://git.openjdk.org/jdk/pull/10741 From ihse at openjdk.org Thu Oct 20 10:36:03 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Oct 2022 10:36:03 GMT Subject: Integrated: 8295470: Update openjdk.java.net => openjdk.org URLs in test code In-Reply-To: References: Message-ID: On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie wrote: > This is a continuation of the effort to update all our URLs to the new top-level domain. > > This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace. > > I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos. This pull request has now been integrated. Changeset: d5a1521f Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/d5a1521fde3f6ff7e810e8257a4722a09c9ef60b Stats: 138 lines in 45 files changed: 46 ins; 0 del; 92 mod 8295470: Update openjdk.java.net => openjdk.org URLs in test code Reviewed-by: michaelm, prr, darcy ------------- PR: https://git.openjdk.org/jdk/pull/10744 From abimpoudis at openjdk.org Thu Oct 20 11:40:23 2022 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 20 Oct 2022 11:40:23 GMT Subject: RFR: 8295447: NullPointerException with invalid pattern matching construct in constructor call Message-ID: In the examples below: int i = (o instanceof Bar(int x))? 0 : 1; meth(i); meth((o instanceof Bar(int x))? 0 : 1); the error `DeconstructionPatternOnlyRecords` was reported only on the first case but the compiler was still crashing in both occasions. `NoType` was passed and `checkCastablePattern` was letting an erroneous type to pass through the subtyping checks. The proposed fix addresses that in `checkCastablePattern`. ------------- Commit messages: - 8295447: NullPointerException with invalid pattern matching construct in constructor call Changes: https://git.openjdk.org/jdk/pull/10791/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10791&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295447 Stats: 57 lines in 3 files changed: 56 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10791.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10791/head:pull/10791 PR: https://git.openjdk.org/jdk/pull/10791 From ihse at openjdk.org Thu Oct 20 12:06:27 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Oct 2022 12:06:27 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files Message-ID: Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. ------------- Commit messages: - 8295729: Add jcheck whitespace checking for properties files Changes: https://git.openjdk.org/jdk/pull/10792/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295729 Stats: 1105 lines in 368 files changed: 0 ins; 0 del; 1105 mod Patch: https://git.openjdk.org/jdk/pull/10792.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792 PR: https://git.openjdk.org/jdk/pull/10792 From jlahoda at openjdk.org Thu Oct 20 13:03:52 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Oct 2022 13:03:52 GMT Subject: Integrated: 8294550: Sealed check for casts isn't applied to array components In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 14:24:18 GMT, Jan Lahoda wrote: > For code like: > > sealed interface I permits A {} > final class A implements I {} > interface J {} > > J j = null; > I i = (I) j; //error reported here, as no instance of J can implement I > J[] jj = null; > I[] i = (I[]) jj; //incorrectly no error reported here, despite JLS saying there must be a narrowing conversion from J to I in this case, which there isn't as per the case above > > > The cause for this is that we check the sealed constraints at the end of `Types.isCastable`, and only for classes, not for arrays. It would be possible to enhance the check to include array types, but feels clearer and more reliable to recurse, and do a full castability check on the element types. > > A sketch of a CSR is here: > https://bugs.openjdk.org/browse/JDK-8294586 > > Feedback is welcome! This pull request has now been integrated. Changeset: 78dc4977 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/78dc4977863a92f990b355f6b4d2609a674ab19b Stats: 26 lines in 2 files changed: 24 ins; 0 del; 2 mod 8294550: Sealed check for casts isn't applied to array components Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/10490 From duke at openjdk.org Thu Oct 20 14:01:16 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 20 Oct 2022 14:01:16 GMT Subject: Integrated: 7039014: Confusing error message for method conflict In-Reply-To: References: Message-ID: <4_zw9hqpV6SPnj17P_mPlGWtjqwYI8b0m6NC40RjQFk=.43635e75-d19a-4af6-8bbb-eb668190be77@github.com> On Tue, 18 Oct 2022 21:43:10 GMT, Archie L. Cobbs wrote: > This fixes a confusing error message. > > Currently, this input: > > interface A { > byte m(String x); > char m(T x); > } > > interface B extends A { > } > > produces this error: > > A.java:6: error: types A and A are incompatible; > interface B extends A { > ^ > both define m(String), but with unrelated return types > 1 error > > This patch detects when the two types are actually the same type and gives this error message instead: > > A.java:6: error: type A defines m(String) more than once with unrelated return types > interface B extends A { > ^ > 1 error This pull request has now been integrated. Changeset: 9b971626 Author: Archie L. Cobbs Committer: Vicente Romero URL: https://git.openjdk.org/jdk/commit/9b971626f79b4f64442cf6888c2b6114c9a06351 Stats: 86 lines in 6 files changed: 83 ins; 0 del; 3 mod 7039014: Confusing error message for method conflict Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/10752 From vromero at openjdk.org Thu Oct 20 15:00:11 2022 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 20 Oct 2022 15:00:11 GMT Subject: RFR: 8291914: generated constructors are considered compact when they shouldn't In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 06:13:40 GMT, Jan Lahoda wrote: > Looks good to me. thanks for the review ------------- PR: https://git.openjdk.org/jdk/pull/10756 From vromero at openjdk.org Thu Oct 20 15:01:53 2022 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 20 Oct 2022 15:01:53 GMT Subject: Integrated: 8291914: generated constructors are considered compact when they shouldn't In-Reply-To: References: Message-ID: <_cqWLr9edzXUTP2aNYY8Rad2W1zd4lc-YgAn149y0Ao=.785be4ef-bb3f-4cac-943f-c4aa6e44b043@github.com> On Wed, 19 Oct 2022 04:52:29 GMT, Vicente Romero wrote: > javac is considering all record generated constructors as compact constructors. According to the spec compact constructors should be declared explicitly. This constructor is compact: > > record R1(int i) { > R1 {} > } > > here there is no explicit constructor so the compiler is providing one but it shouldn't be considered a compact constructor: > > record R2(int i) {} > > this PR is fixing the current compiler bug so that for declarations like record R2 the compiler generated constructor is not considered a compact one. > > TIA This pull request has now been integrated. Changeset: 95dd376b Author: Vicente Romero URL: https://git.openjdk.org/jdk/commit/95dd376ba249b9eb8ab40a957238dfd79e60112f Stats: 9 lines in 4 files changed: 2 ins; 0 del; 7 mod 8291914: generated constructors are considered compact when they shouldn't Reviewed-by: darcy, jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/10756 From jlahoda at openjdk.org Thu Oct 20 15:25:51 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Oct 2022 15:25:51 GMT Subject: Integrated: 8294670: Enhanced switch statements have an implicit default which does not complete normally In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 14:48:57 GMT, Jan Lahoda wrote: > When a synthetic `default` is generated for enhanced switch, it never completes normally, which should be used when detecting liveness after the switch statement, which is what this patch is trying to do. This pull request has now been integrated. Changeset: 7bc9692a Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/7bc9692a5181a0db92ac2e0bca83dfe0bf2de05a Stats: 119 lines in 4 files changed: 114 ins; 2 del; 3 mod 8294670: Enhanced switch statements have an implicit default which does not complete normally Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/10540 From vromero at openjdk.org Thu Oct 20 15:38:46 2022 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 20 Oct 2022 15:38:46 GMT Subject: RFR: 8292159: TYPE_USE annotations on generic type arguments of record components discarded [v4] In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 09:03:10 GMT, Srikanth Adayapalam wrote: >> Handle carryover of type annotations to record components in a place which will be >> reached regardless of whether there are any annotations in a SE5 annotation location. > > Srikanth Adayapalam 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 five additional commits since the last revision: > > - Merge branch 'master' into JDK-8292159 > - Incorporate review comments from Vicente (Thanks!) > - Merge branch 'master' into JDK-8292159 > - Merge branch 'master' into JDK-8292159 > - 8292159: TYPE_USE annotations on generic type arguments of record components discarded looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10741 From vromero at openjdk.org Thu Oct 20 15:45:53 2022 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 20 Oct 2022 15:45:53 GMT Subject: Integrated: 8029633: Raw inner class constructor ref should not perform diamond inference In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 20:20:14 GMT, Vicente Romero wrote: > This PR is synchronizing the compiler with the spec, in particular with this portion of section `15.13.1 Compile-Time Declaration of a Method Reference`: > > > ? If the method reference expression has the form ClassType :: > [TypeArguments] new , then the potentially applicable methods are a set of > notional methods corresponding to the constructors of ClassType. > If ClassType is a raw type, but is not a non- static member type of a raw type, > the candidate notional member methods are those specified in ?15.9.3 for a > class instance creation expression that uses <> to elide the type arguments to a > class. Otherwise, the candidate notional member methods are the constructors > of ClassType, treated as if they were methods with return type ClassType. > > so javac should treat the code below as a raw constructor invocation: > > > class Outer { > class Inner {} > > Supplier.Inner> s = Outer.Inner::new; > } > > currently javac is rejecting this code > > TIA > > PS. Please review the related CSR too This pull request has now been integrated. Changeset: 6707bfbc Author: Vicente Romero URL: https://git.openjdk.org/jdk/commit/6707bfbc153de193b891c1ad3d4d8d0a6ee62307 Stats: 32 lines in 3 files changed: 31 ins; 0 del; 1 mod 8029633: Raw inner class constructor ref should not perform diamond inference Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/9784 From archie.cobbs at gmail.com Thu Oct 20 15:50:54 2022 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 20 Oct 2022 10:50:54 -0500 Subject: RFR: 7039014: Confusing error message for method conflict [v3] In-Reply-To: <6olTcVT2eDBEu8MJh56kzXCr9-RiAI5GHjc2SkIeiYg=.0d7cb8bd-4278-4d66-870d-f2284af08281@github.com> References: <6olTcVT2eDBEu8MJh56kzXCr9-RiAI5GHjc2SkIeiYg=.0d7cb8bd-4278-4d66-870d-f2284af08281@github.com> Message-ID: On Wed, Oct 19, 2022 at 11:51 PM Vicente Romero wrote: > >> This fixes a confusing error message. > > looks good > Thanks very much for the quick review. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Oct 20 15:55:24 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 20 Oct 2022 15:55:24 GMT Subject: RFR: 7176515: ExceptionInInitializerError for an enum with multiple switch statements Message-ID: This patch is both a minor optimization and a fix for JDK-7176515. JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar". The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later. Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug. This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table. This results in two improvements: * It avoids building the lookup table for switches on self * It fixes JDK-7176515 as stated Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out). So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it. Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled. ------------- Commit messages: - Skip enum switch lookup tables when compiling the enum switch class. Changes: https://git.openjdk.org/jdk/pull/10797/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10797&range=00 Issue: https://bugs.openjdk.org/browse/JDK-7176515 Stats: 166 lines in 2 files changed: 156 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10797.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10797/head:pull/10797 PR: https://git.openjdk.org/jdk/pull/10797 From erikj at openjdk.org Thu Oct 20 18:26:46 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 20 Oct 2022 18:26:46 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie wrote: > Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. > > With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). > > The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. Nice job! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/10792 From naoto at openjdk.org Thu Oct 20 18:33:47 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 20 Oct 2022 18:33:47 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: <0VhVC2dpGOdpE3OL1278r0iCVXO1Jd_83Q4kszfikjY=.fecfe4ed-9a48-4fe4-827a-7ab1bc2defa2@github.com> On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie wrote: > Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. > > With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). > > The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. LGTM. Haven't looked at all the l10n files. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/10792 From angorya at openjdk.org Thu Oct 20 18:40:47 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Oct 2022 18:40:47 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie wrote: > Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. > > With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). > > The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. I would vote against this change. Per java properties spec https://github.com/openjdk/jdk/pull/10792 White space following the property value is not ignored, and is treated as part of the property value. This change might break localization or messages where trailing whitespace is important (example: "Label: ") ------------- PR: https://git.openjdk.org/jdk/pull/10792 From ihse at openjdk.org Thu Oct 20 18:48:17 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Oct 2022 18:48:17 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > I would vote against this change. Per java properties spec > https://github.com/openjdk/jdk/pull/10792 > > > White space following the property value is not ignored, and is treated as part of the property value. > > > This change might break localization or messages where trailing whitespace is important (example: "Label: ") > > edit: sorry, the link above is not a spec. looking at the Properties.load(Reader) javadoc: > https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader) > > > Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string; @andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From erikj at openjdk.org Thu Oct 20 18:53:49 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 20 Oct 2022 18:53:49 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie wrote: > Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. > > With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). > > The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. Given that trailing whitespace may be part of a property value, then I take back my review. ------------- Changes requested by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/10792 From cjplummer at openjdk.org Thu Oct 20 18:53:50 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 20 Oct 2022 18:53:50 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev wrote: > `White space following the property value is not ignored, and is treated as part of the property value.` Although I didn't know this was in the spec, I suspected it might be the case. When looking at the jdk.management.agent changes, it looked like the extra space was actually a typo and was copied into all the localized versions (and not actually localized for unicode locales). In this case removing the white space is the right thing to do. It is in fact fixing an actual bug. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From angorya at openjdk.org Thu Oct 20 18:53:51 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Oct 2022 18:53:51 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 18:46:04 GMT, Magnus Ihse Bursie wrote: >> I would vote against this change. Per java properties spec >> https://github.com/openjdk/jdk/pull/10792 >> >> >> White space following the property value is not ignored, and is treated as part of the property value. >> >> >> This change might break localization or messages where trailing whitespace is important (example: "Label: ") >> >> edit: sorry, the link above is not a spec. looking at the Properties.load(Reader) javadoc: >> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader) >> >> >> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string; > > @andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored. @magicus : no, this is how Properties were working from day one. package goryachev.research; import java.io.IOException; import java.io.StringReader; import java.util.Properties; public class TestProperties { public static void main(String[] args) throws IOException { String text = "key= value "; Properties p = new Properties(); p.load(new StringReader(text)); System.out.println("value=[" +p.getProperty("key") + "]"); } } outputs: value=[value ] ------------- PR: https://git.openjdk.org/jdk/pull/10792 From ihse at openjdk.org Thu Oct 20 19:07:52 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 20 Oct 2022 19:07:52 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie wrote: > Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. > > With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). > > The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. Okay. That definitely rules out adding .properties to the whitespace jcheck verification. However, I think that instead opens up a ton of more individual problems, since I think most (if perhaps not all) of these trailing whitespaces are incidental, and thus might be bugs. Perhaps no-one really noticed a double whitespace where it were not supposed to be, etc, especially not if it was just for a translated language. I'm thinking I should redirect this PR to skip the jcheck requirement, and revert all changes to property values, but keep the part of the patch that removes trailing spaces in `#` comment lines. That seems to account for a majority of the changes. For the remaining properties files with trailing spaces in the actual values, I'll make a sanity check if it seems correct or not, and if it looks fishy, I'll open bugs on the respective component teams to verify that their property values are indeed correct. Does that sound reasonable? ------------- PR: https://git.openjdk.org/jdk/pull/10792 From naoto at openjdk.org Thu Oct 20 19:29:51 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 20 Oct 2022 19:29:51 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie wrote: > Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. > > With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). > > The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. Retracting my approval too. Thanks for the catch, Andy! That sounds reasonable > Magnus ------------- PR: https://git.openjdk.org/jdk/pull/10792 From naoto at openjdk.org Thu Oct 20 19:40:55 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 20 Oct 2022 19:40:55 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie wrote: > Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. > > With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). > > The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. (retracting approval) ------------- Changes requested by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/10792 From duke at openjdk.org Thu Oct 20 20:23:07 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 20 Oct 2022 20:23:07 GMT Subject: RFR: 8155259: Suspicious buffer allocation in com.sun.tools.javac.file.BaseFileManager Message-ID: JDK-8155259 notes that in `BaseFileManager` this code: ByteBuffer.allocate(capacity + capacity>>1) is actually equivalent (assuming no overflow) to: ByteBuffer.allocate(capacity) because in Java the `+` operator has higher precedence than the `>>` operator. In the bug it is suggested that this be changed to reflect the presumed original intent to over-allocate by 50%, i.e.: ByteBuffer.allocate(capacity + (capacity>>1)) however, this patch is more conservative in that it leaves the existing behavior alone and instead just simplifies it to: ByteBuffer.allocate(capacity) allowing us to at least resolve JDK-8155259. ------------- Commit messages: - 8155259: Suspicious buffer allocation in com.sun.tools.javac.file.BaseFileManager Changes: https://git.openjdk.org/jdk/pull/10803/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10803&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8155259 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10803.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10803/head:pull/10803 PR: https://git.openjdk.org/jdk/pull/10803 From duke at openjdk.org Thu Oct 20 21:47:47 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 20 Oct 2022 21:47:47 GMT Subject: RFR: 8155259: Suspicious buffer allocation in com.sun.tools.javac.file.BaseFileManager In-Reply-To: References: Message-ID: <7VRafYttMuVK8fN6wD_z497QbuGgmQnsXhmUTF0uync=.25c59134-f38b-497a-91b5-15ba279501d1@github.com> On Thu, 20 Oct 2022 20:15:12 GMT, Archie L. Cobbs wrote: > JDK-8155259 notes that in `BaseFileManager` this code: > > ByteBuffer.allocate(capacity + capacity>>1) > > is actually equivalent (assuming no overflow) to: > > ByteBuffer.allocate(capacity) > > because in Java the `+` operator has higher precedence than the `>>` operator. > > In the bug it is suggested that this be changed to reflect the presumed original intent to over-allocate by 50%, i.e.: > > ByteBuffer.allocate(capacity + (capacity>>1)) > > however, this patch is more conservative in that it leaves the existing behavior alone and instead just simplifies it to: > > ByteBuffer.allocate(capacity) > > allowing us to at least resolve JDK-8155259. I just realized this change actually fixes another bug: > [JDK-8172106](https://bugs.openjdk.org/browse/JDK-8172106) - javac throws exception when compiling source file of size 1.5G ------------- PR: https://git.openjdk.org/jdk/pull/10803 From archie.cobbs at gmail.com Thu Oct 20 22:56:24 2022 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 20 Oct 2022 17:56:24 -0500 Subject: Bugs that are inadvertently fixed In-Reply-To: References: Message-ID: On Tue, Oct 18, 2022 at 3:45 PM Michel Trudeau wrote: > Please keep reporting. It?s useful info. > Here are a few more that I've found so far. FYI I'm testing with JDK 19. JDK-7158531 - Not sure (no reproducing example given) but from inspection it looks like it's fixed JDK-7167356 - Partially fixed JavacParserTest.testPositionBrokenSource126732a() is working now - can be re-enabled JavacParserTest.testPositionBrokenSource126732b() is working now - can be re-enabled JavacParserTest.testStartPositionEnumConstantInit() is still broken JDK-8006042 - Appears to be fixed JDK-8024687 - Possibly fixed? - the behavior has changed at least: Test.java:3: error: namePrep has private access in IDN { IDN.namePrep.toString(); } ^ Test.java:3: error: Object.toString() is defined in an inaccessible class or interface { IDN.namePrep.toString(); } ^ 2 errors JDK-8024317 - Locking is no longer used so the bug as reported appears to be fixed. JDK-8027682 - Appears to be fixed JDK-8034251 - I don't understand what the bug is here. Compiler seems to be doing the right thing. JDK-8043279 - Appears to be fixed (based on the linked test case in JDK-8034147 ) JDK-8044734 - Appears to be fixed JDK-8048547 - Appears to be fixed These next six bugs all seem to be one identical bug filed multiple times: JDK-8052121 - Appears to be fixed JDK-8052135 - Appears to be fixed JDK-8054274 - Appears to be fixed JDK-8054275 - Appears to be fixed JDK-8054276 - Appears to be fixed JDK-8054284 - Appears to be fixed JDK-8065572 - Appears to be fixed JDK-8065988 - Appears to be fixed JDK-8130386 - Appears to be fixed JDK-8130401 - Appears to be fixed JDK-8151992 - Probably can resolve now as not reproducible JDK-8152894 - Appears to be fixed JDK-8155907 - Appears to be fixed JDK-8157773 - Appears to be fixed JDK-8159667 - Appears to be fixed JDK-8166209 - Appears to be fixed JDK-8172106 - Soon to be "inadvertently" fixed by pr#10803 :) JDK-8174921 - Appears to be fixed JDK-8179359 - Link to test case is broken, so this bug seems no longer decipherable JDK-8180387 - Is fixed to the extent that the JavacTask() constructor is now documented JDK-8184324 - Probably no longer reproducible because it's based on another project in 2017 JDK-8184224 - Appears to be fixed JDK-8186030 - Appears to be fixed JDK-8187425 - Appears to be fixed JDK-8191896 - IMHO this is not a bug. The compiler is simply reporting only the first of two problems. JDK-8194847 - Appears to be fixed JDK-8200156 - Appears to be fixed This has been an interesting tour so far. I'm going in order of creation time and am up to March 2018. Just looking at ones that are easy for me to try to reproduce. My query is: component = tools AND Subcomponent = javac AND status = OPEN AND type = Bug order by created asc Several of the old bugs that are still around are stuck waiting on JLS clarification. I wonder whether that has happened, or whether JLS clarification is itself somehow stuck (a thought that's slightly disturbing). -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From sadayapalam at openjdk.org Fri Oct 21 03:01:20 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Fri, 21 Oct 2022 03:01:20 GMT Subject: RFR: 8292159: TYPE_USE annotations on generic type arguments of record components discarded [v5] In-Reply-To: References: Message-ID: > Handle carryover of type annotations to record components in a place which will be > reached regardless of whether there are any annotations in a SE5 annotation location. Srikanth Adayapalam 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 six additional commits since the last revision: - Merge branch 'master' into JDK-8292159 - Merge branch 'master' into JDK-8292159 - Incorporate review comments from Vicente (Thanks!) - Merge branch 'master' into JDK-8292159 - Merge branch 'master' into JDK-8292159 - 8292159: TYPE_USE annotations on generic type arguments of record components discarded ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10741/files - new: https://git.openjdk.org/jdk/pull/10741/files/1f9085e6..4b82002a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10741&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10741&range=03-04 Stats: 2725 lines in 109 files changed: 1194 ins; 1093 del; 438 mod Patch: https://git.openjdk.org/jdk/pull/10741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10741/head:pull/10741 PR: https://git.openjdk.org/jdk/pull/10741 From ihse at openjdk.org Fri Oct 21 08:17:46 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 21 Oct 2022 08:17:46 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v2] In-Reply-To: References: Message-ID: > Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. > > With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). > > The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Remove check for .properties from jcheck - Restore trailing whitespace for property values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10792/files - new: https://git.openjdk.org/jdk/pull/10792/files/e33c0765..c91fdaa1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=00-01 Stats: 412 lines in 131 files changed: 0 ins; 0 del; 412 mod Patch: https://git.openjdk.org/jdk/pull/10792.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792 PR: https://git.openjdk.org/jdk/pull/10792 From ihse at openjdk.org Fri Oct 21 08:31:59 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 21 Oct 2022 08:31:59 GMT Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in properties files [v2] In-Reply-To: References: Message-ID: <1mu65mMxl2Nf-mwa4iZczOBqJbPdutKpL6dE_3vMWcg=.c03430ed-70df-40fa-994e-700080b7b8fa@github.com> On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove check for .properties from jcheck > - Restore trailing whitespace for property values Ok, I repurposed this PR to deal only with trailing space on non-value lines (comments and empty lines). This should be trivial, and will reduce the trailing spaces to only the value lines. I believe most, but perhaps not all, trailing spaces in the value lines are actually bugs, but that will need further scrutiny by the owners of the properties files. Expect follow up bugs on this. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From sadayapalam at openjdk.org Fri Oct 21 09:45:34 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Fri, 21 Oct 2022 09:45:34 GMT Subject: RFR: 8059632: Method reference compilation uses incorrect qualifying type Message-ID: Align with JLS 13.1 (the qualifying class or interface of the method invocation) by referring to the type of the receiver rather than the type of the declaring class/interface in the bootstrap attribute ------------- Commit messages: - Fix whitespace problem - 8059632: Method reference compilation uses incorrect qualifying type Changes: https://git.openjdk.org/jdk/pull/10809/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10809&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8059632 Stats: 376 lines in 6 files changed: 325 ins; 47 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10809.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10809/head:pull/10809 PR: https://git.openjdk.org/jdk/pull/10809 From sadayapalam at openjdk.org Fri Oct 21 09:45:35 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Fri, 21 Oct 2022 09:45:35 GMT Subject: RFR: 8059632: Method reference compilation uses incorrect qualifying type In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 09:31:11 GMT, Srikanth Adayapalam wrote: > Align with JLS 13.1 (the qualifying class or interface of the method invocation) by > referring to the type of the receiver rather than the type of the declaring > class/interface in the bootstrap attribute test/langtools/tools/javac/lambda/methodReference/8059632/MethodRefQualifyingTypeTest.java line 75: > 73: // per JLS 13.1 (see "the qualifying type of the method invocation"). > 74: > 75: Class.forName("MethodRefQualifyingTypeTest$MethodInvoker").getMethod("invoke").invoke(null); This test is actually derived from a "failing" JCK test: lang/LMBD/lmbd171/lmbd17101m51/lmbd17101m51.html.lmbd17101m51 that incorrectly asserts that there be a linkage error ------------- PR: https://git.openjdk.org/jdk/pull/10809 From mcimadamore at openjdk.org Fri Oct 21 10:22:15 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Oct 2022 10:22:15 GMT Subject: RFR: 8059632: Method reference compilation uses incorrect qualifying type In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 09:31:11 GMT, Srikanth Adayapalam wrote: > Align with JLS 13.1 (the qualifying class or interface of the method invocation) by > referring to the type of the receiver rather than the type of the declaring > class/interface in the bootstrap attribute Looks very good to me. Nice unification of the code, the spec is quite clear on this (binary form of method references and method invocation should be the same). src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3651: > 3649: // array clone can be qualified by the array type in later targets > 3650: Symbol qualifier; > 3651: if ((qualifier = qualifiedSymbolCache.get(site)) == null) { I know this code has been moved here from Gen - I'd be very very curious to understand if the caching mechanism actually does anything meaningful performance-wise. Seems just a way to add more state. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/10809 From mcimadamore at openjdk.org Fri Oct 21 10:22:15 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Oct 2022 10:22:15 GMT Subject: RFR: 8059632: Method reference compilation uses incorrect qualifying type In-Reply-To: References: Message-ID: <59W9YaRAQ4Uy7VhjxyX_T4T1v4u0FHN4gVe6D_05Ht8=.66642704-992c-4ddf-a7c1-ceae1fbec01d@github.com> On Fri, 21 Oct 2022 10:10:48 GMT, Maurizio Cimadamore wrote: >> Align with JLS 13.1 (the qualifying class or interface of the method invocation) by >> referring to the type of the receiver rather than the type of the declaring >> class/interface in the bootstrap attribute > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3651: > >> 3649: // array clone can be qualified by the array type in later targets >> 3650: Symbol qualifier; >> 3651: if ((qualifier = qualifiedSymbolCache.get(site)) == null) { > > I know this code has been moved here from Gen - I'd be very very curious to understand if the caching mechanism actually does anything meaningful performance-wise. Seems just a way to add more state. Needs a CSR, given the potential change to the set of programs that might run correctly. ------------- PR: https://git.openjdk.org/jdk/pull/10809 From abimpoudis at openjdk.org Fri Oct 21 12:44:24 2022 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Fri, 21 Oct 2022 12:44:24 GMT Subject: RFR: 8294943: Implement record patterns in enhanced for Message-ID: This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: record Complex(double real, double img) {} List list = ...; for (Complex(var real, var img) : list) { // can use ?real? and ?img? directly } This PR proposes an implementation for the "Record Patterns in Enhanced For" subtask regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following: - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`. - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression. - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`. - The enhanced for, supports record patterns for both arrays and reference types. Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason. For more information on the changes please see: - the JEP: [JEP 432](https://openjdk.org/jeps/432) - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) Looking forward for your review. ------------- Commit messages: - Store element type calculation result in JCEnhancedForLoop - API cleanup. - Adding @since, adding PreviewFeature, restoring API method. - 8294943: Implement record patterns in enhanced for Changes: https://git.openjdk.org/jdk/pull/10798/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294943 Stats: 602 lines in 21 files changed: 532 ins; 7 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/10798.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798 PR: https://git.openjdk.org/jdk/pull/10798 From erikj at openjdk.org Fri Oct 21 12:59:48 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 21 Oct 2022 12:59:48 GMT Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in properties files [v2] In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove check for .properties from jcheck > - Restore trailing whitespace for property values Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10792 From duke at openjdk.org Fri Oct 21 15:40:32 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 21 Oct 2022 15:40:32 GMT Subject: RFR: 8200610: Compiling fails with java.nio.file.ReadOnlyFileSystemException Message-ID: In `JavaCompiler`, when trying to write a class file, if an `IOException`s is thrown, instead of crashing, we report a normal error" `error while writing [file]: ...`. However there are some I/O errors that can generate `RuntimeException`s not caught by this logic. So instead these errors cause a compiler crash. An example is given in JDK-8200610, where the compiler tries to write into a ZIP file system and a `java.nio.file.ReadOnlyFileSystemException` is thrown. This patch adds that exception and a couple of others which (in my estimation) could reasonably be expected to be thrown in various obscure cases involving alternative file systems: `FileSystemNotFoundException` and `InvalidPathException`. Any suggestions on what the most appropriate list of exception types to include here are appreciated. ------------- Commit messages: - Catch and report some java.nio.file.* exceptions along with IOException. Changes: https://git.openjdk.org/jdk/pull/10818/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10818&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8200610 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10818.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10818/head:pull/10818 PR: https://git.openjdk.org/jdk/pull/10818 From naoto at openjdk.org Fri Oct 21 16:09:28 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 21 Oct 2022 16:09:28 GMT Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in properties files [v2] In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove check for .properties from jcheck > - Restore trailing whitespace for property values One possible solution to this is to replace those dangling white spaces with explicit Unicode escapes, i.e. "\u0009" and "\u0020". This way jcheck can safely be enabled to detect future unwanted trailing spaces, and possibly existing ones can be visually recognizable by the engineers to correct them. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From angorya at openjdk.org Fri Oct 21 16:09:29 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Oct 2022 16:09:29 GMT Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in properties files [v2] In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 16:04:14 GMT, Naoto Sato wrote: > replace those dangling white spaces with explicit Unicode escapes this is a *very good* idea. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From michel.trudeau at oracle.com Fri Oct 21 16:20:19 2022 From: michel.trudeau at oracle.com (Michel Trudeau) Date: Fri, 21 Oct 2022 16:20:19 +0000 Subject: Bugs that are inadvertently fixed In-Reply-To: References: Message-ID: Thank you Archie, that?s great. We?ll process those in the next week or so. -Michel From: compiler-dev on behalf of Archie Cobbs Date: Thursday, October 20, 2022 at 3:56 PM To: compiler-dev at openjdk.org Subject: Re: Bugs that are inadvertently fixed On Tue, Oct 18, 2022 at 3:45 PM Michel Trudeau > wrote: Please keep reporting. It?s useful info. Here are a few more that I've found so far. FYI I'm testing with JDK 19. JDK-7158531 - Not sure (no reproducing example given) but from inspection it looks like it's fixed JDK-7167356 - Partially fixed JavacParserTest.testPositionBrokenSource126732a() is working now - can be re-enabled JavacParserTest.testPositionBrokenSource126732b() is working now - can be re-enabled JavacParserTest.testStartPositionEnumConstantInit() is still broken JDK-8006042 - Appears to be fixed JDK-8024687 - Possibly fixed? - the behavior has changed at least: Test.java:3: error: namePrep has private access in IDN { IDN.namePrep.toString(); } ^ Test.java:3: error: Object.toString() is defined in an inaccessible class or interface { IDN.namePrep.toString(); } ^ 2 errors JDK-8024317 - Locking is no longer used so the bug as reported appears to be fixed. JDK-8027682 - Appears to be fixed JDK-8034251 - I don't understand what the bug is here. Compiler seems to be doing the right thing. JDK-8043279 - Appears to be fixed (based on the linked test case in JDK-8034147) JDK-8044734 - Appears to be fixed JDK-8048547 - Appears to be fixed These next six bugs all seem to be one identical bug filed multiple times: JDK-8052121 - Appears to be fixed JDK-8052135 - Appears to be fixed JDK-8054274 - Appears to be fixed JDK-8054275 - Appears to be fixed JDK-8054276 - Appears to be fixed JDK-8054284 - Appears to be fixed JDK-8065572 - Appears to be fixed JDK-8065988 - Appears to be fixed JDK-8130386 - Appears to be fixed JDK-8130401 - Appears to be fixed JDK-8151992 - Probably can resolve now as not reproducible JDK-8152894 - Appears to be fixed JDK-8155907 - Appears to be fixed JDK-8157773 - Appears to be fixed JDK-8159667 - Appears to be fixed JDK-8166209 - Appears to be fixed JDK-8172106 - Soon to be "inadvertently" fixed by pr#10803 :) JDK-8174921 - Appears to be fixed JDK-8179359 - Link to test case is broken, so this bug seems no longer decipherable JDK-8180387 - Is fixed to the extent that the JavacTask() constructor is now documented JDK-8184324 - Probably no longer reproducible because it's based on another project in 2017 JDK-8184224 - Appears to be fixed JDK-8186030 - Appears to be fixed JDK-8187425 - Appears to be fixed JDK-8191896 - IMHO this is not a bug. The compiler is simply reporting only the first of two problems. JDK-8194847 - Appears to be fixed JDK-8200156 - Appears to be fixed This has been an interesting tour so far. I'm going in order of creation time and am up to March 2018. Just looking at ones that are easy for me to try to reproduce. My query is: component = tools AND Subcomponent = javac AND status = OPEN AND type = Bug order by created asc Several of the old bugs that are still around are stuck waiting on JLS clarification. I wonder whether that has happened, or whether JLS clarification is itself somehow stuck (a thought that's slightly disturbing). -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Oct 21 17:23:29 2022 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 21 Oct 2022 10:23:29 -0700 Subject: Bugs that are inadvertently fixed In-Reply-To: References: Message-ID: +lots !! -- Jon On 10/21/22 9:20 AM, Michel Trudeau wrote: > > Thank you Archie, that?s great.?? We?ll process those in the next week > or so. > > -Michel > > *From: *compiler-dev on behalf of > Archie Cobbs > *Date: *Thursday, October 20, 2022 at 3:56 PM > *To: *compiler-dev at openjdk.org > *Subject: *Re: Bugs that are inadvertently fixed > > On Tue, Oct 18, 2022 at 3:45 PM Michel Trudeau > wrote: > > Please keep reporting.?? It?s useful info. > > Here are a few more that I've found so far. FYI I'm testing with JDK 19. > > JDK-7158531 - Not sure > (no reproducing example given) but from inspection it looks like it's > fixed > > JDK-7167356 - Partially > fixed > > JavacParserTest.testPositionBrokenSource126732a() is working now - can > be re-enabled > > JavacParserTest.testPositionBrokenSource126732b() is working now - can > be re-enabled > > JavacParserTest.testStartPositionEnumConstantInit() is still broken > > JDK-8006042 - Appears to > be fixed > > JDK-8024687 - Possibly > fixed? - the behavior has changed at least: > > Test.java:3: error: namePrep has private access in IDN > { IDN.namePrep.toString(); } > ?^ > Test.java:3: error: Object.toString() is defined in an inaccessible > class or interface > { IDN.namePrep.toString(); } > ? ? ? ? ? ^ > 2 errors > > JDK-8024317 - Locking is > no longer used so the bug as reported appears to be fixed. > > JDK-8027682 - Appears to > be fixed > > JDK-8034251 - I don't > understand what the bug is here. Compiler seems to be doing the right > thing. > > JDK-8043279 - Appears to > be fixed (based on the linked test case in JDK-8034147 > ) > > JDK-8044734 - Appears to > be fixed > > JDK-8048547 - Appears to > be fixed > > These next six bugs all seem to be one identical bug filed multiple times: > > JDK-8052121 - Appears to > be fixed > > JDK-8052135 - Appears to > be fixed > > JDK-8054274 - Appears to > be fixed > > JDK-8054275 - Appears to > be fixed > > JDK-8054276 - Appears to > be fixed > > JDK-8054284 - Appears to > be fixed > > JDK-8065572 - Appears to > be fixed > > JDK-8065988 - Appears to > be fixed > > JDK-8130386 - Appears to > be fixed > > JDK-8130401 - Appears to > be fixed > > JDK-8151992 - Probably > can resolve now as not reproducible > > JDK-8152894 - Appears to > be fixed > > JDK-8155907 - Appears to > be fixed > > JDK-8157773 - Appears to > be fixed > > JDK-8159667 - Appears to > be fixed > > JDK-8166209 - Appears to > be fixed > > JDK-8172106 - Soon to be > "inadvertently" fixed by pr#10803 > :) > > JDK-8174921 - Appears to > be fixed > > JDK-8179359 - Link to > test case is broken, so this bug seems no longer decipherable > > JDK-8180387 - Is fixed > to the extent that the JavacTask() constructor is now documented > > JDK-8184324 - Probably > no longer reproducible because it's based on another project in 2017 > > JDK-8184224 - Appears to > be fixed > > JDK-8186030 - Appears to > be fixed > > JDK-8187425 - Appears to > be fixed > > JDK-8191896 - IMHO this > is not a bug. The compiler is simply reporting only the first of two > problems. > > JDK-8194847 - Appears to > be fixed > > JDK-8200156 - Appears to > be fixed > > This has been an interesting tour so far. I'm going in order of > creation time and am up to March 2018. Just looking at ones that are > easy for me to try to reproduce. > > My query is: component = tools AND Subcomponent = javac AND status = > OPEN AND type = Bug order by created asc > > Several of the old bugs that are still around are stuck waiting on JLS > clarification. I wonder whether that has happened, or whether JLS > clarification is itself somehow stuck (a thought that's slightly > disturbing). > > -Archie > > -- > > Archie L. Cobbs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.org Fri Oct 21 18:21:13 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 21 Oct 2022 18:21:13 GMT Subject: RFR: 7176515: ExceptionInInitializerError for an enum with multiple switch statements In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 15:46:01 GMT, Archie L. Cobbs wrote: > This patch is both a minor optimization and a fix for JDK-7176515. > > JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar". > > The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later. > > Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug. > > This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table. > > This results in two improvements: > * It avoids building the lookup table for switches on self > * It fixes JDK-7176515 as stated > > Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out). > > So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it. > > Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled. test/langtools/tools/javac/enum/T7176515.java line 32: > 30: import java.math.RoundingMode; > 31: > 32: public class T7176515 { We've generally moved away from naming test after the bug number, although that was a long-standing practice in the past. test/langtools/tools/javac/enum/T7176515.java line 90: > 88: boolean shouldBeOdd = true; > 89: for (MyEnum x : MyEnum.values()) { > 90: assert x.isOdd() == shouldBeOdd; While we do typically run the tests with assertions enabled, it is preferable if the tests did not rely on that for proper operation. ------------- PR: https://git.openjdk.org/jdk/pull/10797 From duke at openjdk.org Fri Oct 21 19:29:32 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 21 Oct 2022 19:29:32 GMT Subject: RFR: 7176515: ExceptionInInitializerError for an enum with multiple switch statements [v2] In-Reply-To: References: Message-ID: <0f4VMnC0bFx0DtxhdsIxddezZ3FpTFOQRLACHQyXXZg=.ccbcb894-603b-4a7c-9b4f-bc79b3a1c6a5@github.com> > This patch is both a minor optimization and a fix for JDK-7176515. > > JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar". > > The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later. > > Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug. > > This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table. > > This results in two improvements: > * It avoids building the lookup table for switches on self > * It fixes JDK-7176515 as stated > > Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out). > > So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it. > > Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled. Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Give test a better name and don't rely on assertions being enabled. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10797/files - new: https://git.openjdk.org/jdk/pull/10797/files/b5337927..8cd5b49c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10797&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10797&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10797.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10797/head:pull/10797 PR: https://git.openjdk.org/jdk/pull/10797 From duke at openjdk.org Fri Oct 21 19:29:34 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 21 Oct 2022 19:29:34 GMT Subject: RFR: 7176515: ExceptionInInitializerError for an enum with multiple switch statements [v2] In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 18:17:35 GMT, Joe Darcy wrote: >> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Give test a better name and don't rely on assertions being enabled. > > test/langtools/tools/javac/enum/T7176515.java line 32: > >> 30: import java.math.RoundingMode; >> 31: >> 32: public class T7176515 { > > We've generally moved away from naming test after the bug number, although that was a long-standing practice in the past. Thanks for the heads-up. Test name updated in 8cd5b49c5f2. > test/langtools/tools/javac/enum/T7176515.java line 90: > >> 88: boolean shouldBeOdd = true; >> 89: for (MyEnum x : MyEnum.values()) { >> 90: assert x.isOdd() == shouldBeOdd; > > While we do typically run the tests with assertions enabled, it is preferable if the tests did not rely on that for proper operation. Good idea - thanks. Fixed in 8cd5b49c5f2. ------------- PR: https://git.openjdk.org/jdk/pull/10797 From daniel.smith at oracle.com Fri Oct 21 19:47:19 2022 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 21 Oct 2022 19:47:19 +0000 Subject: Surprised that TYPE_USE annotations are accepted on `var` lambda parameters In-Reply-To: References: Message-ID: <98D5C067-0CC1-4413-A967-39531481ACEC@oracle.com> On Oct 11, 2022, at 12:17 PM, Chris Povirk > wrote: I didn't find a clear statement either way in my browsing of the JLS. On the one hand, JLS 9.7.4 specifically forbids using type-use annotations with var only for local variables: "If the annotation appears before a void method declaration or a local variable declaration that uses var (?14.4), then there is no closest type." On the other hand, I don't think any of the JLS rules for finding the "closest type" would apply in the case of a var lambda parameter. Thanks for noticing this, I've filed a bug to fix the spec: https://bugs.openjdk.org/browse/JDK-8295807 I've CC'ed Srikanth who can pursue a bug fix for javac. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Fri Oct 21 20:00:43 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 21 Oct 2022 13:00:43 -0700 Subject: RFR: 8294943: Implement record patterns in enhanced for In-Reply-To: References: Message-ID: <3624c93f-d5f8-0be6-009d-cc84fba89812@oracle.com> JLS 14.14.2 comments: 1. The verbiage around "the header of the enhanced for statement" is painful at times, e.g. "References to the local variable declared in a local variable declaration contained in the header of the enhanced for statement from a nested class ..." First, observe that using the word "header" in narrative text is proper only when the grammar has a *Header production, see 8.4 and 8.10. (Note that 14.14.1 doesn't have *Header, so its narrative doesn't use "header"; instead, its narrative refers to productions like ForInit directly.) Rename EnhancedForDeclaration to EnhancedForHeader so that "the header of the enhanced for statement" is grounded. Second, you can generally move faster in the narrative, e.g. "The header of the enhanced for statement contains either (i) the declaration of a local variable whose name is the identifier given by VariableDeclaratorId ..." and "If the header of the enhanced for statement is a local variable declaration, the rules for the local variable are specified in 14.4 ..." 2. The CSR says "The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression." so I went looking for this sensible rule in 14.14.2. What I found is this note buried deep inside the translation items: "If T is the type of the expression #i.next() this translation implies both (i) the record pattern p must be applicable at the type T (14.30.3), and (ii) the set containing the record pattern p must be exhaustive for the type T (14.11.1.1)." This relationship between the record pattern and T is critical. Hardly any readers will be able to join the dots offered by the current note. Please turn everything around: before the translation, state the sensible rule as plainly as possible, appending "or a compile-time error occurs"; then give the relationship in more detail: "Specifically, (i) the record pattern must be applicable at the type ... (ii) ... must be exhaustive ..."; and finally give a note claiming "The translation below implies that these properties are true." Alex On 10/21/2022 5:44 AM, Aggelos Biboudis wrote: > This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: > > > record Complex(double real, double img) {} > > List list = ...; > > for (Complex(var real, var img) : list) { > // can use ?real? and ?img? directly > } > > > This PR proposes an implementation for the "Record Patterns in Enhanced For" subtask regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following: > > - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`. > - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. > - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression. > - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`. > - The enhanced for, supports record patterns for both arrays and reference types. > > Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason. > > For more information on the changes please see: > > - the JEP: [JEP 432](https://openjdk.org/jeps/432) > - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) > - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) > > Looking forward for your review. > > ------------- > > Commit messages: > - Store element type calculation result in JCEnhancedForLoop > - API cleanup. > - Adding @since, adding PreviewFeature, restoring API method. > - 8294943: Implement record patterns in enhanced for > > Changes: https://git.openjdk.org/jdk/pull/10798/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8294943 > Stats: 602 lines in 21 files changed: 532 ins; 7 del; 63 mod > Patch: https://git.openjdk.org/jdk/pull/10798.diff > Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798 > > PR: https://git.openjdk.org/jdk/pull/10798 From duke at openjdk.org Fri Oct 21 22:37:10 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 21 Oct 2022 22:37:10 GMT Subject: RFR: 8219810: javac throws NullPointerException Message-ID: JVMS 4.5 states: > Each field of a class may have at most one of its ACC_PUBLIC, ACC_PRIVATE, and ACC_PROTECTED flags set (JLS ?8.3.1), and must not have both its ACC_FINAL and ACC_VOLATILE flags set (JLS ?8.3.1.4). and JVMS 4.6 states: > Each method of a class may have at most one of its ACC_PUBLIC, ACC_PRIVATE, and ACC_PROTECTED flags set (JLS ?8.4.3). However, when reading class files these illegal combinations are not actually checked, and this can lead to compiler crashes as in the bug example. This patch adds checks for these illegal combinations. ------------- Commit messages: - Also disallow field access flags from having both FINAL and VOLATILE. - Detect invalid access flag combinations for fields and methods in classfiles. Changes: https://git.openjdk.org/jdk/pull/10826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10826&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8219810 Stats: 194 lines in 9 files changed: 192 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10826.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10826/head:pull/10826 PR: https://git.openjdk.org/jdk/pull/10826 From archie.cobbs at gmail.com Sat Oct 22 02:33:44 2022 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Fri, 21 Oct 2022 21:33:44 -0500 Subject: Draft PR for JDK-8043251: Bogus javac error: required: no arguments, found: no arguments Message-ID: I'm looking for any thoughts or comments on a draft PR for JDK-8043251 "Bogus javac error: required: no arguments, found: no arguments" Here's the summary: We have an error message compiler.err.cant.apply.symbol for cases where a > method invocation doesn't work. It shows the "required" parameters and the > "found" parameters, plus a further description of the problem. > > This message being used inappropriately when the problem is actually due > to the method's type parameters instead of its method parameters. > > For example, if you do this: > > Function f = Function.identity(); > > the error reported is this: > > error: method identity in interface Function cannot be applied to given types; > Function f = Function.identity(); > ^ > required: no arguments > found: no arguments > reason: wrong number of type arguments; required 1 > where T,R are type-variables: > T extends Object declared in interface Function > R extends Object declared in interface Function > > This patch creates a alternate version of that error message ( > compiler.err.cant.apply.symbol.noargs) that omits the "required" and > "found" lines. In the example above you instead get this: > > error: method identity in interface Function cannot be applied to given types; > Function f = Function.identity(); > ^ > reason: wrong number of type arguments; required 1 > where T,R are type-variables: > T extends Object declared in interface Function > R extends Object declared in interface Function > 1 error > > However, I'm not satisfied with how this patch works and am looking for > suggestions on how to improve it (that's why this is a draft PR). > > Currently it simply looks for cases where the error is due to "wrong > number of type arguments" or "explicit type argument X does not conform to > declared bound(s)" (by checking the error key), and if so it uses the > alternate form. > > At least two aspects could be improved.. > > - Looking at the diagnostic key to differentiate type parameter > mismatches vs. regular parameter mismatches seems a little kludgey. Is > there a better way? Maybe a new flag added to InapplicableSymbolError? > - Ideally, for type parameter errors we would keep the "required" and > "found" lines, but display the type parameters required & found instead of > the normal parameters required & found. Then we wouldn't even need a new > error message. But I'm not sure how to retrieve those. > > Any ideas or improvements welcome. > Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From aturbanov at openjdk.org Sun Oct 23 11:34:51 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sun, 23 Oct 2022 11:34:51 GMT Subject: RFR: 8059632: Method reference compilation uses incorrect qualifying type In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 09:31:11 GMT, Srikanth Adayapalam wrote: > Align with JLS 13.1 (the qualifying class or interface of the method invocation) by > referring to the type of the receiver rather than the type of the declaring > class/interface in the bootstrap attribute test/langtools/tools/javac/lambda/methodReference/8059632/MethodRefQualifyingTypeTest.java line 57: > 55: MyFunctionalInterface instance = null; > 56: MethodSupplierImpl ms = new MethodSupplierImpl() { > 57: public int m(int a){ Suggestion: public int m(int a){ ------------- PR: https://git.openjdk.org/jdk/pull/10809 From prr at openjdk.org Mon Oct 24 03:55:56 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 24 Oct 2022 03:55:56 GMT Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in properties files [v2] In-Reply-To: References: Message-ID: <6Nga-zBIoxnexiDJp-uJqSHjkki2U2n6y5WW9chvPz0=.f389c36c-e6bd-4b32-81a2-0304f23ba6a2@github.com> On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove check for .properties from jcheck > - Restore trailing whitespace for property values Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10792 From abimpoudis at openjdk.org Mon Oct 24 12:10:07 2022 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 24 Oct 2022 12:10:07 GMT Subject: RFR: 8294943: Implement record patterns in enhanced for In-Reply-To: References: Message-ID: <9mUpT_a5GtyhtEl8x4-K23M9NnSXPxFQ6-r5ZFf__Co=.7404dc58-8836-4019-8648-24dc4af14e00@github.com> On Thu, 20 Oct 2022 16:39:51 GMT, Aggelos Biboudis wrote: > This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: > > > record Complex(double real, double img) {} > > List list = ...; > > for (Complex(var real, var img) : list) { > // can use ?real? and ?img? directly > } > > > This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following: > > - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`. > - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. > - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression. > - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`. > - The enhanced for, supports record patterns for both arrays and reference types. > > Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason. > > For more information on the changes please see: > > - the JEP: [JEP 432](https://openjdk.org/jeps/432) > - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) > - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) > > Looking forward for your review. Thank you Alex! Comments on spec are welcome, good points raised. We will address them and circulate the updated draft spec separately. ------------- PR: https://git.openjdk.org/jdk/pull/10798 From cpovirk at google.com Mon Oct 24 13:18:33 2022 From: cpovirk at google.com (Chris Povirk) Date: Mon, 24 Oct 2022 06:18:33 -0700 Subject: Surprised that TYPE_USE annotations are accepted on `var` lambda parameters In-Reply-To: <98D5C067-0CC1-4413-A967-39531481ACEC@oracle.com> References: <98D5C067-0CC1-4413-A967-39531481ACEC@oracle.com> Message-ID: Thanks, Dan! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihse at openjdk.org Mon Oct 24 19:21:07 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 24 Oct 2022 19:21:07 GMT Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in properties files [v3] In-Reply-To: References: Message-ID: > Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. > > With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). > > The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Revert "Remove check for .properties from jcheck" This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. - Change trailing space and tab in values to unicode encoding ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10792/files - new: https://git.openjdk.org/jdk/pull/10792/files/c91fdaa1..f4f94341 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=01-02 Stats: 412 lines in 131 files changed: 0 ins; 0 del; 412 mod Patch: https://git.openjdk.org/jdk/pull/10792.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792 PR: https://git.openjdk.org/jdk/pull/10792 From angorya at openjdk.org Mon Oct 24 19:22:38 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Oct 2022 19:22:38 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v2] In-Reply-To: References: Message-ID: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com> On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove check for .properties from jcheck > - Restore trailing whitespace for property values 368 files to review! I wish we had separate PRs for fixing properties and checking for trailing whitespace. i 'd expect it will take some time to review localization, unless we just keep them as is. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From ihse at openjdk.org Mon Oct 24 19:25:38 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 24 Oct 2022 19:25:38 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding I agree, that was an excellent idea Naoto! In my last commit, I have converted all trailing spaces/tabs in value lines into explicit unicode characters. Since that means we have no trailing spaces (from a jcheck perspective), I could also restore the jcheck that was the original driver behind this bug. (And also restore the bug/PR title to show the original intent.) ------------- PR: https://git.openjdk.org/jdk/pull/10792 From ihse at openjdk.org Mon Oct 24 19:31:26 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 24 Oct 2022 19:31:26 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v2] In-Reply-To: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com> References: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com> Message-ID: On Mon, 24 Oct 2022 19:20:24 GMT, Andy Goryachev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove check for .properties from jcheck >> - Restore trailing whitespace for property values > > 368 files to review! I wish we had separate PRs for fixing properties and checking for trailing whitespace. i 'd expect it will take some time to review localization, unless we just keep them as is. @andy-goryachev-oracle They are all automatically processed. There are two kinds of changes: Non-value lines have their trailing whitespace removed. You can verify that part of the PR by looking here: https://github.com/openjdk/jdk/pull/10792/files/c91fdaa19dc06351598bd1c0614e1af3bfa08ae2 This was the state of the PR as of three days ago. The most numerous number of changed files are here, but you can just scroll through the change and verify quickly that it is trivial. The second change is the one suggested by Naoti; I have replaced all trailing tabs (there were just one) with `\u0009` and all trailing spaces with `\u0020`. That part was just pushed by me now. You can see that part separately here: https://github.com/openjdk/jdk/pull/10792/commits/a509b90f1b7f833924493fbd28b3cbb1a85c1f21 This affects far fewer files. And once again, it was mechanically generated. You can once again just scroll through and verify that all changes are due to the trailing whitespace being converted to unicode sequences. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From angorya at openjdk.org Mon Oct 24 19:45:01 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Oct 2022 19:45:01 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding Started looking at whether certain trailing spaces can be (and/or should be) removed, but it quickly became apparent that we should just keep these properties as is (with the unicode escapes), rather than risk regression. src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187: > 185: ### Button Demo ### > 186: > 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020 trailing whitespace looks unnecessary (accessible description?) src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties line 67: > 65: FileChooser.renameErrorTitle.textAndMnemonic=Fehler beim Umbenennen von Datei oder Ordner > 66: FileChooser.renameError.textAndMnemonic={0} kann nicht umbenannt werden > 67: FileChooser.renameErrorFileExists.textAndMnemonic={0} kann nicht umbenannt werden: Es ist bereits eine Datei mit dem angegebenen Namen vorhanden. Geben Sie einen anderen Dateinamen an.\u0020 prob. unnecessary src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties line 67: > 65: FileChooser.renameErrorTitle.textAndMnemonic=Error al cambiar el nombre del archivo o carpeta > 66: FileChooser.renameError.textAndMnemonic=No se puede cambiar el nombre de {0} > 67: FileChooser.renameErrorFileExists.textAndMnemonic=No se puede cambiar el nombre de {0}: ya existe un archivo con el nombre especificado. Especifique otro nombre de archivo.\u0020 prob. unnecessary src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties line 67: > 65: FileChooser.renameErrorTitle.textAndMnemonic=Erreur lors du changement de nom du fichier ou du dossier > 66: FileChooser.renameError.textAndMnemonic=Impossible de renommer {0} > 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossible de renommer {0} : il existe d\u00E9j\u00E0 un fichier portant le nom indiqu\u00E9. Indiquez-en un autre.\u0020 prob. unnecessary src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties line 67: > 65: FileChooser.renameErrorTitle.textAndMnemonic=Errore durante la ridenominazione del file o della cartella > 66: FileChooser.renameError.textAndMnemonic=Impossibile rinominare {0} > 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossibile rinominare {0}: esiste gi\u00E0 un file con il nome specificato. Specificare un altro nome.\u0020 prob. unnecessary src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties line 67: > 65: FileChooser.renameErrorTitle.textAndMnemonic=\u30D5\u30A1\u30A4\u30EB\u307E\u305F\u306F\u30D5\u30A9\u30EB\u30C0\u306E\u540D\u524D\u5909\u66F4\u30A8\u30E9\u30FC > 66: FileChooser.renameError.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093 > 67: FileChooser.renameErrorFileExists.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093: \u6307\u5B9A\u3057\u305F\u540D\u524D\u306E\u30D5\u30A1\u30A4\u30EB\u306F\u3059\u3067\u306B\u5B58\u5728\u3057\u307E\u3059\u3002\u5225\u306E\u30D5\u30A1\u30A4\u30EB\u540D\u3092\u6307\u5B9A\u3057\u3066\u304F\u3060\u3055\u3044\u3002\u0020 prob. unnecessary src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties line 67: > 65: FileChooser.renameErrorTitle.textAndMnemonic=Ett fel intr\u00E4ffade vid f\u00F6rs\u00F6k att \u00E4ndra namn p\u00E5 fil eller mapp > 66: FileChooser.renameError.textAndMnemonic=Kan inte namn\u00E4ndra {0} > 67: FileChooser.renameErrorFileExists.textAndMnemonic=Kan inte namn\u00E4ndra {0}: En fil med angivet namn finns redan. Ange ett annat filnamn.\u0020 prob. unnecessary src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 44: > 42: cachedrowsetimpl.floatfail = getFloat failed on value ( {0} ) in column {1} > 43: cachedrowsetimpl.doublefail = getDouble failed on value ( {0} ) in column {1} > 44: cachedrowsetimpl.dtypemismt = Data Type Mismatch\u0020 prob. unnecessary src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 73: > 71: cachedrowsetimpl.numrows = Number of rows is less than zero or less than fetch size > 72: cachedrowsetimpl.startpos = Start position cannot be negative > 73: cachedrowsetimpl.nextpage = Populate data before calling\u0020 prob. unnecessary src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 87: > 85: > 86: #FilteredRowSetImpl exceptions > 87: filteredrowsetimpl.relative = relative : Invalid cursor operation\u0020 prob. unnecessary src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 128: > 126: crswriter.params1 = Value of params1 : {0}\u0020 > 127: crswriter.params2 = Value of params2 : {0}\u0020 > 128: crswriter.conflictsno = conflicts while synchronizing\u0020 this is tricky. if this value is a part of a sentence (i.e. something like "5 conflicts..."), the localization is likely to be wrong. it's hard to tell without looking further into the code. src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134: > 132: > 133: #SyncResolverImpl exceptions > 134: syncrsimpl.indexval = Index value out of range\u0020\u0020 prob. unnecessary src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 44: > 42: cachedrowsetimpl.floatfail = getFloat bei Wert ( {0} ) in Spalte {1} nicht erfolgreich > 43: cachedrowsetimpl.doublefail = getDouble bei Wert ( {0} ) in Spalte {1} nicht erfolgreich > 44: cachedrowsetimpl.dtypemismt = Keine Datentyp\u00FCbereinstimmung\u0020 prob. unnecessary src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 73: > 71: cachedrowsetimpl.numrows = Zeilenanzahl ist kleiner als null oder kleiner als Abrufgr\u00F6\u00DFe > 72: cachedrowsetimpl.startpos = Startposition darf keinen Negativwert aufweisen > 73: cachedrowsetimpl.nextpage = Daten m\u00FCssen vor dem Aufruf ausgef\u00FCllt werden\u0020 prob. unnecessary src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 87: > 85: > 86: #FilteredRowSetImpl exceptions > 87: filteredrowsetimpl.relative = relative: Ung\u00FCltiger Cursorvorgang\u0020 prob. unnecessary src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 134: > 132: > 133: #SyncResolverImpl exceptions > 134: syncrsimpl.indexval = Indexwert liegt au\u00DFerhalb des Bereichs\u0020\u0020 prob. unnecessary ------------- Marked as reviewed by angorya (no project role). PR: https://git.openjdk.org/jdk/pull/10792 From ihse at openjdk.org Mon Oct 24 19:45:01 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 24 Oct 2022 19:45:01 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed. I did not think it was a good idea to hold this PR, waiting for component teams to do the whitespace check first, for two reasons: 1) Now the trailing whitespace will be obvious, and any intended whitespace will not be accidentally stripped by an editor, so it will be easier for engineers to fix any problems. 2) I know from experience that this kind of cleaning-up has a very low priority for many engineers. If this PR were dependent on all JDK groups going through their properties files, it would basically never be closed. And finally: Here is a complete list of the files which has trailing "unicode whitespace" in values. I will try to figure out to which components these belongs and open corresponding bugs. src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties src/java.desktop/share/classes/sun/print/resources/serviceui_zh_TW.properties src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_ja.properties src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_zh_CN.properties src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_de.properties src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties test/jdk/javax/net/ssl/Stapling/TEST.properties test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/FileChooserDemo.properties test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/togglebutton/resources/ToggleButtonDemo.properties test/jdk/tools/jmod/src/foo/jdk/test/foo/resources/foo.properties ------------- PR: https://git.openjdk.org/jdk/pull/10792 From jjg at openjdk.org Mon Oct 24 19:45:01 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 24 Oct 2022 19:45:01 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order. Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From angorya at openjdk.org Mon Oct 24 19:45:01 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Oct 2022 19:45:01 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:34:56 GMT, Magnus Ihse Bursie wrote: > For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed. probably not needed - if nobody noticed anything until now we have no problem. the solution to escape whitespace in values is the right solution, solves both the jcheck and WS visibility issues. good job! (and we can ignore my "prob. unnecessary" comments) ------------- PR: https://git.openjdk.org/jdk/pull/10792 From angorya at openjdk.org Mon Oct 24 19:45:02 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Oct 2022 19:45:02 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:23:04 GMT, Andy Goryachev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert "Remove check for .properties from jcheck" >> >> This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. >> - Change trailing space and tab in values to unicode encoding > > src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187: > >> 185: ### Button Demo ### >> 186: >> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020 > > trailing whitespace looks unnecessary (accessible description?) although this is in demo... ------------- PR: https://git.openjdk.org/jdk/pull/10792 From naoto at openjdk.org Mon Oct 24 20:02:54 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 24 Oct 2022 20:02:54 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding The problem here is that all those (unnecessary) trailing spaces are appended by the external translators, who are not aware those spaces should not be at the end. I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From angorya at openjdk.org Mon Oct 24 20:12:02 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Oct 2022 20:12:02 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:58:31 GMT, Naoto Sato wrote: > I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles. Good idea! I wonder if this should be done as a unit test. go through all the bundles and check leading/trailing whitespace. in my experience, the translators also (unintentionally) change the quotes and other symbols, sometimes breaking the code. I assume the JDK has been exhaustively tested and we have no such problems. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From naoto at openjdk.org Mon Oct 24 20:16:56 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 24 Oct 2022 20:16:56 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 20:08:02 GMT, Andy Goryachev wrote: > Good idea! I wonder if this should be done as a unit test. go through all the bundles and check leading/trailing whitespace. Right. Definitely not a job for `jcheck`, but it should be considered somewhere in the l10n process. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From ihse at openjdk.org Mon Oct 24 20:39:57 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 24 Oct 2022 20:39:57 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:39:21 GMT, Jonathan Gibbons wrote: > I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order. I respectfully disagree. I think changing a trailing " " into a "\u0020" is the opposite of hiding it; it is making it plainly visible. In fact, I believe most of these trailing spaces are the result of them not being visible enough (and the tooling not warning). Secondly, there are a lot of definitely unintentional trailing spaces, in comments and blank lines. I'd say there is factor 10:1 more of these. Getting these out of the way allows developers to focus more clearly on the trailing whitespace that matters: those in the key-value pairs. And as I said, I intend to file follow-up issues for all files where there is a trailing unicode-sequence whitespace, so it will definitely not be lost on the respective component teams that they have something they need to address. > Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version. That's probably a good idea, but I think we should leave that to each respective team. Just like Andy's and Naoto's suggestion of improving i18n tooling to detect issues like this earlier on. Good idea, but I'd like to see that implemented separated from this PR. This PR is already large. The only reason it makes sense is because all changes (except the one to jcheck) are automatically generated and trivial to verify correctness of. If we were to start adding individual, manual changes into this PR, it would be just a huge mess. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From dcubed at openjdk.org Mon Oct 24 21:38:39 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 24 Oct 2022 21:38:39 GMT Subject: RFR: 8295855: ProblemList jdk/jshell/CommandCompletionTest.java on linux-all Message-ID: <0ifpOEPM7f5v1gUoPUqzk0OnLEC2eYjtQ733hfxsmSo=.3bee0cfb-c533-479a-b69d-356a285df0de@github.com> A trivial fix to ProblemList jdk/jshell/CommandCompletionTest.java on linux-all. ------------- Commit messages: - 8295855: ProblemList jdk/jshell/CommandCompletionTest.java on linux-all Changes: https://git.openjdk.org/jdk/pull/10841/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10841&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295855 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10841.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10841/head:pull/10841 PR: https://git.openjdk.org/jdk/pull/10841 From dholmes at openjdk.org Mon Oct 24 21:38:39 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 24 Oct 2022 21:38:39 GMT Subject: RFR: 8295855: ProblemList jdk/jshell/CommandCompletionTest.java on linux-all In-Reply-To: <0ifpOEPM7f5v1gUoPUqzk0OnLEC2eYjtQ733hfxsmSo=.3bee0cfb-c533-479a-b69d-356a285df0de@github.com> References: <0ifpOEPM7f5v1gUoPUqzk0OnLEC2eYjtQ733hfxsmSo=.3bee0cfb-c533-479a-b69d-356a285df0de@github.com> Message-ID: On Mon, 24 Oct 2022 21:23:05 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jshell/CommandCompletionTest.java on linux-all. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10841 From dcubed at openjdk.org Mon Oct 24 21:38:40 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 24 Oct 2022 21:38:40 GMT Subject: RFR: 8295855: ProblemList jdk/jshell/CommandCompletionTest.java on linux-all In-Reply-To: References: <0ifpOEPM7f5v1gUoPUqzk0OnLEC2eYjtQ733hfxsmSo=.3bee0cfb-c533-479a-b69d-356a285df0de@github.com> Message-ID: On Mon, 24 Oct 2022 21:30:31 GMT, David Holmes wrote: >> A trivial fix to ProblemList jdk/jshell/CommandCompletionTest.java on linux-all. > > Marked as reviewed by dholmes (Reviewer). @dholmes-ora - Thanks for the fast review! ------------- PR: https://git.openjdk.org/jdk/pull/10841 From dcubed at openjdk.org Mon Oct 24 21:43:04 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 24 Oct 2022 21:43:04 GMT Subject: Integrated: 8295855: ProblemList jdk/jshell/CommandCompletionTest.java on linux-all In-Reply-To: <0ifpOEPM7f5v1gUoPUqzk0OnLEC2eYjtQ733hfxsmSo=.3bee0cfb-c533-479a-b69d-356a285df0de@github.com> References: <0ifpOEPM7f5v1gUoPUqzk0OnLEC2eYjtQ733hfxsmSo=.3bee0cfb-c533-479a-b69d-356a285df0de@github.com> Message-ID: On Mon, 24 Oct 2022 21:23:05 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jshell/CommandCompletionTest.java on linux-all. This pull request has now been integrated. Changeset: 7520d0a7 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/7520d0a72573ebaec0b6d9f9f1f1d87688bff8c0 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8295855: ProblemList jdk/jshell/CommandCompletionTest.java on linux-all Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/10841 From cjplummer at openjdk.org Tue Oct 25 03:16:49 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 25 Oct 2022 03:16:49 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding Changes requested by cjplummer (Reviewer). src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties line 27: > 25: > 26: agent.err.error = Error > 27: agent.err.exception = Exception thrown by the agent\u0020 I believe this space was just a typo and should be removed. Same for `agent.err.agentclass.failed` below and in all the other management property files. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From weijun at openjdk.org Tue Oct 25 13:30:53 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 25 Oct 2022 13:30:53 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding test/jdk/javax/net/ssl/Stapling/TEST.properties line 5: > 3: java.base/sun.security.util \ > 4: java.base/sun.security.validator \ > 5: java.base/sun.security.x509\u0020 I'm quite sure this space can be safely removed. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From weijun at openjdk.org Tue Oct 25 13:47:02 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 25 Oct 2022 13:47:02 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding I noticed another problem. In some English properties files (Ex: `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`), `\u0020` is already used today but it turns into a whitespace in the translated files. It looks like the translation tool (most likely written in Java) decoded it while reading the English file but was not able to encode it back in a translation. I wonder if this means even if we get everything right now the tool might add trailing spaces again later. I suggest we focus on the English files this time and file a bug to the translation tool. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From hannesw at openjdk.org Tue Oct 25 13:54:54 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 25 Oct 2022 13:54:54 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors [v6] In-Reply-To: References: Message-ID: <5V9-9Xl-FM3unMDlbQh0TjoFBYUfhFT6PMwL_tQqIXg=.c712ff48-f2ae-4f3e-ba92-d0aaa8cb576c@github.com> > Please review a a new feature to allow `@link`, `@linkplain` and `@see` tags to link to arbitrary URI fragments in the generated documentation (including in auxiliary `doc-files` documentation). > > The changes in module `jdk.compiler` are mostly cleanup changes retained from earlier versions of the patch. The current proposed version uses a very simple change in `ReferenceParser` to avoid parsing the member name section of the reference when a non-member fragment is encountered. > > The implementation introduces a new form of reference with a double hash mark (`##`) separator. This is a change from the previous implementation which also auto-recognized URI fragments and documentation paths by looking for `-` characters which are not allowed in member names. This feature was removed upon further consideration because it makes the feature more complex and less recognizable. > > Links to auxiliary documentation files follow the same rules. They are recognized by looking for `/` characters in the fragment name. This means that ordinary `id` attribute values must not contain `/`, while auxiliary file paths must contain a `/` character. Both restrictions should be easy to sustain. > > One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. In contrast to program element names a fragment name does usually not make a good human readable name. The solution is to use the fragment name as default label text. I expect that the feature will usually be used with a user provided label. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Add reference parsing modes and doctree tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10395/files - new: https://git.openjdk.org/jdk/pull/10395/files/1ea15afc..bfd2d7f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10395&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10395&range=04-05 Stats: 205 lines in 10 files changed: 180 ins; 3 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/10395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10395/head:pull/10395 PR: https://git.openjdk.org/jdk/pull/10395 From archie.cobbs at gmail.com Tue Oct 25 15:43:03 2022 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 25 Oct 2022 10:43:03 -0500 Subject: Effectively final local variable cannot be declared as final In-Reply-To: References: Message-ID: On Tue, Sep 27, 2022 at 4:25 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I believe this is a bug in how the compiler determines effective > finality. Javac does this while computing DA/DU. This is because locals > that are assigned "at most once" are considered effectively final (as > per the JLS). > FYI, I just posted a PR that should fix this... any comments or suggestions appreciated. https://github.com/openjdk/jdk/pull/10856 -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Oct 25 15:45:34 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Tue, 25 Oct 2022 15:45:34 GMT Subject: RFR: 8294461: wrong effectively final determination by javac Message-ID: This bug involves DA/DU analysis and the concept of "effectively final". Here's the test case, which the compiler currently but incorrectly accepts: for (int i = 0; i < 10; i++) { Runnable r = () -> System.out.println(i); // variable i is NOT effectively final break; // even though "i++" is never reached } For the purposes of "effectively final", it doesn't matter whether an assignment statement that makes a variable no longer effectively final is actually reachable or not. In cases like the `i++` above, a statement can be actually unreachable yet not "unreachable" according to the JLS, and so it does not generate an "unreachable statement" compiler error (which would otherwise hide this bug). JLS ?4.12.4 states: > A local variable declared by a statement and whose declarator has an initializer ... is effectively final if all of the following are true: > ... > ? It never occurs as the operand of a prefix or postfix increment or decrement operator (?15.14, ?15.15). So clearly `i` is not effectively final. However, the way we calculate effective finality does not involve actually looking for increment/decrement operators. Instead, it's determined during DA/DU analysis: non-final variables have an `EFFECTIVELY_FINAL` flag which is initialized to `true` and then cleared if/when we encounter contrary evidence - e.g., an assignment when not DU. For simplicity, the DA/DU analysis works like this: * Variables with initializers are treated like variables without initializers followed by an assignment * Increment/decrement operators are treated as a normal read followed by a normal assignment. These are reasonable. However, it means this clause of JLS ?4.12.4 effectively applies: > A local variable declared by a statement and whose declarator lacks an initializer is effectively final if all of the following are true: > ... > ? Whenever it occurs as the left hand side in an assignment expression, it is definitely unassigned and not definitely assigned before the assignment... The bug with the current code is that when we see an assignment to a variable with the `EFFECTIVELY_FINAL` flag still set, we clear the flag if the variable is not DU, but we are _not_ clearing the flag if the variable is DA, as required above. This happens with the `i++` statement because, by virtue of it being actually unreachable, `i` is both DA and DU before that statement. This patch corrects that omission. ------------- Commit messages: - A for loop variable is not effectively final even if the loop never increments. Changes: https://git.openjdk.org/jdk/pull/10856/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10856&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294461 Stats: 23 lines in 3 files changed: 17 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10856.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10856/head:pull/10856 PR: https://git.openjdk.org/jdk/pull/10856 From naoto at openjdk.org Tue Oct 25 17:31:52 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 25 Oct 2022 17:31:52 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 13:43:56 GMT, Weijun Wang wrote: > I wonder if this means even if we get everything right now the tool might add trailing spaces again later. Good catch, Max. Yes, that should be dealt with in the translation process. > I suggest we focus on the English files this time and file a bug to the translation tool. Agree. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From abimpoudis at openjdk.org Wed Oct 26 13:22:28 2022 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 26 Oct 2022 13:22:28 GMT Subject: RFR: 8294943: Implement record patterns in enhanced for [v2] In-Reply-To: References: Message-ID: > This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: > > > record Complex(double real, double img) {} > > List list = ...; > > for (Complex(var real, var img) : list) { > // can use ?real? and ?img? directly > } > > > This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following: > > - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`. > - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. > - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression. > - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`. > - The enhanced for, supports record patterns for both arrays and reference types. > > Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason. > > For more information on the changes please see: > > - the JEP: [JEP 432](https://openjdk.org/jeps/432) > - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) > - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) > > Looking forward for your review. Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Fix applicability bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10798/files - new: https://git.openjdk.org/jdk/pull/10798/files/2b48bea4..ce2c78c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=00-01 Stats: 28 lines in 4 files changed: 14 ins; 2 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/10798.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798 PR: https://git.openjdk.org/jdk/pull/10798 From dfuchs at openjdk.org Wed Oct 26 16:11:27 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 26 Oct 2022 16:11:27 GMT Subject: RFR: 8294241: Deprecate URL public constructors Message-ID: Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 ------------- Commit messages: - Fix whitespace issues - 8294241 Changes: https://git.openjdk.org/jdk/pull/10874/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294241 Stats: 849 lines in 82 files changed: 701 ins; 2 del; 146 mod Patch: https://git.openjdk.org/jdk/pull/10874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874 PR: https://git.openjdk.org/jdk/pull/10874 From michaelm at openjdk.org Wed Oct 26 16:45:22 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 26 Oct 2022 16:45:22 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 src/java.base/share/classes/java/net/JarURLConnection.java line 177: > 175: @SuppressWarnings("deprecation") > 176: var tmp = jarFileURL = new URL(spec.substring(0, separator++)); > 177: I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better? ------------- PR: https://git.openjdk.org/jdk/pull/10874 From weijun at openjdk.org Wed Oct 26 16:48:22 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 26 Oct 2022 16:48:22 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: Message-ID: <6CBNoueQtp5P8wa0FuOCHQtmw9610BdOrP7pvhg1g70=.6cc91f26-df33-4722-9c49-f390ed6387aa@github.com> On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 The change to security-related code looks fine to me. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From xuelei at openjdk.org Wed Oct 26 17:11:27 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 26 Oct 2022 17:11:27 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: Message-ID: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com> On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 src/java.base/share/classes/java/net/URL.java line 852: > 850: * @since 20 > 851: */ > 852: public static URL fromURI(URI uri, URLStreamHandler streamHandler) What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already? ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Wed Oct 26 17:29:01 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 26 Oct 2022 17:29:01 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com> References: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com> Message-ID: On Wed, 26 Oct 2022 17:09:20 GMT, Xue-Lei Andrew Fan wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > src/java.base/share/classes/java/net/URL.java line 852: > >> 850: * @since 20 >> 851: */ >> 852: public static URL fromURI(URI uri, URLStreamHandler streamHandler) > > What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already? `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From xuelei at openjdk.org Wed Oct 26 17:42:31 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 26 Oct 2022 17:42:31 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com> Message-ID: On Wed, 26 Oct 2022 17:24:59 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/net/URL.java line 852: >> >>> 850: * @since 20 >>> 851: */ >>> 852: public static URL fromURI(URI uri, URLStreamHandler streamHandler) >> >> What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already? > > `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent. I see your point. It may be more appropriate if URI.toURL was designed as URL.fromURL. I was wondering to have application developers a consistent way to get an URL instance. Now there are two methods in different classes URI.toURL and URL.fromURI. It might be easier to use the old URI.toURL form. Never mind, it is just my personal preference. It is fine to me to have a new URL.fromURI method. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Wed Oct 26 17:57:40 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 26 Oct 2022 17:57:40 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com> Message-ID: On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan wrote: >> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent. > > I see your point. It may be more appropriate if URI.toURL was designed as URL.fromURL. > > I was wondering to have application developers a consistent way to get an URL instance. Now there are two methods in different classes URI.toURL and URL.fromURI. It might be easier to use the old URI.toURL form. > > Never mind, it is just my personal preference. It is fine to me to have a new URL.fromURI method. One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From duke at openjdk.org Wed Oct 26 19:45:05 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 26 Oct 2022 19:45:05 GMT Subject: RFR: 8294461: wrong effectively final determination by javac [v2] In-Reply-To: References: Message-ID: > This bug involves DA/DU analysis and the concept of "effectively final". > > Here's the test case, which the compiler currently but incorrectly accepts: > > for (int i = 0; i < 10; i++) { > Runnable r = () -> System.out.println(i); // variable i is NOT effectively final > break; // even though "i++" is never reached > } > > > For the purposes of "effectively final", it doesn't matter whether an assignment statement that makes a variable no longer effectively final is actually reachable or not. In cases like the `i++` above, a statement can be actually unreachable yet not "unreachable" according to the JLS, and so it does not generate an "unreachable statement" compiler error (which would otherwise hide this bug). > > JLS ?4.12.4 states: > >> A local variable declared by a statement and whose declarator has an initializer ... is effectively final if all of the following are true: >> ... >> ? It never occurs as the operand of a prefix or postfix increment or decrement operator (?15.14, ?15.15). > > So clearly `i` is not effectively final. > > However, the way we calculate effective finality does not involve actually looking for increment/decrement operators. Instead, it's determined during DA/DU analysis: non-final variables have an `EFFECTIVELY_FINAL` flag which is initialized to `true` and then cleared if/when we encounter contrary evidence - e.g., an assignment when not DU. > > For simplicity, the DA/DU analysis works like this: > * Variables with initializers are treated like variables without initializers followed by an assignment > * Increment/decrement operators are treated as a normal read followed by a normal assignment. > > These are reasonable. However, it means this clause of JLS ?4.12.4 effectively applies: > >> A local variable declared by a statement and whose declarator lacks an initializer is effectively final if all of the following are true: >> ... >> ? Whenever it occurs as the left hand side in an assignment expression, it is definitely unassigned and not definitely assigned before the assignment... > > The bug with the current code is that when we see an assignment to a variable with the `EFFECTIVELY_FINAL` flag still set, we clear the flag if the variable is not DU, but we are _not_ clearing the flag if the variable is DA, as required above. This happens with the `i++` statement because, by virtue of it being actually unreachable, `i` is both DA and DU before that statement. > > This patch corrects that omission. Archie L. Cobbs 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-8294461 - A for loop variable is not effectively final even if the loop never increments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10856/files - new: https://git.openjdk.org/jdk/pull/10856/files/449a5efb..014d67d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10856&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10856&range=00-01 Stats: 25053 lines in 338 files changed: 1115 ins; 23570 del; 368 mod Patch: https://git.openjdk.org/jdk/pull/10856.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10856/head:pull/10856 PR: https://git.openjdk.org/jdk/pull/10856 From vromero at openjdk.org Wed Oct 26 19:58:26 2022 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 26 Oct 2022 19:58:26 GMT Subject: RFR: 8294461: wrong effectively final determination by javac [v2] In-Reply-To: References: Message-ID: <-Z2PA_Cnyy_Z3vuakRJKDlTg2ui0OLWtqaR7MPGjWZI=.e6735dec-df55-4d5c-8867-c628797a1290@github.com> On Wed, 26 Oct 2022 19:45:05 GMT, Archie L. Cobbs wrote: >> This bug involves DA/DU analysis and the concept of "effectively final". >> >> Here's the test case, which the compiler currently but incorrectly accepts: >> >> for (int i = 0; i < 10; i++) { >> Runnable r = () -> System.out.println(i); // variable i is NOT effectively final >> break; // even though "i++" is never reached >> } >> >> >> For the purposes of "effectively final", it doesn't matter whether an assignment statement that makes a variable no longer effectively final is actually reachable or not. In cases like the `i++` above, a statement can be actually unreachable yet not "unreachable" according to the JLS, and so it does not generate an "unreachable statement" compiler error (which would otherwise hide this bug). >> >> JLS ?4.12.4 states: >> >>> A local variable declared by a statement and whose declarator has an initializer ... is effectively final if all of the following are true: >>> ... >>> ? It never occurs as the operand of a prefix or postfix increment or decrement operator (?15.14, ?15.15). >> >> So clearly `i` is not effectively final. >> >> However, the way we calculate effective finality does not involve actually looking for increment/decrement operators. Instead, it's determined during DA/DU analysis: non-final variables have an `EFFECTIVELY_FINAL` flag which is initialized to `true` and then cleared if/when we encounter contrary evidence - e.g., an assignment when not DU. >> >> For simplicity, the DA/DU analysis works like this: >> * Variables with initializers are treated like variables without initializers followed by an assignment >> * Increment/decrement operators are treated as a normal read followed by a normal assignment. >> >> These are reasonable. However, it means this clause of JLS ?4.12.4 effectively applies: >> >>> A local variable declared by a statement and whose declarator lacks an initializer is effectively final if all of the following are true: >>> ... >>> ? Whenever it occurs as the left hand side in an assignment expression, it is definitely unassigned and not definitely assigned before the assignment... >> >> The bug with the current code is that when we see an assignment to a variable with the `EFFECTIVELY_FINAL` flag still set, we clear the flag if the variable is not DU, but we are _not_ clearing the flag if the variable is DA, as required above. This happens with the `i++` statement because, by virtue of it being actually unreachable, `i` is both DA and DU before that statement. >> >> This patch corrects that omission. > > Archie L. Cobbs 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-8294461 > - A for loop variable is not effectively final even if the loop never increments. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10856 From sadayapalam at openjdk.org Thu Oct 27 04:53:22 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Thu, 27 Oct 2022 04:53:22 GMT Subject: RFR: 8292159: TYPE_USE annotations on generic type arguments of record components discarded [v6] In-Reply-To: References: Message-ID: > Handle carryover of type annotations to record components in a place which will be > reached regardless of whether there are any annotations in a SE5 annotation location. Srikanth Adayapalam 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 seven additional commits since the last revision: - Merge branch 'master' into JDK-8292159 - Merge branch 'master' into JDK-8292159 - Merge branch 'master' into JDK-8292159 - Incorporate review comments from Vicente (Thanks!) - Merge branch 'master' into JDK-8292159 - Merge branch 'master' into JDK-8292159 - 8292159: TYPE_USE annotations on generic type arguments of record components discarded ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10741/files - new: https://git.openjdk.org/jdk/pull/10741/files/4b82002a..6734bd61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10741&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10741&range=04-05 Stats: 140550 lines in 893 files changed: 81757 ins; 28614 del; 30179 mod Patch: https://git.openjdk.org/jdk/pull/10741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10741/head:pull/10741 PR: https://git.openjdk.org/jdk/pull/10741 From sadayapalam at openjdk.org Thu Oct 27 04:59:16 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Thu, 27 Oct 2022 04:59:16 GMT Subject: Integrated: 8292159: TYPE_USE annotations on generic type arguments of record components discarded In-Reply-To: References: Message-ID: <0ZsKLefzVpfYUoyJCwkKjzM9e7LPnp8I-XtTbDD5-_U=.065badf6-4b2f-4b31-a389-abab31c3112f@github.com> On Tue, 18 Oct 2022 07:54:02 GMT, Srikanth Adayapalam wrote: > Handle carryover of type annotations to record components in a place which will be > reached regardless of whether there are any annotations in a SE5 annotation location. This pull request has now been integrated. Changeset: 4d9a1cd2 Author: Srikanth Adayapalam URL: https://git.openjdk.org/jdk/commit/4d9a1cd26fa0cda902aafcccd6e02bd7bc60bbb3 Stats: 72 lines in 3 files changed: 69 ins; 0 del; 3 mod 8292159: TYPE_USE annotations on generic type arguments of record components discarded Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/10741 From sadayapalam at openjdk.org Thu Oct 27 05:09:40 2022 From: sadayapalam at openjdk.org (Srikanth Adayapalam) Date: Thu, 27 Oct 2022 05:09:40 GMT Subject: RFR: 8059632: Method reference compilation uses incorrect qualifying type [v2] In-Reply-To: References: Message-ID: > Align with JLS 13.1 (the qualifying class or interface of the method invocation) by > referring to the type of the receiver rather than the type of the declaring > class/interface in the bootstrap attribute Srikanth Adayapalam 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 three additional commits since the last revision: - Merge branch 'master' into JDK-8059632 - Fix whitespace problem - 8059632: Method reference compilation uses incorrect qualifying type ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10809/files - new: https://git.openjdk.org/jdk/pull/10809/files/6f39d848..b44fe30e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10809&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10809&range=00-01 Stats: 140279 lines in 879 files changed: 81595 ins; 28534 del; 30150 mod Patch: https://git.openjdk.org/jdk/pull/10809.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10809/head:pull/10809 PR: https://git.openjdk.org/jdk/pull/10809 From duke at openjdk.org Thu Oct 27 05:16:38 2022 From: duke at openjdk.org (ExE Boss) Date: Thu, 27 Oct 2022 05:16:38 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: Message-ID: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com> On Wed, 26 Oct 2022 16:41:29 GMT, Michael McMahon wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > src/java.base/share/classes/java/net/JarURLConnection.java line 177: > >> 175: @SuppressWarnings("deprecation") >> 176: var tmp = jarFileURL = new URL(spec.substring(0, separator++)); >> 177: > > I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better? Having?unnamed local?variables[^1] would?probably be?best for?this. [^1]: https://openjdk.org/jeps/8294349 ------------- PR: https://git.openjdk.org/jdk/pull/10874 From michaelm at openjdk.org Thu Oct 27 09:21:35 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 27 Oct 2022 09:21:35 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com> References: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com> Message-ID: On Thu, 27 Oct 2022 05:14:19 GMT, ExE Boss wrote: >> src/java.base/share/classes/java/net/JarURLConnection.java line 177: >> >>> 175: @SuppressWarnings("deprecation") >>> 176: var tmp = jarFileURL = new URL(spec.substring(0, separator++)); >>> 177: >> >> I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better? > > Having?unnamed local?variables[^1] would?probably be?best for?this. > > [^1]: https://openjdk.org/jeps/8294349 How about `_unused` or `_unused1`, `_unused2` then in the meantime? ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Thu Oct 27 11:28:26 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 27 Oct 2022 11:28:26 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com> Message-ID: On Thu, 27 Oct 2022 09:17:29 GMT, Michael McMahon wrote: >> Having?unnamed local?variables[^1] would?probably be?best for?this. >> >> [^1]: https://openjdk.org/jeps/8294349 > > How about `_unused` or `_unused1`, `_unused2` then in the meantime? I'd be happy to make the change. Let's wait to see if anybody has a better naming suggestion. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From duke at openjdk.org Thu Oct 27 13:22:32 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 27 Oct 2022 13:22:32 GMT Subject: RFR: 8294461: wrong effectively final determination by javac [v2] In-Reply-To: References: Message-ID: <4SHqWFBmCCrfHBjX9MJCBdmu_9LBBQGcoUZpd9BX30U=.3e53d8e9-fbfd-44e0-ba79-15ed01469bf9@github.com> On Wed, 26 Oct 2022 19:45:05 GMT, Archie L. Cobbs wrote: >> This bug involves DA/DU analysis and the concept of "effectively final". >> >> Here's the test case, which the compiler currently but incorrectly accepts: >> >> for (int i = 0; i < 10; i++) { >> Runnable r = () -> System.out.println(i); // variable i is NOT effectively final >> break; // even though "i++" is never reached >> } >> >> >> For the purposes of "effectively final", it doesn't matter whether an assignment statement that makes a variable no longer effectively final is actually reachable or not. In cases like the `i++` above, a statement can be actually unreachable yet not "unreachable" according to the JLS, and so it does not generate an "unreachable statement" compiler error (which would otherwise hide this bug). >> >> JLS ?4.12.4 states: >> >>> A local variable declared by a statement and whose declarator has an initializer ... is effectively final if all of the following are true: >>> ... >>> ? It never occurs as the operand of a prefix or postfix increment or decrement operator (?15.14, ?15.15). >> >> So clearly `i` is not effectively final. >> >> However, the way we calculate effective finality does not involve actually looking for increment/decrement operators. Instead, it's determined during DA/DU analysis: non-final variables have an `EFFECTIVELY_FINAL` flag which is initialized to `true` and then cleared if/when we encounter contrary evidence - e.g., an assignment when not DU. >> >> For simplicity, the DA/DU analysis works like this: >> * Variables with initializers are treated like variables without initializers followed by an assignment >> * Increment/decrement operators are treated as a normal read followed by a normal assignment. >> >> These are reasonable. However, it means this clause of JLS ?4.12.4 effectively applies: >> >>> A local variable declared by a statement and whose declarator lacks an initializer is effectively final if all of the following are true: >>> ... >>> ? Whenever it occurs as the left hand side in an assignment expression, it is definitely unassigned and not definitely assigned before the assignment... >> >> The bug with the current code is that when we see an assignment to a variable with the `EFFECTIVELY_FINAL` flag still set, we clear the flag if the variable is not DU, but we are _not_ clearing the flag if the variable is DA, as required above. This happens with the `i++` statement because, by virtue of it being actually unreachable, `i` is both DA and DU before that statement. >> >> This patch corrects that omission. > > Archie L. Cobbs 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-8294461 > - A for loop variable is not effectively final even if the loop never increments. Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/10856 From archie.cobbs at gmail.com Thu Oct 27 15:45:54 2022 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 27 Oct 2022 10:45:54 -0500 Subject: Bugs that are inadvertently fixed In-Reply-To: References: Message-ID: Here are a few more... JDK-8215645 - Not sure what this one is about, but the other bug it references is resolved These are all bugs relating to local methods. I'm not following that work so don't know if they're still relevant or not. JDK-8232931 JDK-8233003 JDK-8233099 JDK-8233102 JDK-8234874 JDK-8239087 - Obsolete/fixed? No way is given to reproduce. JDK-8239087 - Appears to be fixed JDK-8288619 - Seems to be fixed, or else this is a javadoc issue not a javac issue? JDK-8239087 - Appears to be fixed JDK-8239087 - Obsolete/fixed? JDK-8239087 - Obsolete/fixed? JDK-8259072 - Bug as reported appears to be fixed JDK-8259721 - Appears to be fixed (?) -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Oct 27 16:01:31 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 27 Oct 2022 16:01:31 GMT Subject: Integrated: 8294461: wrong effectively final determination by javac In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 15:36:05 GMT, Archie L. Cobbs wrote: > This bug involves DA/DU analysis and the concept of "effectively final". > > Here's the test case, which the compiler currently but incorrectly accepts: > > for (int i = 0; i < 10; i++) { > Runnable r = () -> System.out.println(i); // variable i is NOT effectively final > break; // even though "i++" is never reached > } > > > For the purposes of "effectively final", it doesn't matter whether an assignment statement that makes a variable no longer effectively final is actually reachable or not. In cases like the `i++` above, a statement can be actually unreachable yet not "unreachable" according to the JLS, and so it does not generate an "unreachable statement" compiler error (which would otherwise hide this bug). > > JLS ?4.12.4 states: > >> A local variable declared by a statement and whose declarator has an initializer ... is effectively final if all of the following are true: >> ... >> ? It never occurs as the operand of a prefix or postfix increment or decrement operator (?15.14, ?15.15). > > So clearly `i` is not effectively final. > > However, the way we calculate effective finality does not involve actually looking for increment/decrement operators. Instead, it's determined during DA/DU analysis: non-final variables have an `EFFECTIVELY_FINAL` flag which is initialized to `true` and then cleared if/when we encounter contrary evidence - e.g., an assignment when not DU. > > For simplicity, the DA/DU analysis works like this: > * Variables with initializers are treated like variables without initializers followed by an assignment > * Increment/decrement operators are treated as a normal read followed by a normal assignment. > > These are reasonable. However, it means this clause of JLS ?4.12.4 effectively applies: > >> A local variable declared by a statement and whose declarator lacks an initializer is effectively final if all of the following are true: >> ... >> ? Whenever it occurs as the left hand side in an assignment expression, it is definitely unassigned and not definitely assigned before the assignment... > > The bug with the current code is that when we see an assignment to a variable with the `EFFECTIVELY_FINAL` flag still set, we clear the flag if the variable is not DU, but we are _not_ clearing the flag if the variable is DA, as required above. This happens with the `i++` statement because, by virtue of it being actually unreachable, `i` is both DA and DU before that statement. > > This patch corrects that omission. This pull request has now been integrated. Changeset: b8ad6cd9 Author: Archie L. Cobbs Committer: Vicente Romero URL: https://git.openjdk.org/jdk/commit/b8ad6cd98a7e4b577b888dc5f9d93c2e4d3bf177 Stats: 23 lines in 3 files changed: 17 ins; 2 del; 4 mod 8294461: wrong effectively final determination by javac Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/10856 From joehw at openjdk.org Thu Oct 27 17:22:26 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 27 Oct 2022 17:22:26 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Hi Daniel, if it's not a major improvement, we'd like to keep the java.xml module at the JDK 8 code level. Can we remove the 'var' usage in a few java.xml classes? ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Thu Oct 27 17:38:24 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 27 Oct 2022 17:38:24 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: Message-ID: <9IeUomzE_jMjeWk2jrzY5-1W8n2JhijVyCPO2mQJrtI=.82a69e23-ccae-43a4-988c-5de54e4aad07@github.com> On Thu, 27 Oct 2022 17:20:04 GMT, Joe Wang wrote: > Hi Daniel, if it's not a major improvement, we'd like to keep the java.xml module at the JDK 8 code level. Can we remove the 'var' usage in a few java.xml classes? No problem - I will make this change when we have settled on a name for the variable `tmp` vs `_unused` (proposed by Michael). ------------- PR: https://git.openjdk.org/jdk/pull/10874 From aturbanov at openjdk.org Thu Oct 27 17:54:31 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 27 Oct 2022 17:54:31 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 test/jdk/java/net/URL/URLFromURITest.java line 268: > 266: // - URL authority is null or empty depending on the protocol > 267: // and on whether the URL is hierarchical or not. > 268: if (isFileBased && authority == null) { Suggestion: if (isFileBased && authority == null) { ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Thu Oct 27 18:08:34 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 27 Oct 2022 18:08:34 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 17:50:37 GMT, Andrey Turbanov wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > test/jdk/java/net/URL/URLFromURITest.java line 268: > >> 266: // - URL authority is null or empty depending on the protocol >> 267: // and on whether the URL is hierarchical or not. >> 268: if (isFileBased && authority == null) { > > Suggestion: > > if (isFileBased && authority == null) { Thanks - I will apply this suggestion. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From duke at openjdk.org Thu Oct 27 22:19:26 2022 From: duke at openjdk.org (Rob Leland) Date: Thu, 27 Oct 2022 22:19:26 GMT Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Why not go ahead and replace all the usages with fromURI(} to start with.where possible ? ------------- PR: https://git.openjdk.org/jdk/pull/10874 From jlaskey at openjdk.org Thu Oct 27 22:27:47 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 27 Oct 2022 22:27:47 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) Message-ID: Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). ------------- Commit messages: - Tabs to spaces - Force processor before template string expression - Correct implNote - Add valueGetters method - Added RAW template processor - Merge branch 'master' into 8285932 - Rename to ValidatingProcessor - Javadoc mistakes - Rename TemplateProcessor - Clean up tests - ... and 4 more: https://git.openjdk.org/jdk/compare/0c13d666...7b2011ac Changes: https://git.openjdk.org/jdk/pull/10889/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285932 Stats: 7452 lines in 74 files changed: 7263 ins; 45 del; 144 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Thu Oct 27 22:47:26 2022 From: duke at openjdk.org (ExE Boss) Date: Thu, 27 Oct 2022 22:47:26 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 20:16:14 GMT, Jim Laskey wrote: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 115: > 113: * we do not use all those slots, to let the strategies with MethodHandle > 114: * combinators to use some arguments. > 115: */ Suggestion: * * @since 20 */ src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1058: > 1056: * @throws Throwable if fails to prepend value (unusual). > 1057: */ > 1058: long prepend(long lengthCoder, byte[] buffer) throws Throwable; This?method is?inherently?unsafe, as?`StringConcatFactory` uses?`Unsafe.allocateUninitializedArray(...)` to?construct the?`buffer`, the?intrinsic?implementation of?which ***DOESN?T***?zero?out the?memory?region occupied?by?the?array, which?can?contain potentially?sensitive?data. -------------------------------------------------------------------------------- The?`StringConcatItem`?interface should?be?sealed or?at?least moved?to a?`jdk.internal.*`?package. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From cjplummer at openjdk.org Fri Oct 28 00:55:44 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 28 Oct 2022 00:55:44 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com> References: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com> Message-ID: On Fri, 7 Oct 2022 12:51:26 GMT, Alan Bateman wrote: >> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Reinstate typos in Apache code that is copied into the JDK >> - Merge ../jdk-openjdk into typos-typos >> - Remove file that was removed upstream >> - Fix inconsistency in capitalization >> - Undo change in zlip >> - Fix typos > > src/java.se/share/data/jdwp/jdwp.spec line 101: > >> 99: "platform thread " >> 100: "in the target VM. This includes platform threads created with the Thread " >> 101: "API and all native threads attached to the target VM with JNI code." > > The spec for the JDWP AllThreads command was significantly reworded in Java 19 so this is where this typo crept in. We have JDK-8294672 tracking it to fix for Java 20, maybe you should take it? Since this PR has gone stale, I'll be fixing this typo in jdwp.spec via [JDK-8294672](https://bugs.openjdk.org/browse/JDK-8294672). ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Fri Oct 28 02:13:20 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 28 Oct 2022 02:13:20 GMT Subject: RFR: 8184444: The compiler error "variable not initialized in the default constructor" is not apt in case of static final variables Message-ID: This bug causes this class: class StaticFinalInit { static final int foo; } to fail to compile as it should but with a confusing error message: StaticFinalInit.java:2: error: variable foo not initialized in the default constructor static final int foo; ^ In another variant, if there is a non-default constructor: class StaticFinalInit { static final int foo; StaticFinalInit() { } } the compiler gives the right error message but shows the wrong source code location: StaticFinalInit.java:3: error: variable foo might not have been initialized StaticFinalInit() { } ^ This behavior is a side-effect of the roundabout way we currently check for definite assignment of static final fields. When recursing into a class definition in `Flow.AssignAnalyzer`, we first initialize DA/DU analysis for static fields, and then recurse on the static initializers to pick up static field assignments. However, we don't then check for definite assignment of static final fields. Instead, we proceed with the analysis, and then later, whenever we visit an initial constructor (i.e., one that invokes `super()` instead of `this()`), we check for definite assignment of both static final and instance final fields. This works because every class has at least one initial constructor, so static fields will always get checked at least once. Of course, it also results in doing some redundant work (if there are multiple initial constructors) and it generates the wrong error message and/or source code position. This patch adds a check for definite assignment of static final fields (with the appropriate error message) after we recurse on the static initializers, and it filters out static fields from the checks being done in initial constructors. It also updates a couple of existing unit tests that were expecting the wrong source code position. The two examples above now both generate this error message: StaticFinalInit.java:2: error: variable foo might not have been initialized static final int foo; ^ ------------- Commit messages: - Fix confusing error message for uninitialized static final fields. Changes: https://git.openjdk.org/jdk/pull/10896/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10896&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8184444 Stats: 24 lines in 5 files changed: 20 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10896.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10896/head:pull/10896 PR: https://git.openjdk.org/jdk/pull/10896 From vromero at openjdk.org Fri Oct 28 03:05:18 2022 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 28 Oct 2022 03:05:18 GMT Subject: RFR: 8232933: Javac inferred type does not conform to equality constraint Message-ID: <2euRx3nxZrGa-iDmuGUJCo9e6rOxFXYBhdhCI7PQjeo=.4fc91bac-8072-43c4-8bab-72ef38467df8@github.com> When dealing with nested invocations it could be that the inference context of a nested invocation is propagated to the inference context of the outer invocation. There are occasions when the propagated inference context can be minimized if some of its inference variables are deemed redundant. This is an optimization that is done in order to speed up the type inference algo which can take a while if the number of variables to be reduced is large. Of course by removing some variables from an inference context we have an inherent risk of cutting too much and not being able to produce the same results compared to not minimizing it. My understanding is that this bug shows one of those cases in which an inference context has been reduced too much. The proposed solution is not to minimize an inference context if at least one of its inference variables is a capture type. The reason is because when capture types are present, some bounds are wildcards which could be captured again generating new capture types etc., this could make impossible to prove that some constraints hold for an inference context, thus making the compiler wrongly reject correct code. TIA ------------- Commit messages: - 8232933: Javac inferred type does not conform to equality constraint Changes: https://git.openjdk.org/jdk/pull/10897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10897&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8232933 Stats: 60 lines in 2 files changed: 60 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10897.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10897/head:pull/10897 PR: https://git.openjdk.org/jdk/pull/10897 From dfuchs at openjdk.org Fri Oct 28 14:54:26 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 28 Oct 2022 14:54:26 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs 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: - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml - Merge branch 'master' into deprecate-url-ctor-8294241 - Fix whitespace issues - 8294241 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10874/files - new: https://git.openjdk.org/jdk/pull/10874/files/25a0188c..fd4ca287 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=00-01 Stats: 25761 lines in 392 files changed: 1581 ins; 23649 del; 531 mod Patch: https://git.openjdk.org/jdk/pull/10874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874 PR: https://git.openjdk.org/jdk/pull/10874 From jlaskey at openjdk.org Fri Oct 28 14:55:28 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Oct 2022 14:55:28 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v2] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Move StringConcatItem to FormatConcatItem ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/7b2011ac..26485968 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=00-01 Stats: 239 lines in 6 files changed: 93 ins; 109 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Oct 28 14:55:30 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Oct 2022 14:55:30 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v2] In-Reply-To: References: Message-ID: <8KVfwqrbnCSF-80frLIKExvp7jih3Ltp-UY3eaHuTco=.2f87479c-39d9-4eda-87f4-832b6ac8b9cb@github.com> On Thu, 27 Oct 2022 21:21:52 GMT, ExE Boss wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Move StringConcatItem to FormatConcatItem > > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 115: > >> 113: * we do not use all those slots, to let the strategies with MethodHandle >> 114: * combinators to use some arguments. >> 115: */ > > Suggestion: > > * > * @since 20 > */ Updated along with a couple @since 19 > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1058: > >> 1056: * @throws Throwable if fails to prepend value (unusual). >> 1057: */ >> 1058: long prepend(long lengthCoder, byte[] buffer) throws Throwable; > > This?method is?inherently?unsafe, as?`StringConcatFactory` uses?`Unsafe.allocateUninitializedArray(...)` to?construct the?`buffer`, the?intrinsic?implementation of?which ***DOESN?T***?zero?out the?memory?region occupied?by?the?array, which?can?contain potentially?sensitive?data. > > -------------------------------------------------------------------------------- > > The?`StringConcatItem`?interface should?be?sealed or?at?least moved?to a?`jdk.internal.*`?package. Went the sealed class route. Unfortunately, the permitted classes are all package private otherwise I would have moved to an internal package. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Fri Oct 28 16:12:50 2022 From: duke at openjdk.org (j3graham) Date: Fri, 28 Oct 2022 16:12:50 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v2] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 14:55:28 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Move StringConcatItem to FormatConcatItem src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 365: > 363: Objects.requireNonNull(sts, "sts must not be null"); > 364: if (sts.length == 0) { > 365: StringTemplate.of(""); Missing return? src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 367: > 365: StringTemplate.of(""); > 366: } else if (sts.length == 1) { > 367: return sts[0]; Check for null? ------------- PR: https://git.openjdk.org/jdk/pull/10889 From joehw at openjdk.org Fri Oct 28 16:43:23 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 28 Oct 2022 16:43:23 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: <4ThJRTvihtvhX_xBjaCTHOL4w-VHDJuXTUkvtfRVPvY=.ad69332e-e7a2-43fc-9893-3a27f7ca4d5c@github.com> On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs 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: > > - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Fix whitespace issues > - 8294241 Thanks Daniel. The java.xml part looks good to me. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.org/jdk/pull/10874 From jlaskey at openjdk.org Fri Oct 28 17:57:30 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Oct 2022 17:57:30 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update TemplateRuntime::combine ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/26485968..20f54dec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Oct 28 18:01:30 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Oct 2022 18:01:30 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v2] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 16:09:51 GMT, j3graham wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Move StringConcatItem to FormatConcatItem > > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 365: > >> 363: Objects.requireNonNull(sts, "sts must not be null"); >> 364: if (sts.length == 0) { >> 365: StringTemplate.of(""); > > Missing return? Yep - updated > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 367: > >> 365: StringTemplate.of(""); >> 366: } else if (sts.length == 1) { >> 367: return sts[0]; > > Check for null? Added null checks ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mcimadamore at openjdk.org Fri Oct 28 18:38:20 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Oct 2022 18:38:20 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update TemplateRuntime::combine Added some comments - will probably have some more at a later point ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mcimadamore at openjdk.org Fri Oct 28 18:38:26 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Oct 2022 18:38:26 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v2] In-Reply-To: References: Message-ID: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com> On Fri, 28 Oct 2022 14:55:28 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Move StringConcatItem to FormatConcatItem src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 631: > 629: stringTemplateType = enterClass("java.lang.template.StringTemplate"); > 630: templateRuntimeType = enterClass("java.lang.template.TemplateRuntime"); > 631: templateProcessorType = enterClass("java.lang.template.ValidatingProcessor"); Please give it a name that matches the corresponding class - this threw me off when looking at the type-checking code. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 106: > 104: private final Attr attr; > 105: private final Symtab syms; > 106: private final Types types; Why this change? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4974: > 4972: if (processor != null) { > 4973: resultType = attribTree(processor, env, new ResultInfo(KindSelector.VAL, Type.noType)); > 4974: resultType = chk.checkProcessorType(processor, resultType, env); It seems that if this check is erroneous, the type that is considered as returned by the processor is just `StringTemplate`. This seems odd - if we have issues type-checking and we get StringTemplate instead of some type T that the user expects, but doesn't get (e.g. because of raw types), there could be spurious error messages generated from a type mismatch between T and StringTemplate. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139: > 4137: List typeArguments = interfaceType.getTypeArguments(); > 4138: > 4139: if (typeArguments.size() == 2) { Is this code correct? TemplateProcessor seems to have just one type argument. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java.orig line 1: > 1: /* This file shouldn't be here src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 348: > 346: try { > 347: chk.disablePreviewCheck = true; > 348: String autoImports = """ I see why you went down here. It is pragmatic, given we might add other stuff to the list. But it is mildly odd to see parser being called again from here, although harmless. What worries me more is the dance around enabling/disabling preview checks. Again, I see why you went there. As a possible alternative to disable preview checks globally, you could instead install a deferred log handler (see Log) class - so that all the diagnostics generated when following imports can be dropped on the floor. (we use this mechanism in DeferredAttr, to disable diagnostics during a deferred attribution step). ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mcimadamore at openjdk.org Fri Oct 28 18:38:27 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Oct 2022 18:38:27 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v2] In-Reply-To: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com> References: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com> Message-ID: On Fri, 28 Oct 2022 16:09:16 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Move StringConcatItem to FormatConcatItem > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139: > >> 4137: List typeArguments = interfaceType.getTypeArguments(); >> 4138: >> 4139: if (typeArguments.size() == 2) { > > Is this code correct? TemplateProcessor seems to have just one type argument. Ah - `templateProcessorType` is not what it seems :-) ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Fri Oct 28 18:50:34 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 28 Oct 2022 18:50:34 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com> On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update TemplateRuntime::combine src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 32: > 30: > 31: import java.io.IOException; > 32: import java.util.*; Please do not use import *. src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 36: > 34: import java.lang.invoke.MethodHandles.Lookup; > 35: import java.lang.template.StringTemplate; > 36: import java.util.*; Another import * here src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118: > 116: * @since 20 > 117: */ > 118: public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200; I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation. src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 999: > 997: * Promote integral types to int. > 998: */ > 999: private static Class promoteIntType(Class t) { promoteToIntType ? ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Fri Oct 28 19:02:30 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 28 Oct 2022 19:02:30 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update TemplateRuntime::combine src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042: > 1040: * The number of fragments must be one more that the number of ptypes. > 1041: * The total number of slots used by the ptypes must be less than or equal > 1042: * to MAX_INDY_CONCAT_ARG_SLOTS. see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1060: > 1058: throws StringConcatException > 1059: { > 1060: Objects.requireNonNull(fragments, "fragments is null"); I think you need to do some defensive copy here ptypes = List.copyOf(pTypes); to avoid the types and fragments to be changed at the same time they are checked. src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177: > 1175: */ > 1176: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) > 1177: public static List makeConcatWithTemplateCluster( I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 51: > 49: /** > 50: * Construct a {@link MethodHandle} that constructs a result based on the > 51: * bootstrap method information. This comment is quite obscure if you have no idea how it works. And the information that the returned method handle has the type of the MethodType passed as parameter is missing. src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38: > 36: record SimpleStringTemplate(List fragments, > 37: List values > 38: ) implements StringTemplate {} A compact constructor doing defensive copies is missing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Fri Oct 28 19:11:30 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 28 Oct 2022 19:11:30 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update TemplateRuntime::combine src/java.base/share/classes/java/lang/template/StringProcessor.java line 45: > 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) > 44: @FunctionalInterface > 45: public interface StringProcessor extends TemplateProcessor {} The name should be `StringTemplateProcessor`. And i'm not sure it's useful to have a specialized version for String, TemplateProcessor is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor` does not seem to offer enough bangs for bucks. src/java.base/share/classes/java/lang/template/StringTemplate.java line 29: > 27: > 28: import java.lang.invoke.MethodHandle; > 29: import java.util.*; Please fix. src/java.base/share/classes/java/lang/template/StringTemplate.java line 149: > 147: * {@return the interpolation of the StringTemplate} > 148: */ > 149: default String interpolate() { I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy src/java.base/share/classes/java/lang/template/StringTemplate.java line 175: > 173: * method {@code processor.process(this)}. > 174: */ > 175: default R process(ValidatingProcessor processor) throws E { signature should be `ValidatingProcessor processor` src/java.base/share/classes/java/lang/template/StringTemplate.java line 204: > 202: * embedded expressions fields, otherwise this method returns getters for the values list. > 203: */ > 204: default public List valueGetters() { I think i prefer the term accessors instead of getters ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Fri Oct 28 19:31:36 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 28 Oct 2022 19:31:36 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update TemplateRuntime::combine src/java.base/share/classes/java/lang/template/StringTemplate.java line 307: > 305: Objects.requireNonNull(fragment, "fragments elements must be non-null"); > 306: } > 307: fragments = Collections.unmodifiableList(new ArrayList<>(fragments)); I think using `List.copyOf()` is more efficient that `Collections.unmodifiableList(new ArrayList<>(...))` because there is no copy if the list is already created with List.of(). src/java.base/share/classes/java/lang/template/StringTemplate.java line 323: > 321: * @throws NullPointerException fragments or values is null or if any of the fragments is null > 322: */ > 323: public static String interpolate(List fragments, List values) { This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation. src/java.base/share/classes/java/lang/template/StringTemplate.java line 354: > 352: * @implNote The result of interpolation is not interned. > 353: */ > 354: public static final StringProcessor STR = st -> st.interpolate(); Should be `StringTemplate::interpolate`. src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 38: > 36: * that do not throw checked exceptions. For example: > 37: * {@snippet : > 38: * TemplateProcessor processor = st -> { This is a good example of why having both way to describe a template processor of string, TemplateProcessor 43: */ > 44: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) > 45: public final class TemplateRuntime { Why this class is public ? and it should be called `TemplateProcessors` linke all other classes in Java that store a bunch of static methods (Collections, Collectors, etc) src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 65: > 63: * @throws Throwable if linkage fails > 64: */ > 65: public static CallSite stringTemplateBSM( I wonder if this method should be moved to a class named `TemplateProcesorFactory` inside `java.lang.runtime`? Like the all the bootstrap methods recently added. src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 79: > 77: MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class); > 78: ValidatingProcessor processor = > 79: (ValidatingProcessor)processorGetter.asType(processorGetterType).invokeExact(); `ValidatingProcessor` should be enough ? No ? Not using a "? extends Throwable" here make the type unchecked. src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 88: > 86: * Manages the boostrapping of {@link ProcessorLinkage} callsites. > 87: */ > 88: private static class TemplateBootstrap { This class should be `final` src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 117: > 115: * Static final processor. > 116: */ > 117: private final ValidatingProcessor processor; Use `ValidatingProcessor` here src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 145: > 143: private TemplateBootstrap(MethodHandles.Lookup lookup, String name, MethodType type, > 144: List fragments, > 145: ValidatingProcessor processor) { Use ValidatingProcessor here src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211: > 209: @SuppressWarnings("unchecked") > 210: public static List toList(E... elements) { > 211: return Collections.unmodifiableList(Arrays.asList(elements)); This is List.of(), please use List.of() instead ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Oct 28 19:31:37 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Oct 2022 19:31:37 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v2] In-Reply-To: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com> References: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com> Message-ID: On Fri, 28 Oct 2022 16:33:11 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Move StringConcatItem to FormatConcatItem > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 631: > >> 629: stringTemplateType = enterClass("java.lang.template.StringTemplate"); >> 630: templateRuntimeType = enterClass("java.lang.template.TemplateRuntime"); >> 631: templateProcessorType = enterClass("java.lang.template.ValidatingProcessor"); > > Please give it a name that matches the corresponding class - this threw me off when looking at the type-checking code. Renaming. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 106: > >> 104: private final Attr attr; >> 105: private final Symtab syms; >> 106: private final Types types; > > Why this change? Renaming. Was residual to some context based typing (StringTemplate vs String) Jan and I experimented with. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4974: > >> 4972: if (processor != null) { >> 4973: resultType = attribTree(processor, env, new ResultInfo(KindSelector.VAL, Type.noType)); >> 4974: resultType = chk.checkProcessorType(processor, resultType, env); > > It seems that if this check is erroneous, the type that is considered as returned by the processor is just `StringTemplate`. This seems odd - if we have issues type-checking and we get StringTemplate instead of some type T that the user expects, but doesn't get (e.g. because of raw types), there could be spurious error messages generated from a type mismatch between T and StringTemplate. Not sure where you get `StringTemplate`. If you specify `TemplateProcessor` the `resultType` will be `String`. For example: public class Processor implements TemplateProcessor { @Override public String process(StringTemplate st) { return st.interpolate(); } } and public class Main { public static void main(String... args) throws Throwable { Processor processor = new Processor(); System.out.println(processor."1234"); } } works with "1234" as a result. If you later change to public class Processor implements TemplateProcessor { @Override public Integer process(StringTemplate st) { return Integer.valueOf(st.interpolate()); } } Then you get a `java.lang.ClassCastException` as you would expect. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java.orig line 1: > >> 1: /* > > This file shouldn't be here oops - We should change the `.gitignore` to include `.orig` and `.rej` > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 348: > >> 346: try { >> 347: chk.disablePreviewCheck = true; >> 348: String autoImports = """ > > I see why you went down here. It is pragmatic, given we might add other stuff to the list. But it is mildly odd to see parser being called again from here, although harmless. > > What worries me more is the dance around enabling/disabling preview checks. Again, I see why you went there. > > As a possible alternative to disable preview checks globally, you could instead install a deferred log handler (see Log) class - so that all the diagnostics generated when following imports can be dropped on the floor. (we use this mechanism in DeferredAttr, to disable diagnostics during a deferred attribution step). This was recommended by Jan and the procedure used in other parts of the code. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Oct 28 19:31:38 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Oct 2022 19:31:38 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v2] In-Reply-To: References: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com> Message-ID: On Fri, 28 Oct 2022 16:33:31 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139: >> >>> 4137: List typeArguments = interfaceType.getTypeArguments(); >>> 4138: >>> 4139: if (typeArguments.size() == 2) { >> >> Is this code correct? TemplateProcessor seems to have just one type argument. > > Ah - `templateProcessorType` is not what it seems :-) Renaming. I held off assuming that bike shedding would change it once again. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Oct 28 19:41:33 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Oct 2022 19:41:33 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com> References: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com> Message-ID: On Fri, 28 Oct 2022 18:45:05 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 32: > >> 30: >> 31: import java.io.IOException; >> 32: import java.util.*; > > Please do not use import *. Changing. > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 36: > >> 34: import java.lang.invoke.MethodHandles.Lookup; >> 35: import java.lang.template.StringTemplate; >> 36: import java.util.*; > > Another import * here Changing > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118: > >> 116: * @since 20 >> 117: */ >> 118: public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200; > > I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation. There have been several requests to make it public in the past. You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code. > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 999: > >> 997: * Promote integral types to int. >> 998: */ >> 999: private static Class promoteIntType(Class t) { > > promoteToIntType ? Changing > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1060: > >> 1058: throws StringConcatException >> 1059: { >> 1060: Objects.requireNonNull(fragments, "fragments is null"); > > I think you need to do some defensive copy here > > ptypes = List.copyOf(pTypes); > > to avoid the types and fragments to be changed at the same time they are checked. Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Fri Oct 28 19:41:34 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 28 Oct 2022 19:41:34 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update TemplateRuntime::combine src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 289: > 287: try { > 288: MethodHandles.Lookup lookup = MethodHandles.lookup(); > 289: MethodHandle getter = lookup.findStatic(TemplateRuntime.class, "getValue", This should be a constant (using the class holder idiom or not) src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 302: > 300: > 301: /** > 302: * Private ethod used by {@link TemplateRuntime#valueGetters(StringTemplate)} Private "method" src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 325: > 323: * @throws NullPointerException fragments or values is null or if any of the fragments is null > 324: */ > 325: static String interpolate(List fragments, List values) { I think it should be better to ensure that the caller always call with a List.of() or a List.copyOf() so null is not a possible element src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 389: > 387: } > 388: } > 389: return new SimpleStringTemplate(java.lang.template.TemplateRuntime.toList(fragments), java.lang.template.TemplateRuntime.toList(values)); It seems that IntelliJ was lot when auto-completing or doing a refactoring given that you are alreay in the class TemplateRuntime. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Oct 28 19:51:49 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Oct 2022 19:51:49 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v4] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove .orig file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/20f54dec..347df715 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=02-03 Stats: 4223 lines in 1 file changed: 0 ins; 4223 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Fri Oct 28 19:51:49 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 28 Oct 2022 19:51:49 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update TemplateRuntime::combine src/java.base/share/classes/java/util/FormatProcessor.java line 198: > 196: * {@link FMT} uses the Locale.US {@link Locale}. > 197: */ > 198: public static final FormatProcessor FMT = new FormatProcessor(Locale.US); `Locale.US` or `Locale.ROOT` ?? see https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Locale.html#ROOT ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Fri Oct 28 19:55:07 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 28 Oct 2022 19:55:07 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com> Message-ID: <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com> On Fri, 28 Oct 2022 19:34:37 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118: >> >>> 116: * @since 20 >>> 117: */ >>> 118: public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200; >> >> I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation. > > There have been several requests to make it public in the past. You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code. But it's an implementation details, BTW i wonder if the limitation is still valid, i know that John has changed the implementation of the BSM in that area. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Fri Oct 28 20:01:29 2022 From: duke at openjdk.org (Franz =?UTF-8?B?V2lsaGVsbXN0w7Z0dGVy?=) Date: Fri, 28 Oct 2022 20:01:29 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 19:21:56 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211: > >> 209: @SuppressWarnings("unchecked") >> 210: public static List toList(E... elements) { >> 211: return Collections.unmodifiableList(Arrays.asList(elements)); > > This is List.of(), please use List.of() instead `List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied: public static List toList(E... elements) { return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements))); } ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Fri Oct 28 20:01:30 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 28 Oct 2022 20:01:30 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com> On Fri, 28 Oct 2022 19:51:21 GMT, Franz Wilhelmst?tter wrote: >> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211: >> >>> 209: @SuppressWarnings("unchecked") >>> 210: public static List toList(E... elements) { >>> 211: return Collections.unmodifiableList(Arrays.asList(elements)); >> >> This is List.of(), please use List.of() instead > > `List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied: > > public static List toList(E... elements) { > return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements))); > } Yes, it only occurs to me mid review, that said there is already an implementation in the jdk of a compact immutable that allow null inside the JDK (this implementation is used when stream.toList() is used). Using that implementation will avoid a bunch of indirection ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Fri Oct 28 20:25:35 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 28 Oct 2022 20:25:35 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com> References: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com> <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com> Message-ID: On Fri, 28 Oct 2022 19:52:14 GMT, R?mi Forax wrote: >> There have been several requests to make it public in the past. You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code. > > But it's an implementation details, BTW i wonder if the limitation is still valid, i know that John has changed the implementation of the BSM in that area. Anyway, i think you are right, this can be public ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Oct 28 20:25:36 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Oct 2022 20:25:36 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 18:52:28 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042: > >> 1040: * The number of fragments must be one more that the number of ptypes. >> 1041: * The total number of slots used by the ptypes must be less than or equal >> 1042: * to MAX_INDY_CONCAT_ARG_SLOTS. > > see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public Disagree. > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177: > >> 1175: */ >> 1176: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) >> 1177: public static List makeConcatWithTemplateCluster( > > I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not Use cases are very different. The first one produces a `MethodHandle` that has multiple inputs, The second one produces a `MethodHandle` that can only have one input. > src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 51: > >> 49: /** >> 50: * Construct a {@link MethodHandle} that constructs a result based on the >> 51: * bootstrap method information. > > This comment is quite obscure if you have no idea how it works. > And the information that the returned method handle has the type of the MethodType passed as parameter is missing. Deliberate obscure for preview. Once we sort out the functional space you have been looking for, this will likely go away. ProcessorFactory and ProcessorBuilder are a couple of the possibilities. > src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38: > >> 36: record SimpleStringTemplate(List fragments, >> 37: List values >> 38: ) implements StringTemplate {} > > A compact constructor doing defensive copies is missing The defensive copies are done by the callers. > src/java.base/share/classes/java/lang/template/StringProcessor.java line 45: > >> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) >> 44: @FunctionalInterface >> 45: public interface StringProcessor extends TemplateProcessor {} > > The name should be `StringTemplateProcessor`. > And i'm not sure it's useful to have a specialized version for String, TemplateProcessor is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor` does not seem to offer enough bangs for bucks. > > see TemplateProcessor Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();` ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Fri Oct 28 20:25:36 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 28 Oct 2022 20:25:36 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com> On Fri, 28 Oct 2022 20:01:41 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042: >> >>> 1040: * The number of fragments must be one more that the number of ptypes. >>> 1041: * The total number of slots used by the ptypes must be less than or equal >>> 1042: * to MAX_INDY_CONCAT_ARG_SLOTS. >> >> see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public > > Disagree. As i said above, i consider this thread as resolved >> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177: >> >>> 1175: */ >>> 1176: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) >>> 1177: public static List makeConcatWithTemplateCluster( >> >> I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not > > Use cases are very different. The first one produces a `MethodHandle` that has multiple inputs, The second one produces a `MethodHandle` that can only have one input. yes, sorry for the noise. >> src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38: >> >>> 36: record SimpleStringTemplate(List fragments, >>> 37: List values >>> 38: ) implements StringTemplate {} >> >> A compact constructor doing defensive copies is missing > > The defensive copies are done by the callers. In that case, i wonder if not not better to move that record inside another class, closer to where the callers are >> src/java.base/share/classes/java/lang/template/StringProcessor.java line 45: >> >>> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) >>> 44: @FunctionalInterface >>> 45: public interface StringProcessor extends TemplateProcessor {} >> >> The name should be `StringTemplateProcessor`. >> And i'm not sure it's useful to have a specialized version for String, TemplateProcessor is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor` does not seem to offer enough bangs for bucks. >> >> see TemplateProcessor > > Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();` Is it that different from`TemplateProcessor upper = st -> st.interpolate().toUpperCase();` ? People are really used to use <> with the functional interfaces of java.util.function, and you avoid the "two ways" to express the same thing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Fri Oct 28 23:54:22 2022 From: duke at openjdk.org (j3graham) Date: Fri, 28 Oct 2022 23:54:22 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v4] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 19:51:49 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove .orig file src/java.base/share/classes/java/util/FormatterBuilder.java line 470: > 468: */ > 469: MethodHandle build() { > 470: Formatter.parse(format); `Formatter.parse` is called here, and then again a few lines down. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jjg at openjdk.org Sat Oct 29 00:05:32 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Sat, 29 Oct 2022 00:05:32 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs 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: > > - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Fix whitespace issues > - 8294241 The changes in `jdk.compiler` and `jdk.javadoc` seem innocuous enough. Because of the bootstrap issue/latency, we'll have to wait before we can update to non-deprecated code. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From jjg at openjdk.org Sat Oct 29 00:32:22 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Sat, 29 Oct 2022 00:32:22 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors [v6] In-Reply-To: <5V9-9Xl-FM3unMDlbQh0TjoFBYUfhFT6PMwL_tQqIXg=.c712ff48-f2ae-4f3e-ba92-d0aaa8cb576c@github.com> References: <5V9-9Xl-FM3unMDlbQh0TjoFBYUfhFT6PMwL_tQqIXg=.c712ff48-f2ae-4f3e-ba92-d0aaa8cb576c@github.com> Message-ID: On Tue, 25 Oct 2022 13:54:54 GMT, Hannes Walln?fer wrote: >> Please review a a new feature to allow `@link`, `@linkplain` and `@see` tags to link to arbitrary URI fragments in the generated documentation (including in auxiliary `doc-files` documentation). >> >> The changes in module `jdk.compiler` are mostly cleanup changes retained from earlier versions of the patch. The current proposed version uses a very simple change in `ReferenceParser` to avoid parsing the member name section of the reference when a non-member fragment is encountered. >> >> The implementation introduces a new form of reference with a double hash mark (`##`) separator. This is a change from the previous implementation which also auto-recognized URI fragments and documentation paths by looking for `-` characters which are not allowed in member names. This feature was removed upon further consideration because it makes the feature more complex and less recognizable. >> >> Links to auxiliary documentation files follow the same rules. They are recognized by looking for `/` characters in the fragment name. This means that ordinary `id` attribute values must not contain `/`, while auxiliary file paths must contain a `/` character. Both restrictions should be easy to sustain. >> >> One thing that is difficult for this feature is to provide a good link label if no label is supplied in the tag. In contrast to program element names a fragment name does usually not make a good human readable name. The solution is to use the fragment name as default label text. I expect that the feature will usually be used with a user provided label. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Add reference parsing modes and doctree tests Thanks for the new support in the doc-comment-parser for kinds of references. While docent may be able to make better checks, it can also be disabled, so it is good to catch things early where that is possible. I noticed various additional new/improved doc comments as well: nice! test/langtools/jdk/javadoc/doclet/testSeeLinkAnchor/TestSeeLinkAnchor.java line 114: > 112: checkOrder("m1/module-summary.html", > 113: """ > 114: See main heading in Class2"""); It seems like an anti-pattern to check the order of a single item! Is this as intended? Other examples, below, provide pairs. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.org/jdk/pull/10395 From duke at openjdk.org Sat Oct 29 01:03:23 2022 From: duke at openjdk.org (ExE Boss) Date: Sat, 29 Oct 2022 01:03:23 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com> On Fri, 28 Oct 2022 19:13:54 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 323: > >> 321: * @throws NullPointerException fragments or values is null or if any of the fragments is null >> 322: */ >> 323: public static String interpolate(List fragments, List values) { > > This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation. Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter. The?instance?method is?only?assignable to?`Function` or?`Supplier`, and?the?static?method is?only?assignable to?`BiFunction, List, String>`. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jpai at openjdk.org Sat Oct 29 11:58:26 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 29 Oct 2022 11:58:26 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com> Message-ID: On Thu, 27 Oct 2022 11:24:32 GMT, Daniel Fuchs wrote: >> How about `_unused` or `_unused1`, `_unused2` then in the meantime? > > I'd be happy to make the change. Let's wait to see if anybody has a better naming suggestion. Hello Daniel, I think calling it `unused` is fine. I did a quick search in the JDK code and we already have places where we use such a variable name for similar usecase. I don't see the need for using an underscore as a prefix, but it is OK with me if you and others prefer to use it. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From jpai at openjdk.org Sat Oct 29 12:05:07 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 29 Oct 2022 12:05:07 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com> Message-ID: On Wed, 26 Oct 2022 17:51:31 GMT, Daniel Fuchs wrote: >> I see your point. It may be more appropriate if URI.toURL was designed as URL.fromURL. >> >> I was wondering to have application developers a consistent way to get an URL instance. Now there are two methods in different classes URI.toURL and URL.fromURI. It might be easier to use the old URI.toURL form. >> >> Never mind, it is just my personal preference. It is fine to me to have a new URL.fromURI method. > > One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review. I think `URL.of(URI, URLStreamHandler)` is fine. As for `URL.of(URI)`, whose implementation I suspect will just do `uri.toURL()` on the passed `URI`, I don't think we need it. It might add to unnecesary confusion on whether/when to use `URL.of(URI)` and when to use `URI.toURL()` In the case of `URL.of(URI, URLStreamHandler)` it's pretty clear that you use it (only) when you have a specific `URLStreamHandler` to use for the constructed `URL`. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From aivanov at openjdk.org Sat Oct 29 12:14:25 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Sat, 29 Oct 2022 12:14:25 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:29:41 GMT, Andy Goryachev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert "Remove check for .properties from jcheck" >> >> This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. >> - Change trailing space and tab in values to unicode encoding > > src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134: > >> 132: >> 133: #SyncResolverImpl exceptions >> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020 > > prob. unnecessary This case is similar the one you mentioned below. If this value is used in a string template or concatenation, the trailing white-space could be necessary; however, one space is probably enough. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From aivanov at openjdk.org Sat Oct 29 13:22:09 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Sat, 29 Oct 2022 13:22:09 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: <4Npxj4pEaiqkJ2UBTsYb3xTHYseNBoj_3yshwocOIxw=.c701af52-62db-40c2-b3a3-90e47c44ed76@github.com> On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding Trailing spaces in `LocaleNames_*` are only in two files: - `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties` - `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties` It is very unlikely these spaces are part of a country or language name. The former file contains a few trailing spaces, the latter ? only one. src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties line 238: > 236: cpp=Kreolisch-Portugiesische Sprache > 237: crh=Krimtatarisch > 238: crp=Kreolische Sprache\u0020 I'm pretty sure locale names shouldn't contain trailing spaces. ------------- Marked as reviewed by aivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/10792 From alanb at openjdk.org Sat Oct 29 14:28:07 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 29 Oct 2022 14:28:07 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs 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: > > - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Fix whitespace issues > - 8294241 src/java.base/share/classes/java/net/URL.java line 133: > 131: * specified. The optional fragment is not inherited. > 132: * > 133: *

Constructing instances of {@code URL}

Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated? src/java.base/share/classes/java/net/URL.java line 157: > 155: * The URL constructors are specified to throw > 156: * {@link MalformedURLException} but the actual parsing/validation > 157: * that are performed is implementation dependent. Some parsing/validation "the ... are performed" -> "the ... is performed". src/java.base/share/classes/java/net/URL.java line 166: > 164: * The {@code java.net.URL} constructors are deprecated. > 165: * Developers are encouraged to use {@link URI java.net.URI} to parse > 166: * or construct any {@code URL}. In cases where an instance of {@code "any URL" -> "a URL" or "all URLs". src/java.base/share/classes/java/net/URL.java line 168: > 166: * or construct any {@code URL}. In cases where an instance of {@code > 167: * java.net.URL} is needed to open a connection, {@link URI} can be used > 168: * to construct or parse the URL string, possibly calling {@link I wonder if it might be clearer to say "url string", only to avoid anyone thinking they call URL::toString. src/java.base/share/classes/java/net/URL.java line 852: > 850: * @since 20 > 851: */ > 852: public static URL of(URI uri, URLStreamHandler streamHandler) The parameter is named "handler" rather than "streamHandler" in constructors so we should probably keep it the same to avoid any confusion. src/java.base/share/classes/java/net/URL.java line 885: > 883: > 884: @SuppressWarnings("deprecation") > 885: var result = new URL("jrt", host, port, file, null); The URL scheme for jrt does have a port so we should look at that some time. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From t.lapommeray at gmail.com Sat Oct 29 23:14:52 2022 From: t.lapommeray at gmail.com (Thalia L) Date: Sat, 29 Oct 2022 19:14:52 -0400 Subject: Running Diagnostic Examples Message-ID: Ran into an issue trying to run diagnostic examples, file in the readme (located at *test/langtools/tools/javac/diags/README.examples.txt*) states * RunExamples can be run standalone and as a jtreg test, in which case it generates a simple plain text report. In addition, the langtools/make/build.xml file has a target "diags-examples" that uses RunExamples to create an HTML report containing the output from all the examples.* but there is no file called langtools/make/build.xml however there is a file *make/langtools/diags-examples.xml *which is the only one with a diags-examples target it says to run like this* ant -f langtools/make/run-examples.xml -Dlangtools.jdk.home=* There is no *run-examples.xml.* When trying to run the command *cd make && ant -f langtools/diags-examples.xml -Dlangtools.jdk.home=../build/macosx-aarch64-server-release/jdk/, I get this error* Buildfile: /Users/thalial/Desktop/source/jdk/make/langtools/diags-examples.xml -def-check: -check-langtools.jdk.home: -prepare-build: [mkdir] Created dir: /Users/thalial/Desktop/source/jdk/make/build/langtools/modules [mkdir] Created dir: /Users/thalial/Desktop/source/jdk/make/build/langtools/toolclasses [mkdir] Created dir: /Users/thalial/Desktop/source/jdk/make/build/langtools/gensrc [mkdir] Created dir: /Users/thalial/Desktop/source/jdk/make/build/langtools/bin [mkdir] Created dir: /Users/thalial/Desktop/source/jdk/make/build/langtools/prevsrc -def-pparse: BUILD FAILED /Users/thalial/Desktop/source/jdk/make/langtools/build.xml:285: /Users/thalial/Desktop/source/jdk/make/make/langtools/tools/propertiesparser does not exist. Total time: 0 seconds Any advice on this issue? -- - Thalia La Pommeray ?understate and overprove..." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.org Sun Oct 30 18:52:32 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Sun, 30 Oct 2022 18:52:32 GMT Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second Preview) Message-ID: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements: - removal of named record patterns - (preview) type inference for type test and record patterns - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns) - fixing exhaustiveness of certain switches The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798). For more information on the changes please see: - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433) - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946) - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) (note the draft does not yet include details on type inference) Any feedback is welcome. Thanks! ------------- Commit messages: - Fixing test. - Cleanup. - Some more cleanup. - Various cleanup and adjustments to specification updates. - 8294942: Compiler implementation for Record Patterns (Second Preview) Changes: https://git.openjdk.org/jdk/pull/10814/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10814&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294942 Stats: 1465 lines in 38 files changed: 1081 ins; 277 del; 107 mod Patch: https://git.openjdk.org/jdk/pull/10814.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10814/head:pull/10814 PR: https://git.openjdk.org/jdk/pull/10814 From abimpoudis at openjdk.org Sun Oct 30 18:52:33 2022 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Sun, 30 Oct 2022 18:52:33 GMT Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second Preview) In-Reply-To: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com> References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com> Message-ID: On Fri, 21 Oct 2022 11:56:50 GMT, Jan Lahoda wrote: > This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements: > > - removal of named record patterns > - (preview) type inference for type test and record patterns > - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns) > - fixing exhaustiveness of certain switches > > The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798). > > For more information on the changes please see: > - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433) > - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946) > - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) (note the draft does not yet include details on type inference) > > Any feedback is welcome. > > Thanks! Some minor comments. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 656: > 654: } > 655: > 656: public Type instantiatePatternType(DiagnosticPosition pos, Type expressionType, TypeSymbol patternTypeSymbol) { `pos` seems unused so far. test/langtools/tools/javac/patterns/NewCaseStructureTest.java line 283: > 281: case Integer i when i > 0 -> 0; > 282: case 0 -> 0; > 283: case Integer i -> 0; This case is not needed, right? test/langtools/tools/javac/patterns/NewCaseStructureTest.java line 299: > 297: case E e when e == E.A -> 0; > 298: case B -> 0; > 299: case E e -> 0; Similarly. test/langtools/tools/javac/patterns/NewCaseStructureTest.java line 316: > 314: case String s when s.isEmpty() -> 0; > 315: case "a" -> 0; > 316: case String s -> 0; Similarly. test/langtools/tools/javac/patterns/NewCaseStructureTest.java line 348: > 346: default -> 0; > 347: case (Integer i) when i > 0 -> 0; > 348: case (Integer i) when i > 0 -> 0; Similarly. test/langtools/tools/javac/patterns/NewCaseStructureTest.java line 361: > 359: private int test(Integer o) { > 360: return switch (o) { > 361: case (Integer i) when i > 0 -> 0; Similarly. ------------- PR: https://git.openjdk.org/jdk/pull/10814 From jlahoda at openjdk.org Sun Oct 30 18:52:33 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Sun, 30 Oct 2022 18:52:33 GMT Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second Preview) In-Reply-To: References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com> Message-ID: On Tue, 25 Oct 2022 09:52:39 GMT, Aggelos Biboudis wrote: >> This is a partial implementation of [JEP 432: Record Patterns (Second Preview)](https://openjdk.org/jeps/432) and [JEP 433: Pattern Matching for switch (Fourth Preview)](https://openjdk.org/jeps/433). Namely, it implements: >> >> - removal of named record patterns >> - (preview) type inference for type test and record patterns >> - cleaner switch case specification (e.g. no combination of `null` constants and type test patterns) >> - fixing exhaustiveness of certain switches >> >> The patch does not contain support for record patterns in enhanced for statements, that is [part of a separate pull request](https://github.com/openjdk/jdk/pull/10798). >> >> For more information on the changes please see: >> - the JEPs: [JEP 432](https://openjdk.org/jeps/432) and [JEP 433](https://openjdk.org/jeps/433) >> - the CSRs: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) and [JEP 433 - JDK-8294946](https://bugs.openjdk.org/browse/JDK-8294946) >> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) (note the draft does not yet include details on type inference) >> >> Any feedback is welcome. >> >> Thanks! > > test/langtools/tools/javac/patterns/NewCaseStructureTest.java line 283: > >> 281: case Integer i when i > 0 -> 0; >> 282: case 0 -> 0; >> 283: case Integer i -> 0; > > This case is not needed, right? Well, omitting the unconditional case would make the switch non-exhaustive. While that would not be a blocker for a testcase that verifies that error are reported, I think it is cleaner to avoid unrelated errors in the source code. ------------- PR: https://git.openjdk.org/jdk/pull/10814 From abimpoudis at openjdk.org Sun Oct 30 18:52:34 2022 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Sun, 30 Oct 2022 18:52:34 GMT Subject: RFR: 8294942: Compiler implementation for Record Patterns (Second Preview) In-Reply-To: References: <_y9yHnRsLiueAOVuAv4b8y_DzigP52Rinnypg7aqjwM=.2ec12ad5-e69c-4d43-bf4c-8aea927b9663@github.com> Message-ID: On Thu, 27 Oct 2022 13:21:58 GMT, Jan Lahoda wrote: >> test/langtools/tools/javac/patterns/NewCaseStructureTest.java line 283: >> >>> 281: case Integer i when i > 0 -> 0; >>> 282: case 0 -> 0; >>> 283: case Integer i -> 0; >> >> This case is not needed, right? > > Well, omitting the unconditional case would make the switch non-exhaustive. While that would not be a blocker for a testcase that verifies that error are reported, I think it is cleaner to avoid unrelated errors in the source code. I checked: the exhaustivity errors are not reported after these points. The dominance check short circuits the structure test. But I see what you mean: while the tests do not isolate the error, they are type correct modulo dominance. Sounds good to me. ------------- PR: https://git.openjdk.org/jdk/pull/10814 From forax at openjdk.org Mon Oct 31 07:17:49 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 31 Oct 2022 07:17:49 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com> References: <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com> Message-ID: On Sat, 29 Oct 2022 00:56:18 GMT, ExE Boss wrote: >> src/java.base/share/classes/java/lang/template/StringTemplate.java line 323: >> >>> 321: * @throws NullPointerException fragments or values is null or if any of the fragments is null >>> 322: */ >>> 323: public static String interpolate(List fragments, List values) { >> >> This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation. > > Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter. > > The?instance?method is?only?assignable to?`Function` or?`Supplier`, and?the?static?method is?only?assignable to?`BiFunction, List, String>`. Ok, get it. I still see not reason to have this method being public given that this is equivalent to `Template.of(fragments, values).interpolate()`. The less methods in the API, the better. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlahoda at openjdk.org Mon Oct 31 09:15:43 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 31 Oct 2022 09:15:43 GMT Subject: RFR: 8294943: Implement record patterns in enhanced for [v2] In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 13:22:28 GMT, Aggelos Biboudis wrote: >> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: >> >> >> record Complex(double real, double img) {} >> >> List list = ...; >> >> for (Complex(var real, var img) : list) { >> // can use ?real? and ?img? directly >> } >> >> >> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following: >> >> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`. >> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. >> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression. >> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`. >> - The enhanced for, supports record patterns for both arrays and reference types. >> >> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason. >> >> For more information on the changes please see: >> >> - the JEP: [JEP 432](https://openjdk.org/jeps/432) >> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) >> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) >> >> Looking forward for your review. > > Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: > > Fix applicability bug Overall, seems good to me. Some comments/adjustments are inline. Thanks! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java line 428: > 426: @Override > 427: boolean match(JCEnhancedForLoop tree){ > 428: Assert.check(tree.getDeclarationKind() == EnhancedForLoopTree.DeclarationKind.VARIABLE); This assert is wrong - at the point the Analyzer is running, the enhanced for loop may use patterns Try, for example: public class ForEachTest { private void test(Iterable l) { for (R(Object a) : l) { } } record R(Object a) {} } And run: $ javac --enable-preview -source 20 -XDfind=all /tmp/ForEachTest.java Note: /tmp/ForEachTest.java uses preview features of Java SE 20. Note: Recompile with -Xlint:preview for details. An exception has occurred in the compiler (20-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. java.lang.AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) at jdk.compiler/com.sun.tools.javac.comp.Analyzer$RedundantLocalVarTypeAnalyzerForEach.match(Analyzer.java:428) ... Suggest to change the code of this method to: return tree.getDeclarationKind() == EnhancedForLoopTree.DeclarationKind.VARIABLE && !isImplicitlyTyped((JCVariableDecl) tree.varOrRecordPattern); Note the asserts in the other methods here are OK, as those methods should not (AFAIK) be called when this method returns false. Analyzer tests are under `test/langtools/tools/javac/analyzer`. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1549: > 1547: } > 1548: } > 1549: if(tree.getDeclarationKind() == EnhancedForLoopTree.DeclarationKind.VARIABLE) { It should be possible to use `tree.varOrRecordPattern instanceof JCVariableDecl jcVariableDecl` as is done in `Flow`, right? (Dtto on other places.) Nit: we usually put a space between `if` and `(`. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3463: > 3461: make.Ident(index)).setType(elemtype); > 3462: > 3463: JCBlock body = null; Offhand, it seems there are unnecessary changes in this file (like this declaration of `JCBlock body`. Please go through the patch, and undo the unnecessary changes. Keeping/adding the `Assert.check` is good, of course. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 753: > 751: make.at(tree.pos).VarDef(currentValue, null).setType(selectorType); > 752: > 753: List params = List.of(makeNull(), makeNull()); The specification says the exception should be `new MatchException(new NullPointerException())`, but the nested NPE seems to be missing here. FWIW, I think it is OK, for now, to create an empty NPE, but we may be able to do something better after PR 9746. ------------- Changes requested by jlahoda (Reviewer). PR: https://git.openjdk.org/jdk/pull/10798 From hannesw at openjdk.org Mon Oct 31 09:40:28 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 31 Oct 2022 09:40:28 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors [v6] In-Reply-To: References: <5V9-9Xl-FM3unMDlbQh0TjoFBYUfhFT6PMwL_tQqIXg=.c712ff48-f2ae-4f3e-ba92-d0aaa8cb576c@github.com> Message-ID: On Sat, 29 Oct 2022 00:21:29 GMT, Jonathan Gibbons wrote: >> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: >> >> Add reference parsing modes and doctree tests > > test/langtools/jdk/javadoc/doclet/testSeeLinkAnchor/TestSeeLinkAnchor.java line 114: > >> 112: checkOrder("m1/module-summary.html", >> 113: """ >> 114: See main heading in Class2"""); > > It seems like an anti-pattern to check the order of a single item! > Is this as intended? Other examples, below, provide pairs. Admittedly it was not a conscious choice to use `checkOrder` here, but I don't think it is an anti-pattern. Using `checkOrder` for a single string adds no overhead compared to `checkOutput`, and If we ever add additional string I think it is ok to do an ordered check by default. ------------- PR: https://git.openjdk.org/jdk/pull/10395 From hannesw at openjdk.org Mon Oct 31 09:40:28 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 31 Oct 2022 09:40:28 GMT Subject: RFR: JDK-8200337: Generalize see and link tags for user-defined anchors [v6] In-Reply-To: References: <5V9-9Xl-FM3unMDlbQh0TjoFBYUfhFT6PMwL_tQqIXg=.c712ff48-f2ae-4f3e-ba92-d0aaa8cb576c@github.com> Message-ID: On Mon, 31 Oct 2022 09:32:25 GMT, Hannes Walln?fer wrote: >> test/langtools/jdk/javadoc/doclet/testSeeLinkAnchor/TestSeeLinkAnchor.java line 114: >> >>> 112: checkOrder("m1/module-summary.html", >>> 113: """ >>> 114: See main heading in Class2"""); >> >> It seems like an anti-pattern to check the order of a single item! >> Is this as intended? Other examples, below, provide pairs. > > Admittedly it was not a conscious choice to use `checkOrder` here, but I don't think it is an anti-pattern. Using `checkOrder` for a single string adds no overhead compared to `checkOutput`, and If we ever add additional string I think it is ok to do an ordered check by default. Looking at the `JavadocTester` source code, I notice that the remaining uses of `checkOutput` are numbered and marked as TODO, which supports the idea that `checkOrder` should be the default. ------------- PR: https://git.openjdk.org/jdk/pull/10395 From jlaskey at openjdk.org Mon Oct 31 12:39:28 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 12:39:28 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com> References: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com> Message-ID: On Fri, 28 Oct 2022 20:23:26 GMT, R?mi Forax wrote: >> Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();` > > Is it that different from`TemplateProcessor upper = st -> st.interpolate().toUpperCase();` ? > > People are really used to use <> with the functional interfaces of java.util.function, and you avoid the "two ways" to express the same thing. Noted ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Oct 31 12:53:32 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 12:53:32 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 19:05:10 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 29: > >> 27: >> 28: import java.lang.invoke.MethodHandle; >> 29: import java.util.*; > > Please fix. Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Oct 31 12:53:29 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 12:53:29 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com> References: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com> Message-ID: On Fri, 28 Oct 2022 20:07:35 GMT, R?mi Forax wrote: >> The defensive copies are done by the callers. > > In that case, i wonder if not not better to move that record inside another class, closer to where the callers are Moving to TemplateRuntime ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Oct 31 12:59:36 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 12:59:36 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 19:06:43 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 175: > >> 173: * method {@code processor.process(this)}. >> 174: */ >> 175: default R process(ValidatingProcessor processor) throws E { > > signature should be `ValidatingProcessor processor` Changing > src/java.base/share/classes/java/lang/template/StringTemplate.java line 204: > >> 202: * embedded expressions fields, otherwise this method returns getters for the values list. >> 203: */ >> 204: default public List valueGetters() { > > I think i prefer the term accessors instead of getters Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Oct 31 13:04:32 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 13:04:32 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 19:08:56 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 149: > >> 147: * {@return the interpolation of the StringTemplate} >> 148: */ >> 149: default String interpolate() { > > I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy Actually instance interpolate() is the most important method. Each synthetic StringTemplate gets a specialized interpolate providing performance equivalent to string concat. And, a good percentage of processors will work with the result of interpolate to produce result. Ex. `StringProcessor STR = st -> st.interpolate();` and`TemplateProcessor JSON = st -> new JSONObject(st.interpolate());` ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Oct 31 13:40:38 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 13:40:38 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 19:12:02 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 307: > >> 305: Objects.requireNonNull(fragment, "fragments elements must be non-null"); >> 306: } >> 307: fragments = Collections.unmodifiableList(new ArrayList<>(fragments)); > > I think using `List.copyOf()` is more efficient that `Collections.unmodifiableList(new ArrayList<>(...))` because there is no copy if the list is already created with List.of(). > > Edit: > fragments should use List.copyOf() but i suppose that a value inside values can be null, so you can not use List.copyOf() for the values. > > There a little secret, the ImmutableList has a special flag to represent an unmodifiable list that can access null, this implementation is used by `stream.toList()`, i think you should use a shared secret access to have have access to this implementation instead of relying on `Collections.unmodifiableList(new ArrayList<>(...))`. > > @stuart-marks, do you think it's a good idea to use the null allowed ImmutableList here ? Changing as recommended > src/java.base/share/classes/java/lang/template/StringTemplate.java line 354: > >> 352: * @implNote The result of interpolation is not interned. >> 353: */ >> 354: public static final StringProcessor STR = st -> st.interpolate(); > > Should be `StringTemplate::interpolate`. Yep > src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 38: > >> 36: * that do not throw checked exceptions. For example: >> 37: * {@snippet : >> 38: * TemplateProcessor processor = st -> { > > This is a good example of why having both way to describe a template processor of string, TemplateProcessor References: <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com> Message-ID: On Mon, 31 Oct 2022 07:14:45 GMT, R?mi Forax wrote: >> Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter. >> >> The?instance?method is?only?assignable to?`Function` or?`Supplier`, and?the?static?method is?only?assignable to?`BiFunction, List, String>`. > > Ok, get it. > I still see not reason to have this method being public given that this is equivalent to `Template.of(fragments, values).interpolate()`. > > The less methods in the API, the better. Noted ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Oct 31 13:49:18 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 13:49:18 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: <81w3GhLtAZqVqYEmlmtrr8sAR1ntZEL-J3HB1x8AoC0=.3d20f03c-ac54-4fb1-b292-5190352bb4a1@github.com> On Fri, 28 Oct 2022 19:20:40 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 45: > >> 43: */ >> 44: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) >> 45: public final class TemplateRuntime { > > Why this class is public ? and it should be called `TemplateProcessors` linke all other classes in Java that store a bunch of static methods (Collections, Collectors, etc) Purely because of the BSM and BSMs access to internals of `java.lang.template`. I'll work on moving the BSM to `jdk.internal`. and access through `SharedSecrets`. > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 65: > >> 63: * @throws Throwable if linkage fails >> 64: */ >> 65: public static CallSite stringTemplateBSM( > > I wonder if this method should be moved to a class named `TemplateProcesorFactory` inside `java.lang.runtime`? Like the all the bootstrap methods recently added. Will work on it. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Oct 31 13:49:20 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 13:49:20 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com> References: <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com> Message-ID: On Fri, 28 Oct 2022 19:57:41 GMT, R?mi Forax wrote: >> `List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied: >> >> public static List toList(E... elements) { >> return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements))); >> } > > Yes, it only occurs to me mid review, that said there is already an implementation in the jdk of a compact immutable that allow null inside the JDK (this implementation is used when stream.toList() is used). > Using that implementation will avoid a bunch of indirection Changing to use `JUCA`. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Oct 31 13:54:44 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 13:54:44 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 19:26:20 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 79: > >> 77: MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class); >> 78: ValidatingProcessor processor = >> 79: (ValidatingProcessor)processorGetter.asType(processorGetterType).invokeExact(); > > `ValidatingProcessor` should be enough ? No ? > Using a "? extends Throwable" here make the type unchecked. That works. Changing. > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 88: > >> 86: * Manages the boostrapping of {@link ProcessorLinkage} callsites. >> 87: */ >> 88: private static class TemplateBootstrap { > > This class should be `final` Changing. > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 117: > >> 115: * Static final processor. >> 116: */ >> 117: private final ValidatingProcessor processor; > > Use `ValidatingProcessor` here That works. Changing. > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 145: > >> 143: private TemplateBootstrap(MethodHandles.Lookup lookup, String name, MethodType type, >> 144: List fragments, >> 145: ValidatingProcessor processor) { > > Use ValidatingProcessor<?, ?> here That works. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From abimpoudis at openjdk.org Mon Oct 31 13:59:37 2022 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 31 Oct 2022 13:59:37 GMT Subject: RFR: 8294943: Implement record patterns in enhanced for [v3] In-Reply-To: References: Message-ID: > This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: > > > record Complex(double real, double img) {} > > List list = ...; > > for (Complex(var real, var img) : list) { > // can use ?real? and ?img? directly > } > > > This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following: > > - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`. > - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. > - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression. > - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`. > - The enhanced for, supports record patterns for both arrays and reference types. > > Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason. > > For more information on the changes please see: > > - the JEP: [JEP 432](https://openjdk.org/jeps/432) > - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) > - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) > > Looking forward for your review. Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Address Review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10798/files - new: https://git.openjdk.org/jdk/pull/10798/files/ce2c78c7..6a8b8b76 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=01-02 Stats: 66 lines in 7 files changed: 34 ins; 7 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/10798.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798 PR: https://git.openjdk.org/jdk/pull/10798 From abimpoudis at openjdk.org Mon Oct 31 13:59:38 2022 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 31 Oct 2022 13:59:38 GMT Subject: RFR: 8294943: Implement record patterns in enhanced for [v2] In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 08:52:45 GMT, Jan Lahoda wrote: >> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix applicability bug > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java line 428: > >> 426: @Override >> 427: boolean match(JCEnhancedForLoop tree){ >> 428: Assert.check(tree.getDeclarationKind() == EnhancedForLoopTree.DeclarationKind.VARIABLE); > > This assert is wrong - at the point the Analyzer is running, the enhanced for loop may use patterns Try, for example: > > public class ForEachTest { > private void test(Iterable l) { > for (R(Object a) : l) { > > } > } > record R(Object a) {} > } > > > And run: > > $ javac --enable-preview -source 20 -XDfind=all /tmp/ForEachTest.java > Note: /tmp/ForEachTest.java uses preview features of Java SE 20. > Note: Recompile with -Xlint:preview for details. > An exception has occurred in the compiler (20-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. > java.lang.AssertionError > at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) > at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) > at jdk.compiler/com.sun.tools.javac.comp.Analyzer$RedundantLocalVarTypeAnalyzerForEach.match(Analyzer.java:428) > ... > > > Suggest to change the code of this method to: > > return tree.getDeclarationKind() == EnhancedForLoopTree.DeclarationKind.VARIABLE && > !isImplicitlyTyped((JCVariableDecl) tree.varOrRecordPattern); > > > Note the asserts in the other methods here are OK, as those methods should not (AFAIK) be called when this method returns false. > > Analyzer tests are under `test/langtools/tools/javac/analyzer`. Very good point! Added it as a stand alone test too! > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1549: > >> 1547: } >> 1548: } >> 1549: if(tree.getDeclarationKind() == EnhancedForLoopTree.DeclarationKind.VARIABLE) { > > It should be possible to use `tree.varOrRecordPattern instanceof JCVariableDecl jcVariableDecl` as is done in `Flow`, right? (Dtto on other places.) > > Nit: we usually put a space between `if` and `(`. I used what you propose when we need to initialise a variable, but kept the `getDeclarationKind()` method call when a variable is not needed (e.g. in assertions). Testing that way is visually clearer I think. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3463: > >> 3461: make.Ident(index)).setType(elemtype); >> 3462: >> 3463: JCBlock body = null; > > Offhand, it seems there are unnecessary changes in this file (like this declaration of `JCBlock body`. Please go through the patch, and undo the unnecessary changes. Keeping/adding the `Assert.check` is good, of course. I reverted this but kept the necessary cast. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 753: > >> 751: make.at(tree.pos).VarDef(currentValue, null).setType(selectorType); >> 752: >> 753: List params = List.of(makeNull(), makeNull()); > > The specification says the exception should be `new MatchException(new NullPointerException())`, but the nested NPE seems to be missing here. > > FWIW, I think it is OK, for now, to create an empty NPE, but we may be able to do something better after PR 9746. Addressed! ------------- PR: https://git.openjdk.org/jdk/pull/10798 From jlaskey at openjdk.org Mon Oct 31 14:30:28 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 14:30:28 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 19:33:38 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 289: > >> 287: try { >> 288: MethodHandles.Lookup lookup = MethodHandles.lookup(); >> 289: MethodHandle getter = lookup.findStatic(TemplateRuntime.class, "getValue", > > This should be a constant (using the class holder idiom or not) Changing > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 302: > >> 300: >> 301: /** >> 302: * Private ethod used by {@link TemplateRuntime#valueGetters(StringTemplate)} > > Private "method" Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Oct 31 14:39:34 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 14:39:34 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 19:39:01 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 389: > >> 387: } >> 388: } >> 389: return new SimpleStringTemplate(java.lang.template.TemplateRuntime.toList(fragments), java.lang.template.TemplateRuntime.toList(values)); > > It seems that IntelliJ was lost when auto-completing or doing a refactoring given that you are alreay in the class TemplateRuntime. Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Oct 31 14:49:30 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 14:49:30 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 19:36:07 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 325: > >> 323: * @throws NullPointerException fragments or values is null or if any of the fragments is null >> 324: */ >> 325: static String interpolate(List fragments, List values) { > > I think it should be better to ensure that the caller always call with a List.of() or a List.copyOf() so null is not a possible element Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From abimpoudis at openjdk.org Mon Oct 31 14:55:08 2022 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 31 Oct 2022 14:55:08 GMT Subject: RFR: 8294943: Implement record patterns in enhanced for [v4] In-Reply-To: References: Message-ID: > This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: > > > record Complex(double real, double img) {} > > List list = ...; > > for (Complex(var real, var img) : list) { > // can use ?real? and ?img? directly > } > > > This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following: > > - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`. > - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. > - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression. > - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`. > - The enhanced for, supports record patterns for both arrays and reference types. > > Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason. > > For more information on the changes please see: > > - the JEP: [JEP 432](https://openjdk.org/jeps/432) > - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) > - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) > > Looking forward for your review. Aggelos Biboudis 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: - Adjustments to make for-patterns and JDK-8294942 work together. - Merge remote-tracking branch 'lahodaj/JDK-8294942' into for-patterns - Fixing test. - Cleanup. - Some more cleanup. - Various cleanup and adjustments to specification updates. - 8294942: Compiler implementation for Record Patterns (Second Preview) - Address Review - Fix applicability bug - Store element type calculation result in JCEnhancedForLoop - ... and 3 more: https://git.openjdk.org/jdk/compare/9060c888...892fddf3 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10798/files - new: https://git.openjdk.org/jdk/pull/10798/files/6a8b8b76..892fddf3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10798&range=02-03 Stats: 36772 lines in 1364 files changed: 21606 ins; 9738 del; 5428 mod Patch: https://git.openjdk.org/jdk/pull/10798.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10798/head:pull/10798 PR: https://git.openjdk.org/jdk/pull/10798 From jlaskey at openjdk.org Mon Oct 31 15:01:31 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 15:01:31 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 19:45:55 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/java.base/share/classes/java/util/FormatProcessor.java line 198: > >> 196: * {@link FMT} uses the Locale.US {@link Locale}. >> 197: */ >> 198: public static final FormatProcessor FMT = new FormatProcessor(Locale.US); > > `Locale.US` or `Locale.ROOT` ?? > see https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Locale.html#ROOT There was a bug in DecimalFormatSymbols when I started this work and Locale.ROOT was problematic. I didn't circle around to check later. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Oct 31 15:01:35 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 15:01:35 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v4] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 23:50:11 GMT, j3graham wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove .orig file > > src/java.base/share/classes/java/util/FormatterBuilder.java line 470: > >> 468: */ >> 469: MethodHandle build() { >> 470: Formatter.parse(format); > > `Formatter.parse` is called here, and then again a few lines down. Residue cruft. Thanks. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Oct 31 15:38:42 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 15:38:42 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v5] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Requested changes #2 - Requested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/347df715..d30e6eff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=03-04 Stats: 168 lines in 15 files changed: 60 ins; 60 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Mon Oct 31 15:55:28 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 31 Oct 2022 15:55:28 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: <1lXCczNkyU6NVUX-kcITGUPRSJO5nhPgEZcWetMYTEw=.18a8f846-2688-445f-8d23-e2d2eeb88603@github.com> On Mon, 31 Oct 2022 13:02:18 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/template/StringTemplate.java line 149: >> >>> 147: * {@return the interpolation of the StringTemplate} >>> 148: */ >>> 149: default String interpolate() { >> >> I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy > > Actually instance interpolate() is the most important method. Each synthetic StringTemplate gets a specialized interpolate providing performance equivalent to string concat. And, a good percentage of processors will work with the result of interpolate to produce result. Ex. `StringProcessor STR = st -> st.interpolate();` and`TemplateProcessor JSON = st -> new JSONObject(st.interpolate());` Interesting ! I believe the javadoc should mention that. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From darcy at openjdk.org Mon Oct 31 16:55:42 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 31 Oct 2022 16:55:42 GMT Subject: RFR: 8294461: wrong effectively final determination by javac [v2] In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 19:45:05 GMT, Archie L. Cobbs wrote: >> This bug involves DA/DU analysis and the concept of "effectively final". >> >> Here's the test case, which the compiler currently but incorrectly accepts: >> >> for (int i = 0; i < 10; i++) { >> Runnable r = () -> System.out.println(i); // variable i is NOT effectively final >> break; // even though "i++" is never reached >> } >> >> >> For the purposes of "effectively final", it doesn't matter whether an assignment statement that makes a variable no longer effectively final is actually reachable or not. In cases like the `i++` above, a statement can be actually unreachable yet not "unreachable" according to the JLS, and so it does not generate an "unreachable statement" compiler error (which would otherwise hide this bug). >> >> JLS ?4.12.4 states: >> >>> A local variable declared by a statement and whose declarator has an initializer ... is effectively final if all of the following are true: >>> ... >>> ? It never occurs as the operand of a prefix or postfix increment or decrement operator (?15.14, ?15.15). >> >> So clearly `i` is not effectively final. >> >> However, the way we calculate effective finality does not involve actually looking for increment/decrement operators. Instead, it's determined during DA/DU analysis: non-final variables have an `EFFECTIVELY_FINAL` flag which is initialized to `true` and then cleared if/when we encounter contrary evidence - e.g., an assignment when not DU. >> >> For simplicity, the DA/DU analysis works like this: >> * Variables with initializers are treated like variables without initializers followed by an assignment >> * Increment/decrement operators are treated as a normal read followed by a normal assignment. >> >> These are reasonable. However, it means this clause of JLS ?4.12.4 effectively applies: >> >>> A local variable declared by a statement and whose declarator lacks an initializer is effectively final if all of the following are true: >>> ... >>> ? Whenever it occurs as the left hand side in an assignment expression, it is definitely unassigned and not definitely assigned before the assignment... >> >> The bug with the current code is that when we see an assignment to a variable with the `EFFECTIVELY_FINAL` flag still set, we clear the flag if the variable is not DU, but we are _not_ clearing the flag if the variable is DA, as required above. This happens with the `i++` statement because, by virtue of it being actually unreachable, `i` is both DA and DU before that statement. >> >> This patch corrects that omission. > > Archie L. Cobbs 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-8294461 > - A for loop variable is not effectively final even if the loop never increments. Should this change have a (retroactive) CSR and/or release note? ------------- PR: https://git.openjdk.org/jdk/pull/10856 From jonathan.gibbons at oracle.com Mon Oct 31 17:09:08 2022 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 31 Oct 2022 10:09:08 -0700 Subject: Running Diagnostic Examples In-Reply-To: References: Message-ID: <3faf1a59-7bf8-bad2-ac35-c180e8af3dab@oracle.com> Filed https://bugs.openjdk.org/browse/JDK-8296137 the `make/make` pair in the error message is clearly wrong, but fixing it requires more investigation -- Jon On 10/29/22 4:14 PM, Thalia L wrote: > Ran into an issue trying to run diagnostic examples, file in the > readme (located at > /test/langtools/tools/javac/diags/README.examples.txt/) states > > /? ? RunExamples can be run standalone and as a jtreg test, in which > case it > ? ? generates a simple plain text report. In addition, the > langtools/make/build.xml > ? ? file has a target "diags-examples" that uses RunExamples to create > an HTML > ? ? report containing the output from all the examples./ > > but there is no file called langtools/make/build.xml however there is > a file /make/langtools/diags-examples.xml /which is the only one with > a diags-examples target > it says to run like this/ant -f langtools/make/run-examples.xml > -Dlangtools.jdk.home=/ > > There is no /run-examples.xml. > / > When trying to run the command /cd make && ?ant -f > langtools/diags-examples.xml > -Dlangtools.jdk.home=../build/macosx-aarch64-server-release/jdk/, I > get this error/ > // > > Buildfile: > /Users/thalial/Desktop/source/jdk/make/langtools/diags-examples.xml > > -def-check: > > -check-langtools.jdk.home: > > -prepare-build: > ? ? [mkdir] Created dir: > /Users/thalial/Desktop/source/jdk/make/build/langtools/modules > ? ? [mkdir] Created dir: > /Users/thalial/Desktop/source/jdk/make/build/langtools/toolclasses > ? ? [mkdir] Created dir: > /Users/thalial/Desktop/source/jdk/make/build/langtools/gensrc > ? ? [mkdir] Created dir: > /Users/thalial/Desktop/source/jdk/make/build/langtools/bin > ? ? [mkdir] Created dir: > /Users/thalial/Desktop/source/jdk/make/build/langtools/prevsrc > > -def-pparse: > > BUILD FAILED > /Users/thalial/Desktop/source/jdk/make/langtools/build.xml:285: > /Users/thalial/Desktop/source/jdk/make/make/langtools/tools/propertiesparser > does not exist. > > Total time: 0 seconds > > Any advice on this issue? > > -- > - Thalia La Pommeray > > ?understate and overprove..." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaskey at openjdk.org Mon Oct 31 17:39:58 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 17:39:58 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v6] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Move template bootstrap ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/d30e6eff..75fcc49a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=04-05 Stats: 364 lines in 4 files changed: 210 ins; 147 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Mon Oct 31 19:04:45 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Mon, 31 Oct 2022 19:04:45 GMT Subject: RFR: 8294461: wrong effectively final determination by javac [v2] In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 19:45:05 GMT, Archie L. Cobbs wrote: >> This bug involves DA/DU analysis and the concept of "effectively final". >> >> Here's the test case, which the compiler currently but incorrectly accepts: >> >> for (int i = 0; i < 10; i++) { >> Runnable r = () -> System.out.println(i); // variable i is NOT effectively final >> break; // even though "i++" is never reached >> } >> >> >> For the purposes of "effectively final", it doesn't matter whether an assignment statement that makes a variable no longer effectively final is actually reachable or not. In cases like the `i++` above, a statement can be actually unreachable yet not "unreachable" according to the JLS, and so it does not generate an "unreachable statement" compiler error (which would otherwise hide this bug). >> >> JLS ?4.12.4 states: >> >>> A local variable declared by a statement and whose declarator has an initializer ... is effectively final if all of the following are true: >>> ... >>> ? It never occurs as the operand of a prefix or postfix increment or decrement operator (?15.14, ?15.15). >> >> So clearly `i` is not effectively final. >> >> However, the way we calculate effective finality does not involve actually looking for increment/decrement operators. Instead, it's determined during DA/DU analysis: non-final variables have an `EFFECTIVELY_FINAL` flag which is initialized to `true` and then cleared if/when we encounter contrary evidence - e.g., an assignment when not DU. >> >> For simplicity, the DA/DU analysis works like this: >> * Variables with initializers are treated like variables without initializers followed by an assignment >> * Increment/decrement operators are treated as a normal read followed by a normal assignment. >> >> These are reasonable. However, it means this clause of JLS ?4.12.4 effectively applies: >> >>> A local variable declared by a statement and whose declarator lacks an initializer is effectively final if all of the following are true: >>> ... >>> ? Whenever it occurs as the left hand side in an assignment expression, it is definitely unassigned and not definitely assigned before the assignment... >> >> The bug with the current code is that when we see an assignment to a variable with the `EFFECTIVELY_FINAL` flag still set, we clear the flag if the variable is not DU, but we are _not_ clearing the flag if the variable is DA, as required above. This happens with the `i++` statement because, by virtue of it being actually unreachable, `i` is both DA and DU before that statement. >> >> This patch corrects that omission. > > Archie L. Cobbs 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-8294461 > - A for loop variable is not effectively final even if the loop never increments. There shouldn't be any spec change implied by this change. From my understanding, the compiler was not following the spec, which says that the variable `i` in the example is not effectively final. This change makes the compiler follow the spec and generate a "local variables referenced from a lambda expression must be final or effectively final" error. Regarding release notes, I'll let someone else who has more familiarity with the release process comment on that. ------------- PR: https://git.openjdk.org/jdk/pull/10856 From jlaskey at openjdk.org Mon Oct 31 20:11:34 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 31 Oct 2022 20:11:34 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: Message-ID: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Add @SafeVarargs declarations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/75fcc49a..6d1d902e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=05-06 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Mon Oct 31 20:49:36 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 31 Oct 2022 20:49:36 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add @SafeVarargs declarations src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 132: > 130: return result; > 131: } > 132: for (Object value : st.values()) { I think that valueTypes() should return the types of the values not the dynamic classes of the values. Here there is no type information so it should be Object for all values. It has also the nice property that the return type of the accessors returned by valueAccessors are the same as valueTypes() which is i believe more coherent. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Mon Oct 31 20:54:33 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 31 Oct 2022 20:54:33 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add @SafeVarargs declarations src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 119: > 117: Class tsClass = st.getClass(); > 118: if (tsClass.isSynthetic()) { > 119: try { I do not know if this code is worth of optimizing but the way to avoid to recompute the List> each time is to use a java.lang.ClassValue and store the classes inside an unmodifiable List. (Field[] -> Class[] -> List>) The last leg can be done just by calling List.of(), there is no need for an ArrayList here ------------- PR: https://git.openjdk.org/jdk/pull/10889 From vromero at openjdk.org Mon Oct 31 21:01:22 2022 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 31 Oct 2022 21:01:22 GMT Subject: RFR: 8294943: Implement record patterns in enhanced for [v4] In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 14:55:08 GMT, Aggelos Biboudis wrote: >> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: >> >> >> record Complex(double real, double img) {} >> >> List list = ...; >> >> for (Complex(var real, var img) : list) { >> // can use ?real? and ?img? directly >> } >> >> >> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following: >> >> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`. >> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. >> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression. >> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`. >> - The enhanced for, supports record patterns for both arrays and reference types. >> >> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason. >> >> For more information on the changes please see: >> >> - the JEP: [JEP 432](https://openjdk.org/jeps/432) >> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) >> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) >> >> Looking forward for your review. > > Aggelos Biboudis 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: > > - Adjustments to make for-patterns and JDK-8294942 work together. > - Merge remote-tracking branch 'lahodaj/JDK-8294942' into for-patterns > - Fixing test. > - Cleanup. > - Some more cleanup. > - Various cleanup and adjustments to specification updates. > - 8294942: Compiler implementation for Record Patterns (Second Preview) > - Address Review > - Fix applicability bug > - Store element type calculation result in JCEnhancedForLoop > - ... and 3 more: https://git.openjdk.org/jdk/compare/f1323c33...892fddf3 src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 1248: > 1246: @Override @DefinedBy(Api.COMPILER_TREE) > 1247: public EnhancedForLoopTree.DeclarationKind getDeclarationKind() { > 1248: if (varOrRecordPattern instanceof JCVariableDecl) { probably better to use `JCTree::hasTag` instead of `instanceof`? ------------- PR: https://git.openjdk.org/jdk/pull/10798 From smarks at openjdk.org Mon Oct 31 21:25:41 2022 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 31 Oct 2022 21:25:41 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com> On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add @SafeVarargs declarations src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 99: > 97: private static List toList(E... elements) { > 98: return JUCA.listFromTrustedArrayNullsAllowed(elements); > 99: } I'm ok with using JUCA to create an unmodifiable list that can contain nulls. However, it "trusts" the argument array, meaning that the array is assumed to be referenced exclusively and so the array reference is used directly in the resulting List object. That implies that one needs to be very careful about the array that gets passed in, otherwise, the resulting List might not actually be unmodifiable. In particular, the call site in StringTemplate.of() https://github.com/openjdk/jdk/pull/10889/files#diff-d4e02e5ead5ad4f2cfe509c58d1145f599285cd6736bbf37e4116045b2fd50bcR309 passes the array obtained from a List parameter that comes directly from a public call, meaning that malicious code could keep a reference to the array returned by `toArray` and modify it later. You could clone the array, or just revert back to the slow path. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From prr at openjdk.org Mon Oct 31 22:02:15 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 31 Oct 2022 22:02:15 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com> On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs 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: > > - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Fix whitespace issues > - 8294241 Deprecate URL constructors. Developers are encouraged to use java.net.URI to parse or construct any URL. ... To construct a URL, using URI::toURL should be preferred. You have jumped through some refactoring hoops to be able to apply the deprecation suppression to as little code as possible .. having made such changes, then why didn't you just make the recommended change instead ? Should I presume that the recommended route will have some nasty little incompatibilities we will need to be careful of first ? And what about Peter Firmstone's comment "We stopped using java.net.URI some years ago as it's obsolete.?" I can't reconcile that with the recommendation to use it .. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From vromero at openjdk.org Mon Oct 31 22:06:29 2022 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 31 Oct 2022 22:06:29 GMT Subject: RFR: 8294461: wrong effectively final determination by javac [v2] In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 16:51:34 GMT, Joe Darcy wrote: > Should this change have a (retroactive) CSR and/or release note? well on similar cases we have done a CSR, I didn't realize during the review, sorry. I guess a CSR should probably be enough. I can help reviewing it ------------- PR: https://git.openjdk.org/jdk/pull/10856 From peter.firmstone at zeus.net.au Wed Oct 26 22:54:02 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 26 Oct 2022 22:54:02 -0000 Subject: RFR: 8294241: Deprecate URL public constructors In-Reply-To: References: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com> Message-ID: <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au> Interesting.? Is this RFR a done deal? While I like the concept and and understand the reasoning of URL not having a public constructor, I think this may have been thought of in isolation, I'm not sure how a custom URI, that strictly complies with RFC 3986 will behave, if it must also be parsed by java.net.URI, which is loosely compliant with RFC 2396 and RFC 2732.? Has anyone done any investigation?? We stopped using java.net.URI some years ago as it's obsolete.? The change will have some performance impact, by requiring redundant parsing. Just thought I'd mention it, in case it hasn't been thought of. If you do an internet search there are other implementations of RFC3986 in java also. https://github.com/pfirmstone/JGDMS/blob/e4a5012e71fd9a61b6e1e505f07e6c5358a4ccbc/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L1966 We have a strict URI 3986 implementation, which we use to create all URL instances from. This is how we avoid unnecessarily incurring accesses to file systems and DNS, this implementation had a massive performance and scalability improvement for us. /** ?* This class represents an immutable instance of a URI as defined by RFC 3986. ?*

?* This class replaces java.net.URI functionality. ?*

?* Unlike java.net.URI this class is not Serializable and hashCode and ?* equality is governed by strict RFC3986 normalisation. In addition "other" ?* characters allowed in java.net.URI as specified by javadoc, not specifically ?* allowed by RFC3986 are illegal and must be escaped.? This strict adherence ?* is essential to eliminate false negative or positive matches. ?*

?* In addition to RFC3896 normalisation, on OS platforms with a \ file separator ?* the path is converted to UPPER CASE for comparison for file: schema, during ?* equals and hashCode calls. ?*

?* IPv6 and IPvFuture host addresses must be enclosed in square brackets as per ?* RFC3986.? A zone delimiter %, if present, must be represented in escaped %25 ?* form. ?*

?* In addition to RFC3896 normalization, IPv6 host addresses will be normalized ?* to comply with RFC 5952 A Recommendation for IPv6 Address Text Representation. ?* This is to ensure consistent equality between identical IPv6 addresses. ?* ?* @since 3.0.0 ?*/ Regards, Peter. On 27/10/2022 3:57 am, Daniel Fuchs wrote: > On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan wrote: > >>> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent. >> I see your point. It may be more appropriate if URI.toURL was designed as URL.fromURL. >> >> I was wondering to have application developers a consistent way to get an URL instance. Now there are two methods in different classes URI.toURL and URL.fromURI. It might be easier to use the old URI.toURL form. >> >> Never mind, it is just my personal preference. It is fine to me to have a new URL.fromURI method. > One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review. > > ------------- > > PR: https://git.openjdk.org/jdk/pull/10874