From jjg at openjdk.java.net Fri Oct 1 00:02:11 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 1 Oct 2021 00:02:11 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v4] In-Reply-To: References: Message-ID: > Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world. > > ## Previously ... > > Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class. (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.) The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available. > > ## Now ... > > All `DCTree` nodes have 4 positions, 3 publicly available. > * the position of the first unique character, `pos` > * the starting position of the range of characters, `getStartPosition()` > * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()` > * the end position of the range of characters, `getEndPosition()`. > These are all relative to the beginning of the comment text, and are converted to file positions as needed. > > Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods. > > `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic. > > `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods. > > `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified. > > ## Testing ... > > Up until the point at which `DCTree.pos` was modified, all tests passed without change. When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated. > > Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker` which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue. > > ## Behavior ... > > Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`. This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work. Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: fix handling of PROVIDES and USES add new StartEndPosChecker for DocCommentTester add new CoverageTest, to ensure DocCommentTester tests provide full coverage ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5510/files - new: https://git.openjdk.java.net/jdk/pull/5510/files/cf6d3b8e..14c29bdc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5510&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5510&range=02-03 Stats: 263 lines in 3 files changed: 259 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5510.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5510/head:pull/5510 PR: https://git.openjdk.java.net/jdk/pull/5510 From jjg at openjdk.java.net Fri Oct 1 00:09:40 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 1 Oct 2021 00:09:40 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v4] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 00:02:11 GMT, Jonathan Gibbons wrote: >> Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world. >> >> ## Previously ... >> >> Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class. (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.) The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available. >> >> ## Now ... >> >> All `DCTree` nodes have 4 positions, 3 publicly available. >> * the position of the first unique character, `pos` >> * the starting position of the range of characters, `getStartPosition()` >> * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()` >> * the end position of the range of characters, `getEndPosition()`. >> These are all relative to the beginning of the comment text, and are converted to file positions as needed. >> >> Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods. >> >> `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic. >> >> `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods. >> >> `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified. >> >> ## Testing ... >> >> Up until the point at which `DCTree.pos` was modified, all tests passed without change. When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated. >> >> Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker` which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue. >> >> ## Behavior ... >> >> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`. This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work. Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > fix handling of PROVIDES and USES > add new StartEndPosChecker for DocCommentTester > add new CoverageTest, to ensure DocCommentTester tests provide full coverage test/langtools/tools/javac/doctree/CoverageTest.java line 129: > 127: > 128: List notFound = Stream.of(DocTree.Kind.values()) > 129: .filter(k -> switch (k) { case DOC_TYPE, OTHER -> false; default -> true; }) DOC_TYPE only appears in HTML files, and only then processing the entire file (i.e. not just the `` element, as in `package.html` etc. So, it cannot be generated by `.java` files. OTHER is a special kind that can be used to help provide compatible evolution of visitors/etc. It does not appear in any standard tree nodes. ------------- PR: https://git.openjdk.java.net/jdk/pull/5510 From jjg at openjdk.java.net Fri Oct 1 00:14:54 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 1 Oct 2021 00:14:54 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v4] In-Reply-To: References: Message-ID: <0lTxbe7Ukisk2agn5QjbH0hzYdczO-fVgVKA4GeDZ1s=.3defbdaf-85ac-417f-8da4-28e5ff43c074@github.com> On Fri, 1 Oct 2021 00:02:11 GMT, Jonathan Gibbons wrote: >> Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world. >> >> ## Previously ... >> >> Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class. (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.) The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available. >> >> ## Now ... >> >> All `DCTree` nodes have 4 positions, 3 publicly available. >> * the position of the first unique character, `pos` >> * the starting position of the range of characters, `getStartPosition()` >> * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()` >> * the end position of the range of characters, `getEndPosition()`. >> These are all relative to the beginning of the comment text, and are converted to file positions as needed. >> >> Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods. >> >> `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic. >> >> `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods. >> >> `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified. >> >> ## Testing ... >> >> Up until the point at which `DCTree.pos` was modified, all tests passed without change. When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated. >> >> Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker` which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue. >> >> ## Behavior ... >> >> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`. This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work. Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > fix handling of PROVIDES and USES > add new StartEndPosChecker for DocCommentTester > add new CoverageTest, to ensure DocCommentTester tests provide full coverage It turns out there is remarkable similarity between the new `CoverageTest` (2021) and the much older `SimpleDocTreeVisitorTest` (2012) written with the API was first introduced. The new test is effectively a modern rewrite that supersedes the old test. We might want to merge them at some point, or simply delete the old one. ------------- PR: https://git.openjdk.java.net/jdk/pull/5510 From jjg at openjdk.java.net Fri Oct 1 00:37:19 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 1 Oct 2021 00:37:19 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v5] In-Reply-To: References: Message-ID: > Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world. > > ## Previously ... > > Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class. (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.) The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available. > > ## Now ... > > All `DCTree` nodes have 4 positions, 3 publicly available. > * the position of the first unique character, `pos` > * the starting position of the range of characters, `getStartPosition()` > * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()` > * the end position of the range of characters, `getEndPosition()`. > These are all relative to the beginning of the comment text, and are converted to file positions as needed. > > Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods. > > `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic. > > `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods. > > `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified. > > ## Testing ... > > Up until the point at which `DCTree.pos` was modified, all tests passed without change. When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated. > > Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker` which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue. > > ## Behavior ... > > Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`. This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work. Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: improve comments in new tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5510/files - new: https://git.openjdk.java.net/jdk/pull/5510/files/14c29bdc..a532b2f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5510&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5510&range=03-04 Stats: 11 lines in 2 files changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5510.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5510/head:pull/5510 PR: https://git.openjdk.java.net/jdk/pull/5510 From serb at openjdk.java.net Fri Oct 1 01:39:31 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 1 Oct 2021 01:39:31 GMT Subject: RFR: 8272358: Some tests may fail when executed with other locales than the US In-Reply-To: References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com> <-6m-FQLBb9SgouaBObjGmNW0eukggujk_gVgqxv4Nmc=.c3887d22-1163-48e5-8d74-a870770abd39@github.com> <6Xtrgr_XaaB4_i80BPEbX2AnT6QFE16kmEGMHyIn9lA=.336d6708-9709-41cd-88c4-69975899f8bf@github.com> Message-ID: On Sat, 25 Sep 2021 12:10:16 GMT, Jie Fu wrote: > Shall we also fix ToolBasicTest.java and ToolSimpleTest.java just as what is done for LambdaTranslationTest1.java and LambdaTranslationTest2.java? If so, the 4 tests would be also fixed on our MacOS platforms. I do not want to add a global locale parameter to the places which may trigger loading of the different translations. Probably we missed the bugs like this(not exactly but similar to) https://bugs.openjdk.java.net/browse/JDK-8274544 because everybody passes US locale to the tests. Probably we missed some other bugs as well. > And do you test the fix on Linux? Thanks. On Linux I have checked "JA" and "RU" locales, nothing changed for "JA" it uses the same float format as the US, so the LambdaTranslationTest1/LambdaTranslationTest2 passed before/after the fix and the ToolBasicTest/ToolSimpleTest failed in the "JA" locale, one of the subtests compare the expected output saved for US locale with the real output of the test. For RU locale the tests fail before the fix and passed after because there is no specific translation so the US text is used, and this PR fixes the problem in the float format. ------------- PR: https://git.openjdk.java.net/jdk/pull/5098 From jiefu at openjdk.java.net Fri Oct 1 01:46:41 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 1 Oct 2021 01:46:41 GMT Subject: RFR: 8272358: Some tests may fail when executed with other locales than the US In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com> References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com> Message-ID: On Thu, 12 Aug 2021 08:46:07 GMT, Sergey Bylokhov wrote: > As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14). So this change doesn't fix the failure with Chinese and JA locales. ------------- PR: https://git.openjdk.java.net/jdk/pull/5098 From serb at openjdk.java.net Fri Oct 1 01:53:31 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 1 Oct 2021 01:53:31 GMT Subject: RFR: 8272358: Some tests may fail when executed with other locales than the US In-Reply-To: References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com> Message-ID: On Fri, 1 Oct 2021 01:43:12 GMT, Jie Fu wrote: > So this change doesn't fix the failure with Chinese and JA locales. Yes, I can rephrase it as "it fixes the locales which do not have translations". ------------- PR: https://git.openjdk.java.net/jdk/pull/5098 From jiefu at openjdk.java.net Fri Oct 1 01:57:45 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 1 Oct 2021 01:57:45 GMT Subject: RFR: 8272358: Some tests may fail when executed with other locales than the US In-Reply-To: References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com> Message-ID: On Fri, 1 Oct 2021 01:50:06 GMT, Sergey Bylokhov wrote: > > So this change doesn't fix the failure with Chinese and JA locales. > > Yes, I can rephrase it as "it fixes the locales which do not have translations". Then people with RU locale should look at this fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/5098 From serb at openjdk.java.net Fri Oct 1 04:10:29 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 1 Oct 2021 04:10:29 GMT Subject: RFR: 8272358: Some tests may fail when executed with other locales than the US In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com> References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com> Message-ID: On Thu, 12 Aug 2021 08:46:07 GMT, Sergey Bylokhov wrote: > As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14). @aivanov-jdk please take a look ------------- PR: https://git.openjdk.java.net/jdk/pull/5098 From jlahoda at openjdk.java.net Fri Oct 1 06:57:57 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 1 Oct 2021 06:57:57 GMT Subject: RFR: 8274363: Transitively sealed classes not considered exhaustive in switches [v2] In-Reply-To: <4Ic1_oURyu8UUM4voPOjhtqy9LhVEHB0eHW7_c_RvHI=.32af168f-774e-45a6-bb8a-de8b67dd06e7@github.com> References: <4Ic1_oURyu8UUM4voPOjhtqy9LhVEHB0eHW7_c_RvHI=.32af168f-774e-45a6-bb8a-de8b67dd06e7@github.com> Message-ID: > Consider code like: > > public class SwitchCoverage { > sealed interface A {} > sealed interface B1 extends A {} > sealed interface B2 extends A {} > sealed interface C extends A {} > final class D1 implements B1, C {} > final class D2 implements B2, C {} > > void test(A arg) { > int i = switch (arg) { > case B1 b1 -> 1; > case B2 b2 -> 2; > }; > } > > } > > > Note that `B1` covers `D1` and `B2` covers `D2`. So, `B1` and `B2` cover `C`, and hence `B1` and `B2` cover `A`. To detect this, when looking for coverage of permitted types of `A`, we need to transitively look if any of the permitted type is covered. > > The check uses the `DeferredCompletionFailureHandler`, because if don't want to fail the compilation on unresolvable permitted subclass. (In case the permitted subclass is covered by some other means, of course.) Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5717/files - new: https://git.openjdk.java.net/jdk/pull/5717/files/0a63b376..bf725e57 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5717&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5717&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5717/head:pull/5717 PR: https://git.openjdk.java.net/jdk/pull/5717 From jlahoda at openjdk.java.net Fri Oct 1 08:56:35 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 1 Oct 2021 08:56:35 GMT Subject: Integrated: 8269113: Javac throws when compiling switch (null) In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 11:15:03 GMT, Jan Lahoda wrote: > This handles a case of `switch (null)` (i.e. switch over a literal `null`). It is necessary to handle `BOT` (null type) in the switch's selector, similarly to how it is handled in `null instanceof ...`. Note that since any reference type is a supertype of the `null` (JLS 4.10.2.), any type pattern is total for `switch (null)`. This pull request has now been integrated. Changeset: 18870284 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/18870284084aaaf729640de0105ce21e253546b9 Stats: 45 lines in 4 files changed: 40 ins; 2 del; 3 mod 8269113: Javac throws when compiling switch (null) Co-authored-by: Guoxiong Li Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/5713 From jlahoda at openjdk.java.net Fri Oct 1 08:57:45 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 1 Oct 2021 08:57:45 GMT Subject: Integrated: 8274363: Transitively sealed classes not considered exhaustive in switches In-Reply-To: <4Ic1_oURyu8UUM4voPOjhtqy9LhVEHB0eHW7_c_RvHI=.32af168f-774e-45a6-bb8a-de8b67dd06e7@github.com> References: <4Ic1_oURyu8UUM4voPOjhtqy9LhVEHB0eHW7_c_RvHI=.32af168f-774e-45a6-bb8a-de8b67dd06e7@github.com> Message-ID: <8kHyUJDjPpoyM_mIORIfTTu456uhbuFWAsX2xMmGN-c=.11a066c4-e901-4307-898e-d95ec9786e02@github.com> On Mon, 27 Sep 2021 18:05:26 GMT, Jan Lahoda wrote: > Consider code like: > > public class SwitchCoverage { > sealed interface A {} > sealed interface B1 extends A {} > sealed interface B2 extends A {} > sealed interface C extends A {} > final class D1 implements B1, C {} > final class D2 implements B2, C {} > > void test(A arg) { > int i = switch (arg) { > case B1 b1 -> 1; > case B2 b2 -> 2; > }; > } > > } > > > Note that `B1` covers `D1` and `B2` covers `D2`. So, `B1` and `B2` cover `C`, and hence `B1` and `B2` cover `A`. To detect this, when looking for coverage of permitted types of `A`, we need to transitively look if any of the permitted type is covered. > > The check uses the `DeferredCompletionFailureHandler`, because if don't want to fail the compilation on unresolvable permitted subclass. (In case the permitted subclass is covered by some other means, of course.) This pull request has now been integrated. Changeset: 292d7bb1 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/292d7bb1d5d311b517b2cd6d0f6dc77e35b3f649 Stats: 72 lines in 2 files changed: 54 ins; 8 del; 10 mod 8274363: Transitively sealed classes not considered exhaustive in switches Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/5717 From prappo at openjdk.java.net Fri Oct 1 10:30:38 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 1 Oct 2021 10:30:38 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v5] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 00:37:19 GMT, Jonathan Gibbons wrote: >> Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world. >> >> ## Previously ... >> >> Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class. (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.) The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available. >> >> ## Now ... >> >> All `DCTree` nodes have 4 positions, 3 publicly available. >> * the position of the first unique character, `pos` >> * the starting position of the range of characters, `getStartPosition()` >> * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()` >> * the end position of the range of characters, `getEndPosition()`. >> These are all relative to the beginning of the comment text, and are converted to file positions as needed. >> >> Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods. >> >> `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic. >> >> `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods. >> >> `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified. >> >> ## Testing ... >> >> Up until the point at which `DCTree.pos` was modified, all tests passed without change. When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated. >> >> Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker` which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue. >> >> ## Behavior ... >> >> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`. This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work. Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > improve comments in new tests Changes requested by prappo (Reviewer). src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 225: > 223: } > 224: > 225: return Position.NOPOS; This method should return Diagnostic.NOPOS. I'm concerned with mixing com.sun.tools.javac.util.Position.NOPOS and javax.tools.Diagnostic.NOPOS. Although they currently have the same int value, they are of different types, used in different contexts, and not guaranteed to remain equal in the future. We might need to do something about it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5510 From prappo at openjdk.java.net Fri Oct 1 11:12:34 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 1 Oct 2021 11:12:34 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v3] In-Reply-To: References: <5k-NokDnsit6veesUaENZNCHMFcqm6pnoxuhmh0fdD0=.094c2232-c80e-459a-b282-201ba28d2d81@github.com> Message-ID: On Thu, 30 Sep 2021 19:11:31 GMT, Jonathan Gibbons wrote: >> For the sake of this review, using `switch` would be better: fewer changes, less cognitive load. Later we can think of ways of improving that code. It would be nice to structure it such that it would fail at compile time, if we forgot a case. > > It's hard to know how to make it fail at compile time. There are essentially 3 groups of trees ... inline tags (and other trees that use `DCEndPosTree`), block tags (the big block of cases round about line 177), and "other". We could arguably move block tags into the `default` case and use a type test, which would improve the future-safety. We could arguably catch missing cases at runtime with suitable use of `IllegalStateException`. > > As for tests, we *do* have tests for `ProvidesTree` and `UsesTree`, but the new `RangeChecker` didn't catch the missing case labels because the basic checks in `RangeChecker` were satisfied by the code in the default case in the switch statement. I agree that it might prove hard, if at all possible. That said, we should investigate this later, not in this PR. One potential direction for investigation would be "switching on sealed interfaces". A class or an interface can be a part of multiple sealed-interface hierarchies: sealed interface Tag permits Block, Inline {} sealed interface Block extends Tag permits Block1, Bimodal {} non-sealed interface Block1 extends Block {} sealed interface Inline extends Tag permits Inline1, Bimodal {} non-sealed interface Inline1 extends Inline {} non-sealed interface Bimodal extends Block, Inline {} After pattern matching for `switch` (currently in preview via JEP 406) has been standardized, the exhaustiveness of a switch could help us catch bugs at compile time. Possibly. ------------- PR: https://git.openjdk.java.net/jdk/pull/5510 From jlahoda at openjdk.java.net Fri Oct 1 11:39:31 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 1 Oct 2021 11:39:31 GMT Subject: RFR: 8274605: Fix predicate guarantees on returned values in (Doc)SourcePositions In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 19:31:11 GMT, Pavel Rappo wrote: > Please review this documentation change. The result might look verbose, but at least it is no longer confusing. Looks reasonable to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5781 From jjg at openjdk.java.net Fri Oct 1 15:18:29 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 1 Oct 2021 15:18:29 GMT Subject: RFR: 8274605: Fix predicate guarantees on returned values in (Doc)SourcePositions In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 19:31:11 GMT, Pavel Rappo wrote: > Please review this documentation change. The result might look verbose, but at least it is no longer confusing. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5781 From jjg at openjdk.java.net Fri Oct 1 15:40:41 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 1 Oct 2021 15:40:41 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v3] In-Reply-To: References: <5k-NokDnsit6veesUaENZNCHMFcqm6pnoxuhmh0fdD0=.094c2232-c80e-459a-b282-201ba28d2d81@github.com> Message-ID: On Fri, 1 Oct 2021 11:09:20 GMT, Pavel Rappo wrote: >> It's hard to know how to make it fail at compile time. There are essentially 3 groups of trees ... inline tags (and other trees that use `DCEndPosTree`), block tags (the big block of cases round about line 177), and "other". We could arguably move block tags into the `default` case and use a type test, which would improve the future-safety. We could arguably catch missing cases at runtime with suitable use of `IllegalStateException`. >> >> As for tests, we *do* have tests for `ProvidesTree` and `UsesTree`, but the new `RangeChecker` didn't catch the missing case labels because the basic checks in `RangeChecker` were satisfied by the code in the default case in the switch statement. > > I agree that it might prove hard, if at all possible. That said, we should investigate this later, not in this PR. One potential direction for investigation would be "switching on sealed interfaces". A class or an interface can be a part of multiple sealed-interface hierarchies: > > > sealed interface Tag permits Block, Inline {} > sealed interface Block extends Tag permits Block1, Bimodal {} > non-sealed interface Block1 extends Block {} > sealed interface Inline extends Tag permits Inline1, Bimodal {} > non-sealed interface Inline1 extends Inline {} > non-sealed interface Bimodal extends Block, Inline {} > > > After pattern matching for `switch` (currently in preview via JEP 406) has been standardized, the exhaustiveness of a switch could help us catch bugs at compile time. Possibly. Maybe. ------------- PR: https://git.openjdk.java.net/jdk/pull/5510 From jjg at openjdk.java.net Fri Oct 1 15:44:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 1 Oct 2021 15:44:38 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v5] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 10:25:41 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> improve comments in new tests > > src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 225: > >> 223: } >> 224: >> 225: return Position.NOPOS; > > This method should return Diagnostic.NOPOS. > > I'm concerned with mixing com.sun.tools.javac.util.Position.NOPOS and javax.tools.Diagnostic.NOPOS. Although they currently have the same int value, they are of different types, used in different contexts, and not guaranteed to remain equal in the future. We might need to do something about it. Hmmm. I doubt this is the only place where the values are conflated. I'll check with other `javac` folk about defining `com.sun.tools.javac.util.Position.NOPOS` in terms of `javax.tools.Diagnostic.NOPOS`. The internal version predates the public value, but the two are intended too be the same. ------------- PR: https://git.openjdk.java.net/jdk/pull/5510 From prappo at openjdk.java.net Fri Oct 1 16:19:30 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 1 Oct 2021 16:19:30 GMT Subject: Integrated: 8274605: Fix predicate guarantees on returned values in (Doc)SourcePositions In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 19:31:11 GMT, Pavel Rappo wrote: > Please review this documentation change. The result might look verbose, but at least it is no longer confusing. This pull request has now been integrated. Changeset: 05d38604 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/05d38604a2c620dcaf8682f02dae2fddab8e0c0b Stats: 20 lines in 2 files changed: 0 ins; 0 del; 20 mod 8274605: Fix predicate guarantees on returned values in (Doc)SourcePositions Reviewed-by: jlahoda, jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/5781 From jjg at openjdk.java.net Fri Oct 1 16:28:01 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 1 Oct 2021 16:28:01 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v6] In-Reply-To: References: Message-ID: > Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world. > > ## Previously ... > > Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class. (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.) The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available. > > ## Now ... > > All `DCTree` nodes have 4 positions, 3 publicly available. > * the position of the first unique character, `pos` > * the starting position of the range of characters, `getStartPosition()` > * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()` > * the end position of the range of characters, `getEndPosition()`. > These are all relative to the beginning of the comment text, and are converted to file positions as needed. > > Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods. > > `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic. > > `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods. > > `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified. > > ## Testing ... > > Up until the point at which `DCTree.pos` was modified, all tests passed without change. When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated. > > Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker` which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue. > > ## Behavior ... > > Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`. This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work. Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: remove unnecessary type qualifier ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5510/files - new: https://git.openjdk.java.net/jdk/pull/5510/files/a532b2f3..31547632 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5510&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5510&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5510.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5510/head:pull/5510 PR: https://git.openjdk.java.net/jdk/pull/5510 From jjg at openjdk.java.net Fri Oct 1 16:28:03 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 1 Oct 2021 16:28:03 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v5] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 15:41:17 GMT, Jonathan Gibbons wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 225: >> >>> 223: } >>> 224: >>> 225: return Position.NOPOS; >> >> This method should return Diagnostic.NOPOS. >> >> I'm concerned with mixing com.sun.tools.javac.util.Position.NOPOS and javax.tools.Diagnostic.NOPOS. Although they currently have the same int value, they are of different types, used in different contexts, and not guaranteed to remain equal in the future. We might need to do something about it. > > Hmmm. I doubt this is the only place where the values are conflated. I'll check with other `javac` folk about defining `com.sun.tools.javac.util.Position.NOPOS` in terms of `javax.tools.Diagnostic.NOPOS`. The internal version predates the public value, but the two are intended to be the same. I changed the line, but only to remove the redundant use of `Position.` The two values, `Diagnostic.NOPOS` and `Position.NOPOS` are intended to be the same value, allowing for the difference in type. The difference in type for `NOPOS`, and all methods in `Trees` (and `DocTrees`) that return positions, was intended to allow other implementations of `javax.tools` to handle longer source files (!!!) even though `javac` only support `int`-sized files. ------------- PR: https://git.openjdk.java.net/jdk/pull/5510 From jjg at openjdk.java.net Fri Oct 1 17:00:34 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 1 Oct 2021 17:00:34 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v4] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 00:06:22 GMT, Jonathan Gibbons wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> fix handling of PROVIDES and USES >> add new StartEndPosChecker for DocCommentTester >> add new CoverageTest, to ensure DocCommentTester tests provide full coverage > > test/langtools/tools/javac/doctree/CoverageTest.java line 129: > >> 127: >> 128: List notFound = Stream.of(DocTree.Kind.values()) >> 129: .filter(k -> switch (k) { case DOC_TYPE, OTHER -> false; default -> true; }) > > DOC_TYPE only appears in HTML files, and only then processing the entire file (i.e. not just the `` element, as in `package.html` etc. So, it cannot be generated by `.java` files. > > OTHER is a special kind that can be used to help provide compatible evolution of visitors/etc. It does not appear in any standard tree nodes. Added this explanation as comments in the file. ------------- PR: https://git.openjdk.java.net/jdk/pull/5510 From darcy at openjdk.java.net Mon Oct 4 06:52:21 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 4 Oct 2021 06:52:21 GMT Subject: RFR: 8274244: ReportOnImportedModuleAnnotation.java fails on rerun Message-ID: In terms of jtreg build tags, semantically this test wants to: * build annotation processing sources * compile module sources, running build annotation processor In particular, the test wants to always compile the module sources, even if class files are newer than the module-info.java files. Since the test is not written in terms of those tags, I've added a pre-step which delete any existing class files from the output directory. If needed, some extra care could be taken to only delete files from the one module. With this addition, the test will pass even when run with an already populated JTwork directory. At present, the test fails since the implicit compilation of module-info.java is *not* done when the class files in the output directory are newer than the sources. ------------- Commit messages: - 8274244: ReportOnImportedModuleAnnotation.java fails on rerun Changes: https://git.openjdk.java.net/jdk/pull/5802/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5802&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274244 Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5802/head:pull/5802 PR: https://git.openjdk.java.net/jdk/pull/5802 From prappo at openjdk.java.net Mon Oct 4 13:40:11 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 4 Oct 2021 13:40:11 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v6] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 16:28:01 GMT, Jonathan Gibbons wrote: >> Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world. >> >> ## Previously ... >> >> Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class. (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.) The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available. >> >> ## Now ... >> >> All `DCTree` nodes have 4 positions, 3 publicly available. >> * the position of the first unique character, `pos` >> * the starting position of the range of characters, `getStartPosition()` >> * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()` >> * the end position of the range of characters, `getEndPosition()`. >> These are all relative to the beginning of the comment text, and are converted to file positions as needed. >> >> Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods. >> >> `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic. >> >> `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods. >> >> `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified. >> >> ## Testing ... >> >> Up until the point at which `DCTree.pos` was modified, all tests passed without change. When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated. >> >> Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker` which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue. >> >> ## Behavior ... >> >> Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`. This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work. Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > remove unnecessary type qualifier Looks ok. src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 254: > 252: @Override @DefinedBy(Api.COMPILER_TREE) > 253: public Void scan(DocTree node, Void p) { > 254: if (node instanceof DCTree dcTree) last[0] = dcTree; When is it possible here to get a `DocTree` node, which is not also a `DCTree`? Separately. This is one more case that shows that the (Doc)TreeScanner should be able to control traversal. With the search case (JDK-8267690), we work around the lack of such control by throwing an exception to avoid traversing the rest of the tree when the node is found. Here, we are not so lucky and have to traverse the complete tree so that we eventually end up with the rightmost deepest node. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5510 From prappo at openjdk.java.net Mon Oct 4 13:55:13 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 4 Oct 2021 13:55:13 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v5] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 16:23:24 GMT, Jonathan Gibbons wrote: >> Hmmm. I doubt this is the only place where the values are conflated. I'll check with other `javac` folk about defining `com.sun.tools.javac.util.Position.NOPOS` in terms of `javax.tools.Diagnostic.NOPOS`. The internal version predates the public value, but the two are intended to be the same. > > I changed the line, but only to remove the redundant use of `Position.` > The two values, `Diagnostic.NOPOS` and `Position.NOPOS` are intended to be the same value, allowing for the difference in type. The difference in type for `NOPOS`, and all methods in `Trees` (and `DocTrees`) that return positions, was intended to allow other implementations of `javax.tools` to handle longer source files (!!!) even though `javac` only support `int`-sized files. Would you consider changing the definition of `Position.NOPOS` to this as you described elsewhere? Position.NOPOS = (int) Diagnostic.NOPOS Separately, consider adding these two assertions to com.sun.tools.javac.util.Position: static { assert NOPOS == ((int) javax.tools.Diagnostic.NOPOS); assert ((long) NOPOS) == javax.tools.Diagnostic.NOPOS; } These assertions would document our intent clearly and verifiably: these constants can be used interchangeably, barring occasional downcasting. ------------- PR: https://git.openjdk.java.net/jdk/pull/5510 From jjg at openjdk.java.net Mon Oct 4 15:33:08 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 4 Oct 2021 15:33:08 GMT Subject: RFR: 8268869: java in source-file mode suggests javac-only Xlint flags In-Reply-To: References: Message-ID: <2wP5q0KCIRH6Rtf1gBb9wOBMCMeZqSZm-rWYs16wEN4=.0f477bd4-7f1f-49d9-ac4f-423cee10f87a@github.com> On Mon, 28 Jun 2021 13:33:04 GMT, Adam Sotona wrote: > java in source-file mode (see JEP 330) displays compiler notes suggesting recompile with -Xlint:deprecation and -Xlint:unchecked. According JEP 330 these advanced javac optionns are not allowed. The goal with JEP 330 was to support developers that are at the early stages of learning Java, so options such as -Xlint are out of their scope. > > This patch prevents displaying "Note: Recompile with -Xlint:deprecation for details." and "Note: Recompile with -Xlint:unchecked for details." by implicitly enabling -Xlint:deprecation and -Xlint:unchecked in com.sun.tool.javac.launcher.Main for all invocations. > > Beside avoiding prohibited javac option suggestion notes this patch has positive effect of more verbose compilation diagnostic. Higher diagnostic verbosity is appreciated by users learning Java on single-source programs in java source-file mode. > > Similar case with -Xdiags:verbose was reported in JDK-8248843 and resolved in commit openjdk/jdk/31d0f0d8after review openjdk/jdk/4094 > > The patch also provides new test "testNoRecompileWithSuggestions" detecting unwanted recompilation suggestions in java in source-file mode execution. The test cover also case from JDK-8248843 with -Xdiags:verbose Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4613 From jjg at openjdk.java.net Mon Oct 4 15:33:10 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 4 Oct 2021 15:33:10 GMT Subject: RFR: 8268869: java in source-file mode suggests javac-only Xlint flags In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 08:59:44 GMT, Adam Sotona wrote: >> test/langtools/tools/javac/launcher/SourceLauncherTest.java line 624: >> >>> 622: " if (o instanceof String s) {\n" + >>> 623: " System.out.println(s);\n" + >>> 624: " }\n" + >> >> Is there a reason you're not using a text block here? > > Using text block will prevent potential "clean" backports of this issue. However if you think this patch won't be subject of backport, I can turn it into text block. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/4613 From asotona at openjdk.java.net Mon Oct 4 15:51:11 2021 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 4 Oct 2021 15:51:11 GMT Subject: Integrated: 8268869: java in source-file mode suggests javac-only Xlint flags In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 13:33:04 GMT, Adam Sotona wrote: > java in source-file mode (see JEP 330) displays compiler notes suggesting recompile with -Xlint:deprecation and -Xlint:unchecked. According JEP 330 these advanced javac optionns are not allowed. The goal with JEP 330 was to support developers that are at the early stages of learning Java, so options such as -Xlint are out of their scope. > > This patch prevents displaying "Note: Recompile with -Xlint:deprecation for details." and "Note: Recompile with -Xlint:unchecked for details." by implicitly enabling -Xlint:deprecation and -Xlint:unchecked in com.sun.tool.javac.launcher.Main for all invocations. > > Beside avoiding prohibited javac option suggestion notes this patch has positive effect of more verbose compilation diagnostic. Higher diagnostic verbosity is appreciated by users learning Java on single-source programs in java source-file mode. > > Similar case with -Xdiags:verbose was reported in JDK-8248843 and resolved in commit openjdk/jdk/31d0f0d8after review openjdk/jdk/4094 > > The patch also provides new test "testNoRecompileWithSuggestions" detecting unwanted recompilation suggestions in java in source-file mode execution. The test cover also case from JDK-8248843 with -Xdiags:verbose This pull request has now been integrated. Changeset: 139a8334 Author: Adam Sotona URL: https://git.openjdk.java.net/jdk/commit/139a8334cbc0c8e1a7a708efe18bd488d28292fd Stats: 35 lines in 2 files changed: 33 ins; 0 del; 2 mod 8268869: java in source-file mode suggests javac-only Xlint flags Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4613 From jjg at openjdk.java.net Mon Oct 4 16:34:08 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 4 Oct 2021 16:34:08 GMT Subject: RFR: 8274244: ReportOnImportedModuleAnnotation.java fails on rerun In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 00:35:19 GMT, Joe Darcy wrote: > In terms of jtreg build tags, semantically this test wants to: > > * build annotation processing sources > * compile module sources, running build annotation processor > > In particular, the test wants to always compile the module sources, even if class files are newer than the module-info.java files. Since the test is not written in terms of those tags, I've added a pre-step which delete any existing class files from the output directory. If needed, some extra care could be taken to only delete files from the one module. > > With this addition, the test will pass even when run with an already populated JTwork directory. At present, the test fails since the implicit compilation of module-info.java is *not* done when the class files in the output directory are newer than the sources. test/langtools/tools/javac/processing/ReportOnImportedModuleAnnotation/ReportOnImportedModuleAnnotation.java line 64: > 62: File file = path.toFile(); > 63: if (file.getName().endsWith(".class")) { > 64: file.delete(); This is unlikely to work reliably on Windows, where the delete can be asynchronous. I recommend the use of the `ToolBox` test library class, and `ToolBox.delete` Alternatively use jorge built-in guarantee that work directory is empty at the beginning of the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/5802 From jjg at openjdk.java.net Mon Oct 4 17:07:14 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 4 Oct 2021 17:07:14 GMT Subject: RFR: JDK-8273244: Improve diagnostic output related to ErroneousTree [v6] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 12:49:58 GMT, Pavel Rappo wrote: > When is it possible here to get a DocTree node, which is not also a DCTree? In standard `javac`/`javadoc`, essentially never. > Here, we are not so lucky and have to traverse the complete tree It's a shame we can't traverse the tree right to left ;-) But, this is only used for diagnostic positions, so is arguably less performance-sensitive. ------------- PR: https://git.openjdk.java.net/jdk/pull/5510 From jjg at openjdk.java.net Mon Oct 4 17:07:16 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 4 Oct 2021 17:07:16 GMT Subject: Integrated: JDK-8273244: Improve diagnostic output related to ErroneousTree In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 16:05:41 GMT, Jonathan Gibbons wrote: > Please review a medium size update/overhaul to the way that positions and diagnostic positions are handled in the `DocTree`/`DCTree` world. > > ## Previously ... > > Previously, most `DCTree` nodes only had an explicit "position" (`pos`). Start and end positions were provided by `DocSourcePositions`, but these were not directly available in tree nodes, because of the lack of access to the `DocSourcePositions` class. (In contrast, `JCTree` nodes do have position info, via static methods in `TreeInfo`.) The one notable exception to these guidelines was `DCErroneous` which (by analogy with `JCTree`) directly implemented `JCDiagnostic.DiagnosticPosition` but that was an arguably bad implementation because the positions were relative to the start of the comment, and not the start of the file. This did not show up in code and tests, because diagnostics related to `DocTree` nodes used `DCTree.pos` which returned a `SimpleDiagnosticPosition` referencing just the start position -- at least in part because more specific information was not easily available. > > ## Now ... > > All `DCTree` nodes have 4 positions, 3 publicly available. > * the position of the first unique character, `pos` > * the starting position of the range of characters, `getStartPosition()` > * the "preferred" position in the range, used to position the caret in diagnostic messages, `getPreferredPosition()` > * the end position of the range of characters, `getEndPosition()`. > These are all relative to the beginning of the comment text, and are converted to file positions as needed. > > Code to implement the end position is moved from `JavacTrees` to `DCTree`. It's still a switch on kind, but could reasonably be converted to using overriding methods. > > `DCErroneous` no longer implements `JCDiagnostic.DiagnosticPosition`. the constructor methods to create a diagnostic are removed, in favor of passing in a correctly-formed diagnostic. > > `DCTree` has a new improved `pos(DCDocComment)` method which now uses the new start/pref/end position methods. > > `DocCommentParser.ParseException` and the `erroneous` method now take an optional "pos" parameter to allow the position of an error to be more accurately specified. > > ## Testing ... > > Up until the point at which `DCTree.pos` was modified, all tests passed without change. When `DCTree.pos()` was modified, a few (3) doclint tests starting failing, demonstrating a latent reliance of the old form of `DCTree.pos()`. These tests are updated. > > Rather than write a single new test, the existing `DocCommentTester` class is updated to include a new `Checker` which, generally, checks the "left to right" nature of all positions in a doc comment tree and its subtrees. This leverages all the existing good and bad test cases in the `tools/javac/doctree` directory, which therefore all get tagged with the bug number for this issue. > > ## Behavior ... > > Apart from fixing generally bad behavior, there is one other tiny behavioral change. For an empty `DocCommentTree` the ending position is now the same at the starting position, and not `NOPOS`. This was triggered by the new code in `DocCommentTester`, but which affected one `jshell` test, which started getting `StringIndexOutOfBounds` exception. This is minimally fixed for now, but the code in question would arguably be better to use the new comment-based positions, rather than the file-based positions. But that seems out of scope for this work. Also worth investigating is the method `JavacTrees.getDocCommentTree(FileObject fileObject)` which uses a fixed offset of 0 (JavacTrees, line 1052) when creating doc comments for HTML files. This pull request has now been integrated. Changeset: 0ca094bc Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/0ca094bc5f568842b1619229206ec4a385e5ebf6 Stats: 1034 lines in 50 files changed: 676 ins; 127 del; 231 mod 8273244: Improve diagnostic output related to ErroneousTree Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/5510 From joe.darcy at oracle.com Mon Oct 4 17:21:19 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 4 Oct 2021 10:21:19 -0700 Subject: RFR: 8274244: ReportOnImportedModuleAnnotation.java fails on rerun In-Reply-To: References: Message-ID: <4cc696ad-f756-4be9-d366-8357780a50c5@oracle.com> On 10/4/2021 9:34 AM, Jonathan Gibbons wrote: > On Mon, 4 Oct 2021 00:35:19 GMT, Joe Darcy wrote: > >> In terms of jtreg build tags, semantically this test wants to: >> >> * build annotation processing sources >> * compile module sources, running build annotation processor >> >> In particular, the test wants to always compile the module sources, even if class files are newer than the module-info.java files. Since the test is not written in terms of those tags, I've added a pre-step which delete any existing class files from the output directory. If needed, some extra care could be taken to only delete files from the one module. >> >> With this addition, the test will pass even when run with an already populated JTwork directory. At present, the test fails since the implicit compilation of module-info.java is *not* done when the class files in the output directory are newer than the sources. > test/langtools/tools/javac/processing/ReportOnImportedModuleAnnotation/ReportOnImportedModuleAnnotation.java line 64: > >> 62: File file = path.toFile(); >> 63: if (file.getName().endsWith(".class")) { >> 64: file.delete(); > This is unlikely to work reliably on Windows, where the delete can be asynchronous. I recommend the use of the `ToolBox` test library class, and `ToolBox.delete` > Updated as suggested to use the toolbox; thanks, -Joe From darcy at openjdk.java.net Mon Oct 4 17:26:27 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 4 Oct 2021 17:26:27 GMT Subject: RFR: 8274244: ReportOnImportedModuleAnnotation.java fails on rerun [v2] In-Reply-To: References: Message-ID: > In terms of jtreg build tags, semantically this test wants to: > > * build annotation processing sources > * compile module sources, running build annotation processor > > In particular, the test wants to always compile the module sources, even if class files are newer than the module-info.java files. Since the test is not written in terms of those tags, I've added a pre-step which delete any existing class files from the output directory. If needed, some extra care could be taken to only delete files from the one module. > > With this addition, the test will pass even when run with an already populated JTwork directory. At present, the test fails since the implicit compilation of module-info.java is *not* done when the class files in the output directory are newer than the sources. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedbakc. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5802/files - new: https://git.openjdk.java.net/jdk/pull/5802/files/84653e63..c161c3ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5802&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5802&range=00-01 Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5802/head:pull/5802 PR: https://git.openjdk.java.net/jdk/pull/5802 From jjg at openjdk.java.net Mon Oct 4 18:54:20 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 4 Oct 2021 18:54:20 GMT Subject: RFR: JDK-8274745: ProblemList TestSnippetTag.java Message-ID: Please review a PR to problem-list `TestSnippetTag.java` while we investigating the cause for the failure ------------- Commit messages: - JDK-8274745: ProblemList TestSnippetTag.java Changes: https://git.openjdk.java.net/jdk/pull/5810/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5810&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274745 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5810.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5810/head:pull/5810 PR: https://git.openjdk.java.net/jdk/pull/5810 From prappo at openjdk.java.net Mon Oct 4 18:58:12 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 4 Oct 2021 18:58:12 GMT Subject: RFR: JDK-8274745: ProblemList TestSnippetTag.java In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 18:46:45 GMT, Jonathan Gibbons wrote: > Please review a PR to problem-list `TestSnippetTag.java` while we investigating the cause for the failure Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5810 From jjg at openjdk.java.net Mon Oct 4 19:05:12 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 4 Oct 2021 19:05:12 GMT Subject: Integrated: JDK-8274745: ProblemList TestSnippetTag.java In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 18:46:45 GMT, Jonathan Gibbons wrote: > Please review a PR to problem-list `TestSnippetTag.java` while we investigating the cause for the failure This pull request has now been integrated. Changeset: 75d6688d Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/75d6688df9845ecb8f370b4cd2d5a36f13d3cdc0 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod 8274745: ProblemList TestSnippetTag.java Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/5810 From darcy at openjdk.java.net Mon Oct 4 19:40:34 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 4 Oct 2021 19:40:34 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v8] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits: - Make readObject and writeObject methods in tests call default impl. - Merge branch 'master' into JDK-8202056 - Fix test. - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Fix whitespace. - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - ... and 31 more: https://git.openjdk.java.net/jdk/compare/9ca6bf0d...d912c92e ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=07 Stats: 1456 lines in 32 files changed: 1450 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From jjg at openjdk.java.net Mon Oct 4 21:26:19 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 4 Oct 2021 21:26:19 GMT Subject: RFR: JDK-8274744: TestSnippetTag test fails after recent integration Message-ID: Please review the update to `TestSnippetTag.java`, to update the "expected error" lines and caret positions, due to the improvements in JDK-8273244. ------------- Commit messages: - JDK-8274744: TestSnippetTag test fails after recent integration Changes: https://git.openjdk.java.net/jdk/pull/5812/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5812&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274744 Stats: 35 lines in 2 files changed: 0 ins; 2 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5812/head:pull/5812 PR: https://git.openjdk.java.net/jdk/pull/5812 From jjg at openjdk.java.net Mon Oct 4 22:48:18 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 4 Oct 2021 22:48:18 GMT Subject: RFR: JDK-8274729: Define Position.NOPOS == Diagnostic.NOPOS Message-ID: Please review a trivial change to formally connect `Position.NOPOS` and `Diagnostic.NOPOS`. ------------- Commit messages: - JDK-8274729: Define Position.NOPOS == Diagnostic.NOPOS Changes: https://git.openjdk.java.net/jdk/pull/5813/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5813&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274729 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5813.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5813/head:pull/5813 PR: https://git.openjdk.java.net/jdk/pull/5813 From darcy at openjdk.java.net Tue Oct 5 01:26:46 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 5 Oct 2021 01:26:46 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v9] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: <6Yb9QBOxsqcbEwZ5ZkucOtALQfDSI8jr9bW7LDT5btQ=.4c2850fc-23c6-45cd-8500-e86c4d8608ce@github.com> > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typos in properties file; improve implemention in Attr. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5709/files - new: https://git.openjdk.java.net/jdk/pull/5709/files/d912c92e..df18308b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=07-08 Stats: 237 lines in 8 files changed: 180 ins; 30 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Tue Oct 5 04:11:23 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 5 Oct 2021 04:11:23 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v10] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Merge branch 'master' into JDK-8202056 - Remove checkTypeOfField; improve checking for serialPersistentFields. - Fix typos in properties file; improve implemention in Attr. - Make readObject and writeObject methods in tests call default impl. - Merge branch 'master' into JDK-8202056 - Fix test. - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Fix whitespace. - ... and 34 more: https://git.openjdk.java.net/jdk/compare/e43f540c...ddcf3582 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=09 Stats: 1588 lines in 38 files changed: 1582 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Tue Oct 5 04:19:29 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 5 Oct 2021 04:19:29 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v11] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: <7O2u9IZV0Z7tQFlr2ZfBN9qD89ad1oQm_rbauJsLgVE=.3cb03f4f-1a84-4ad1-9dab-7f6a1fe0b2e5@github.com> > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Appease jcheck. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5709/files - new: https://git.openjdk.java.net/jdk/pull/5709/files/ddcf3582..4bb0e2d5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=09-10 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From jlahoda at openjdk.java.net Tue Oct 5 10:21:17 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 5 Oct 2021 10:21:17 GMT Subject: Integrated: 8272564: Incorrect attribution of method invocations of Object methods on interfaces In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 13:46:59 GMT, Jan Lahoda wrote: > Consider these declarations: > > interface I { > public String toString(); > } > interface J extends I {} > > > There are two issues with the `toString` inherited from `I` into `J`: > -`Trees.isAccessible(..., I.toString, J)` will return false, because `Resolve.isAccessible` will return false, because `Resolve.notOverriddenIn` returns false, because the `Object.toString` method is found as an implementation of `I.toString` in the context of `J`. This is unfortunate, because `Elements.getAllMembers(J)` will return `I.toString` as a member, not `Object.toString`, so any API client listing all members and then validating them using `Trees.isAccessible` will filter `toString` out. The proposed solution is to avoid using the methods from `java.lang.Object` as implementations of interface methods in `Resolve.notOverriddenIn`. (Interfaces don't inherit from `j.l.Object` per my understanding of JLS.) > -as a slightly less problematic case, consider: > > I i = null; > i.toString(); //AST and classfile contain call to I.toString() > J j = null; > j.toString(); //AST and classfile contain call to j.l.Object.toString() > > > I believe the second invocation should also preferably be a call to `I.toString()`, not a call to `j.l.Object.toString()`. The reason for this behavior is that in javac, interfaces have `j.l.Object` as a supertype, so method lookups over interfaces will look into `j.l.Object` before looking into the superinterfaces, and the concrete method will prevail over the super interface method found later. The proposal is, for interfaces, to only look into `j.l.Object` is a method is not found in the interface and its superinterfaces. This pull request has now been integrated. Changeset: a5080eff Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/a5080effc7ec7e260e84e3169c36c5217f18d231 Stats: 180 lines in 6 files changed: 176 ins; 0 del; 4 mod 8272564: Incorrect attribution of method invocations of Object methods on interfaces Reviewed-by: jlaskey, mcimadamore, vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/5165 From prappo at openjdk.java.net Tue Oct 5 10:52:07 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 5 Oct 2021 10:52:07 GMT Subject: RFR: JDK-8274744: TestSnippetTag test fails after recent integration In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 21:19:07 GMT, Jonathan Gibbons wrote: > Please review the update to `TestSnippetTag.java`, to update the "expected error" lines and caret positions, due to the improvements in JDK-8273244. Looks good. While in many cases diagnostics became more helpful, in the "unexpected content" case (missing newline after the colon) it is now more confusing. This is because the caret points to the colon and not to the unexpected character which follows the colon. We will have to improve that later. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5812 From jjg at openjdk.java.net Tue Oct 5 15:30:13 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 5 Oct 2021 15:30:13 GMT Subject: Integrated: JDK-8274744: TestSnippetTag test fails after recent integration In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 21:19:07 GMT, Jonathan Gibbons wrote: > Please review the update to `TestSnippetTag.java`, to update the "expected error" lines and caret positions, due to the improvements in JDK-8273244. This pull request has now been integrated. Changeset: 4e3948f1 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/4e3948f18b9b8dab96239ad24473134b712ada1a Stats: 35 lines in 2 files changed: 0 ins; 2 del; 33 mod 8274744: TestSnippetTag test fails after recent integration Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/5812 From jjg at openjdk.java.net Tue Oct 5 15:30:12 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 5 Oct 2021 15:30:12 GMT Subject: RFR: JDK-8274744: TestSnippetTag test fails after recent integration In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 10:48:45 GMT, Pavel Rappo wrote: > While in many cases diagnostics became more helpful, in the "unexpected content" case (missing newline after the colon) it is now more confusing. This is because the caret points to the colon and not to the unexpected character which follows the colon. We will have to improve that later. Two points: 1. (General) We probably have to be careful to ensure we don't try and point to a newline character. I'm not sure what the reporting system will do in that case. On the other hand, newline after colon is not an error, so we're probably OK in that case. 2. In the `javac` world, we found it better to report what was expected, more than just saying that what was found was unexpected. In this context, it would suggest replacing `unexpected content` with `newline expected after ':'`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5812 From jjg at openjdk.java.net Tue Oct 5 16:28:11 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 5 Oct 2021 16:28:11 GMT Subject: RFR: 8274244: ReportOnImportedModuleAnnotation.java fails on rerun [v2] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 17:26:27 GMT, Joe Darcy wrote: >> In terms of jtreg build tags, semantically this test wants to: >> >> * build annotation processing sources >> * compile module sources, running build annotation processor >> >> In particular, the test wants to always compile the module sources, even if class files are newer than the module-info.java files. Since the test is not written in terms of those tags, I've added a pre-step which delete any existing class files from the output directory. If needed, some extra care could be taken to only delete files from the one module. >> >> With this addition, the test will pass even when run with an already populated JTwork directory. At present, the test fails since the implicit compilation of module-info.java is *not* done when the class files in the output directory are newer than the sources. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedbakc. test/langtools/tools/javac/processing/ReportOnImportedModuleAnnotation/ReportOnImportedModuleAnnotation.java line 69: > 67: BasicFileAttributes attrs) { > 68: File file = path.toFile(); > 69: if (file.getName().endsWith(".class")) { You can avoid the `File` with: if (path.getFileName().toString().endsWith(".class")) ------------- PR: https://git.openjdk.java.net/jdk/pull/5802 From darcy at openjdk.java.net Tue Oct 5 17:22:29 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 5 Oct 2021 17:22:29 GMT Subject: RFR: 8274244: ReportOnImportedModuleAnnotation.java fails on rerun [v3] In-Reply-To: References: Message-ID: > In terms of jtreg build tags, semantically this test wants to: > > * build annotation processing sources > * compile module sources, running build annotation processor > > In particular, the test wants to always compile the module sources, even if class files are newer than the module-info.java files. Since the test is not written in terms of those tags, I've added a pre-step which delete any existing class files from the output directory. If needed, some extra care could be taken to only delete files from the one module. > > With this addition, the test will pass even when run with an already populated JTwork directory. At present, the test fails since the implicit compilation of module-info.java is *not* done when the class files in the output directory are newer than the sources. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5802/files - new: https://git.openjdk.java.net/jdk/pull/5802/files/c161c3ce..1190616e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5802&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5802&range=01-02 Stats: 18 lines in 1 file changed: 0 ins; 16 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5802/head:pull/5802 PR: https://git.openjdk.java.net/jdk/pull/5802 From jjg at openjdk.java.net Tue Oct 5 17:26:09 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 5 Oct 2021 17:26:09 GMT Subject: RFR: 8274244: ReportOnImportedModuleAnnotation.java fails on rerun [v2] In-Reply-To: References: Message-ID: <0tsOz2iuwT4GrCdfBs6rMqhDuF8rCFA7TFn8P9ujq-0=.83990c87-86d9-4ce6-aafd-1b5a5a9a3620@github.com> On Mon, 4 Oct 2021 17:26:27 GMT, Joe Darcy wrote: >> In terms of jtreg build tags, semantically this test wants to: >> >> * build annotation processing sources >> * compile module sources, running build annotation processor >> >> In particular, the test wants to always compile the module sources, even if class files are newer than the module-info.java files. Since the test is not written in terms of those tags, I've added a pre-step which delete any existing class files from the output directory. If needed, some extra care could be taken to only delete files from the one module. >> >> With this addition, the test will pass even when run with an already populated JTwork directory. At present, the test fails since the implicit compilation of module-info.java is *not* done when the class files in the output directory are newer than the sources. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedbakc. Marked as reviewed by jjg (Reviewer). test/langtools/tools/javac/processing/ReportOnImportedModuleAnnotation/ReportOnImportedModuleAnnotation.java line 63: > 61: // Clean any existing class files in output directory > 62: var tb = new ToolBox(); > 63: Files.walkFileTree(testOutputPath, If it is OK to remove the entire directory contents, you could use `tb.cleanDirectory(testOutputPath);` test/langtools/tools/javac/processing/ReportOnImportedModuleAnnotation/ReportOnImportedModuleAnnotation.java line 73: > 71: tb.deleteFiles(path); > 72: } catch (java.io.IOException ioe) { > 73: ; // ignore in tests, it my be reasonable to let exceptions percolate all the way up, rather than ignore them. ------------- PR: https://git.openjdk.java.net/jdk/pull/5802 From jjg at openjdk.java.net Tue Oct 5 17:26:11 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 5 Oct 2021 17:26:11 GMT Subject: RFR: 8274244: ReportOnImportedModuleAnnotation.java fails on rerun [v3] In-Reply-To: References: Message-ID: <4HIw52TKKpZ89puH7-hoOWCz_YgvL7bicDDExuSoVAY=.f5dd33de-2dba-487e-b510-6d39bb36da54@github.com> On Tue, 5 Oct 2021 17:22:29 GMT, Joe Darcy wrote: >> In terms of jtreg build tags, semantically this test wants to: >> >> * build annotation processing sources >> * compile module sources, running build annotation processor >> >> In particular, the test wants to always compile the module sources, even if class files are newer than the module-info.java files. Since the test is not written in terms of those tags, I've added a pre-step which delete any existing class files from the output directory. If needed, some extra care could be taken to only delete files from the one module. >> >> With this addition, the test will pass even when run with an already populated JTwork directory. At present, the test fails since the implicit compilation of module-info.java is *not* done when the class files in the output directory are newer than the sources. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. test/langtools/tools/javac/processing/ReportOnImportedModuleAnnotation/ReportOnImportedModuleAnnotation.java line 43: > 41: import java.nio.file.Files; > 42: import java.nio.file.Path; > 43: import java.nio.file.SimpleFileVisitor; Consider removing redundant imports. test/langtools/tools/javac/processing/ReportOnImportedModuleAnnotation/ReportOnImportedModuleAnnotation.java line 63: > 61: // Clean any existing files in output directory > 62: (new ToolBox()).cleanDirectory(testOutputPath); > 63: Nice. ------------- PR: https://git.openjdk.java.net/jdk/pull/5802 From jjg at openjdk.java.net Tue Oct 5 17:26:12 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 5 Oct 2021 17:26:12 GMT Subject: RFR: 8274244: ReportOnImportedModuleAnnotation.java fails on rerun [v2] In-Reply-To: <0tsOz2iuwT4GrCdfBs6rMqhDuF8rCFA7TFn8P9ujq-0=.83990c87-86d9-4ce6-aafd-1b5a5a9a3620@github.com> References: <0tsOz2iuwT4GrCdfBs6rMqhDuF8rCFA7TFn8P9ujq-0=.83990c87-86d9-4ce6-aafd-1b5a5a9a3620@github.com> Message-ID: <9m9qyXtxlBsEKqc1vMkbSMcVXx8vh3x5XXeF9cHxBoI=.a22476c2-bd35-4651-b148-e1f8746cea03@github.com> On Tue, 5 Oct 2021 16:28:05 GMT, Jonathan Gibbons wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedbakc. > > test/langtools/tools/javac/processing/ReportOnImportedModuleAnnotation/ReportOnImportedModuleAnnotation.java line 63: > >> 61: // Clean any existing class files in output directory >> 62: var tb = new ToolBox(); >> 63: Files.walkFileTree(testOutputPath, > > If it is OK to remove the entire directory contents, you could use `tb.cleanDirectory(testOutputPath);` The code (here) to do a filtered delete suggests an RFE for `ToolBox`, for a new overload of `cleanDirectory` ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5802 From darcy at openjdk.java.net Tue Oct 5 17:35:39 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 5 Oct 2021 17:35:39 GMT Subject: RFR: 8274244: ReportOnImportedModuleAnnotation.java fails on rerun [v4] In-Reply-To: References: Message-ID: > In terms of jtreg build tags, semantically this test wants to: > > * build annotation processing sources > * compile module sources, running build annotation processor > > In particular, the test wants to always compile the module sources, even if class files are newer than the module-info.java files. Since the test is not written in terms of those tags, I've added a pre-step which delete any existing class files from the output directory. If needed, some extra care could be taken to only delete files from the one module. > > With this addition, the test will pass even when run with an already populated JTwork directory. At present, the test fails since the implicit compilation of module-info.java is *not* done when the class files in the output directory are newer than the sources. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Clean up imports. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5802/files - new: https://git.openjdk.java.net/jdk/pull/5802/files/1190616e..f09d43de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5802&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5802&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5802/head:pull/5802 PR: https://git.openjdk.java.net/jdk/pull/5802 From darcy at openjdk.java.net Tue Oct 5 17:35:41 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 5 Oct 2021 17:35:41 GMT Subject: Integrated: 8274244: ReportOnImportedModuleAnnotation.java fails on rerun In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 00:35:19 GMT, Joe Darcy wrote: > In terms of jtreg build tags, semantically this test wants to: > > * build annotation processing sources > * compile module sources, running build annotation processor > > In particular, the test wants to always compile the module sources, even if class files are newer than the module-info.java files. Since the test is not written in terms of those tags, I've added a pre-step which delete any existing class files from the output directory. If needed, some extra care could be taken to only delete files from the one module. > > With this addition, the test will pass even when run with an already populated JTwork directory. At present, the test fails since the implicit compilation of module-info.java is *not* done when the class files in the output directory are newer than the sources. This pull request has now been integrated. Changeset: c391e59e Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/c391e59ea6fe6759553425e342b2d97824dd9323 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod 8274244: ReportOnImportedModuleAnnotation.java fails on rerun Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/5802 From darcy at openjdk.java.net Tue Oct 5 18:30:29 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 5 Oct 2021 18:30:29 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v12] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: <3ogF7k0HD-0vcaqSB8DwHQ8U_eazzf5-gfJNdBIX5ds=.c28724af-b986-4f10-9efa-d271eef5cc42@github.com> > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits: - Merge branch 'master' into JDK-8202056 - Appease jcheck. - Merge branch 'master' into JDK-8202056 - Remove checkTypeOfField; improve checking for serialPersistentFields. - Fix typos in properties file; improve implemention in Attr. - Make readObject and writeObject methods in tests call default impl. - Merge branch 'master' into JDK-8202056 - Fix test. - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - ... and 36 more: https://git.openjdk.java.net/jdk/compare/1e752033...fb8e0551 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=11 Stats: 1570 lines in 37 files changed: 1564 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From jlahoda at openjdk.java.net Tue Oct 5 18:53:06 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 5 Oct 2021 18:53:06 GMT Subject: RFR: JDK-8274729: Define Position.NOPOS == Diagnostic.NOPOS In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 22:41:42 GMT, Jonathan Gibbons wrote: > Please review a trivial change to formally connect `Position.NOPOS` and `Diagnostic.NOPOS`. Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5813 From jjg at openjdk.java.net Tue Oct 5 19:00:13 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 5 Oct 2021 19:00:13 GMT Subject: Integrated: JDK-8274729: Define Position.NOPOS == Diagnostic.NOPOS In-Reply-To: References: Message-ID: <4QOhwPf5NH_NoHoVZRtPAt1PxVJlOD6wiqPIdmNgn3M=.31b5cec0-5d71-49b8-9613-21e43be16b0f@github.com> On Mon, 4 Oct 2021 22:41:42 GMT, Jonathan Gibbons wrote: > Please review a trivial change to formally connect `Position.NOPOS` and `Diagnostic.NOPOS`. This pull request has now been integrated. Changeset: 332f0673 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/332f0673880d547a5f09cb4efd3b952868a84b91 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8274729: Define Position.NOPOS == Diagnostic.NOPOS Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/5813 From darcy at openjdk.java.net Wed Oct 6 00:00:32 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 6 Oct 2021 00:00:32 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v13] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: <9UFtnvEOmv7X8yC_nQzszoAvraB1-NwrW0Cwo5Udp0w=.1456e13f-773b-41ae-821c-15f233e9e415@github.com> > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits: - Fix whitespace. - Merge branch 'master' into JDK-8202056 - Add resource for checking return type. - Merge branch 'master' into JDK-8202056 - More precse compiler.properties message; start refactoring of checking method return type. - Improve comments for suppressed serial warnings. - Merge branch 'master' into JDK-8202056 - Appease jcheck. - Merge branch 'master' into JDK-8202056 - Remove checkTypeOfField; improve checking for serialPersistentFields. - ... and 42 more: https://git.openjdk.java.net/jdk/compare/df7b0c70...82cae467 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=12 Stats: 1638 lines in 37 files changed: 1632 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From duke at openjdk.java.net Wed Oct 6 02:49:11 2021 From: duke at openjdk.java.net (duke) Date: Wed, 6 Oct 2021 02:49:11 GMT Subject: Withdrawn: 8272234: Pass originating elements from Filer to JavaFileManager In-Reply-To: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> Message-ID: On Tue, 10 Aug 2021 20:46:32 GMT, Jan Lahoda wrote: > This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files. > > Any feedback on this prototype would be welcome. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5076 From darcy at openjdk.java.net Wed Oct 6 03:16:09 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 6 Oct 2021 03:16:09 GMT Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v2] In-Reply-To: References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com> Message-ID: On Tue, 10 Aug 2021 20:06:56 GMT, Joe Darcy wrote: >> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type. > > 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 two additional commits since the last revision: > > - Merge branch 'master' into JDK-8224922 > - 8224922: Access JavaFileObject from Element(s) Still keep-alive. ------------- PR: https://git.openjdk.java.net/jdk/pull/5038 From darcy at openjdk.java.net Wed Oct 6 05:13:35 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 6 Oct 2021 05:13:35 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v14] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Improve argument checking. - Improve checking of method modifiers. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5709/files - new: https://git.openjdk.java.net/jdk/pull/5709/files/82cae467..01c88369 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=12-13 Stats: 198 lines in 9 files changed: 73 ins; 39 del; 86 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From jlahoda at openjdk.java.net Wed Oct 6 09:14:17 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 6 Oct 2021 09:14:17 GMT Subject: RFR: 8274347: Passing a *nested* switch expression as a parameter causes an NPE during compile Message-ID: Switch handling needs to compute if a case's statements complete normally or not (this is used on multiple places later in the pipeline). But, especially during speculative attributions, the tree may not be fully attributed. `preFlow` should be invoked before invoking flow. The patch also fixes binding pattern handling in preFlow/postAttr. ------------- Commit messages: - An additional test, and improving preflow/post-attr. - 8274347: Passing a *nested* switch expression as a parameter causes an NPE during compile Changes: https://git.openjdk.java.net/jdk/pull/5836/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5836&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274347 Stats: 88 lines in 3 files changed: 85 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5836.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5836/head:pull/5836 PR: https://git.openjdk.java.net/jdk/pull/5836 From goetz.lindenmaier at sap.com Wed Oct 6 14:19:58 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 6 Oct 2021 14:19:58 +0000 Subject: JDK-8211148 missing in jdk11u Message-ID: Hi, While working on "8245147: Refactor and improve utility of test/langtools/tools/javac/versions/Versions.java", I figured that jdk11u accepts Java 11 code even if -source 10 is set. I found "JDK-8211148 var in implicit lambdas shouldn't be accepted for source < 11" is not backported to 11. Is there a good reason for this, or is this just an oversight? Best regards, Goetz. https://bugs.openjdk.java.net/browse/JDK-8211148 https://bugs.openjdk.java.net/browse/JDK-8245147 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vromero at openjdk.java.net Wed Oct 6 15:56:09 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 6 Oct 2021 15:56:09 GMT Subject: RFR: 8274347: Passing a *nested* switch expression as a parameter causes an NPE during compile In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 09:04:59 GMT, Jan Lahoda wrote: > Switch handling needs to compute if a case's statements complete normally or not (this is used on multiple places later in the pipeline). But, especially during speculative attributions, the tree may not be fully attributed. `preFlow` should be invoked before invoking flow. The patch also fixes binding pattern handling in preFlow/postAttr. looks sensible to me src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1803: > 1801: addVars(c.stats, switchEnv.info.scope); > 1802: > 1803: preFlow(c); this makes sense, we are doing the same for lambdas ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5836 From vicente.romero at oracle.com Wed Oct 6 15:58:29 2021 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 6 Oct 2021 11:58:29 -0400 Subject: JDK-8211148 missing in jdk11u In-Reply-To: References: Message-ID: Hi, On 10/6/21 10:19 AM, Lindenmaier, Goetz wrote: > > Hi, > > While working on ?8245147: Refactor and improve utility of > test/langtools/tools/javac/versions/Versions.java > ?, > > I figured that jdk11u accepts Java 11 code even if -source 10 is set. > > I found ?JDK-8211148 > var in implicit > lambdas shouldn't be accepted > > for source < 11? is not backported to 11. > > Is there a good reason for this, or is this just an oversight? > I don't remember if it was discussed or not backporting this to 11, it could perfectly be an oversight > Best regards, > > Goetz. > > https://bugs.openjdk.java.net/browse/JDK-8211148 > > > https://bugs.openjdk.java.net/browse/JDK-8245147 > > Thanks, Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.java.net Wed Oct 6 19:11:36 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 6 Oct 2021 19:11:36 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v15] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: <-wMfqNjVZ7vUfNAN0CjgC7NQyGbNxykUER_SY6e2crs=.b43f787c-3a61-4e3d-bccb-55850d7df25a@github.com> > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: - Merge branch 'master' into JDK-8202056 - Favor names in properties; clean up whitespace usage in tests. - Improve argument checking. - Improve checking of method modifiers. - Fix whitespace. - Merge branch 'master' into JDK-8202056 - Add resource for checking return type. - Merge branch 'master' into JDK-8202056 - More precse compiler.properties message; start refactoring of checking method return type. - Improve comments for suppressed serial warnings. - ... and 46 more: https://git.openjdk.java.net/jdk/compare/9945f7a0...91bd896f ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=14 Stats: 1673 lines in 37 files changed: 1644 ins; 2 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From cushon at openjdk.java.net Wed Oct 6 21:08:36 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Wed, 6 Oct 2021 21:08:36 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations. Message-ID: This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. ------------- Commit messages: - JDK-8273914: Indy string concat changes order of operations. Changes: https://git.openjdk.java.net/jdk/pull/5844/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5844&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273914 Stats: 383 lines in 7 files changed: 345 ins; 0 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/5844.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5844/head:pull/5844 PR: https://git.openjdk.java.net/jdk/pull/5844 From darcy at openjdk.java.net Wed Oct 6 21:42:05 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 6 Oct 2021 21:42:05 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations. In-Reply-To: References: Message-ID: <2ViCPHHF4n1X3eNUEfmTMZcoH5yXLeFaRaV9qOerILs=.25916af1-bc70-41ac-97b2-7a9768ed22bd@github.com> On Wed, 6 Oct 2021 21:00:04 GMT, Liam Miller-Cushon wrote: > This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. Please file a CSR for this issues to discuss the behavioral changes, even if to fix a bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From forax at openjdk.java.net Wed Oct 6 21:42:06 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 6 Oct 2021 21:42:06 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations. In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 21:00:04 GMT, Liam Miller-Cushon wrote: > This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java line 313: > 311: * possible side-effects. > 312: */ > 313: protected boolean shouldConvertToStringEagerly(Type argType) { For me the implementation should be neither a primitive type nor a final class of java.lang. I think that at least the wrappers should not be converted eagerly ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From cushon at openjdk.java.net Wed Oct 6 22:24:05 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Wed, 6 Oct 2021 22:24:05 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 21:36:30 GMT, R?mi Forax wrote: >> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. > > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java line 313: > >> 311: * possible side-effects. >> 312: */ >> 313: protected boolean shouldConvertToStringEagerly(Type argType) { > > For me the implementation should be neither a primitive type nor a final class of java.lang. I think that at least the wrappers should not be converted eagerly @forax can you expand on the suggestion here? The current implementation is not eagerly converting boxes for primitives types, which wrappers should not be converted eagerly? Also note that one of the motivating examples was `StringBuilder`, which is a `final` class in `java.lang`. It's not just about `toString()` not having side-effects, it's also about insulting the operands from each others's side effects (e.g. `myStringBuilder.append("foo") + myStringBuilder.append("bar")`) ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From cushon at openjdk.java.net Wed Oct 6 22:34:10 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Wed, 6 Oct 2021 22:34:10 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations In-Reply-To: <2ViCPHHF4n1X3eNUEfmTMZcoH5yXLeFaRaV9qOerILs=.25916af1-bc70-41ac-97b2-7a9768ed22bd@github.com> References: <2ViCPHHF4n1X3eNUEfmTMZcoH5yXLeFaRaV9qOerILs=.25916af1-bc70-41ac-97b2-7a9768ed22bd@github.com> Message-ID: On Wed, 6 Oct 2021 21:38:41 GMT, Joe Darcy wrote: >> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. > > Please file a CSR for this issues to discuss the behavioral changes, even if to fix a bug. @jddarcy thanks, I have opened a CSR: https://bugs.openjdk.java.net/browse/JDK-8274863 ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From dholmes at openjdk.java.net Thu Oct 7 01:23:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 7 Oct 2021 01:23:04 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations In-Reply-To: References: Message-ID: <7vi4k4GvtmpYBBrLcJkUnFbqrmhQZc9UjJ0GrXdA94I=.acbaa16b-e27b-41a0-a7d1-efb6d2bec5ea@github.com> On Wed, 6 Oct 2021 21:00:04 GMT, Liam Miller-Cushon wrote: > This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. Can you explain the changes made in relation to the runtime test: test/hotspot/jtreg/runtime/modules/AccessCheck/MethodAccessReadTwice.java please. The connection to this fix is not at all apparent, nor what the conversion to jasm is achieving. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From forax at openjdk.java.net Thu Oct 7 05:45:08 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 7 Oct 2021 05:45:08 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 22:20:11 GMT, Liam Miller-Cushon wrote: > The current implementation is not eagerly converting boxes for primitives types, which wrappers should not be converted eagerly? I was just thinking that not calling Boolean or Double.toString() explicitly was Ok > `myStringBuilder.append("foo") + myStringBuilder.append("bar")` Aaaah, so only primitives + their boxes should not be evaluated eagerly. ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From darcy at openjdk.java.net Thu Oct 7 05:59:27 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 7 Oct 2021 05:59:27 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v16] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: - Adding warning for serial fields in interfaces; cleanup. - Merge branch 'master' into JDK-8202056 - Add thrown type checks. - Improve no-args checking. - Merge branch 'master' into JDK-8202056 - Favor names in properties; clean up whitespace usage in tests. - Improve argument checking. - Improve checking of method modifiers. - Fix whitespace. - Merge branch 'master' into JDK-8202056 - ... and 50 more: https://git.openjdk.java.net/jdk/compare/c833b4d1...9ef6aeb7 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=15 Stats: 1881 lines in 41 files changed: 1843 ins; 2 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From github.com+741251+turbanoff at openjdk.java.net Thu Oct 7 08:17:23 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 7 Oct 2021 08:17:23 GMT Subject: RFR: 8274881: Update jdk.compiler classes to use try-with-resources Message-ID: 8274881: Update jdk.compiler classes to use try-with-resources ------------- Commit messages: - [PATCH] Update jdk.compiler classes to use try-with-resources - [PATCH] Update jdk.compiler classes to use try-with-resources - [PATCH] Use try-with-resources to close FileInputStream in jdk.compiler Changes: https://git.openjdk.java.net/jdk/pull/5816/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5816&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274881 Stats: 34 lines in 4 files changed: 0 ins; 23 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5816.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5816/head:pull/5816 PR: https://git.openjdk.java.net/jdk/pull/5816 From shade at openjdk.java.net Thu Oct 7 10:05:08 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 7 Oct 2021 10:05:08 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations In-Reply-To: References: Message-ID: <68BDuBBYz6-r3y7E9T9gtb8GEzEni0_Ha8ZqHeVyIWs=.02d8b773-10df-47de-8f04-4c4112ace03d@github.com> On Wed, 6 Oct 2021 21:00:04 GMT, Liam Miller-Cushon wrote: > This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. Thank you for fixing this. It looks nominally fine, but I would defer to javac experts to approve this. Minor testing suggestions below. ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From vromero at openjdk.java.net Thu Oct 7 16:12:15 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 7 Oct 2021 16:12:15 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v16] In-Reply-To: References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: On Thu, 7 Oct 2021 05:59:27 GMT, Joe Darcy wrote: >> This is an initial PR for expanded lint warnings done under two bugs: >> >> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields >> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type >> >> to get feedback on the general approach and test strategy before further polishing the implementation. >> >> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. >> >> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. >> >> Please also review the corresponding CSRs: >> >> https://bugs.openjdk.java.net/browse/JDK-8274335 >> https://bugs.openjdk.java.net/browse/JDK-8274336 >> >> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. >> >> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. >> >> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: > > - Adding warning for serial fields in interfaces; cleanup. > - Merge branch 'master' into JDK-8202056 > - Add thrown type checks. > - Improve no-args checking. > - Merge branch 'master' into JDK-8202056 > - Favor names in properties; clean up whitespace usage in tests. > - Improve argument checking. > - Improve checking of method modifiers. > - Fix whitespace. > - Merge branch 'master' into JDK-8202056 > - ... and 50 more: https://git.openjdk.java.net/jdk/compare/c833b4d1...9ef6aeb7 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5564: > 5562: * Check structure of serialization declarations. > 5563: */ > 5564: private void checkSerialStructure(JCClassDecl tree, ClassSymbol c, Env env) { I think that most of the new code, checking related code, should live in com.sun.tools.javac.Check rather than here in Attr ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Thu Oct 7 18:01:28 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 7 Oct 2021 18:01:28 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v17] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits: - Merge branch 'master' into JDK-8202056 - Appease jcheck. - Update test. - Adding warning for serial fields in interfaces; cleanup. - Merge branch 'master' into JDK-8202056 - Add thrown type checks. - Improve no-args checking. - Merge branch 'master' into JDK-8202056 - Favor names in properties; clean up whitespace usage in tests. - Improve argument checking. - ... and 53 more: https://git.openjdk.java.net/jdk/compare/920e7070...2d72377e ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=16 Stats: 1883 lines in 42 files changed: 1844 ins; 2 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From cushon at openjdk.java.net Thu Oct 7 19:47:40 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Thu, 7 Oct 2021 19:47:40 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v2] In-Reply-To: References: Message-ID: <-Jnn2x65IcAPhkGOCxmmrmathQVOJ81DVNH2eyNnuyg=.690b0387-68b6-4dc7-84db-cb686db95ed1@github.com> > This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision: - Also test evaluation order for 'inline' - Remove sharpestAccessible logic, since types are now passed as strings ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5844/files - new: https://git.openjdk.java.net/jdk/pull/5844/files/dd3abbe5..fabecf52 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5844&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5844&range=00-01 Stats: 28 lines in 2 files changed: 4 ins; 21 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5844.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5844/head:pull/5844 PR: https://git.openjdk.java.net/jdk/pull/5844 From shade at openjdk.java.net Thu Oct 7 19:47:44 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 7 Oct 2021 19:47:44 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v2] In-Reply-To: <-Jnn2x65IcAPhkGOCxmmrmathQVOJ81DVNH2eyNnuyg=.690b0387-68b6-4dc7-84db-cb686db95ed1@github.com> References: <-Jnn2x65IcAPhkGOCxmmrmathQVOJ81DVNH2eyNnuyg=.690b0387-68b6-4dc7-84db-cb686db95ed1@github.com> Message-ID: On Thu, 7 Oct 2021 19:44:10 GMT, Liam Miller-Cushon wrote: >> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. > > Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision: > > - Also test evaluation order for 'inline' > - Remove sharpestAccessible logic, since types are now passed as strings test/langtools/tools/javac/StringConcat/StringAppendEvaluatesInOrder.java line 28: > 26: * @bug 8273914 > 27: * @summary Indy string concat changes order of operations > 28: * Here and later: please add the test block with `-XDstringConcat=inline` here as well, so that test would verify that every javac strategy produces the same result? ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From cushon at openjdk.java.net Thu Oct 7 19:47:50 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Thu, 7 Oct 2021 19:47:50 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v2] In-Reply-To: References: <-Jnn2x65IcAPhkGOCxmmrmathQVOJ81DVNH2eyNnuyg=.690b0387-68b6-4dc7-84db-cb686db95ed1@github.com> Message-ID: On Thu, 7 Oct 2021 19:42:38 GMT, Liam Miller-Cushon wrote: >> test/langtools/tools/javac/StringConcat/StringAppendEvaluatesInOrder.java line 28: >> >>> 26: * @bug 8273914 >>> 27: * @summary Indy string concat changes order of operations >>> 28: * >> >> Here and later: please add the test block with `-XDstringConcat=inline` here as well, so that test would verify that every javac strategy produces the same result? > > Done, thanks (The `WellKnownTypes` test still only exercises the indy strategies, because it's testing logic that only exists in those strategies.) ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From cushon at openjdk.java.net Thu Oct 7 19:47:48 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Thu, 7 Oct 2021 19:47:48 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v2] In-Reply-To: References: <-Jnn2x65IcAPhkGOCxmmrmathQVOJ81DVNH2eyNnuyg=.690b0387-68b6-4dc7-84db-cb686db95ed1@github.com> Message-ID: On Thu, 7 Oct 2021 10:00:36 GMT, Aleksey Shipilev wrote: >> Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision: >> >> - Also test evaluation order for 'inline' >> - Remove sharpestAccessible logic, since types are now passed as strings > > test/langtools/tools/javac/StringConcat/StringAppendEvaluatesInOrder.java line 28: > >> 26: * @bug 8273914 >> 27: * @summary Indy string concat changes order of operations >> 28: * > > Here and later: please add the test block with `-XDstringConcat=inline` here as well, so that test would verify that every javac strategy produces the same result? Done, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From cushon at openjdk.java.net Thu Oct 7 20:02:08 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Thu, 7 Oct 2021 20:02:08 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v2] In-Reply-To: <7vi4k4GvtmpYBBrLcJkUnFbqrmhQZc9UjJ0GrXdA94I=.acbaa16b-e27b-41a0-a7d1-efb6d2bec5ea@github.com> References: <7vi4k4GvtmpYBBrLcJkUnFbqrmhQZc9UjJ0GrXdA94I=.acbaa16b-e27b-41a0-a7d1-efb6d2bec5ea@github.com> Message-ID: On Thu, 7 Oct 2021 01:20:04 GMT, David Holmes wrote: >> Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision: >> >> - Also test evaluation order for 'inline' >> - Remove sharpestAccessible logic, since types are now passed as strings > > Can you explain the changes made in relation to the runtime test: > > test/hotspot/jtreg/runtime/modules/AccessCheck/MethodAccessReadTwice.java > > please. The connection to this fix is not at all apparent, nor what the conversion to jasm is achieving. > > Thanks, > David @dholmes-ora > Can you explain the changes made in relation to the runtime test: > > test/hotspot/jtreg/runtime/modules/AccessCheck/MethodAccessReadTwice.java > > please. The connection to this fix is not at all apparent, nor what the conversion to jasm is achieving. Thanks, good question: That test is for [JDK-8174954](https://bugs.openjdk.java.net/browse/JDK-8174954), which checks for an expected `IllegalAccessError` when the parameter type of an invokedynamic is inaccessible. It's assuming that given `"" + param`, javac generates an invokedynamic that uses the specific type of `param`. This change make javac eagerly convert `param` to a `String` before passing it to the `invokedynamic` call, which avoids the accessibility issue the test is trying to exercise. Using `jasm` preserves the existing bytecode (including the signature of the `invokedynamic`) that the test is expecting. ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From darcy at openjdk.java.net Thu Oct 7 23:06:32 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 7 Oct 2021 23:06:32 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v18] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add support for checking for serialPersistentFields initialized to a literal null. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5709/files - new: https://git.openjdk.java.net/jdk/pull/5709/files/2d72377e..2e296380 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=16-17 Stats: 42 lines in 5 files changed: 36 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From david.holmes at oracle.com Fri Oct 8 01:01:13 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Oct 2021 11:01:13 +1000 Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v2] In-Reply-To: References: <7vi4k4GvtmpYBBrLcJkUnFbqrmhQZc9UjJ0GrXdA94I=.acbaa16b-e27b-41a0-a7d1-efb6d2bec5ea@github.com> Message-ID: <53b98756-d5f2-8e57-7600-e67ef6ea57ab@oracle.com> On 8/10/2021 6:02 am, Liam Miller-Cushon wrote: > On Thu, 7 Oct 2021 01:20:04 GMT, David Holmes wrote: > >>> Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision: >>> >>> - Also test evaluation order for 'inline' >>> - Remove sharpestAccessible logic, since types are now passed as strings >> >> Can you explain the changes made in relation to the runtime test: >> >> test/hotspot/jtreg/runtime/modules/AccessCheck/MethodAccessReadTwice.java >> >> please. The connection to this fix is not at all apparent, nor what the conversion to jasm is achieving. >> >> Thanks, >> David > > @dholmes-ora > >> Can you explain the changes made in relation to the runtime test: >> >> test/hotspot/jtreg/runtime/modules/AccessCheck/MethodAccessReadTwice.java >> >> please. The connection to this fix is not at all apparent, nor what the conversion to jasm is achieving. > > Thanks, good question: > > That test is for [JDK-8174954](https://bugs.openjdk.java.net/browse/JDK-8174954), which checks for an expected `IllegalAccessError` when the parameter type of an invokedynamic is inaccessible. It's assuming that given `"" + param`, javac generates an invokedynamic that uses the specific type of `param`. This change make javac eagerly convert `param` to a `String` before passing it to the `invokedynamic` call, which avoids the accessibility issue the test is trying to exercise. > > Using `jasm` preserves the existing bytecode (including the signature of the `invokedynamic`) that the test is expecting. Okay, can you please add a comment to the jasm file that explains that. It is useful to know what Java code a jasm file represents and where/why it differs from how that Java code would compile. Thanks, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5844 > From vromero at openjdk.java.net Fri Oct 8 03:04:15 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 8 Oct 2021 03:04:15 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v18] In-Reply-To: <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> Message-ID: On Thu, 7 Oct 2021 23:06:32 GMT, Joe Darcy wrote: >> This is an initial PR for expanded lint warnings done under two bugs: >> >> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields >> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type >> >> to get feedback on the general approach and test strategy before further polishing the implementation. >> >> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. >> >> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. >> >> Please also review the corresponding CSRs: >> >> https://bugs.openjdk.java.net/browse/JDK-8274335 >> https://bugs.openjdk.java.net/browse/JDK-8274336 >> >> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. >> >> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. >> >> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add support for checking for serialPersistentFields initialized to a literal null. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5564: > 5562: * Check structure of serialization declarations. > 5563: */ > 5564: private void checkSerialStructure(JCClassDecl tree, ClassSymbol c, Env env) { the arg `env` is not used in method `checkSerialStructure`, could be dropped ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From vromero at openjdk.java.net Fri Oct 8 03:13:07 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 8 Oct 2021 03:13:07 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v18] In-Reply-To: <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> Message-ID: On Thu, 7 Oct 2021 23:06:32 GMT, Joe Darcy wrote: >> This is an initial PR for expanded lint warnings done under two bugs: >> >> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields >> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type >> >> to get feedback on the general approach and test strategy before further polishing the implementation. >> >> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. >> >> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. >> >> Please also review the corresponding CSRs: >> >> https://bugs.openjdk.java.net/browse/JDK-8274335 >> https://bugs.openjdk.java.net/browse/JDK-8274336 >> >> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. >> >> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. >> >> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add support for checking for serialPersistentFields initialized to a literal null. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5595: > 5593: * public void readExternal(ObjectInput) throws IOException > 5594: */ > 5595: private class SerialTypeVisitor extends ElementKindVisitor14 { right as you mentioned in the description this visitor should use a closer to idiomatic javac super type. I guess that you can extend com.sun.tools.javac.tree.TreeScanner ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From vromero at openjdk.java.net Fri Oct 8 03:17:07 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 8 Oct 2021 03:17:07 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v18] In-Reply-To: <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> Message-ID: On Thu, 7 Oct 2021 23:06:32 GMT, Joe Darcy wrote: >> This is an initial PR for expanded lint warnings done under two bugs: >> >> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields >> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type >> >> to get feedback on the general approach and test strategy before further polishing the implementation. >> >> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. >> >> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. >> >> Please also review the corresponding CSRs: >> >> https://bugs.openjdk.java.net/browse/JDK-8274335 >> https://bugs.openjdk.java.net/browse/JDK-8274336 >> >> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. >> >> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. >> >> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add support for checking for serialPersistentFields initialized to a literal null. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5629: > 5627: // for enums or records. > 5628: VarSymbol svuidSym = null; > 5629: for (Symbol sym : c.members().getSymbolsByName(names.serialVersionUID)) { also if you extend TreeScanner I think that this code will be split into smaller (field oriented, method oriented) methods ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From vromero at openjdk.java.net Fri Oct 8 03:25:11 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 8 Oct 2021 03:25:11 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v18] In-Reply-To: <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> Message-ID: On Thu, 7 Oct 2021 23:06:32 GMT, Joe Darcy wrote: >> This is an initial PR for expanded lint warnings done under two bugs: >> >> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields >> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type >> >> to get feedback on the general approach and test strategy before further polishing the implementation. >> >> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. >> >> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. >> >> Please also review the corresponding CSRs: >> >> https://bugs.openjdk.java.net/browse/JDK-8274335 >> https://bugs.openjdk.java.net/browse/JDK-8274336 >> >> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. >> >> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. >> >> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add support for checking for serialPersistentFields initialized to a literal null. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5565: > 5563: */ > 5564: private void checkSerialStructure(JCClassDecl tree, ClassSymbol c, Env env) { > 5565: (new SerialTypeVisitor()).visit(c, tree); do we want to show the additional warnings regardless of the source we are compiling? I mean also for source < 18? if not then we will need to add a new feature to com.sun.tools.javac.code.Source, then check that the feature is allowed etc ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From vromero at openjdk.java.net Fri Oct 8 03:35:10 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 8 Oct 2021 03:35:10 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v18] In-Reply-To: <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> Message-ID: On Thu, 7 Oct 2021 23:06:32 GMT, Joe Darcy wrote: >> This is an initial PR for expanded lint warnings done under two bugs: >> >> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields >> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type >> >> to get feedback on the general approach and test strategy before further polishing the implementation. >> >> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. >> >> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. >> >> Please also review the corresponding CSRs: >> >> https://bugs.openjdk.java.net/browse/JDK-8274335 >> https://bugs.openjdk.java.net/browse/JDK-8274336 >> >> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. >> >> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. >> >> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add support for checking for serialPersistentFields initialized to a literal null. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5769: > 5767: ClassSymbol supertype = ((ClassSymbol)(((DeclaredType)superClass).asElement())); > 5768: for (var ctor: > 5769: ElementFilter.constructorsIn(supertype.getEnclosedElements()) ) { yes as you mentioned this code needs a closer to javac conversion src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5819: > 5817: } > 5818: > 5819: if (!types.isSameType(spf.type, OSF_TYPE)) { I think that here you can just compare the type's tsym field like if (type1.tsym == type2.tsym) // same type src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5831: > 5829: // Warn if serialPersistentFields is initialized to a > 5830: // literal null. > 5831: JCTree spfDecl = TreeInfo.declarationFor(spf, tree); this code should be simpler once the visitor inherits from TreeScanner ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Fri Oct 8 04:31:08 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 8 Oct 2021 04:31:08 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v18] In-Reply-To: References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> Message-ID: On Fri, 8 Oct 2021 03:20:45 GMT, Vicente Romero wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Add support for checking for serialPersistentFields initialized to a literal null. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5565: > >> 5563: */ >> 5564: private void checkSerialStructure(JCClassDecl tree, ClassSymbol c, Env env) { >> 5565: (new SerialTypeVisitor()).visit(c, tree); > > do we want to show the additional warnings regardless of the source we are compiling? I mean also for source < 18? if not then we will need to add a new feature to com.sun.tools.javac.code.Source, then check that the feature is allowed etc Other than new constraints/conditions for new constructs like records, the semantics checks are serialization haven't changed very much since JDK 1.2-1.3. So I don't think it is necessary to gate the serial checks on the source level since the warnings are equally valid on earlier source levels too. ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From vromero at openjdk.java.net Fri Oct 8 14:07:08 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 8 Oct 2021 14:07:08 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v18] In-Reply-To: References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> Message-ID: <28bZEJokhOxzBPUbwhxRcJ-lxUmiZH8uZpc-HLDohVA=.c5f43d63-bb29-49c1-8e28-42be39cb30df@github.com> On Fri, 8 Oct 2021 04:27:58 GMT, Joe Darcy wrote: > Other than new constraints/conditions for new constructs like records, the semantics checks are serialization haven't changed very much since JDK 1.2-1.3. So I don't think it is necessary to gate the serial checks on the source level since the warnings are equally valid on earlier source levels too. Oh I see, thanks for the clarification ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From cushon at openjdk.java.net Fri Oct 8 18:22:42 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Fri, 8 Oct 2021 18:22:42 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v3] In-Reply-To: References: Message-ID: > This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Document the rationale for the jasm changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5844/files - new: https://git.openjdk.java.net/jdk/pull/5844/files/fabecf52..bd4cb71e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5844&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5844&range=01-02 Stats: 32 lines in 2 files changed: 32 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5844.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5844/head:pull/5844 PR: https://git.openjdk.java.net/jdk/pull/5844 From cushon at openjdk.java.net Fri Oct 8 18:22:42 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Fri, 8 Oct 2021 18:22:42 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations In-Reply-To: <53b98756-d5f2-8e57-7600-e67ef6ea57ab@oracle.com> References: <53b98756-d5f2-8e57-7600-e67ef6ea57ab@oracle.com> Message-ID: On Fri, 8 Oct 2021 01:02:39 GMT, David Holmes wrote: > Okay, can you please add a comment to the jasm file that explains that. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From jjg at openjdk.java.net Fri Oct 8 18:43:26 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 8 Oct 2021 18:43:26 GMT Subject: RFR: JDK-8189591: No way to locally suppress doclint warnings Message-ID: Please review a moderately simple change, to have DocLint check for relevant `@SuppressWarnings` annotations before reporting any messages. ------------- Commit messages: - JDK-8189591: No way to locally suppress doclint warnings Changes: https://git.openjdk.java.net/jdk/pull/5870/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5870&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8189591 Stats: 256 lines in 4 files changed: 246 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5870.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5870/head:pull/5870 PR: https://git.openjdk.java.net/jdk/pull/5870 From darcy at openjdk.java.net Fri Oct 8 23:02:35 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 8 Oct 2021 23:02:35 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v19] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update javac.properties for command-line usage output. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5709/files - new: https://git.openjdk.java.net/jdk/pull/5709/files/2e296380..f18fa943 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=17-18 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From cushon at openjdk.java.net Sat Oct 9 03:46:11 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Sat, 9 Oct 2021 03:46:11 GMT Subject: RFR: 8271623: Omit enclosing instance fields from inner classes that don't use it [v2] In-Reply-To: References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com> Message-ID: On Tue, 3 Aug 2021 18:48:00 GMT, Liam Miller-Cushon wrote: >> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Add a test case with nested inner classes There was some more discussion in https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-October/003141.html ------------- PR: https://git.openjdk.java.net/jdk/pull/4966 From jlahoda at openjdk.java.net Mon Oct 11 12:41:13 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 11 Oct 2021 12:41:13 GMT Subject: Integrated: 8274347: Passing a *nested* switch expression as a parameter causes an NPE during compile In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 09:04:59 GMT, Jan Lahoda wrote: > Switch handling needs to compute if a case's statements complete normally or not (this is used on multiple places later in the pipeline). But, especially during speculative attributions, the tree may not be fully attributed. `preFlow` should be invoked before invoking flow. The patch also fixes binding pattern handling in preFlow/postAttr. This pull request has now been integrated. Changeset: b870468b Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/b870468bdc99938fbb19a41b0ede0a3e3769ace2 Stats: 88 lines in 3 files changed: 85 ins; 0 del; 3 mod 8274347: Passing a *nested* switch expression as a parameter causes an NPE during compile Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/5836 From jlahoda at openjdk.java.net Mon Oct 11 14:40:29 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 11 Oct 2021 14:40:29 GMT Subject: RFR: 8274817: Allow JavacFiler subclasses and register them in Context Message-ID: An alternative to https://github.com/openjdk/jdk/pull/5076 - this allows to subclass `JavacFiler` and install it to the `Context`. The subclass then can handle the originating elements as needed. ------------- Commit messages: - Removing trailing whitespace - Updating test. - Merge branch 'master' into javacfiler-is-a-service - Making JavacFiler a Context service Changes: https://git.openjdk.java.net/jdk/pull/5840/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5840&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274817 Stats: 297 lines in 3 files changed: 295 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5840.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5840/head:pull/5840 PR: https://git.openjdk.java.net/jdk/pull/5840 From cushon at openjdk.java.net Mon Oct 11 20:11:30 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Mon, 11 Oct 2021 20:11:30 GMT Subject: RFR: 8271623: Omit enclosing instance fields from inner classes that don't use it [v3] In-Reply-To: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com> References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com> Message-ID: > This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state. Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Enable enclosing instance optimization for --release 18 and newer - Add a test case with nested inner classes - 8271623: Omit enclosing instance fields from inner classes that don't use it ------------- Changes: https://git.openjdk.java.net/jdk/pull/4966/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4966&range=02 Stats: 396 lines in 16 files changed: 357 ins; 12 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/4966.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4966/head:pull/4966 PR: https://git.openjdk.java.net/jdk/pull/4966 From darcy at openjdk.java.net Mon Oct 11 22:57:11 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 11 Oct 2021 22:57:11 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v20] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: - Merge branch 'master' into JDK-8202056 - Update javac.properties for command-line usage output. - Add support for checking for serialPersistentFields initialized to a literal null. - Merge branch 'master' into JDK-8202056 - Appease jcheck. - Update test. - Adding warning for serial fields in interfaces; cleanup. - Merge branch 'master' into JDK-8202056 - Add thrown type checks. - Improve no-args checking. - ... and 56 more: https://git.openjdk.java.net/jdk/compare/a05873a2...a4c62309 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=19 Stats: 1923 lines in 43 files changed: 1882 ins; 4 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Tue Oct 12 00:15:06 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 12 Oct 2021 00:15:06 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v21] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits: - Merge branch 'master' into JDK-8202056 - Complete removal of use of javax.lang.model.Modifer. - Incorporate Jan's refactoring. - Merge branch 'master' into JDK-8202056 - Update javac.properties for command-line usage output. - Add support for checking for serialPersistentFields initialized to a literal null. - Merge branch 'master' into JDK-8202056 - Appease jcheck. - Update test. - Adding warning for serial fields in interfaces; cleanup. - ... and 59 more: https://git.openjdk.java.net/jdk/compare/829dea45...3a7a0f22 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=20 Stats: 1976 lines in 45 files changed: 1909 ins; 54 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Tue Oct 12 00:15:08 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 12 Oct 2021 00:15:08 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v16] In-Reply-To: References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: On Thu, 7 Oct 2021 16:07:41 GMT, Vicente Romero wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: >> >> - Adding warning for serial fields in interfaces; cleanup. >> - Merge branch 'master' into JDK-8202056 >> - Add thrown type checks. >> - Improve no-args checking. >> - Merge branch 'master' into JDK-8202056 >> - Favor names in properties; clean up whitespace usage in tests. >> - Improve argument checking. >> - Improve checking of method modifiers. >> - Fix whitespace. >> - Merge branch 'master' into JDK-8202056 >> - ... and 50 more: https://git.openjdk.java.net/jdk/compare/c833b4d1...9ef6aeb7 > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5564: > >> 5562: * Check structure of serialization declarations. >> 5563: */ >> 5564: private void checkSerialStructure(JCClassDecl tree, ClassSymbol c, Env env) { > > I think that most of the new code, checking related code, should live in com.sun.tools.javac.Check rather than here in Attr Pushed an update from Jan which moved most the new logic to Check along with some additional refactoring to fully replace use of javax.lang.model modifiers with javac flags. Thanks to Jan for the refactoring! ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From joe.darcy at oracle.com Tue Oct 12 01:16:55 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 11 Oct 2021 18:16:55 -0700 Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v18] In-Reply-To: References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> <-q434LgXjkSoOlowYOSzilwIxeJZCVTjQ8BvcdhEXUQ=.8b7fc75b-8ba3-46f5-beeb-3b1693ef8ebd@github.com> Message-ID: <02a347b0-76e4-de12-ca4d-bce3da78e5fc@oracle.com> On 10/7/2021 8:04 PM, Vicente Romero wrote: > On Thu, 7 Oct 2021 23:06:32 GMT, Joe Darcy wrote: > >>> This is an initial PR for expanded lint warnings done under two bugs: >>> >>> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields >>> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type >>> >>> to get feedback on the general approach and test strategy before further polishing the implementation. >>> >>> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. >>> >>> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. >>> >>> Please also review the corresponding CSRs: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8274335 >>> https://bugs.openjdk.java.net/browse/JDK-8274336 >>> >>> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. >>> >>> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. >>> >>> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Add support for checking for serialPersistentFields initialized to a literal null. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5564: > >> 5562: * Check structure of serialization declarations. >> 5563: */ >> 5564: private void checkSerialStructure(JCClassDecl tree, ClassSymbol c, Env env) { > the arg `env` is not used in method `checkSerialStructure`, could be dropped > The 'env' parameter removed in most recent version; thanks, -Joe From darcy at openjdk.java.net Tue Oct 12 01:22:14 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 12 Oct 2021 01:22:14 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v22] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: <9sygvbPs3Qu4SdF6sISfjyEeniCLDwtkOFbVDqRnQVM=.669827ad-f800-4313-81c4-4406d8ec07c4@github.com> > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback; add missing newline. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5709/files - new: https://git.openjdk.java.net/jdk/pull/5709/files/3a7a0f22..9b6c898e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=20-21 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Tue Oct 12 02:55:48 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 12 Oct 2021 02:55:48 GMT Subject: RFR: 8274881: Update jdk.compiler classes to use try-with-resources In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 07:52:40 GMT, Andrey Turbanov wrote: > 8274881: Update jdk.compiler classes to use try-with-resources src/jdk.compiler/share/classes/com/sun/tools/javac/processing/ServiceProxy.java line 127: > 125: } catch (IOException y) { > 126: fail(service, ": " + y); > 127: } I haven't traced through this in detail, but it seems different exception behavior could occur. src/jdk.compiler/share/classes/com/sun/tools/javac/util/ByteBuffer.java line 172: > 170: * should be reported. > 171: */ > 172: } The exception behavior seems like it could differ, which may or may not be an issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/5816 From shade at openjdk.java.net Tue Oct 12 06:22:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Oct 2021 06:22:47 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v3] In-Reply-To: References: Message-ID: <92e0Dqmd02DMAQT1lUupi6Um5BciB-iJ0j_cM3FYs_8=.c1de8cc4-b8b9-4b29-9ad1-053a70282e47@github.com> On Fri, 8 Oct 2021 18:22:42 GMT, Liam Miller-Cushon wrote: >> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Document the rationale for the jasm changes @lahodaj, want to review the compiler change? ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From shade at openjdk.java.net Tue Oct 12 06:22:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Oct 2021 06:22:47 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v3] In-Reply-To: References: <-Jnn2x65IcAPhkGOCxmmrmathQVOJ81DVNH2eyNnuyg=.690b0387-68b6-4dc7-84db-cb686db95ed1@github.com> Message-ID: <7o61OyyBYR74qzNjaigOC3uiV3_diVWnHPXZHo9DlAw=.9af8afaf-4f1e-474b-b6d9-9e90669fe490@github.com> On Thu, 7 Oct 2021 19:43:40 GMT, Liam Miller-Cushon wrote: >> Done, thanks > > (The `WellKnownTypes` test still only exercises the indy strategies, because it's testing logic that only exists in those strategies.) But still, we probably want to confirm that `inline` strategy yields the same answer in `WellKnownTypes`? That's my thinking why to test `inline`: that is a baseline. ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From jlahoda at openjdk.java.net Tue Oct 12 07:26:54 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 12 Oct 2021 07:26:54 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v3] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 18:22:42 GMT, Liam Miller-Cushon wrote: >> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Document the rationale for the jasm changes How about code like: StringBuilder builder2 = new StringBuilder("foo"); Object oo = builder2; oo += "" + builder2.append("bar"); Should that be covered as well? From looking at the patch (not really trying it), it does not seem to be covered? ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From shade at openjdk.java.net Tue Oct 12 07:56:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Oct 2021 07:56:47 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 07:23:32 GMT, Jan Lahoda wrote: > ``` > StringBuilder builder2 = new StringBuilder("foo"); > Object oo = builder2; > oo += "" + builder2.append("bar"); > ``` > > Should that be covered as well? From looking at the patch (not really trying it), it does not seem to be covered? Tried it, still not correct: $ cat Concat.java public class Concat { public static void main(String... args) { StringBuilder builder2 = new StringBuilder("foo"); Object oo = builder2; oo += "" + builder2.append("bar"); System.out.println(oo); } } $ build/linux-x86_64-server-fastdebug/images/jdk/bin/javac Concat.java $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java Concat foobarfoobar I believe `if (shouldConvertToStringEagerly(argType))` branch should be handled for first argument as well, i.e. code should be shaped as: if (!first || generateFirstArg) { genExpr(arg, arg.type).load(); } if (shouldConvertToStringEagerly(argType)) { gen.callMethod(pos, syms.stringType, names.valueOf, List.of(syms.objectType), true); argType = syms.stringType; } dynamicArgs.add(argType); This produces the correct result: $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java Concat foofoobar @cushon, could you do this change and add a relevant test case? ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From jlahoda at openjdk.java.net Tue Oct 12 08:06:07 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 12 Oct 2021 08:06:07 GMT Subject: RFR: 8275097: Wrong span of the 'default' tag Message-ID: The span of the 'default' case label AST node is wrong when `default:` is encountered. This patch fixes the positions to be reasonable (i.e. the span of the AST node should be the characters 'default'). ------------- Commit messages: - 8275097: Wrong span of the 'default' tag Changes: https://git.openjdk.java.net/jdk/pull/5905/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5905&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275097 Stats: 96 lines in 3 files changed: 89 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5905.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5905/head:pull/5905 PR: https://git.openjdk.java.net/jdk/pull/5905 From duke at openjdk.java.net Tue Oct 12 08:11:50 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 12 Oct 2021 08:11:50 GMT Subject: RFR: 8274881: Update jdk.compiler classes to use try-with-resources In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 02:49:43 GMT, Joe Darcy wrote: >> 8274881: Update jdk.compiler classes to use try-with-resources > > src/jdk.compiler/share/classes/com/sun/tools/javac/processing/ServiceProxy.java line 127: > >> 125: } catch (IOException y) { >> 126: fail(service, ": " + y); >> 127: } > > I haven't traced through this in detail, but it seems different exception behavior could occur. `fail` method just throws `ServiceConfigurationError`. So, any IOException is still generates the same exception. No behavior change here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5816 From duke at openjdk.java.net Tue Oct 12 08:14:57 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 12 Oct 2021 08:14:57 GMT Subject: RFR: 8274881: Update jdk.compiler classes to use try-with-resources In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 02:52:43 GMT, Joe Darcy wrote: >> 8274881: Update jdk.compiler classes to use try-with-resources > > src/jdk.compiler/share/classes/com/sun/tools/javac/util/ByteBuffer.java line 172: > >> 170: * should be reported. >> 171: */ >> 172: } > > The exception behavior seems like it could differ, which may or may not be an issue. Yes. Behavior is changed for the case, when we read InputStream up the end _without_ any exception and then get Exception during _close_ call. But I think it still worth changing: 1. Code is shorter and cleaner 2. Such case is very rare, when only `InputStream.close` throw exception, but `InputStream.read` did not 3. Swallowing exceptions, even during `close()` call, is a bad code smell. ------------- PR: https://git.openjdk.java.net/jdk/pull/5816 From zjx001202 at gmail.com Tue Oct 12 08:14:45 2021 From: zjx001202 at gmail.com (Glavo) Date: Tue, 12 Oct 2021 16:14:45 +0800 Subject: Allow new language features on older version targets? Message-ID: Starting from Java 9, Java began to iterate rapidly and introduced many new features, which made Java more expressive and modern. However, upgrading Java is always difficult and painful. It needs to go through a series of cumbersome upgrade and migration processes. In these steps, the transplantation at the syntax level is often easy, because Java maintains good compatibility. However, due to subtle changes in the behavior of the JVM and the standard library, it is relatively difficult to upgrade the version of the java runtime. At the same time, for client applications, upgrading the development environment is much easier than upgrading the Java version of the deployment environment (e.g., only Java 8 is currently available on MIPS64el). For various reasons, a large number of users stay on the old java version. According to the statistical report of JetBrains, 71% of users still regularly use Java 8.0 in 2021. The most affected people are the developers of libraries. In order to make the library more widely used, most library authors always need to make their libraries use the lowest java version possible. This makes it difficult for them to enjoy the expression upgrade brought by Java update. This pain is not necessary. Although some language features of Java require the cooperation of JVM and standard library, e.g. Record, but this is not necessary for more features. At present, we can specify the source version and target version respectively, but we can't make the source version higher than the target version. I think this artificial additional restriction can be removed after careful consideration, so that more developers can enjoy the improvement of expression ability brought by Java's new language features. These features are pure language features that can be easily compiled into older versions of Java bytecode: * Milling Project Coin (JEP 213): Allow @SafeVargs on private instance methods; Allow effectively-final variables to be used as resources in the try-with-resources statement;Allow diamond with anonymous classes if the argument type of the inferred type is denotable. * Local-Variable Type Inference (JEP 286) * Local-Variable Syntax for Lambda Parameters (JEP 323) * Switch Expressions (JEP 361) * Text Blocks (JEP 378) * Pattern Matching for instanceof (JEP 394) * Pattern Matching for switch (JEP 406) * Record Patterns & Array Patterns (JEP 405) These characteristics cannot be directly desugared, but can be accepted by the old runtime: * module-info.java (JEP 261): At present, it is a popular practice to use Java 8 compilation library and add module info to it. However, this practice has not been well supported by the official. Even with a build tool like gradle, it needs to be implemented by special means. If javac can accept module info when the target version is less than 9 and compile it to Java 9, it is very helpful to simplify modular existing code. * Allow interface methods to be private (JDK-8071453): This seems to be allowed in jvmls 8, but it was not until Java 9 that it was introduced into the Java language. * Sealed Classes (JEP 409): Javac generates PermittedSubclasses_attribute for sealed classes. This attribute will be ignored on the old runtime and will not destroy the program. Even if it cannot be guaranteed by the runtime before JDK 15, it can enhance the expressiveness of the language and make the code more compatible with the higher version runtime. * Universal Generics (JDK-8261529): Universal generics seem to compile well into bytecode compatible with older Java version. I think it is particularly important to allow use of universal generic in older bytecodes. This allows the library to adapt it without compromising compatibility with older Java versions. This can erase many obstacles to Valhalla's promotion. Now we can use some hacks to do similar things, like https://github.com/bsideup/jabel But this is just hack. It is unofficial and non-standard. At the same time, it also lacks tool support. We can also choose to switch to kotlin or Scala, both of them can emit Java 8 bytecode. In fact, because of the need for compatibility, the new language features of Java can't bring us more attraction because we can't use it most of the time. Over time, kotlin and Scala, which can have more language features on Java 8, have attracted us more and more. These problems are not just in the Java 8 era. The need to be compatible with old Java versions always exists, which makes it difficult for many people to put new features of the Java language into production for a long time. This will make Java less competitive with other JVM languages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cstein at openjdk.java.net Tue Oct 12 14:22:01 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 12 Oct 2021 14:22:01 GMT Subject: RFR: 8272728: javac ignores any -J option in @argfiles silently Message-ID: Make javac error on `-J` being present in `@argfiles` or other locations, where the launcher didn't process and remove them. ------------- Commit messages: - Fix diff by forcing LF as the line-ending - Add integration test - Reporting invalid option and argument - Add throws clause and format message - [JDK-8272728] javac ignores any -J option in @argfiles silently Changes: https://git.openjdk.java.net/jdk/pull/5891/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5891&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272728 Stats: 20 lines in 2 files changed: 18 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5891/head:pull/5891 PR: https://git.openjdk.java.net/jdk/pull/5891 From jjg at openjdk.java.net Tue Oct 12 14:22:02 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 12 Oct 2021 14:22:02 GMT Subject: RFR: 8272728: javac ignores any -J option in @argfiles silently In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:20:02 GMT, Christian Stein wrote: > Make javac error on `-J` being present in `@argfiles` or other locations, where the launcher didn't process and remove them. > Remove process method that takes 2 arguments? Just checking ... what is the code path if someone uses just `-J` with no arg. src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 518: > 516: String message = "-J is not valid here (e.g. in an @argfile): pass -J" > 517: + arg > 518: + " arguments directly to the launcher"; The suggestion to pass `-J` args directly to the launcher may not apply in all cases ... it only applies when invoking tools, not when running the JVM. But generally, throwing `InvalidValueException` seems like the right way to go. ------------- PR: https://git.openjdk.java.net/jdk/pull/5891 From cstein at openjdk.java.net Tue Oct 12 14:22:03 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 12 Oct 2021 14:22:03 GMT Subject: RFR: 8272728: javac ignores any -J option in @argfiles silently In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 14:52:39 GMT, Jonathan Gibbons wrote: >> Make javac error on `-J` being present in `@argfiles` or other locations, where the launcher didn't process and remove them. > > src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 518: > >> 516: String message = "-J is not valid here (e.g. in an @argfile): pass -J" >> 517: + arg >> 518: + " arguments directly to the launcher"; > > The suggestion to pass `-J` args directly to the launcher may not apply in all cases ... it only applies when invoking tools, not when running the JVM. But generally, throwing `InvalidValueException` seems like the right way to go. Okay. Which one do you prefer? - `"-J is not valid here (e.g. in an @argfile)"` without the actual argument or - `"-J%s is not valid here (e.g. in an @argfile)".formatted(arg)` with the actual argument included? ------------- PR: https://git.openjdk.java.net/jdk/pull/5891 From jjg at openjdk.java.net Tue Oct 12 14:22:03 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 12 Oct 2021 14:22:03 GMT Subject: RFR: 8272728: javac ignores any -J option in @argfiles silently In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 14:56:29 GMT, Christian Stein wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 518: >> >>> 516: String message = "-J is not valid here (e.g. in an @argfile): pass -J" >>> 517: + arg >>> 518: + " arguments directly to the launcher"; >> >> The suggestion to pass `-J` args directly to the launcher may not apply in all cases ... it only applies when invoking tools, not when running the JVM. But generally, throwing `InvalidValueException` seems like the right way to go. > > Okay. Which one do you prefer? > > - `"-J is not valid here (e.g. in an @argfile)"` without the actual argument or > - `"-J%s is not valid here (e.g. in an @argfile)".formatted(arg)` with the actual argument included? Also, we tend not to use Latin contractions like `e.g.` and `i.e.` -- use the English equivalent, or avoid the need altogether. Note that arg-files are not the only way to tunnel `-J` options into `javac`, so that may be another reason to generalize the message and make it less specific. For example, `-J is not valid here; pass JVM options directly to the launcher.` ------------- PR: https://git.openjdk.java.net/jdk/pull/5891 From cstein at openjdk.java.net Tue Oct 12 14:22:03 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 12 Oct 2021 14:22:03 GMT Subject: RFR: 8272728: javac ignores any -J option in @argfiles silently In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 14:57:55 GMT, Jonathan Gibbons wrote: >> Okay. Which one do you prefer? >> >> - `"-J is not valid here (e.g. in an @argfile)"` without the actual argument or >> - `"-J%s is not valid here (e.g. in an @argfile)".formatted(arg)` with the actual argument included? > > Also, we tend not to use Latin contractions like `e.g.` and `i.e.` -- use the English equivalent, or avoid the need altogether. > > Note that arg-files are not the only way to tunnel `-J` options into `javac`, so that may be another reason to generalize the message and make it less specific. For example, `-J is not valid here; pass JVM options directly to the launcher.` What about `"-J%s is not valid here; pass JVM options directly to the launcher.".formatted(arg)`? ------------- PR: https://git.openjdk.java.net/jdk/pull/5891 From jjg at openjdk.java.net Tue Oct 12 14:22:04 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 12 Oct 2021 14:22:04 GMT Subject: RFR: 8272728: javac ignores any -J option in @argfiles silently In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 15:09:41 GMT, Christian Stein wrote: >> Also, we tend not to use Latin contractions like `e.g.` and `i.e.` -- use the English equivalent, or avoid the need altogether. >> >> Note that arg-files are not the only way to tunnel `-J` options into `javac`, so that may be another reason to generalize the message and make it less specific. For example, `-J is not valid here; pass JVM options directly to the launcher.` > > What about `"-J%s is not valid here; pass JVM options directly to the launcher.".formatted(arg)`? ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/5891 From forax at univ-mlv.fr Tue Oct 12 14:25:56 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 12 Oct 2021 16:25:56 +0200 (CEST) Subject: Allow new language features on older version targets? In-Reply-To: References: Message-ID: <1759836117.1029337.1634048756575.JavaMail.zimbra@u-pem.fr> Hi, Java 9 can be a hard pill to swallow, part of the issues is that all dependencies need to be updated before moving to 11, slowing down the adoption of Java 11. I think your proposal does not help. You have forgotten the fact that the bytecode is not only consumed by the VM but by a lot of languages, tools, frameworks and libraries. Gradle, ErrorProne, FindBugs, Spring, Hibernate just to cite a few may/will choke if there are known new bytecode attributes but in older classfile versions. So nestmates, records and sealed classes, all introduce new attributes thus can not be backported as is. Records and switch on types both require special bootstrap methods, which did not exist in older JDK thus it can not be backported as is. For switch expression, the structure of the generated bytecode is quite unusual, a value stay on stack before the goto at the end of each case, again, it can trouble some static analysis, so it can not be backported as is. For me, the cost of having to test and maintain all combinations of the new feature with the old bytecodes for every existing software that consume bytecodes clearly outweigh what you think could be a nice feature to have. regards, R?mi PS: i'm currently playing with Scala 3 and i really hope that a lot of people will use it, there are some really great features in Scala 3, and i'm curious how people will use them. > From: "Glavo" > To: "compiler-dev" , "jdk-dev" > > Sent: Mardi 12 Octobre 2021 10:14:45 > Subject: Allow new language features on older version targets? > Starting from Java 9, Java began to iterate rapidly and introduced > many new features, which made Java more expressive and modern. > However, upgrading Java is always difficult and painful. It needs to > go through a series of cumbersome upgrade and migration processes. > In these steps, the transplantation at the syntax level is often easy, > because Java maintains good compatibility. However, due to subtle > changes in the behavior of the JVM and the standard library, it is > relatively difficult to upgrade the version of the java runtime. > At the same time, for client applications, upgrading the development > environment is much easier than upgrading the Java version of the > deployment environment (e.g., only Java 8 is currently available on > MIPS64el). For various reasons, a large number of users stay on the > old java version. According to the statistical report of JetBrains, > 71% of users still regularly use Java 8.0 in 2021. > The most affected people are the developers of libraries. In order to > make the library more widely used, most library authors always need to > make their libraries use the lowest java version possible. This makes > it difficult for them to enjoy the expression upgrade brought by Java > update. > This pain is not necessary. Although some language features of Java > require the cooperation of JVM and standard library, e.g. Record, but > this is not necessary for more features. At present, we can specify > the source version and target version respectively, but we can't make > the source version higher than the target version. I think this > artificial additional restriction can be removed after careful > consideration, so that more developers can enjoy the improvement of > expression ability brought by Java's new language features. > These features are pure language features that can be easily compiled > into older versions of Java bytecode: > * Milling Project Coin (JEP 213): Allow @SafeVargs on private instance > methods; Allow effectively-final variables to be used as resources > in the try-with-resources statement;Allow diamond with anonymous > classes if the argument type of the inferred type is denotable. > * Local-Variable Type Inference (JEP 286) > * Local-Variable Syntax for Lambda Parameters (JEP 323) > * Switch Expressions (JEP 361) > * Text Blocks (JEP 378) > * Pattern Matching for instanceof (JEP 394) > * Pattern Matching for switch (JEP 406) > * Record Patterns & Array Patterns (JEP 405) > These characteristics cannot be directly desugared, but can be accepted > by the old runtime: > * module-info.java (JEP 261): At present, it is a popular practice to > use Java 8 compilation library and add module info to it. However, > this practice has not been well supported by the official. Even > with a build tool like gradle, it needs to be implemented by > special means. If javac can accept module info when the target > version is less than 9 and compile it to Java 9, it is very helpful > to simplify modular existing code. > * Allow interface methods to be private (JDK-8071453): This seems to > be allowed in jvmls 8, but it was not until Java 9 that it was > introduced into the Java language. > * Sealed Classes (JEP 409): Javac generates PermittedSubclasses_attribute > for sealed classes. This attribute will be ignored on the old > runtime and will not destroy the program. Even if it cannot be > guaranteed by the runtime before JDK 15, it can enhance the > expressiveness of the language and make the code more compatible > with the higher version runtime. > * Universal Generics (JDK-8261529): Universal generics seem to > compile well into bytecode compatible with older Java version. > I think it is particularly important to allow use of universal > generic in older bytecodes. This allows the library to adapt it > without compromising compatibility with older Java versions. This > can erase many obstacles to Valhalla's promotion. > Now we can use some hacks to do similar things, like > [ https://github.com/bsideup/jabel | https://github.com/bsideup/jabel ] > But this is just hack. It is unofficial and non-standard. At the same > time, it also lacks tool support. > We can also choose to switch to kotlin or Scala, both of them can emit > Java 8 bytecode. In fact, because of the need for compatibility, the > new language features of Java can't bring us more attraction because > we can't use it most of the time. Over time, kotlin and Scala, which > can have more language features on Java 8, have attracted us more and > more. These problems are not just in the Java 8 era. The need to be > compatible with old Java versions always exists, which makes it difficult > for many people to put new features of the Java language into production > for a long time. This will make Java less competitive with other JVM > languages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesw at openjdk.java.net Tue Oct 12 15:13:52 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 12 Oct 2021 15:13:52 GMT Subject: RFR: JDK-8189591: No way to locally suppress doclint warnings In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 18:32:53 GMT, Jonathan Gibbons wrote: > Please review a moderately simple change, to have DocLint check for relevant `@SuppressWarnings` annotations before reporting any messages. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java line 302: > 300: for (String a: arg.substring(len).split(",")) { > 301: Messages.Group argGroup = gMap.get(a); > 302: if (argGroup != null) { Should we let the user know about unknown doclint:* values? ------------- PR: https://git.openjdk.java.net/jdk/pull/5870 From jjg at openjdk.java.net Tue Oct 12 15:28:52 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 12 Oct 2021 15:28:52 GMT Subject: RFR: JDK-8189591: No way to locally suppress doclint warnings In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 15:11:13 GMT, Hannes Walln?fer wrote: >> Please review a moderately simple change, to have DocLint check for relevant `@SuppressWarnings` annotations before reporting any messages. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java line 302: > >> 300: for (String a: arg.substring(len).split(",")) { >> 301: Messages.Group argGroup = gMap.get(a); >> 302: if (argGroup != null) { > > Should we let the user know about unknown doclint:* values? I thought about this, but in general, the precedent in `SuppressWarnings` is to not reject unknown values, because they might be supported by other systems. `doclint:*` is "unusual" for suggesting a namespace, by virtual of the `:` which might give some justification for rejecting unknown values, but I'm still not sure I want to go there at this time. At some point, there should be more attention to `@SuppressWarnings`, including the ability to detect unused/unnecessary uses of the annotation. ------------- PR: https://git.openjdk.java.net/jdk/pull/5870 From hannesw at openjdk.java.net Tue Oct 12 15:32:50 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 12 Oct 2021 15:32:50 GMT Subject: RFR: JDK-8189591: No way to locally suppress doclint warnings In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 18:32:53 GMT, Jonathan Gibbons wrote: > Please review a moderately simple change, to have DocLint check for relevant `@SuppressWarnings` annotations before reporting any messages. Very nice! Looks good to me. test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java line 459: > 457: > 458: checkOutput(Output.OUT, false, > 459: ": warning:", I'm curious: what's the reason for this change? ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5870 From cushon at openjdk.java.net Tue Oct 12 16:26:22 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Tue, 12 Oct 2021 16:26:22 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v4] In-Reply-To: References: Message-ID: <8Qz8r0yZwfNapR762HXfi6Kjw0XiOInOznn5X2npptg=.cce475d4-4ce8-4d22-a4e9-9dc2c4a2bb8b@github.com> > This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Fix eager toString conversion for compound assignment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5844/files - new: https://git.openjdk.java.net/jdk/pull/5844/files/bd4cb71e..53dddf6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5844&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5844&range=02-03 Stats: 23 lines in 2 files changed: 12 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5844.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5844/head:pull/5844 PR: https://git.openjdk.java.net/jdk/pull/5844 From cushon at openjdk.java.net Tue Oct 12 16:26:25 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Tue, 12 Oct 2021 16:26:25 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v3] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 18:22:42 GMT, Liam Miller-Cushon wrote: >> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Document the rationale for the jasm changes > > ``` > > StringBuilder builder2 = new StringBuilder("foo"); > > Object oo = builder2; > > oo += "" + builder2.append("bar"); > > ``` > > > > Should that be covered as well? From looking at the patch (not really trying it), it does not seem to be covered? > > Tried it, still not correct: > > I believe `if (shouldConvertToStringEagerly(argType))` branch should be handled for first argument as well, i.e. code should be shaped as: > > @cushon, could you do this change and add a relevant test case? Fixed, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From cushon at openjdk.java.net Tue Oct 12 16:29:51 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Tue, 12 Oct 2021 16:29:51 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v4] In-Reply-To: <7o61OyyBYR74qzNjaigOC3uiV3_diVWnHPXZHo9DlAw=.9af8afaf-4f1e-474b-b6d9-9e90669fe490@github.com> References: <-Jnn2x65IcAPhkGOCxmmrmathQVOJ81DVNH2eyNnuyg=.690b0387-68b6-4dc7-84db-cb686db95ed1@github.com> <7o61OyyBYR74qzNjaigOC3uiV3_diVWnHPXZHo9DlAw=.9af8afaf-4f1e-474b-b6d9-9e90669fe490@github.com> Message-ID: <_vdI2pSDLblIK0UxckGjwNbs3HLx6cryCGe_dANyC40=.4a3b6447-b819-4fdf-8341-b81f6b58c144@github.com> On Tue, 12 Oct 2021 06:18:13 GMT, Aleksey Shipilev wrote: >> (The `WellKnownTypes` test still only exercises the indy strategies, because it's testing logic that only exists in those strategies.) > > But still, we probably want to confirm that `inline` strategy yields the same answer in `WellKnownTypes`? That's my thinking why to test `inline`: that is a baseline. I agree in general about using `inline` as a baseline, but `WellKnownTypes` doesn't currently check the output of string concatenation, it checks the signature of the `invokedynamic` it find in the test case. What do you have in mind for `inline` here? Should I update the test to assert on the output of string concatenation (and tolerate not being able to find an `invokedynamic`, which could make the coverage for the indy strategies more fragile)? Or add a different test with similar inputs, and check the output of string concatenation on primitives and boxes? I think it might make sense to rely on other tests to ensure `inline` and the `indy` strategies produce the same results, and use `WellKnownTypes` as a test just for `shouldConvertToStringEagerly`, which is only used by the `indy` strategies. ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From jjg at openjdk.java.net Tue Oct 12 16:36:47 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 12 Oct 2021 16:36:47 GMT Subject: RFR: JDK-8189591: No way to locally suppress doclint warnings In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 15:23:15 GMT, Hannes Walln?fer wrote: >> Please review a moderately simple change, to have DocLint check for relevant `@SuppressWarnings` annotations before reporting any messages. > > test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java line 459: > >> 457: >> 458: checkOutput(Output.OUT, false, >> 459: ": warning:", > > I'm curious: what's the reason for this change? false positives! Aha ... my recollection is that I did the work in a directory that had "suppress-warnings" in the name, and that directory name was showing up in the filename in diagnostics, and thus giving a false positive for the apparent presence of warnings in the output! ------------- PR: https://git.openjdk.java.net/jdk/pull/5870 From joe.darcy at oracle.com Tue Oct 12 16:42:56 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 12 Oct 2021 09:42:56 -0700 Subject: RFR: JDK-8189591: No way to locally suppress doclint warnings In-Reply-To: References: Message-ID: On 10/12/2021 8:28 AM, Jonathan Gibbons wrote: > On Tue, 12 Oct 2021 15:11:13 GMT, Hannes Walln?fer wrote: > >>> Please review a moderately simple change, to have DocLint check for relevant `@SuppressWarnings` annotations before reporting any messages. >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java line 302: >> >>> 300: for (String a: arg.substring(len).split(",")) { >>> 301: Messages.Group argGroup = gMap.get(a); >>> 302: if (argGroup != null) { >> Should we let the user know about unknown doclint:* values? > I thought about this, but in general, the precedent in `SuppressWarnings` is to not reject unknown values, because they might be supported by other systems. One special case of other system can be the JDK used for bootstrapping in the JDK build. -Joe From mgridinas at gmail.com Tue Oct 12 18:03:19 2021 From: mgridinas at gmail.com (Mantas Gridinas) Date: Tue, 12 Oct 2021 18:03:19 +0000 Subject: Allow new language features on older version targets? In-Reply-To: <6AD79BB5-472C-473C-B825-0B0DBC944629@oracle.com> References: <6AD79BB5-472C-473C-B825-0B0DBC944629@oracle.com> Message-ID: I agree with Ron's sentiment. Anecdotal, but back when I had to migrate an application from 8 to 11, it was much simpler to drop 8 support (and 8 runtime altogether) rather than maintain two codebases (and runtimes). The tipping point was cold startup performance increment from 5 minutes to 1 minute solely because we upgraded to Java 11. On Tue, Oct 12, 2021 at 4:45 PM Ron Pressler wrote: > That many people still use Java 8 (often alongside newer versions) doesn't > mean that those applications are under heavy development and can benefit > from > new language features, or from new library features, as much as more active > codebases. > > In any event, you're proposing that we divert resources away from making > new > versions more attractive toward making older versions more attractive. I > don't > think this is a good strategy. The portion of people using alternative > languages on the Java platform has remained more-or-less constant for many > years, and I, for one, am happy that the platform caters to people with > different programming tastes. Java's competitive focus is elsewhere. > > -- Ron > > > On 12 Oct 2021, at 09:14, Glavo wrote: > > > > Starting from Java 9, Java began to iterate rapidly and introduced > > many new features, which made Java more expressive and modern. > > > > However, upgrading Java is always difficult and painful. It needs to > > go through a series of cumbersome upgrade and migration processes. > > In these steps, the transplantation at the syntax level is often easy, > > because Java maintains good compatibility. However, due to subtle > > changes in the behavior of the JVM and the standard library, it is > > relatively difficult to upgrade the version of the java runtime. > > At the same time, for client applications, upgrading the development > > environment is much easier than upgrading the Java version of the > > deployment environment (e.g., only Java 8 is currently available on > > MIPS64el). For various reasons, a large number of users stay on the > > old java version. According to the statistical report of JetBrains, > > 71% of users still regularly use Java 8.0 in 2021. > > > > The most affected people are the developers of libraries. In order to > > make the library more widely used, most library authors always need to > > make their libraries use the lowest java version possible. This makes > > it difficult for them to enjoy the expression upgrade brought by Java > > update. > > > > This pain is not necessary. Although some language features of Java > > require the cooperation of JVM and standard library, e.g. Record, but > > this is not necessary for more features. At present, we can specify > > the source version and target version respectively, but we can't make > > the source version higher than the target version. I think this > > artificial additional restriction can be removed after careful > > consideration, so that more developers can enjoy the improvement of > > expression ability brought by Java's new language features. > > > > > > These features are pure language features that can be easily compiled > > into older versions of Java bytecode: > > > > * Milling Project Coin (JEP 213): Allow @SafeVargs on private instance > > methods; Allow effectively-final variables to be used as resources > > in the try-with-resources statement;Allow diamond with anonymous > > classes if the argument type of the inferred type is denotable. > > > > * Local-Variable Type Inference (JEP 286) > > * Local-Variable Syntax for Lambda Parameters (JEP 323) > > * Switch Expressions (JEP 361) > > * Text Blocks (JEP 378) > > * Pattern Matching for instanceof (JEP 394) > > * Pattern Matching for switch (JEP 406) > > * Record Patterns & Array Patterns (JEP 405) > > > > > > These characteristics cannot be directly desugared, but can be accepted > > by the old runtime: > > > > * module-info.java (JEP 261): At present, it is a popular practice to > > use Java 8 compilation library and add module info to it. However, > > this practice has not been well supported by the official. Even > > with a build tool like gradle, it needs to be implemented by > > special means. If javac can accept module info when the target > > version is less than 9 and compile it to Java 9, it is very helpful > > to simplify modular existing code. > > > > * Allow interface methods to be private (JDK-8071453): This seems to > > be allowed in jvmls 8, but it was not until Java 9 that it was > > introduced into the Java language. > > > > * Sealed Classes (JEP 409): Javac generates > PermittedSubclasses_attribute > > for sealed classes. This attribute will be ignored on the old > > runtime and will not destroy the program. Even if it cannot be > > guaranteed by the runtime before JDK 15, it can enhance the > > expressiveness of the language and make the code more compatible > > with the higher version runtime. > > > > * Universal Generics (JDK-8261529): Universal generics seem to > > compile well into bytecode compatible with older Java version. > > I think it is particularly important to allow use of universal > > generic in older bytecodes. This allows the library to adapt it > > without compromising compatibility with older Java versions. This > > can erase many obstacles to Valhalla's promotion. > > > > > > Now we can use some hacks to do similar things, like > > > > https://github.com/bsideup/jabel > > > > But this is just hack. It is unofficial and non-standard. At the same > > time, it also lacks tool support. > > > > We can also choose to switch to kotlin or Scala, both of them can emit > > Java 8 bytecode. In fact, because of the need for compatibility, the > > new language features of Java can't bring us more attraction because > > we can't use it most of the time. Over time, kotlin and Scala, which > > can have more language features on Java 8, have attracted us more and > > more. These problems are not just in the Java 8 era. The need to be > > compatible with old Java versions always exists, which makes it difficult > > for many people to put new features of the Java language into production > > for a long time. This will make Java less competitive with other JVM > > languages. > > -- // Mantas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Tue Oct 12 16:44:41 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 12 Oct 2021 16:44:41 +0000 Subject: Allow new language features on older version targets? In-Reply-To: References: Message-ID: <6AD79BB5-472C-473C-B825-0B0DBC944629@oracle.com> That many people still use Java 8 (often alongside newer versions) doesn't mean that those applications are under heavy development and can benefit from new language features, or from new library features, as much as more active codebases. In any event, you're proposing that we divert resources away from making new versions more attractive toward making older versions more attractive. I don't think this is a good strategy. The portion of people using alternative languages on the Java platform has remained more-or-less constant for many years, and I, for one, am happy that the platform caters to people with different programming tastes. Java's competitive focus is elsewhere. -- Ron > On 12 Oct 2021, at 09:14, Glavo wrote: > > Starting from Java 9, Java began to iterate rapidly and introduced > many new features, which made Java more expressive and modern. > > However, upgrading Java is always difficult and painful. It needs to > go through a series of cumbersome upgrade and migration processes. > In these steps, the transplantation at the syntax level is often easy, > because Java maintains good compatibility. However, due to subtle > changes in the behavior of the JVM and the standard library, it is > relatively difficult to upgrade the version of the java runtime. > At the same time, for client applications, upgrading the development > environment is much easier than upgrading the Java version of the > deployment environment (e.g., only Java 8 is currently available on > MIPS64el). For various reasons, a large number of users stay on the > old java version. According to the statistical report of JetBrains, > 71% of users still regularly use Java 8.0 in 2021. > > The most affected people are the developers of libraries. In order to > make the library more widely used, most library authors always need to > make their libraries use the lowest java version possible. This makes > it difficult for them to enjoy the expression upgrade brought by Java > update. > > This pain is not necessary. Although some language features of Java > require the cooperation of JVM and standard library, e.g. Record, but > this is not necessary for more features. At present, we can specify > the source version and target version respectively, but we can't make > the source version higher than the target version. I think this > artificial additional restriction can be removed after careful > consideration, so that more developers can enjoy the improvement of > expression ability brought by Java's new language features. > > > These features are pure language features that can be easily compiled > into older versions of Java bytecode: > > * Milling Project Coin (JEP 213): Allow @SafeVargs on private instance > methods; Allow effectively-final variables to be used as resources > in the try-with-resources statement;Allow diamond with anonymous > classes if the argument type of the inferred type is denotable. > > * Local-Variable Type Inference (JEP 286) > * Local-Variable Syntax for Lambda Parameters (JEP 323) > * Switch Expressions (JEP 361) > * Text Blocks (JEP 378) > * Pattern Matching for instanceof (JEP 394) > * Pattern Matching for switch (JEP 406) > * Record Patterns & Array Patterns (JEP 405) > > > These characteristics cannot be directly desugared, but can be accepted > by the old runtime: > > * module-info.java (JEP 261): At present, it is a popular practice to > use Java 8 compilation library and add module info to it. However, > this practice has not been well supported by the official. Even > with a build tool like gradle, it needs to be implemented by > special means. If javac can accept module info when the target > version is less than 9 and compile it to Java 9, it is very helpful > to simplify modular existing code. > > * Allow interface methods to be private (JDK-8071453): This seems to > be allowed in jvmls 8, but it was not until Java 9 that it was > introduced into the Java language. > > * Sealed Classes (JEP 409): Javac generates PermittedSubclasses_attribute > for sealed classes. This attribute will be ignored on the old > runtime and will not destroy the program. Even if it cannot be > guaranteed by the runtime before JDK 15, it can enhance the > expressiveness of the language and make the code more compatible > with the higher version runtime. > > * Universal Generics (JDK-8261529): Universal generics seem to > compile well into bytecode compatible with older Java version. > I think it is particularly important to allow use of universal > generic in older bytecodes. This allows the library to adapt it > without compromising compatibility with older Java versions. This > can erase many obstacles to Valhalla's promotion. > > > Now we can use some hacks to do similar things, like > > https://github.com/bsideup/jabel > > But this is just hack. It is unofficial and non-standard. At the same > time, it also lacks tool support. > > We can also choose to switch to kotlin or Scala, both of them can emit > Java 8 bytecode. In fact, because of the need for compatibility, the > new language features of Java can't bring us more attraction because > we can't use it most of the time. Over time, kotlin and Scala, which > can have more language features on Java 8, have attracted us more and > more. These problems are not just in the Java 8 era. The need to be > compatible with old Java versions always exists, which makes it difficult > for many people to put new features of the Java language into production > for a long time. This will make Java less competitive with other JVM > languages. From zjx001202 at gmail.com Wed Oct 13 01:16:17 2021 From: zjx001202 at gmail.com (Glavo) Date: Wed, 13 Oct 2021 09:16:17 +0800 Subject: Allow new language features on older version targets? In-Reply-To: <6AD79BB5-472C-473C-B825-0B0DBC944629@oracle.com> References: <6AD79BB5-472C-473C-B825-0B0DBC944629@oracle.com> Message-ID: > > That many people still use Java 8 (often alongside newer versions) doesn't > mean that those applications are under heavy development and can benefit > from > new language features, or from new library features, as much as more active > codebases. > I agree that this is the case for program developers, but the focus of the problem is not on them. The main problem is the developers of the libraries. As developers of the library, we need to choose the lower java version as possible and stay here for a long time. Every time we update Java, we are abandoning a group of users and splitting the user group. This doesn't mean that we don't pursue new technologies. I always install the latest JDK on my computer and use it to compile Java 8 compatible code. I will solve the problem of porting with all Java versions, but I can't choose to give up users of the old version of Java, so I can only use Java 8 to develop class libraries forever. I believe that making class libraries compatible with both new and old versions of Java is a very common requirement. A considerable number of these users can benefit from the new language features, but they have to stay in the old version for more users. This problem can be seen from the fact that many class libraries are compiled with Java 8 but carry module-info.class. This problem will also become more prominent because Valhalla refuses us to provide class libraries that work well on both old and new versions, even features such as Universal Generics that should work on old Java. The portion of people using alternative languages on the Java platform has > remained more-or-less constant for many years... > Are you sure? It's not what I know. In my opinion, more and more users are choosing Kotlin instead of Java -- and most of them choose Java 8 or 6 as the target version. I just hate developing class libraries with kotlin or Scala. Their interaction with Java is not as good as using java directly. Moreover, Scala 3 contains too many bugs and introduces features I hate very much. So I've been enduring the syntax of Java 8. So I have been enduring the syntax of Java 8, so that I have begun to develop a compiler compatible with the latest Java syntax and can take Java 8 as the compilation target. But this will take a long time and will cost me a lot of energy to maintain, so I am eager for an official solution. Ron Pressler ?2021?10?13??? ??12:44??? > That many people still use Java 8 (often alongside newer versions) doesn't > mean that those applications are under heavy development and can benefit > from > new language features, or from new library features, as much as more active > codebases. > > In any event, you're proposing that we divert resources away from making > new > versions more attractive toward making older versions more attractive. I > don't > think this is a good strategy. The portion of people using alternative > languages on the Java platform has remained more-or-less constant for many > years, and I, for one, am happy that the platform caters to people with > different programming tastes. Java's competitive focus is elsewhere. > > -- Ron > > > On 12 Oct 2021, at 09:14, Glavo wrote: > > > > Starting from Java 9, Java began to iterate rapidly and introduced > > many new features, which made Java more expressive and modern. > > > > However, upgrading Java is always difficult and painful. It needs to > > go through a series of cumbersome upgrade and migration processes. > > In these steps, the transplantation at the syntax level is often easy, > > because Java maintains good compatibility. However, due to subtle > > changes in the behavior of the JVM and the standard library, it is > > relatively difficult to upgrade the version of the java runtime. > > At the same time, for client applications, upgrading the development > > environment is much easier than upgrading the Java version of the > > deployment environment (e.g., only Java 8 is currently available on > > MIPS64el). For various reasons, a large number of users stay on the > > old java version. According to the statistical report of JetBrains, > > 71% of users still regularly use Java 8.0 in 2021. > > > > The most affected people are the developers of libraries. In order to > > make the library more widely used, most library authors always need to > > make their libraries use the lowest java version possible. This makes > > it difficult for them to enjoy the expression upgrade brought by Java > > update. > > > > This pain is not necessary. Although some language features of Java > > require the cooperation of JVM and standard library, e.g. Record, but > > this is not necessary for more features. At present, we can specify > > the source version and target version respectively, but we can't make > > the source version higher than the target version. I think this > > artificial additional restriction can be removed after careful > > consideration, so that more developers can enjoy the improvement of > > expression ability brought by Java's new language features. > > > > > > These features are pure language features that can be easily compiled > > into older versions of Java bytecode: > > > > * Milling Project Coin (JEP 213): Allow @SafeVargs on private instance > > methods; Allow effectively-final variables to be used as resources > > in the try-with-resources statement;Allow diamond with anonymous > > classes if the argument type of the inferred type is denotable. > > > > * Local-Variable Type Inference (JEP 286) > > * Local-Variable Syntax for Lambda Parameters (JEP 323) > > * Switch Expressions (JEP 361) > > * Text Blocks (JEP 378) > > * Pattern Matching for instanceof (JEP 394) > > * Pattern Matching for switch (JEP 406) > > * Record Patterns & Array Patterns (JEP 405) > > > > > > These characteristics cannot be directly desugared, but can be accepted > > by the old runtime: > > > > * module-info.java (JEP 261): At present, it is a popular practice to > > use Java 8 compilation library and add module info to it. However, > > this practice has not been well supported by the official. Even > > with a build tool like gradle, it needs to be implemented by > > special means. If javac can accept module info when the target > > version is less than 9 and compile it to Java 9, it is very helpful > > to simplify modular existing code. > > > > * Allow interface methods to be private (JDK-8071453): This seems to > > be allowed in jvmls 8, but it was not until Java 9 that it was > > introduced into the Java language. > > > > * Sealed Classes (JEP 409): Javac generates > PermittedSubclasses_attribute > > for sealed classes. This attribute will be ignored on the old > > runtime and will not destroy the program. Even if it cannot be > > guaranteed by the runtime before JDK 15, it can enhance the > > expressiveness of the language and make the code more compatible > > with the higher version runtime. > > > > * Universal Generics (JDK-8261529): Universal generics seem to > > compile well into bytecode compatible with older Java version. > > I think it is particularly important to allow use of universal > > generic in older bytecodes. This allows the library to adapt it > > without compromising compatibility with older Java versions. This > > can erase many obstacles to Valhalla's promotion. > > > > > > Now we can use some hacks to do similar things, like > > > > https://github.com/bsideup/jabel > > > > But this is just hack. It is unofficial and non-standard. At the same > > time, it also lacks tool support. > > > > We can also choose to switch to kotlin or Scala, both of them can emit > > Java 8 bytecode. In fact, because of the need for compatibility, the > > new language features of Java can't bring us more attraction because > > we can't use it most of the time. Over time, kotlin and Scala, which > > can have more language features on Java 8, have attracted us more and > > more. These problems are not just in the Java 8 era. The need to be > > compatible with old Java versions always exists, which makes it difficult > > for many people to put new features of the Java language into production > > for a long time. This will make Java less competitive with other JVM > > languages. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.java.net Wed Oct 13 07:00:10 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 13 Oct 2021 07:00:10 GMT Subject: RFR: 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" Message-ID: When JShell processes `int strictfp = 0;` (which is obviously erroneous), it will speculativelly try to parse and attribute code along these lines: package REPL; import java.io.*;import java.math.*;import java.net.*;import java.nio.file.*;import java.util.*;import java.util.concurrent.*;import java.util.function.*;import java.util.prefs.*;import java.util.regex.*;import java.util.stream.*; class $JShell$DOESNOTMATTER { public static Object do_it$() throws Throwable { return int strictfp = 0; } } This crashes `Attr`, as the `strictfp` will be wrapped in `JCModifiers`, wrapped inside an erroneous tree, and `Attr` does not handle modifiers. The proposal is to let `Attr` "handle" the `JCModifiers` in an error-recovery situation. ------------- Commit messages: - Removing trailing whitespace - 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" Changes: https://git.openjdk.java.net/jdk/pull/5897/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5897&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273039 Stats: 182 lines in 3 files changed: 181 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5897.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5897/head:pull/5897 PR: https://git.openjdk.java.net/jdk/pull/5897 From duke at openjdk.java.net Wed Oct 13 19:03:09 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 13 Oct 2021 19:03:09 GMT Subject: RFR: 8275242: Remove redundant stream() call before forEach in jdk.compiler Message-ID: There are several places in the jdk.compiler, jdk.javadoc, jdk.jshell that use stream().forEach(...), these can be cleaned up. Instead Collection.forEach or Map.forEach can be used directly. This is continuation of 1. [JDK-8273710](https://bugs.openjdk.java.net/browse/JDK-8273710) Remove redundant stream() call before forEach in jdk.jdeps 2. [JDK-8273711](https://bugs.openjdk.java.net/browse/JDK-8273711) Remove redundant stream() call before forEach in jdk.jlink ------------- Commit messages: - [PATCH] Remove redundant stream() call before forEach in jdk.compiler - [PATCH] Remove redundant stream() call before forEach in jdk.* modules - [PATCH] Remove redundant stream() call before forEach in jdk.* modules Changes: https://git.openjdk.java.net/jdk/pull/5521/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5521&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275242 Stats: 17 lines in 5 files changed: 0 ins; 12 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5521.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5521/head:pull/5521 PR: https://git.openjdk.java.net/jdk/pull/5521 From jjg at openjdk.java.net Wed Oct 13 19:03:09 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 13 Oct 2021 19:03:09 GMT Subject: RFR: 8275242: Remove redundant stream() call before forEach in jdk.compiler In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 07:24:35 GMT, Andrey Turbanov wrote: > There are several places in the jdk.compiler, jdk.javadoc, jdk.jshell that use stream().forEach(...), these can be cleaned up. > Instead Collection.forEach or Map.forEach can be used directly. > This is continuation of > 1. [JDK-8273710](https://bugs.openjdk.java.net/browse/JDK-8273710) Remove redundant stream() call before forEach in jdk.jdeps > 2. [JDK-8273711](https://bugs.openjdk.java.net/browse/JDK-8273711) Remove redundant stream() call before forEach in jdk.jlink jdk.compiler and jdk.javadoc changes look OK. src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java line 1645: > 1643: for (RecordComponent rc : recordComponents) { > 1644: List originalAnnos = rc.getOriginalAnnos(); > 1645: originalAnnos.forEach(this::visitAnnotation); while not wrong, this is not covered in the description of the PR ------------- PR: https://git.openjdk.java.net/jdk/pull/5521 From duke at openjdk.java.net Wed Oct 13 19:03:10 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 13 Oct 2021 19:03:10 GMT Subject: RFR: 8275242: Remove redundant stream() call before forEach in jdk.compiler In-Reply-To: References: Message-ID: <--flBl7RwW1K13NIf6JkBA4MhJ0yQg5pwvDVkN-5Gow=.dd7a277b-e84b-48c4-990f-4dd36df2cc4f@github.com> On Tue, 21 Sep 2021 01:27:44 GMT, Jonathan Gibbons wrote: >> There are several places in the jdk.compiler, jdk.javadoc, jdk.jshell that use stream().forEach(...), these can be cleaned up. >> Instead Collection.forEach or Map.forEach can be used directly. >> This is continuation of >> 1. [JDK-8273710](https://bugs.openjdk.java.net/browse/JDK-8273710) Remove redundant stream() call before forEach in jdk.jdeps >> 2. [JDK-8273711](https://bugs.openjdk.java.net/browse/JDK-8273711) Remove redundant stream() call before forEach in jdk.jlink > > src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java line 1645: > >> 1643: for (RecordComponent rc : recordComponents) { >> 1644: List originalAnnos = rc.getOriginalAnnos(); >> 1645: originalAnnos.forEach(this::visitAnnotation); > > while not wrong, this is not covered in the description of the PR Reverted ------------- PR: https://git.openjdk.java.net/jdk/pull/5521 From darcy at openjdk.java.net Thu Oct 14 01:16:08 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 14 Oct 2021 01:16:08 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v23] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: <37vRINMmAo5923WAtL8EUupaydR-NLFA4fEoNymWHr4=.a24bc24e-7b28-4458-abe1-89265a0e39b5@github.com> > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits: - Add support for warning on component type of an array. - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Initial library updates for array component type check. - Improve declared types to remove cast. - Respond to review feedback; add missing newline. - Merge branch 'master' into JDK-8202056 - Complete removal of use of javax.lang.model.Modifer. - Incorporate Jan's refactoring. - ... and 66 more: https://git.openjdk.java.net/jdk/compare/d9e03e42...c8ea34ee ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=22 Stats: 2013 lines in 50 files changed: 1941 ins; 54 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Thu Oct 14 04:23:59 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 14 Oct 2021 04:23:59 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v23] In-Reply-To: <37vRINMmAo5923WAtL8EUupaydR-NLFA4fEoNymWHr4=.a24bc24e-7b28-4458-abe1-89265a0e39b5@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> <37vRINMmAo5923WAtL8EUupaydR-NLFA4fEoNymWHr4=.a24bc24e-7b28-4458-abe1-89265a0e39b5@github.com> Message-ID: On Thu, 14 Oct 2021 01:16:08 GMT, Joe Darcy wrote: >> This is an initial PR for expanded lint warnings done under two bugs: >> >> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields >> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type >> >> to get feedback on the general approach and test strategy before further polishing the implementation. >> >> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. >> >> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. >> >> Please also review the corresponding CSRs: >> >> https://bugs.openjdk.java.net/browse/JDK-8274335 >> https://bugs.openjdk.java.net/browse/JDK-8274336 >> >> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. >> >> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. >> >> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits: > > - Add support for warning on component type of an array. > - Merge branch 'master' into JDK-8202056 > - Merge branch 'master' into JDK-8202056 > - Merge branch 'master' into JDK-8202056 > - Initial library updates for array component type check. > - Improve declared types to remove cast. > - Respond to review feedback; add missing newline. > - Merge branch 'master' into JDK-8202056 > - Complete removal of use of javax.lang.model.Modifer. > - Incorporate Jan's refactoring. > - ... and 66 more: https://git.openjdk.java.net/jdk/compare/d9e03e42...c8ea34ee I updated the PR to implement a refined check on the type of fields of a serializable class: if the type of the field is an array, if the base component type of an array is not serializable, a warning is issued. For example, both Object[] and Object[][] would generate warnings despite the JLS mandating array types are serializable. When an array is serialized, eventually its elements are serialized so a non-serializable component type is worth mentioning. ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From shade at openjdk.java.net Thu Oct 14 08:38:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Oct 2021 08:38:53 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v4] In-Reply-To: <_vdI2pSDLblIK0UxckGjwNbs3HLx6cryCGe_dANyC40=.4a3b6447-b819-4fdf-8341-b81f6b58c144@github.com> References: <-Jnn2x65IcAPhkGOCxmmrmathQVOJ81DVNH2eyNnuyg=.690b0387-68b6-4dc7-84db-cb686db95ed1@github.com> <7o61OyyBYR74qzNjaigOC3uiV3_diVWnHPXZHo9DlAw=.9af8afaf-4f1e-474b-b6d9-9e90669fe490@github.com> <_vdI2pSDLblIK0UxckGjwNbs3HLx6cryCGe_dANyC40=.4a3b6447-b819-4fdf-8341-b81f6b58c144@github.com> Message-ID: On Tue, 12 Oct 2021 16:26:58 GMT, Liam Miller-Cushon wrote: >> But still, we probably want to confirm that `inline` strategy yields the same answer in `WellKnownTypes`? That's my thinking why to test `inline`: that is a baseline. > > I agree in general about using `inline` as a baseline, but `WellKnownTypes` doesn't currently check the output of string concatenation, it checks the signature of the `invokedynamic` it find in the test case. > > What do you have in mind for `inline` here? Should I update the test to assert on the output of string concatenation (and tolerate not being able to find an `invokedynamic`, which could make the coverage for the indy strategies more fragile)? Or add a different test with similar inputs, and check the output of string concatenation on primitives and boxes? > > I think it might make sense to rely on other tests to ensure `inline` and the `indy` strategies produce the same results, and use `WellKnownTypes` as a test just for `shouldConvertToStringEagerly`, which is only used by the `indy` strategies. Ah, I missed that `WellKnownTypes` does not verify concat output. Yes, that resolves my concern, we don't need to handle `inline` there. Maybe rename `WellKnownTypes` to `WellKnownTypeSignatures` or something? But yes, I think adding another test that verifies the "special" input types produce consistent results across all strategies would be useful. ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From prappo at openjdk.java.net Thu Oct 14 15:10:59 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 14 Oct 2021 15:10:59 GMT Subject: RFR: JDK-8189591: No way to locally suppress doclint warnings In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 18:32:53 GMT, Jonathan Gibbons wrote: > Please review a moderately simple change, to have DocLint check for relevant `@SuppressWarnings` annotations before reporting any messages. Looks good; consider the trivial suggestions below. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java line 298: > 296: set = EnumSet.allOf(Messages.Group.class); > 297: break; > 298: } else if (arg.startsWith("doclint:")){ Prepend `{` with whitespace: Suggestion: } else if (arg.startsWith("doclint:")) { src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java line 300: > 298: } else if (arg.startsWith("doclint:")){ > 299: final int len = "doclint:".length(); > 300: for (String a: arg.substring(len).split(",")) { Add whitespace after `String a` for consistency with other enhanced for-loops in this file: Suggestion: for (String a : arg.substring(len).split(",")) { src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java line 310: > 308: suppressWarnings.put(e, set); > 309: } > 310: return set.contains(g); Refactor as `suppressWarnings.computeIfAbsent(...).contains(g)` with a method reference for readability. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java line 332: > 330: for (var item : list) { > 331: if (item instanceof AnnotationValue avItem) { > 332: if (avItem.getValue() instanceof String s) { Suggestion: if (item instanceof AnnotationValue avItem && avItems.getValue() instanceof Srting s) { test/langtools/tools/doclint/SuppressWarningsTest.java line 141: > 139: } > 140: > 141: } Add trailing newline. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5870 From hchao at openjdk.java.net Thu Oct 14 16:13:10 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 14 Oct 2021 16:13:10 GMT Subject: RFR: 8272163: Add -version option to keytool and jarsigner Message-ID: <09nuObEA1zfkqsqe4YoypKcdexK1L5zdRjtXUKHLt_g=.676c0c70-e861-460d-b28e-bdada92a5136@github.com> It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does. ------------- Commit messages: - 8272163: Add -version option to keytool and jarsigner Changes: https://git.openjdk.java.net/jdk/pull/5954/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5954&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272163 Stats: 117 lines in 6 files changed: 116 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5954.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5954/head:pull/5954 PR: https://git.openjdk.java.net/jdk/pull/5954 From cushon at openjdk.java.net Thu Oct 14 17:14:42 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Thu, 14 Oct 2021 17:14:42 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v5] In-Reply-To: References: Message-ID: > This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Rename WellKnownTypes to WellKnownTypeSignatures and add more functional test coverage for string concat of well-known types, covering all strategies. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5844/files - new: https://git.openjdk.java.net/jdk/pull/5844/files/53dddf6d..d23a324d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5844&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5844&range=03-04 Stats: 78 lines in 2 files changed: 3 ins; 41 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/5844.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5844/head:pull/5844 PR: https://git.openjdk.java.net/jdk/pull/5844 From cushon at openjdk.java.net Thu Oct 14 17:14:43 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Thu, 14 Oct 2021 17:14:43 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v5] In-Reply-To: References: <-Jnn2x65IcAPhkGOCxmmrmathQVOJ81DVNH2eyNnuyg=.690b0387-68b6-4dc7-84db-cb686db95ed1@github.com> <7o61OyyBYR74qzNjaigOC3uiV3_diVWnHPXZHo9DlAw=.9af8afaf-4f1e-474b-b6d9-9e90669fe490@github.com> <_vdI2pSDLblIK0UxckGjwNbs3HLx6cryCGe_dANyC40=.4a3b6447-b819-4fdf-8341-b81f6b58c144@github.com> Message-ID: On Thu, 14 Oct 2021 08:35:45 GMT, Aleksey Shipilev wrote: >> I agree in general about using `inline` as a baseline, but `WellKnownTypes` doesn't currently check the output of string concatenation, it checks the signature of the `invokedynamic` it find in the test case. >> >> What do you have in mind for `inline` here? Should I update the test to assert on the output of string concatenation (and tolerate not being able to find an `invokedynamic`, which could make the coverage for the indy strategies more fragile)? Or add a different test with similar inputs, and check the output of string concatenation on primitives and boxes? >> >> I think it might make sense to rely on other tests to ensure `inline` and the `indy` strategies produce the same results, and use `WellKnownTypes` as a test just for `shouldConvertToStringEagerly`, which is only used by the `indy` strategies. > > Ah, I missed that `WellKnownTypes` does not verify concat output. Yes, that resolves my concern, we don't need to handle `inline` there. Maybe rename `WellKnownTypes` to `WellKnownTypeSignatures` or something? > > But yes, I think adding another test that verifies the "special" input types produce consistent results across all strategies would be useful. Sure, thanks--I renamed `WellKnownTypes` to `WellKnownTypeSignatures`, and added a new ` WellKnownTypes` that tests the actual concat behaviour on primitives for all of the strategies. ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From shade at openjdk.java.net Fri Oct 15 08:37:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 15 Oct 2021 08:37:47 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v5] In-Reply-To: References: <-Jnn2x65IcAPhkGOCxmmrmathQVOJ81DVNH2eyNnuyg=.690b0387-68b6-4dc7-84db-cb686db95ed1@github.com> <7o61OyyBYR74qzNjaigOC3uiV3_diVWnHPXZHo9DlAw=.9af8afaf-4f1e-474b-b6d9-9e90669fe490@github.com> <_vdI2pSDLblIK0UxckGjwNbs3HLx6cryCGe_dANyC40=.4a3b6447-b819-4fdf-8341-b81f6b58c144@github.com> Message-ID: On Thu, 14 Oct 2021 17:10:20 GMT, Liam Miller-Cushon wrote: >> Ah, I missed that `WellKnownTypes` does not verify concat output. Yes, that resolves my concern, we don't need to handle `inline` there. Maybe rename `WellKnownTypes` to `WellKnownTypeSignatures` or something? >> >> But yes, I think adding another test that verifies the "special" input types produce consistent results across all strategies would be useful. > > Sure, thanks--I renamed `WellKnownTypes` to `WellKnownTypeSignatures`, and added a new ` WellKnownTypes` that tests the actual concat behaviour on primitives for all of the strategies. Thank you, the last change resolves my comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From jlahoda at openjdk.java.net Fri Oct 15 11:56:14 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 15 Oct 2021 11:56:14 GMT Subject: RFR: 8272234: Pass originating elements from Filer to JavaFileManager [v2] In-Reply-To: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> Message-ID: > This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files. > > Any feedback on this prototype would be welcome. Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Javadoc improvements. - Merge branch 'master' into ap-keep-originating-elements - Cleanup. - Improving testing - Updating @since - Merge branch 'master' into ap-keep-originating-elements - Another attempt to fix the test. - More attempts to fix the test. - Attempting to fix test. - Adding @since - ... and 6 more: https://git.openjdk.java.net/jdk/compare/4cb7124c...9396bbb4 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5076/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5076&range=01 Stats: 579 lines in 7 files changed: 569 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5076.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5076/head:pull/5076 PR: https://git.openjdk.java.net/jdk/pull/5076 From vromero at openjdk.java.net Fri Oct 15 20:05:59 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 15 Oct 2021 20:05:59 GMT Subject: RFR: 8272234: Pass originating elements from Filer to JavaFileManager [v2] In-Reply-To: References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> Message-ID: <2_AI5aPHEPyZls9A8u2WN9XwmuDyXa3OTC4OO7OnZeI=.1e50d43f-ca3a-49bd-af6f-9a88e98bef61@github.com> On Fri, 15 Oct 2021 11:56:14 GMT, Jan Lahoda wrote: >> This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files. >> >> Any feedback on this prototype would be welcome. > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Javadoc improvements. > - Merge branch 'master' into ap-keep-originating-elements > - Cleanup. > - Improving testing > - Updating @since > - Merge branch 'master' into ap-keep-originating-elements > - Another attempt to fix the test. > - More attempts to fix the test. > - Attempting to fix test. > - Adding @since > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/4cb7124c...9396bbb4 I guess this one needs a CSR right? ------------- PR: https://git.openjdk.java.net/jdk/pull/5076 From vromero at openjdk.java.net Fri Oct 15 20:16:00 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 15 Oct 2021 20:16:00 GMT Subject: RFR: 8275242: Remove redundant stream() call before forEach in jdk.compiler In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 07:24:35 GMT, Andrey Turbanov wrote: > There are several places in the jdk.compiler, jdk.javadoc, jdk.jshell that use stream().forEach(...), these can be cleaned up. > Instead Collection.forEach or Map.forEach can be used directly. > This is continuation of > 1. [JDK-8273710](https://bugs.openjdk.java.net/browse/JDK-8273710) Remove redundant stream() call before forEach in jdk.jdeps > 2. [JDK-8273711](https://bugs.openjdk.java.net/browse/JDK-8273711) Remove redundant stream() call before forEach in jdk.jlink src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java line 60: > 58: import com.sun.tools.javac.tree.JCTree; > 59: import com.sun.tools.javac.tree.TreeInfo; > 60: import com.sun.tools.javac.tree.JCTree.JCBlock; probably IDE generated but I think that it is preferable to let the explicit imports and instead remove the: `import com.sun.tools.javac.tree.JCTree.*` below ------------- PR: https://git.openjdk.java.net/jdk/pull/5521 From jjg at openjdk.java.net Fri Oct 15 22:10:52 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 15 Oct 2021 22:10:52 GMT Subject: RFR: 8272234: Pass originating elements from Filer to JavaFileManager [v2] In-Reply-To: References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> Message-ID: On Fri, 15 Oct 2021 11:56:14 GMT, Jan Lahoda wrote: >> This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files. >> >> Any feedback on this prototype would be welcome. > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Javadoc improvements. > - Merge branch 'master' into ap-keep-originating-elements > - Cleanup. > - Improving testing > - Updating @since > - Merge branch 'master' into ap-keep-originating-elements > - Another attempt to fix the test. > - More attempts to fix the test. > - Attempting to fix test. > - Adding @since > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/4cb7124c...9396bbb4 Nice solution overall to an awkward problem, as regards naming. Yes, the new name is awkward and long, but there does not seem to be a satisfactory alternative using overloading, and accepting that, there is a reasonable correspondence between the terms "originating elements" in `Filer` and "originating files" here. src/java.compiler/share/classes/javax/tools/JavaFileManager.java line 348: > 346: * > 347: *

The provided {@code originatingFiles} represent files that > 348: * where in, an unspecified way, used to create the content of spelling: first work should probably be `were`, not `where`. src/java.compiler/share/classes/javax/tools/JavaFileManager.java line 374: > 372: * and this file manager cannot be reopened > 373: * @since 18 > 374: * @see Filer#createSourceFile ?? yes, cross-linking to `Filer` is a good idea. src/java.compiler/share/classes/javax/tools/JavaFileManager.java line 482: > 480: * > 481: *

The provided {@code originatingFiles} represent files that > 482: * where in, an unspecified way, used to create the content of spelling: `were` src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java line 549: > 547: }) > 548: .filter(fo -> fo != null) > 549: .toArray(s -> new JavaFileObject[s]); @jddarcy this is an example of why it would be good to have an API method in the Language Model world to get the "source" from which an `Element` was obtained, where "source" means either a .class or a .java file ... in other words, the `Symbol.classfile` field accessed in this code. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5076 From darcy at openjdk.java.net Fri Oct 15 22:32:53 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 15 Oct 2021 22:32:53 GMT Subject: RFR: 8274881: Update jdk.compiler classes to use try-with-resources In-Reply-To: References: Message-ID: <485wmGx62btQdbp6Iyjqze8Y3RKWz4PvDP4GtqYT6go=.7d800969-705c-4f50-aa80-f48804245051@github.com> On Tue, 12 Oct 2021 08:12:13 GMT, Andrey Turbanov wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/util/ByteBuffer.java line 172: >> >>> 170: * should be reported. >>> 171: */ >>> 172: } >> >> The exception behavior seems like it could differ, which may or may not be an issue. > > Yes. Behavior is changed for the case, when we read InputStream up the end _without_ any exception and then get Exception during _close_ call. > But I think it still worth changing: > 1. Code is shorter and cleaner > 2. Such case is very rare, when only `InputStream.close` throw exception, but `InputStream.read` did not > 3. Swallowing exceptions, even during `close()` call, is a bad code smell. Someone more familiar with the consequences of changing the exception behavior than I am will need to comment here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5816 From jjg at openjdk.java.net Fri Oct 15 23:08:48 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 15 Oct 2021 23:08:48 GMT Subject: RFR: JDK-8189591: No way to locally suppress doclint warnings In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 15:05:38 GMT, Pavel Rappo wrote: >> Please review a moderately simple change, to have DocLint check for relevant `@SuppressWarnings` annotations before reporting any messages. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java line 298: > >> 296: set = EnumSet.allOf(Messages.Group.class); >> 297: break; >> 298: } else if (arg.startsWith("doclint:")){ > > Prepend `{` with whitespace: > Suggestion: > > } else if (arg.startsWith("doclint:")) { ?? > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java line 300: > >> 298: } else if (arg.startsWith("doclint:")){ >> 299: final int len = "doclint:".length(); >> 300: for (String a: arg.substring(len).split(",")) { > > Add whitespace after `String a` for consistency with other enhanced for-loops in this file: > Suggestion: > > for (String a : arg.substring(len).split(",")) { ?? > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java line 310: > >> 308: suppressWarnings.put(e, set); >> 309: } >> 310: return set.contains(g); > > Refactor as `suppressWarnings.computeIfAbsent(...).contains(g)` with a method reference for readability. ?? > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java line 332: > >> 330: for (var item : list) { >> 331: if (item instanceof AnnotationValue avItem) { >> 332: if (avItem.getValue() instanceof String s) { > > Suggestion: > > if (item instanceof AnnotationValue avItem > && avItems.getValue() instanceof Srting s) { ?? > test/langtools/tools/doclint/SuppressWarningsTest.java line 141: > >> 139: } >> 140: >> 141: } > > Add trailing newline. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/5870 From jjg at openjdk.java.net Fri Oct 15 23:16:18 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 15 Oct 2021 23:16:18 GMT Subject: RFR: JDK-8189591: No way to locally suppress doclint warnings [v2] In-Reply-To: References: Message-ID: > Please review a moderately simple change, to have DocLint check for relevant `@SuppressWarnings` annotations before reporting any messages. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5870/files - new: https://git.openjdk.java.net/jdk/pull/5870/files/6938a7ac..6e736b69 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5870&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5870&range=00-01 Stats: 35 lines in 2 files changed: 9 ins; 3 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/5870.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5870/head:pull/5870 PR: https://git.openjdk.java.net/jdk/pull/5870 From darcy at openjdk.java.net Fri Oct 15 23:23:58 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 15 Oct 2021 23:23:58 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion Message-ID: I wanted to get input on the design of API of the method before writing the tests. The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. CSR to follow once the API is nailed down. ------------- Commit messages: - JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersio Changes: https://git.openjdk.java.net/jdk/pull/5973/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275308 Stats: 36 lines in 1 file changed: 36 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5973.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5973/head:pull/5973 PR: https://git.openjdk.java.net/jdk/pull/5973 From prappo at openjdk.java.net Fri Oct 15 23:27:57 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 15 Oct 2021 23:27:57 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 23:17:50 GMT, Joe Darcy wrote: > I wanted to get input on the design of API of the method before writing the tests. > > The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. > > Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. > > Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. > > CSR to follow once the API is nailed down. src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 515: > 513: * RELEASE_17}, is
: > 514: * > 515: * {@code SourceVersion.valueOf(Runtime.Version.parse(Integer.toString(17))) Suggestion: * {@code SourceVersion.valueOf(Runtime.Version.parse(Integer.toString(17)))} ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From prappo at openjdk.java.net Fri Oct 15 23:35:45 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 15 Oct 2021 23:35:45 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion In-Reply-To: References: Message-ID: <-mMoSbqZDso9gjsCvY2Q9HL9Ykng44zBRAMfqnGNHoM=.6c70dffa-f27a-4f98-8af6-2d8fea6c79bc@github.com> On Fri, 15 Oct 2021 23:24:53 GMT, Pavel Rappo wrote: >> I wanted to get input on the design of API of the method before writing the tests. >> >> The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. >> >> Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. >> >> Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. >> >> CSR to follow once the API is nailed down. > > src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 515: > >> 513: * RELEASE_17}, is
: >> 514: * >> 515: * {@code SourceVersion.valueOf(Runtime.Version.parse(Integer.toString(17))) > > Suggestion: > > * {@code SourceVersion.valueOf(Runtime.Version.parse(Integer.toString(17)))} I understand that this PR is an invitation to a discussion, not the final solution. Still, it's easier to reason about API whose doc comments render properly. ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Sat Oct 16 00:02:08 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 16 Oct 2021 00:02:08 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v2] In-Reply-To: References: Message-ID: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> > I wanted to get input on the design of API of the method before writing the tests. > > The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. > > Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. > > Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. > > CSR to follow once the API is nailed down. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5973/files - new: https://git.openjdk.java.net/jdk/pull/5973/files/19e8c52c..bf3e4dff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5973.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5973/head:pull/5973 PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Sat Oct 16 00:02:09 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 16 Oct 2021 00:02:09 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v2] In-Reply-To: <-mMoSbqZDso9gjsCvY2Q9HL9Ykng44zBRAMfqnGNHoM=.6c70dffa-f27a-4f98-8af6-2d8fea6c79bc@github.com> References: <-mMoSbqZDso9gjsCvY2Q9HL9Ykng44zBRAMfqnGNHoM=.6c70dffa-f27a-4f98-8af6-2d8fea6c79bc@github.com> Message-ID: On Fri, 15 Oct 2021 23:32:35 GMT, Pavel Rappo wrote: >> src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 515: >> >>> 513: * RELEASE_17}, is
: >>> 514: * >>> 515: * {@code SourceVersion.valueOf(Runtime.Version.parse(Integer.toString(17))) >> >> Suggestion: >> >> * {@code SourceVersion.valueOf(Runtime.Version.parse(Integer.toString(17)))} > > I understand that this PR is an invitation to a discussion, not the final solution. Still, it's easier to reason about API whose doc comments render properly. Doh! Sorry, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From jjg at openjdk.java.net Sat Oct 16 00:13:48 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 16 Oct 2021 00:13:48 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v2] In-Reply-To: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> References: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> Message-ID: <7EDRXgZdL751gqhGIDQNu-L_D4rIv3qU66HgaOqyPfA=.665e9709-5239-4827-80af-999bab64a700@github.com> On Sat, 16 Oct 2021 00:02:08 GMT, Joe Darcy wrote: >> I wanted to get input on the design of API of the method before writing the tests. >> >> The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. >> >> Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. >> >> Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. >> >> CSR to follow once the API is nailed down. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo. src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 515: > 513: * RELEASE_17}, is
: > 514: * > 515: * {@code SourceVersion.valueOf(Runtime.Version.parse(Integer.toString(17)))} IMO, The use of integer value in the example is something of a distraction, and suggests a hole in the `Runtime.Version` API. IMO, a more likely use case is for code to have a string representing a version, perhaps found as an argument on the command line ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From duke at openjdk.java.net Sat Oct 16 03:04:48 2021 From: duke at openjdk.java.net (Michael Bien) Date: Sat, 16 Oct 2021 03:04:48 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v2] In-Reply-To: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> References: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> Message-ID: On Sat, 16 Oct 2021 00:02:08 GMT, Joe Darcy wrote: >> I wanted to get input on the design of API of the method before writing the tests. >> >> The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. >> >> Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. >> >> Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. >> >> CSR to follow once the API is nailed down. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo. although the new factory method is quite useful to convert from one version representation to another. Unfortunately, I don't think it would solve one particular use case (although a very niche one). NetBeans for example relies on javac for all its editor features and can optionally use a newer javac than the JDK has, on which it is running on. This allows to have java 17 editor features while starting NB on JDK 8 (for whatever reason). That is why you can find code like in https://github.com/apache/netbeans/pull/3166/commits/56cf1c5b4d9b770b7fe39a34be373c0d0165ae58 all over the place since it has to check a feature version against an enum which might not be there. And that is why my first thought went to "wouldn't it be nice if we could just compare ordinals or ask SourceVersion for the feature version int". Calling `version.feature() >= 11` would not require having access to the RELEASE_11 enum you would need to compare the version with. Calling `version.compareTo(SourceVersion.valueOf(Runtime.Version.parse("11")))) >= 0` wouldn't help a lot since it basically has to throw exceptions since it can't just make up enums. But this is so niche that it is probably not worth considering. NB could just put public static boolean supports(SourceVersion model, int featureVersionToCheck) { return model.ordinal() >= featureVersionToCheck; } somewhere which will work until the unlikely event of the enum having non-feature versions before it needs to be changed. (or just keep doing the static initializer workaround) ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From jjg at openjdk.java.net Sat Oct 16 03:09:00 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 16 Oct 2021 03:09:00 GMT Subject: Integrated: JDK-8189591: No way to locally suppress doclint warnings In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 18:32:53 GMT, Jonathan Gibbons wrote: > Please review a moderately simple change, to have DocLint check for relevant `@SuppressWarnings` annotations before reporting any messages. This pull request has now been integrated. Changeset: 96fef40b Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/96fef40b8206c7027c6688bc0cb0bd979bea4b4b Stats: 262 lines in 4 files changed: 252 ins; 5 del; 5 mod 8189591: No way to locally suppress doclint warnings Reviewed-by: hannesw, prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/5870 From jjg at openjdk.java.net Sat Oct 16 03:25:50 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 16 Oct 2021 03:25:50 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v2] In-Reply-To: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> References: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> Message-ID: <5F_SZ42fwH9lXW4K9Rc-cruz-R1pdLUuysKblXW8B94=.218958da-6cd0-47a9-863e-bfdb8f02b0e9@github.com> On Sat, 16 Oct 2021 00:02:08 GMT, Joe Darcy wrote: >> I wanted to get input on the design of API of the method before writing the tests. >> >> The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. >> >> Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. >> >> Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. >> >> CSR to follow once the API is nailed down. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo. Would it help to have a method that provides the inverse mapping Runtime.Version SourceVersion.toRuntimeVersion() ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From duke at openjdk.java.net Sat Oct 16 16:14:52 2021 From: duke at openjdk.java.net (Michael Bien) Date: Sat, 16 Oct 2021 16:14:52 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v2] In-Reply-To: <5F_SZ42fwH9lXW4K9Rc-cruz-R1pdLUuysKblXW8B94=.218958da-6cd0-47a9-863e-bfdb8f02b0e9@github.com> References: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> <5F_SZ42fwH9lXW4K9Rc-cruz-R1pdLUuysKblXW8B94=.218958da-6cd0-47a9-863e-bfdb8f02b0e9@github.com> Message-ID: <9tS_HEZZPN45BOg00gM4GVAoqqlTKqXBdvqBl-rPpTA=.eaa05b07-bc58-4b68-9f69-e45e9f5aa758@github.com> On Sat, 16 Oct 2021 03:23:07 GMT, Jonathan Gibbons wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo. > > Would it help to have a method that provides the inverse mapping > > > Runtime.Version SourceVersion.toRuntimeVersion() @jonathan-gibbons I think that would help indeed. The conversion method would always be able to return a runtime version without throwing exceptions, which would make it a convenient way to access the feature version int. It seems to be also forward compatible to all (prob. unlikely) scenarios of SourceVersion adding non-feature-version enums. ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Sun Oct 17 18:52:00 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 17 Oct 2021 18:52:00 GMT Subject: RFR: JDK-8275360: Use @Override in javax.annotation.processing Message-ID: Simple cleanup to add @Override annotations to AbstractProcessor. IIRC when AbstractProcessor was added in JDK 6, using @Override wasn't yet support for interface methods. ------------- Commit messages: - JDK-8275360: Use @Override in javax.annotation.processing Changes: https://git.openjdk.java.net/jdk/pull/5979/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5979&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275360 Stats: 6 lines in 2 files changed: 5 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5979.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5979/head:pull/5979 PR: https://git.openjdk.java.net/jdk/pull/5979 From darcy at openjdk.java.net Sun Oct 17 21:07:59 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 17 Oct 2021 21:07:59 GMT Subject: RFR: JDK-8275368: Correct statement of kinds of elements Processor.process operates over Message-ID: <_O7Igv0D4f1PFYKDuwisGFjkm5g8d4KGOa8v36te4ec=.af5e9a42-72a2-45f2-b3c6-81d35acfb924@github.com> Correcting docs of Processor.process to not imply that type elements are the only kind of element processed. Updated lines left un-reflowed to ease review. I'll reflow paragraphs and update copyright years before pushing. Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8275369 ------------- Commit messages: - JDK-8275368: Correct statement of kinds of elements Processor.process operates over Changes: https://git.openjdk.java.net/jdk/pull/5982/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5982&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275368 Stats: 11 lines in 2 files changed: 7 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5982.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5982/head:pull/5982 PR: https://git.openjdk.java.net/jdk/pull/5982 From darcy at openjdk.java.net Mon Oct 18 06:04:13 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 18 Oct 2021 06:04:13 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v24] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 79 commits: - Do not warn for prence of serialVersionUID in interfaces. - Sharpen type of method parameters to javac type. - Merge branch 'master' into JDK-8202056 - Add support for warning on component type of an array. - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Initial library updates for array component type check. - Improve declared types to remove cast. - Respond to review feedback; add missing newline. - ... and 69 more: https://git.openjdk.java.net/jdk/compare/31500692...dea009b7 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=23 Stats: 2009 lines in 48 files changed: 1939 ins; 54 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Mon Oct 18 06:18:57 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 18 Oct 2021 06:18:57 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v24] In-Reply-To: References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: On Mon, 18 Oct 2021 06:04:13 GMT, Joe Darcy wrote: >> This is an initial PR for expanded lint warnings done under two bugs: >> >> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields >> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type >> >> to get feedback on the general approach and test strategy before further polishing the implementation. >> >> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. >> >> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. >> >> Please also review the corresponding CSRs: >> >> https://bugs.openjdk.java.net/browse/JDK-8274335 >> https://bugs.openjdk.java.net/browse/JDK-8274336 >> >> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. >> >> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. >> >> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 79 commits: > > - Do not warn for prence of serialVersionUID in interfaces. > - Sharpen type of method parameters to javac type. > - Merge branch 'master' into JDK-8202056 > - Add support for warning on component type of an array. > - Merge branch 'master' into JDK-8202056 > - Merge branch 'master' into JDK-8202056 > - Merge branch 'master' into JDK-8202056 > - Initial library updates for array component type check. > - Improve declared types to remove cast. > - Respond to review feedback; add missing newline. > - ... and 69 more: https://git.openjdk.java.net/jdk/compare/31500692...dea009b7 >From an off-list discussion with Roger and Stuart, I've changed the checks to not warm about the presence of a serialVersionUID field in an interface. There are specialized situations where the serialVersionUID of an interface are used. ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From shade at openjdk.java.net Mon Oct 18 06:47:51 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Oct 2021 06:47:51 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v5] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 17:14:42 GMT, Liam Miller-Cushon wrote: >> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Rename WellKnownTypes to WellKnownTypeSignatures > > and add more functional test coverage for string concat of well-known > types, covering all strategies. Current change passes `tier{1,2,3,4}` for me. Still, I think compiler folks have to approve the javac change. @lahodaj, could you do it, or ask somebody else? ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From duke at openjdk.java.net Mon Oct 18 08:45:13 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 18 Oct 2021 08:45:13 GMT Subject: RFR: 8275242: Remove redundant stream() call before forEach in jdk.compiler [v2] In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 20:12:12 GMT, Vicente Romero wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8275242: Remove redundant stream() call before forEach in jdk.compiler >> expand start import > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java line 60: > >> 58: import com.sun.tools.javac.tree.JCTree; >> 59: import com.sun.tools.javac.tree.TreeInfo; >> 60: import com.sun.tools.javac.tree.JCTree.JCBlock; > > probably IDE generated but I think that it is preferable to let the explicit imports and instead remove the: > `import com.sun.tools.javac.tree.JCTree.*` below updated ------------- PR: https://git.openjdk.java.net/jdk/pull/5521 From duke at openjdk.java.net Mon Oct 18 08:45:12 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 18 Oct 2021 08:45:12 GMT Subject: RFR: 8275242: Remove redundant stream() call before forEach in jdk.compiler [v2] In-Reply-To: References: Message-ID: > There are several places in the jdk.compiler that use stream().forEach(...), these can be cleaned up. > Instead Collection.forEach or Map.forEach can be used directly. > This is continuation of > 1. [JDK-8273710](https://bugs.openjdk.java.net/browse/JDK-8273710) Remove redundant stream() call before forEach in jdk.jdeps > 2. [JDK-8273711](https://bugs.openjdk.java.net/browse/JDK-8273711) Remove redundant stream() call before forEach in jdk.jlink Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8275242: Remove redundant stream() call before forEach in jdk.compiler expand start import ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5521/files - new: https://git.openjdk.java.net/jdk/pull/5521/files/48ca9063..4939c866 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5521&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5521&range=00-01 Stats: 20 lines in 1 file changed: 19 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5521.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5521/head:pull/5521 PR: https://git.openjdk.java.net/jdk/pull/5521 From hannesw at openjdk.java.net Mon Oct 18 08:55:53 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 18 Oct 2021 08:55:53 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v2] In-Reply-To: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> References: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> Message-ID: On Sat, 16 Oct 2021 00:02:08 GMT, Joe Darcy wrote: >> I wanted to get input on the design of API of the method before writing the tests. >> >> The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. >> >> Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. >> >> Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. >> >> CSR to follow once the API is nailed down. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo. FWIW there is one place in javadoc that would also benefit from a SourceVersion to Runtime.Version conversion method. (That code would be less ugly if it used `ordinal()`, the idea was that it would fail more predictably this way if the version naming pattern was ever abandoned.) https://github.com/openjdk/jdk/blob/ebb1363e5d6b47daf1badad93490580fedcb0572/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java#L336-L342 ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From iris at openjdk.java.net Mon Oct 18 15:27:50 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 18 Oct 2021 15:27:50 GMT Subject: RFR: JDK-8275360: Use @Override in javax.annotation.processing In-Reply-To: References: Message-ID: On Sun, 17 Oct 2021 18:43:38 GMT, Joe Darcy wrote: > Simple cleanup to add @Override annotations to AbstractProcessor. IIRC when AbstractProcessor was added in JDK 6, using @Override wasn't yet support for interface methods. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5979 From jlahoda at openjdk.java.net Mon Oct 18 15:33:49 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 18 Oct 2021 15:33:49 GMT Subject: RFR: JDK-8275368: Correct statement of kinds of elements Processor.process operates over In-Reply-To: <_O7Igv0D4f1PFYKDuwisGFjkm5g8d4KGOa8v36te4ec=.af5e9a42-72a2-45f2-b3c6-81d35acfb924@github.com> References: <_O7Igv0D4f1PFYKDuwisGFjkm5g8d4KGOa8v36te4ec=.af5e9a42-72a2-45f2-b3c6-81d35acfb924@github.com> Message-ID: On Sun, 17 Oct 2021 20:57:28 GMT, Joe Darcy wrote: > Correcting docs of Processor.process to not imply that type elements are the only kind of element processed. > > Updated lines left un-reflowed to ease review. I'll reflow paragraphs and update copyright years before pushing. > > Please also review the corresponding CSR: > > https://bugs.openjdk.java.net/browse/JDK-8275369 Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5982 From darcy at openjdk.java.net Mon Oct 18 15:53:18 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 18 Oct 2021 15:53:18 GMT Subject: RFR: JDK-8275368: Correct statement of kinds of elements Processor.process operates over [v2] In-Reply-To: <_O7Igv0D4f1PFYKDuwisGFjkm5g8d4KGOa8v36te4ec=.af5e9a42-72a2-45f2-b3c6-81d35acfb924@github.com> References: <_O7Igv0D4f1PFYKDuwisGFjkm5g8d4KGOa8v36te4ec=.af5e9a42-72a2-45f2-b3c6-81d35acfb924@github.com> Message-ID: <9lXctOizp9U1y1mP3XkDrGhTDu6nPU6nzsueElXSpQ8=.d7ea0ec7-2224-461a-9bae-e4fd2a4c25d6@github.com> > Correcting docs of Processor.process to not imply that type elements are the only kind of element processed. > > Updated lines left un-reflowed to ease review. I'll reflow paragraphs and update copyright years before pushing. > > Please also review the corresponding CSR: > > https://bugs.openjdk.java.net/browse/JDK-8275369 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Reflow paragraphs; update copyright. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5982/files - new: https://git.openjdk.java.net/jdk/pull/5982/files/6f71cdc8..8ffac3c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5982&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5982&range=00-01 Stats: 14 lines in 2 files changed: 1 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/5982.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5982/head:pull/5982 PR: https://git.openjdk.java.net/jdk/pull/5982 From darcy at openjdk.java.net Mon Oct 18 15:53:18 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 18 Oct 2021 15:53:18 GMT Subject: Integrated: JDK-8275368: Correct statement of kinds of elements Processor.process operates over In-Reply-To: <_O7Igv0D4f1PFYKDuwisGFjkm5g8d4KGOa8v36te4ec=.af5e9a42-72a2-45f2-b3c6-81d35acfb924@github.com> References: <_O7Igv0D4f1PFYKDuwisGFjkm5g8d4KGOa8v36te4ec=.af5e9a42-72a2-45f2-b3c6-81d35acfb924@github.com> Message-ID: On Sun, 17 Oct 2021 20:57:28 GMT, Joe Darcy wrote: > Correcting docs of Processor.process to not imply that type elements are the only kind of element processed. > > Updated lines left un-reflowed to ease review. I'll reflow paragraphs and update copyright years before pushing. > > Please also review the corresponding CSR: > > https://bugs.openjdk.java.net/browse/JDK-8275369 This pull request has now been integrated. Changeset: fb8e5cf4 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/fb8e5cf4ecee1b737bdcc806d219709854185764 Stats: 23 lines in 2 files changed: 8 ins; 1 del; 14 mod 8275368: Correct statement of kinds of elements Processor.process operates over Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/5982 From darcy at openjdk.java.net Mon Oct 18 16:03:30 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 18 Oct 2021 16:03:30 GMT Subject: RFR: JDK-8275360: Use @Override in javax.annotation.processing [v2] In-Reply-To: References: Message-ID: > Simple cleanup to add @Override annotations to AbstractProcessor. IIRC when AbstractProcessor was added in JDK 6, using @Override wasn't yet support for interface methods. 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 two additional commits since the last revision: - Merge branch 'master' into JDK-8275360 - JDK-8275360: Use @Override in javax.annotation.processing ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5979/files - new: https://git.openjdk.java.net/jdk/pull/5979/files/9d4dbe7b..695a8fb1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5979&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5979&range=00-01 Stats: 472 lines in 32 files changed: 340 ins; 23 del; 109 mod Patch: https://git.openjdk.java.net/jdk/pull/5979.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5979/head:pull/5979 PR: https://git.openjdk.java.net/jdk/pull/5979 From darcy at openjdk.java.net Mon Oct 18 16:13:53 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 18 Oct 2021 16:13:53 GMT Subject: Integrated: JDK-8275360: Use @Override in javax.annotation.processing In-Reply-To: References: Message-ID: On Sun, 17 Oct 2021 18:43:38 GMT, Joe Darcy wrote: > Simple cleanup to add @Override annotations to AbstractProcessor. IIRC when AbstractProcessor was added in JDK 6, using @Override wasn't yet support for interface methods. This pull request has now been integrated. Changeset: 426bcee9 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/426bcee9274bb3ec7dce551f85adb2ab61c22481 Stats: 6 lines in 2 files changed: 5 ins; 1 del; 0 mod 8275360: Use @Override in javax.annotation.processing Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5979 From cushon at openjdk.java.net Mon Oct 18 16:45:53 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Mon, 18 Oct 2021 16:45:53 GMT Subject: RFR: JDK-8273914: Indy string concat changes order of operations [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 07:53:42 GMT, Aleksey Shipilev wrote: >> How about code like: >> >> StringBuilder builder2 = new StringBuilder("foo"); >> Object oo = builder2; >> oo += "" + builder2.append("bar"); >> >> >> Should that be covered as well? From looking at the patch (not really trying it), it does not seem to be covered? > >> ``` >> StringBuilder builder2 = new StringBuilder("foo"); >> Object oo = builder2; >> oo += "" + builder2.append("bar"); >> ``` >> >> Should that be covered as well? From looking at the patch (not really trying it), it does not seem to be covered? > > Tried it, still not correct: > > > $ cat Concat.java > public class Concat { > public static void main(String... args) { > StringBuilder builder2 = new StringBuilder("foo"); > Object oo = builder2; > oo += "" + builder2.append("bar"); > System.out.println(oo); > } > } > > $ build/linux-x86_64-server-fastdebug/images/jdk/bin/javac Concat.java > $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java Concat > foobarfoobar > > > I believe `if (shouldConvertToStringEagerly(argType))` branch should be handled for first argument as well, i.e. code should be shaped as: > > > if (!first || generateFirstArg) { > genExpr(arg, arg.type).load(); > } > if (shouldConvertToStringEagerly(argType)) { > gen.callMethod(pos, syms.stringType, names.valueOf, List.of(syms.objectType), true); > argType = syms.stringType; > } > dynamicArgs.add(argType); > > > This produces the correct result: > > > $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java Concat > foofoobar > > > @cushon, could you do this change and add a relevant test case? @shipilev this is also blocked on the CSR, I think the next step is for it to be 'reviewed by at least one engineer familiar with that technology area', is that something you'd be able to help with? https://bugs.openjdk.java.net/browse/JDK-8274863 ------------- PR: https://git.openjdk.java.net/jdk/pull/5844 From darcy at openjdk.java.net Tue Oct 19 05:01:50 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 19 Oct 2021 05:01:50 GMT Subject: RFR: 8272234: Pass originating elements from Filer to JavaFileManager [v2] In-Reply-To: <2_AI5aPHEPyZls9A8u2WN9XwmuDyXa3OTC4OO7OnZeI=.1e50d43f-ca3a-49bd-af6f-9a88e98bef61@github.com> References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> <2_AI5aPHEPyZls9A8u2WN9XwmuDyXa3OTC4OO7OnZeI=.1e50d43f-ca3a-49bd-af6f-9a88e98bef61@github.com> Message-ID: On Fri, 15 Oct 2021 20:02:54 GMT, Vicente Romero wrote: > > > I guess this one needs a CSR right? A CSR is needed and I'd happily advance a Proposed request to Provisional in its current form. ------------- PR: https://git.openjdk.java.net/jdk/pull/5076 From darcy at openjdk.java.net Tue Oct 19 05:01:54 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 19 Oct 2021 05:01:54 GMT Subject: RFR: 8272234: Pass originating elements from Filer to JavaFileManager [v2] In-Reply-To: References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> Message-ID: <8-qMX_a4j5tbcrL8jgvfi_MGc3TbWYF1Y0IfkwGsqVM=.08ed801d-4323-4f36-aa73-287feed4a783@github.com> On Fri, 15 Oct 2021 22:05:06 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Javadoc improvements. >> - Merge branch 'master' into ap-keep-originating-elements >> - Cleanup. >> - Improving testing >> - Updating @since >> - Merge branch 'master' into ap-keep-originating-elements >> - Another attempt to fix the test. >> - More attempts to fix the test. >> - Attempting to fix test. >> - Adding @since >> - ... and 6 more: https://git.openjdk.java.net/jdk/compare/4cb7124c...9396bbb4 > > src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java line 549: > >> 547: }) >> 548: .filter(fo -> fo != null) >> 549: .toArray(s -> new JavaFileObject[s]); > > @jddarcy this is an example of why it would be good to have an API method in the Language Model world to get the "source" from which an `Element` was obtained, where "source" means either a .class or a .java file ... in other words, the `Symbol.classfile` field accessed in this code. Acknowledged; it would be preferable if this mapping could be done in the standardized API. ------------- PR: https://git.openjdk.java.net/jdk/pull/5076 From jlahoda at openjdk.java.net Tue Oct 19 11:49:11 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 19 Oct 2021 11:49:11 GMT Subject: RFR: 8272234: Pass originating elements from Filer to JavaFileManager [v3] In-Reply-To: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> Message-ID: > This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files. > > Any feedback on this prototype would be welcome. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing javadoc. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5076/files - new: https://git.openjdk.java.net/jdk/pull/5076/files/9396bbb4..f871a30c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5076&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5076&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5076.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5076/head:pull/5076 PR: https://git.openjdk.java.net/jdk/pull/5076 From vromero at openjdk.java.net Tue Oct 19 13:52:13 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 19 Oct 2021 13:52:13 GMT Subject: RFR: 8275302: unexpected compiler error: cast, intersection types and sealed Message-ID: Please review this fix which is syncing the compiler with the sealed classes spec. Basically the compiler is failing to accept as valid a cast when the type to be cast is an intersection type, even when all the checks mandated by the spec has been done. TIA ------------- Commit messages: - 8275302: unexpected compiler error: cast, intersection types and sealed Changes: https://git.openjdk.java.net/jdk/pull/6009/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6009&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275302 Stats: 14 lines in 2 files changed: 13 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6009/head:pull/6009 PR: https://git.openjdk.java.net/jdk/pull/6009 From weijun at openjdk.java.net Tue Oct 19 14:01:11 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 19 Oct 2021 14:01:11 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 Message-ID: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. ------------- Commit messages: - 8275512: Upgrade required version of jtreg to 6.1 Changes: https://git.openjdk.java.net/jdk/pull/6012/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6012&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275512 Stats: 7 lines in 6 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6012.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6012/head:pull/6012 PR: https://git.openjdk.java.net/jdk/pull/6012 From ihse at openjdk.java.net Tue Oct 19 14:09:49 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Oct 2021 14:09:49 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 In-Reply-To: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: <1Lt3IpTy-rZBwrcdQpbCaw1mCBR42UyLd0JIn_55qJ4=.cf17c8d5-ee9d-4ad1-8f21-ff7a4e5eeacd@github.com> On Tue, 19 Oct 2021 13:51:45 GMT, Weijun Wang wrote: > As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. LGTM ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6012 From iignatyev at openjdk.java.net Tue Oct 19 15:44:51 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 19 Oct 2021 15:44:51 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 In-Reply-To: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 13:51:45 GMT, Weijun Wang wrote: > As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. LGTM ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6012 From jlahoda at openjdk.java.net Tue Oct 19 16:12:52 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 19 Oct 2021 16:12:52 GMT Subject: RFR: 8275302: unexpected compiler error: cast, intersection types and sealed In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 13:43:53 GMT, Vicente Romero wrote: > Please review this fix which is syncing the compiler with the sealed classes spec. Basically the compiler is failing to accept as valid a cast when the type to be cast is an intersection type, even when all the checks mandated by the spec has been done. > > TIA Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6009 From jlahoda at openjdk.java.net Tue Oct 19 16:43:16 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 19 Oct 2021 16:43:16 GMT Subject: RFR: 8272234: Pass originating elements from Filer to JavaFileManager [v4] In-Reply-To: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> Message-ID: <7caxkyMQL_e83wVN2CFEh9knvjYodRYk4PMd-XlHUDo=.4f19a9f9-bd44-44ed-8005-f3ab9a6a09c0@github.com> > This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files. > > Any feedback on this prototype would be welcome. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing typo, as per review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5076/files - new: https://git.openjdk.java.net/jdk/pull/5076/files/f871a30c..aa31c17a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5076&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5076&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5076.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5076/head:pull/5076 PR: https://git.openjdk.java.net/jdk/pull/5076 From vromero at openjdk.java.net Tue Oct 19 16:49:54 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 19 Oct 2021 16:49:54 GMT Subject: RFR: 8275302: unexpected compiler error: cast, intersection types and sealed In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 13:43:53 GMT, Vicente Romero wrote: > Please review this fix which is syncing the compiler with the sealed classes spec. Basically the compiler is failing to accept as valid a cast when the type to be cast is an intersection type, even when all the checks mandated by the spec has been done. > > TIA thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/6009 From vromero at openjdk.java.net Tue Oct 19 16:49:54 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 19 Oct 2021 16:49:54 GMT Subject: Integrated: 8275302: unexpected compiler error: cast, intersection types and sealed In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 13:43:53 GMT, Vicente Romero wrote: > Please review this fix which is syncing the compiler with the sealed classes spec. Basically the compiler is failing to accept as valid a cast when the type to be cast is an intersection type, even when all the checks mandated by the spec has been done. > > TIA This pull request has now been integrated. Changeset: fd10f199 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/fd10f1996ef94529b5b12e547957cd904ade1956 Stats: 14 lines in 2 files changed: 13 ins; 0 del; 1 mod 8275302: unexpected compiler error: cast, intersection types and sealed Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/6009 From weijun at openjdk.java.net Tue Oct 19 17:24:17 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 19 Oct 2021 17:24:17 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: > As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: upgrade the version in GHA config only in patch2: unchanged: ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6012/files - new: https://git.openjdk.java.net/jdk/pull/6012/files/b86e799c..f5ffc49b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6012&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6012&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6012.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6012/head:pull/6012 PR: https://git.openjdk.java.net/jdk/pull/6012 From joehw at openjdk.java.net Tue Oct 19 17:30:56 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 19 Oct 2021 17:30:56 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang wrote: >> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > upgrade the version in GHA config > > only in patch2: > unchanged: Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From lancea at openjdk.java.net Tue Oct 19 20:19:33 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 19 Oct 2021 20:19:33 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang wrote: >> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > upgrade the version in GHA config > > only in patch2: > unchanged: Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From vromero at openjdk.java.net Tue Oct 19 20:23:41 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 19 Oct 2021 20:23:41 GMT Subject: RFR: 8275242: Remove redundant stream() call before forEach in jdk.compiler [v2] In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 08:45:12 GMT, Andrey Turbanov wrote: >> There are several places in the jdk.compiler that use stream().forEach(...), these can be cleaned up. >> Instead Collection.forEach or Map.forEach can be used directly. >> This is continuation of >> 1. [JDK-8273710](https://bugs.openjdk.java.net/browse/JDK-8273710) Remove redundant stream() call before forEach in jdk.jdeps >> 2. [JDK-8273711](https://bugs.openjdk.java.net/browse/JDK-8273711) Remove redundant stream() call before forEach in jdk.jlink > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8275242: Remove redundant stream() call before forEach in jdk.compiler > expand start import looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5521 From vromero at openjdk.java.net Tue Oct 19 20:24:45 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 19 Oct 2021 20:24:45 GMT Subject: RFR: 8272234: Pass originating elements from Filer to JavaFileManager [v4] In-Reply-To: <7caxkyMQL_e83wVN2CFEh9knvjYodRYk4PMd-XlHUDo=.4f19a9f9-bd44-44ed-8005-f3ab9a6a09c0@github.com> References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> <7caxkyMQL_e83wVN2CFEh9knvjYodRYk4PMd-XlHUDo=.4f19a9f9-bd44-44ed-8005-f3ab9a6a09c0@github.com> Message-ID: On Tue, 19 Oct 2021 16:43:16 GMT, Jan Lahoda wrote: >> This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files. >> >> Any feedback on this prototype would be welcome. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing typo, as per review comments. I made some minor edits to the CSR and added myself as reviewer ------------- PR: https://git.openjdk.java.net/jdk/pull/5076 From jjg at openjdk.java.net Tue Oct 19 20:45:40 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 19 Oct 2021 20:45:40 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang wrote: >> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > upgrade the version in GHA config > > only in patch2: > unchanged: Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From mchung at openjdk.java.net Tue Oct 19 20:54:09 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 19 Oct 2021 20:54:09 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang wrote: >> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > upgrade the version in GHA config > > only in patch2: > unchanged: Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From weijun at openjdk.java.net Tue Oct 19 21:09:22 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 19 Oct 2021 21:09:22 GMT Subject: Integrated: 8275512: Upgrade required version of jtreg to 6.1 In-Reply-To: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 13:51:45 GMT, Weijun Wang wrote: > As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. This pull request has now been integrated. Changeset: c24fb852 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/c24fb852f20bf0fc2817dfed52ff1609a5bced59 Stats: 8 lines in 7 files changed: 0 ins; 0 del; 8 mod 8275512: Upgrade required version of jtreg to 6.1 Reviewed-by: ihse, iignatyev, joehw, lancea, jjg, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From darcy at openjdk.java.net Tue Oct 19 22:16:32 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 19 Oct 2021 22:16:32 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v25] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 80 commits: - Merge branch 'master' into JDK-8202056 - Do not warn for prence of serialVersionUID in interfaces. - Sharpen type of method parameters to javac type. - Merge branch 'master' into JDK-8202056 - Add support for warning on component type of an array. - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Initial library updates for array component type check. - Improve declared types to remove cast. - ... and 70 more: https://git.openjdk.java.net/jdk/compare/c24fb852...4750141d ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=24 Stats: 2009 lines in 48 files changed: 1939 ins; 54 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Wed Oct 20 06:15:41 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 20 Oct 2021 06:15:41 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v3] In-Reply-To: References: Message-ID: <1nbt9ae0FrEPifrgzUbuxMEDR9GT3o2hiGLUjTl4Qbc=.44960153-27a6-4c3b-bc97-66771b4fa35a@github.com> > I wanted to get input on the design of API of the method before writing the tests. > > The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. > > Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. > > Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. > > CSR to follow once the API is nailed down. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Add support for reverse conversion. - Merge branch 'master' into JDK-8275308 - Fix typo. - JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersio ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5973/files - new: https://git.openjdk.java.net/jdk/pull/5973/files/bf3e4dff..2062fd43 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=01-02 Stats: 11474 lines in 190 files changed: 9959 ins; 1091 del; 424 mod Patch: https://git.openjdk.java.net/jdk/pull/5973.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5973/head:pull/5973 PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Wed Oct 20 06:15:43 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 20 Oct 2021 06:15:43 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v2] In-Reply-To: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> References: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> Message-ID: <4zo_VlFL5t7lQWBYpIQhaWO8CLM0qriPWcmgiEGA3Oo=.c9ee993a-54e2-48fd-a5e9-103403e41eb9@github.com> On Sat, 16 Oct 2021 00:02:08 GMT, Joe Darcy wrote: >> I wanted to get input on the design of API of the method before writing the tests. >> >> The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. >> >> Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. >> >> Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. >> >> CSR to follow once the API is nailed down. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo. In the latest push, stubbed in support for the reverse mapping from SourceVersion to a runtime version. For now, limiting the mapping to RELEASE_9 and higher since Runtime.Version was added in 9. ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From lzhai at openjdk.java.net Wed Oct 20 09:31:10 2021 From: lzhai at openjdk.java.net (Leslie Zhai) Date: Wed, 20 Oct 2021 09:31:10 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang wrote: >> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > upgrade the version in GHA config > > only in patch2: > unchanged: Hi @wangweij But how to be suitable for jtreg version 6-dev+0? Running tests using JTREG control variable 'VM_OPTIONS=-XX:+UseZGC;TIMEOUT_FACTOR=20;VERBOSE=summary' Test selection 'tier1', will run: * jtreg:test/hotspot/jtreg:tier1 * jtreg:test/jdk:tier1 * jtreg:test/langtools:tier1 * jtreg:test/jaxp:tier1 * jtreg:test/lib-test:tier1 Running test 'jtreg:test/hotspot/jtreg:tier1' Error: The testsuite at /var/lib/jenkins/repos/openjdk/jdk/test/hotspot/jtreg requires jtreg version 6.1 b1 or higher and this is jtreg version 6-dev+0. Thanks, Leslie Zhai ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From ihse at openjdk.java.net Wed Oct 20 10:33:12 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 20 Oct 2021 10:33:12 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: <3fR1ogAG0CXuhf9_gJZrD-GGi9RqG_lP5bGD7fd_GPY=.2ed9d3b9-3b80-4300-a90f-6d5fe954d945@github.com> On Wed, 20 Oct 2021 09:28:30 GMT, Leslie Zhai wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> upgrade the version in GHA config >> >> only in patch2: >> unchanged: > > Hi @wangweij > > But how to be suitable for jtreg version 6-dev+0? > > > Running tests using JTREG control variable 'VM_OPTIONS=-XX:+UseZGC;TIMEOUT_FACTOR=20;VERBOSE=summary' > Test selection 'tier1', will run: > * jtreg:test/hotspot/jtreg:tier1 > * jtreg:test/jdk:tier1 > * jtreg:test/langtools:tier1 > * jtreg:test/jaxp:tier1 > * jtreg:test/lib-test:tier1 > > Running test 'jtreg:test/hotspot/jtreg:tier1' > Error: The testsuite at /var/lib/jenkins/repos/openjdk/jdk/test/hotspot/jtreg requires jtreg version 6.1 b1 or higher and this is jtreg version 6-dev+0. > > > Thanks, > Leslie Zhai @xiangzhai The entire point of this PR is to *not* allow jtreg 6.0. You need to upgrade your local jtreg installation to 6.1. ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From jlahoda at openjdk.java.net Wed Oct 20 12:59:14 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 20 Oct 2021 12:59:14 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v25] In-Reply-To: References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: On Tue, 19 Oct 2021 22:16:32 GMT, Joe Darcy wrote: >> This is an initial PR for expanded lint warnings done under two bugs: >> >> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields >> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type >> >> to get feedback on the general approach and test strategy before further polishing the implementation. >> >> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. >> >> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. >> >> Please also review the corresponding CSRs: >> >> https://bugs.openjdk.java.net/browse/JDK-8274335 >> https://bugs.openjdk.java.net/browse/JDK-8274336 >> >> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. >> >> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. >> >> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 80 commits: > > - Merge branch 'master' into JDK-8202056 > - Do not warn for prence of serialVersionUID in interfaces. > - Sharpen type of method parameters to javac type. > - Merge branch 'master' into JDK-8202056 > - Add support for warning on component type of an array. > - Merge branch 'master' into JDK-8202056 > - Merge branch 'master' into JDK-8202056 > - Merge branch 'master' into JDK-8202056 > - Initial library updates for array component type check. > - Improve declared types to remove cast. > - ... and 70 more: https://git.openjdk.java.net/jdk/compare/c24fb852...4750141d Looks reasonable to me. Left a few comments inline. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 32: > 30: > 31: import javax.lang.model.element.ElementKind; > 32: import javax.lang.model.element.Element; Nit: these new imports are probably unused. test/langtools/tools/javac/warnings/Serial/ImproperSerialPF.java line 12: > 10: // Proper declaration of serialPersistentFields is: > 11: // private static final ObjectStreamField[] serialPersistentFields = ... > 12: public /*instance*/ Object serialPersistentFields = Boolean.TRUE; It might make sense to have tests that would verify every check made for the field - i.e. taking a field named "serialPersistentFields", which should be (I guess) `private`, `static`, `final`, and have type `ObjectStreamField[]`, and have a series of fields that fulfill all these properties except one, and verify the warning is produced. The test could be a some sort of a combo test, or not, that is less important, I think. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5709 From vromero at openjdk.java.net Wed Oct 20 18:53:13 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 20 Oct 2021 18:53:13 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v25] In-Reply-To: References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: On Tue, 19 Oct 2021 22:16:32 GMT, Joe Darcy wrote: >> This is an initial PR for expanded lint warnings done under two bugs: >> >> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields >> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type >> >> to get feedback on the general approach and test strategy before further polishing the implementation. >> >> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. >> >> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. >> >> Please also review the corresponding CSRs: >> >> https://bugs.openjdk.java.net/browse/JDK-8274335 >> https://bugs.openjdk.java.net/browse/JDK-8274336 >> >> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. >> >> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. >> >> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 80 commits: > > - Merge branch 'master' into JDK-8202056 > - Do not warn for prence of serialVersionUID in interfaces. > - Sharpen type of method parameters to javac type. > - Merge branch 'master' into JDK-8202056 > - Add support for warning on component type of an array. > - Merge branch 'master' into JDK-8202056 > - Merge branch 'master' into JDK-8202056 > - Merge branch 'master' into JDK-8202056 > - Initial library updates for array component type check. > - Improve declared types to remove cast. > - ... and 70 more: https://git.openjdk.java.net/jdk/compare/c24fb852...4750141d looks good to me ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Thu Oct 21 00:46:24 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 21 Oct 2021 00:46:24 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v26] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits: - Merge branch 'master' into JDK-8202056 - Improve use of @SuppressWarnings. - Clean up imports. - Merge branch 'master' into JDK-8202056 - Do not warn for prence of serialVersionUID in interfaces. - Sharpen type of method parameters to javac type. - Merge branch 'master' into JDK-8202056 - Add support for warning on component type of an array. - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - ... and 73 more: https://git.openjdk.java.net/jdk/compare/cea3f010...91a71f08 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=25 Stats: 1995 lines in 48 files changed: 1928 ins; 54 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Thu Oct 21 01:14:11 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 21 Oct 2021 01:14:11 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v25] In-Reply-To: References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: On Wed, 20 Oct 2021 12:30:33 GMT, Jan Lahoda wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 80 commits: >> >> - Merge branch 'master' into JDK-8202056 >> - Do not warn for prence of serialVersionUID in interfaces. >> - Sharpen type of method parameters to javac type. >> - Merge branch 'master' into JDK-8202056 >> - Add support for warning on component type of an array. >> - Merge branch 'master' into JDK-8202056 >> - Merge branch 'master' into JDK-8202056 >> - Merge branch 'master' into JDK-8202056 >> - Initial library updates for array component type check. >> - Improve declared types to remove cast. >> - ... and 70 more: https://git.openjdk.java.net/jdk/compare/c24fb852...4750141d > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 32: > >> 30: >> 31: import javax.lang.model.element.ElementKind; >> 32: import javax.lang.model.element.Element; > > Nit: these new imports are probably unused. Cleaned up imports in subsequent push; thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Thu Oct 21 15:58:31 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 21 Oct 2021 15:58:31 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v27] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 84 commits: - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Improve use of @SuppressWarnings. - Clean up imports. - Merge branch 'master' into JDK-8202056 - Do not warn for prence of serialVersionUID in interfaces. - Sharpen type of method parameters to javac type. - Merge branch 'master' into JDK-8202056 - Add support for warning on component type of an array. - Merge branch 'master' into JDK-8202056 - ... and 74 more: https://git.openjdk.java.net/jdk/compare/af146501...9e592a63 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=26 Stats: 1991 lines in 46 files changed: 1924 ins; 54 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From itakiguchi at openjdk.java.net Thu Oct 21 16:24:03 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Thu, 21 Oct 2021 16:24:03 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v3] In-Reply-To: <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com> References: <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com> Message-ID: On Tue, 19 Oct 2021 01:26:35 GMT, Jonathan Gibbons wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274544: Langtools command's usage were garbled on Japanese Windows > > This is pretty ugly code to be replicating so many times. > > What if the tools have been run in an environment where `System.out` and `System.err` have already been redirected in some manner, with `System.setOut` or `System.setErr`? You should not assume that `System.out` and `System.err` will always refer to the console. @jonathan-gibbons I appreciate your comment. I'd like to confirm something. > This is pretty ugly code to be replicating so many times. > What if the tools have been run in an environment where `System.out` and `System.err` have already been redirected in some manner, with `System.setOut` or `System.setErr`? You should not assume that `System.out` and `System.err` will always refer to the console. I was confused since the fixed code did not call System.out/System.err directly. I tried following code on Japanese Windows. import java.io.*; import java.nio.charset.*; public class OutputCheck { public static void main(String[] args) throws Exception { String s = "\u3042"; System.out.println("[1]:"+s); PrintStream ps = System.out; System.setOut(new PrintStream(System.out)); System.out.println("[2]:"+s); ps.println("[3]:"+s); System.setOut(new PrintStream(System.out, true, Charset.forName(System.getProperty("native.encoding")))); System.out.println("[4]:"+s); } } Output is: > jdk-18-b14\bin\java OutputCheck.java [1]:? [2]:?? [3]:? [4]:? [2] refers default charset (UTF-8) [3] is same as [1] [4] specifies native.encoding system encoding Could you explain more detail ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From darcy at openjdk.java.net Thu Oct 21 19:35:22 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 21 Oct 2021 19:35:22 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v25] In-Reply-To: References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: On Wed, 20 Oct 2021 12:29:43 GMT, Jan Lahoda wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 80 commits: >> >> - Merge branch 'master' into JDK-8202056 >> - Do not warn for prence of serialVersionUID in interfaces. >> - Sharpen type of method parameters to javac type. >> - Merge branch 'master' into JDK-8202056 >> - Add support for warning on component type of an array. >> - Merge branch 'master' into JDK-8202056 >> - Merge branch 'master' into JDK-8202056 >> - Merge branch 'master' into JDK-8202056 >> - Initial library updates for array component type check. >> - Improve declared types to remove cast. >> - ... and 70 more: https://git.openjdk.java.net/jdk/compare/c24fb852...4750141d > > test/langtools/tools/javac/warnings/Serial/ImproperSerialPF.java line 12: > >> 10: // Proper declaration of serialPersistentFields is: >> 11: // private static final ObjectStreamField[] serialPersistentFields = ... >> 12: public /*instance*/ Object serialPersistentFields = Boolean.TRUE; > > It might make sense to have tests that would verify every check made for the field - i.e. taking a field named "serialPersistentFields", which should be (I guess) `private`, `static`, `final`, and have type `ObjectStreamField[]`, and have a series of fields that fulfill all these properties except one, and verify the warning is produced. The test could be a some sort of a combo test, or not, that is less important, I think. Acknowledged; this consider this for a future refinement. ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Thu Oct 21 19:59:33 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 21 Oct 2021 19:59:33 GMT Subject: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields [v28] In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: - Merge branch 'master' into JDK-8202056 - Update copyrights; small cleanup. - Merge branch 'master' into JDK-8202056 - Merge branch 'master' into JDK-8202056 - Improve use of @SuppressWarnings. - Clean up imports. - Merge branch 'master' into JDK-8202056 - Do not warn for prence of serialVersionUID in interfaces. - Sharpen type of method parameters to javac type. - Merge branch 'master' into JDK-8202056 - ... and 76 more: https://git.openjdk.java.net/jdk/compare/0961de47...9e5c7533 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=27 Stats: 1982 lines in 46 files changed: 1912 ins; 54 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709 PR: https://git.openjdk.java.net/jdk/pull/5709 From darcy at openjdk.java.net Thu Oct 21 21:14:13 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 21 Oct 2021 21:14:13 GMT Subject: Integrated: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com> Message-ID: On Mon, 27 Sep 2021 01:00:18 GMT, Joe Darcy wrote: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields > 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type > > to get feedback on the general approach and test strategy before further polishing the implementation. > > The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing. > > Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused. > > Please also review the corresponding CSRs: > > https://bugs.openjdk.java.net/browse/JDK-8274335 > https://bugs.openjdk.java.net/browse/JDK-8274336 > > Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056. > > The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check. > > In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before. This pull request has now been integrated. Changeset: 6a466fe7 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/6a466fe7ae281967d1cc4c8029b306f2d66567c9 Stats: 1982 lines in 46 files changed: 1912 ins; 54 del; 16 mod 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type Reviewed-by: erikj, sspitsyn, jlahoda, vromero, rriggs, smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/5709 From jjg at openjdk.java.net Fri Oct 22 00:03:07 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 22 Oct 2021 00:03:07 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v3] In-Reply-To: <1nbt9ae0FrEPifrgzUbuxMEDR9GT3o2hiGLUjTl4Qbc=.44960153-27a6-4c3b-bc97-66771b4fa35a@github.com> References: <1nbt9ae0FrEPifrgzUbuxMEDR9GT3o2hiGLUjTl4Qbc=.44960153-27a6-4c3b-bc97-66771b4fa35a@github.com> Message-ID: On Wed, 20 Oct 2021 06:15:41 GMT, Joe Darcy wrote: >> I wanted to get input on the design of API of the method before writing the tests. >> >> The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. >> >> Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. >> >> Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. >> >> CSR to follow once the API is nailed down. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Add support for reverse conversion. > - Merge branch 'master' into JDK-8275308 > - Fix typo. > - JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersio src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 525: > 523: if (feature > Runtime.version().feature()) { > 524: throw new IllegalArgumentException("No matching SourceVersion for " + rv); > 525: } else { Using `Runtime.version()` as a stand-in for the max `SourceVersion` seems non-obvious. Would it be better to use `SourceVersion.latest().runtimeVersion()` instead? What about when running this API on JDK N-1? ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From hannesw at openjdk.java.net Fri Oct 22 07:57:06 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 22 Oct 2021 07:57:06 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v2] In-Reply-To: <4zo_VlFL5t7lQWBYpIQhaWO8CLM0qriPWcmgiEGA3Oo=.c9ee993a-54e2-48fd-a5e9-103403e41eb9@github.com> References: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> <4zo_VlFL5t7lQWBYpIQhaWO8CLM0qriPWcmgiEGA3Oo=.c9ee993a-54e2-48fd-a5e9-103403e41eb9@github.com> Message-ID: On Wed, 20 Oct 2021 06:12:12 GMT, Joe Darcy wrote: > In the latest push, stubbed in support for the reverse mapping from SourceVersion to a runtime version. For now, limiting the mapping to RELEASE_9 and higher since Runtime.Version was added in 9. Thanks for adding the reverse mapping! Is there a problem with Source.Version representing a version earlier than 9, other than that it was added in that release? Supporting earlier versions would be very useful for javadoc, where we support versions starting from 7. ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From duke at openjdk.java.net Sat Oct 23 04:09:07 2021 From: duke at openjdk.java.net (Michael Bien) Date: Sat, 23 Oct 2021 04:09:07 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v3] In-Reply-To: References: <1nbt9ae0FrEPifrgzUbuxMEDR9GT3o2hiGLUjTl4Qbc=.44960153-27a6-4c3b-bc97-66771b4fa35a@github.com> Message-ID: <7RbSC49wUH6TZeKBAp06elQ9uUXoyUuFGvRY6nLnVw0=.e5c1fdef-3b3c-4c15-b1ac-5d2f79fa6bd8@github.com> On Thu, 21 Oct 2021 23:58:45 GMT, Jonathan Gibbons wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Add support for reverse conversion. >> - Merge branch 'master' into JDK-8275308 >> - Fix typo. >> - JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersio > > src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 525: > >> 523: if (feature > Runtime.version().feature()) { >> 524: throw new IllegalArgumentException("No matching SourceVersion for " + rv); >> 525: } else { > > Using `Runtime.version()` as a stand-in for the max `SourceVersion` seems non-obvious. Would it be better to use `SourceVersion.latest().runtimeVersion()` instead? > > What about when running this API on JDK N-1? if could be potentially dropped since valueOf("RELEASE_" + feature) is throwing IAE already. ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From duke at openjdk.java.net Sat Oct 23 06:39:10 2021 From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Sat, 23 Oct 2021 06:39:10 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2] In-Reply-To: References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Wed, 20 Oct 2021 09:28:30 GMT, Leslie Zhai wrote: > requires jtreg version 6.1 b1 or higher This confused me a bit too; I was using jtreg-6+1.tar.gz from [Adoption Group build](https://ci.adoptopenjdk.net/view/Dependencies/job/dependency_pipeline/lastSuccessfulBuild/artifact/jtreg/), and apparently 6+1 is 6.0b1, not 6.1. For now I'm using jtregtip. ------------- PR: https://git.openjdk.java.net/jdk/pull/6012 From jpai at openjdk.java.net Sun Oct 24 04:23:03 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 24 Oct 2021 04:23:03 GMT Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time [v2] In-Reply-To: References: Message-ID: <78qG2XrUpzrdHfPMiPTFcN4szYF2F9ilg7maRbARGhM=.a079ec7c-9700-4d0b-a7e5-eee374cc4f62@github.com> On Fri, 17 Sep 2021 12:54:07 GMT, Jaikiran Pai wrote: >> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117. >> >> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor. >> >> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here: >> >> 1. When creating a jar (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. >> >> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases. >> >> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge latest from master branch > - 8258117: jar tool sets the time stamp of module-info.class entries to the current time Keep alive. ------------- PR: https://git.openjdk.java.net/jdk/pull/5486 From sundar at openjdk.java.net Mon Oct 25 08:53:04 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 25 Oct 2021 08:53:04 GMT Subject: RFR: 8272728: javac ignores any -J option in @argfiles silently In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:20:02 GMT, Christian Stein wrote: > Make javac error on `-J` being present in `@argfiles` or other locations, where the launcher didn't process and remove them. test/langtools/tools/javac/options/modes/AtFilesTest.java line 75: > 73: .checkResult(Main.Result.CMDERR.exitCode) > 74: .checkLog(Log.DIRECT, "-J-verbose"); > 75: } Should we add a test that for invalid option as well? -J-non_existent_option ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5891 From cstein at openjdk.java.net Mon Oct 25 09:05:11 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 25 Oct 2021 09:05:11 GMT Subject: RFR: 8272728: javac ignores any -J option in @argfiles silently In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 08:50:03 GMT, Athijegannathan Sundararajan wrote: >> Make javac error on `-J` being present in `@argfiles` or other locations, where the launcher didn't process and remove them. > > test/langtools/tools/javac/options/modes/AtFilesTest.java line 75: > >> 73: .checkResult(Main.Result.CMDERR.exitCode) >> 74: .checkLog(Log.DIRECT, "-J-verbose"); >> 75: } > > Should we add a test that for invalid option as well? -J-non_existent_option ? In order to ensure that valid and invalid values passed to `-J` are detected? If yes, then it does not add much to the already tested behaviour: all occurances of `-J` (with valid and invalid values) within an AtFile are now reported as an error. The tests for valid values are performed at launcher-level (I hope). ------------- PR: https://git.openjdk.java.net/jdk/pull/5891 From cstein at openjdk.java.net Mon Oct 25 11:00:12 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 25 Oct 2021 11:00:12 GMT Subject: RFR: 8272728: javac ignores any -J option in @argfiles silently In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 09:02:30 GMT, Christian Stein wrote: >> test/langtools/tools/javac/options/modes/AtFilesTest.java line 75: >> >>> 73: .checkResult(Main.Result.CMDERR.exitCode) >>> 74: .checkLog(Log.DIRECT, "-J-verbose"); >>> 75: } >> >> Should we add a test that for invalid option as well? -J-non_existent_option ? > > In order to ensure that valid and invalid values passed to `-J` are detected? > > If yes, then it does not add much to the already tested behaviour: all occurances of `-J` (with valid and invalid values) within an AtFile are now reported as an error. The tests for valid values are performed at launcher-level (I hope). A test variant for an invalid argument would almost look like the one for the valid argument: @Test void testAtFilesMustNotContainOptionJ() throws IOException { writeFile("args", "-J-non_existent_option"); String[] opts = { "@args", "-version" }; String[] files = { }; runMain(opts, files) .checkResult(Main.Result.CMDERR.exitCode) .checkLog(Log.DIRECT, "-J-non_existent_option"); } ------------- PR: https://git.openjdk.java.net/jdk/pull/5891 From itakiguchi at openjdk.java.net Mon Oct 25 14:20:52 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 25 Oct 2021 14:20:52 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v4] In-Reply-To: References: Message-ID: > JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. > After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. > These commands use PrintWriter instead of standard out/err with PrintStream. Ichiroh Takiguchi 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: - 8274544: Langtools command's usage were garbled on Japanese Windows - 8274544: Langtools command's usage were garbled on Japanese Windows - 8274544: Langtools command's usage were garbled on Japanese Windows - Langtools command's usage were grabled on Japanese Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5771/files - new: https://git.openjdk.java.net/jdk/pull/5771/files/4427d87c..e2a87848 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=02-03 Stats: 35926 lines in 1051 files changed: 24201 ins; 7865 del; 3860 mod Patch: https://git.openjdk.java.net/jdk/pull/5771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771 PR: https://git.openjdk.java.net/jdk/pull/5771 From darcy at openjdk.java.net Mon Oct 25 15:50:28 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 25 Oct 2021 15:50:28 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v4] In-Reply-To: References: Message-ID: > I wanted to get input on the design of API of the method before writing the tests. > > The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. > > Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. > > Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. > > CSR to follow once the API is nailed down. 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 seven additional commits since the last revision: - Appease jcheck. - Initial test support. - Merge branch 'master' into JDK-8275308 - Add support for reverse conversion. - Merge branch 'master' into JDK-8275308 - Fix typo. - JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersio ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5973/files - new: https://git.openjdk.java.net/jdk/pull/5973/files/2062fd43..091e268b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=02-03 Stats: 8405 lines in 264 files changed: 6472 ins; 1205 del; 728 mod Patch: https://git.openjdk.java.net/jdk/pull/5973.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5973/head:pull/5973 PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Mon Oct 25 15:50:28 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 25 Oct 2021 15:50:28 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v2] In-Reply-To: References: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> <4zo_VlFL5t7lQWBYpIQhaWO8CLM0qriPWcmgiEGA3Oo=.c9ee993a-54e2-48fd-a5e9-103403e41eb9@github.com> Message-ID: On Fri, 22 Oct 2021 07:53:44 GMT, Hannes Walln?fer wrote: > > > > In the latest push, stubbed in support for the reverse mapping from SourceVersion to a runtime version. For now, limiting the mapping to RELEASE_9 and higher since Runtime.Version was added in 9. > > Thanks for adding the reverse mapping! Is there a problem with Source.Version representing a version earlier than 9, other than that it was added in that release? Supporting earlier versions would be very useful for javadoc, where we support versions starting from 7. Added support back to 6, the release the javax.lang.model API was added. Strictly speaking release 6, 7, and 7 aren't modeled by Runtime.Version, but just using the feature value can be reasonable. I don't think it is worthwhile to formally map, for instance, RELEASE_5 to something like RuntimeVersion.parse("5.0") or RuntimeVersion.parse("5.0.0") to try to model the versioning scheme used then. ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From itakiguchi at openjdk.java.net Mon Oct 25 16:04:13 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 25 Oct 2021 16:04:13 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v4] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 14:20:52 GMT, Ichiroh Takiguchi wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > Ichiroh Takiguchi 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: > > - 8274544: Langtools command's usage were garbled on Japanese Windows > - 8274544: Langtools command's usage were garbled on Japanese Windows > - 8274544: Langtools command's usage were garbled on Japanese Windows > - Langtools command's usage were grabled on Japanese Windows Terminal setting $ locale LANG=ja_JP.eucjp LC_CTYPE="ja_JP.eucjp" LC_NUMERIC="ja_JP.eucjp" LC_TIME="ja_JP.eucjp" LC_COLLATE="ja_JP.eucjp" LC_MONETARY="ja_JP.eucjp" LC_MESSAGES="ja_JP.eucjp" LC_PAPER="ja_JP.eucjp" LC_NAME="ja_JP.eucjp" LC_ADDRESS="ja_JP.eucjp" LC_TELEPHONE="ja_JP.eucjp" LC_MEASUREMENT="ja_JP.eucjp" LC_IDENTIFICATION="ja_JP.eucjp" LC_ALL= Java testcase by using Scanner. $ cat scan.java import java.util.*; public class scan { public static void main(String[] args) throws Exception { System.out.println("Please input some characters:"); Scanner scanner = new Scanner(System.in); System.out.println(scanner.next()); } } $ ~/jdk-18-b19/bin/java scan.java Please input some characters: ????? ?????????? When `src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractTerminal.java` is modified $ jshell | JShell????? -- ?????18-internal | ??????????????????: /help intro jshell> import java.nio.charset.* jshell> System.out.println(System.getProperty("native.encoding")) EUC-JP-LINUX jshell> System.out.println(Charset.defaultCharset()) UTF-8 jshell> var scan = new Scanner(System.in) scan ==> java.util.Scanner[delimiters=\p{javaWhitespace}+] ... \E][infinity string=\Q?\E] jshell> var s = scan.next() ????? s ==> "?????" jshell> System.out.println(s) ????? jshell> /exit | ????? $ ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From darcy at openjdk.java.net Mon Oct 25 22:01:45 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 25 Oct 2021 22:01:45 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v5] In-Reply-To: References: Message-ID: > I wanted to get input on the design of API of the method before writing the tests. > > The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. > > Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. > > Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. > > CSR to follow once the API is nailed down. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5973/files - new: https://git.openjdk.java.net/jdk/pull/5973/files/091e268b..63c18475 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=03-04 Stats: 48 lines in 2 files changed: 29 ins; 5 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/5973.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5973/head:pull/5973 PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Mon Oct 25 22:01:47 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 25 Oct 2021 22:01:47 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v2] In-Reply-To: References: <1wiz2EcAOLQjj8d7B-56vBIxFZYByvs8Cdq8qbJVWjw=.6b473f16-c82b-4f59-b198-86c0cbdb3845@github.com> <4zo_VlFL5t7lQWBYpIQhaWO8CLM0qriPWcmgiEGA3Oo=.c9ee993a-54e2-48fd-a5e9-103403e41eb9@github.com> Message-ID: On Mon, 25 Oct 2021 15:46:56 GMT, Joe Darcy wrote: > > > > In the latest push, stubbed in support for the reverse mapping from SourceVersion to a runtime version. For now, limiting the mapping to RELEASE_9 and higher since Runtime.Version was added in 9. > > Thanks for adding the reverse mapping! Is there a problem with Source.Version representing a version earlier than 9, other than that it was added in that release? Supporting earlier versions would be very useful for javadoc, where we support versions starting from 7. Changed to RELEASE 6 and later in the latest push; the javax.lang.model API was added in JDK 6. ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Mon Oct 25 22:01:50 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 25 Oct 2021 22:01:50 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v3] In-Reply-To: <7RbSC49wUH6TZeKBAp06elQ9uUXoyUuFGvRY6nLnVw0=.e5c1fdef-3b3c-4c15-b1ac-5d2f79fa6bd8@github.com> References: <1nbt9ae0FrEPifrgzUbuxMEDR9GT3o2hiGLUjTl4Qbc=.44960153-27a6-4c3b-bc97-66771b4fa35a@github.com> <7RbSC49wUH6TZeKBAp06elQ9uUXoyUuFGvRY6nLnVw0=.e5c1fdef-3b3c-4c15-b1ac-5d2f79fa6bd8@github.com> Message-ID: On Sat, 23 Oct 2021 04:06:08 GMT, Michael Bien wrote: >> src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 525: >> >>> 523: if (feature > Runtime.version().feature()) { >>> 524: throw new IllegalArgumentException("No matching SourceVersion for " + rv); >>> 525: } else { >> >> Using `Runtime.version()` as a stand-in for the max `SourceVersion` seems non-obvious. Would it be better to use `SourceVersion.latest().runtimeVersion()` instead? >> >> What about when running this API on JDK N-1? > > if could be potentially dropped since valueOf("RELEASE_" + feature) is throwing IAE already. Updated as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From duke at openjdk.java.net Mon Oct 25 22:14:10 2021 From: duke at openjdk.java.net (Michael Bien) Date: Mon, 25 Oct 2021 22:14:10 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v5] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 22:01:45 GMT, Joe Darcy wrote: >> I wanted to get input on the design of API of the method before writing the tests. >> >> The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. >> >> Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. >> >> Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. >> >> CSR to follow once the API is nailed down. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. would the doc need `@since 18` tags? ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Mon Oct 25 22:18:15 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 25 Oct 2021 22:18:15 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v5] In-Reply-To: References: Message-ID: <_tUWJ32SohYqh3Pp6-DEQiUopxT9HB0GH6eaGdk6jDk=.e7d1a0af-f2c3-4e42-83ff-4c53772dc732@github.com> On Mon, 25 Oct 2021 22:01:45 GMT, Joe Darcy wrote: >> I wanted to get input on the design of API of the method before writing the tests. >> >> The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. >> >> Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. >> >> Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. >> >> CSR to follow once the API is nailed down. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. CSR now available for review: https://bugs.openjdk.java.net/browse/JDK-8275888 ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Mon Oct 25 22:28:44 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 25 Oct 2021 22:28:44 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v6] In-Reply-To: References: Message-ID: > I wanted to get input on the design of API of the method before writing the tests. > > The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. > > Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. > > Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. > > CSR to follow once the API is nailed down. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add @since tags. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5973/files - new: https://git.openjdk.java.net/jdk/pull/5973/files/63c18475..4517e54e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=04-05 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5973.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5973/head:pull/5973 PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Mon Oct 25 22:28:46 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 25 Oct 2021 22:28:46 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v5] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 22:11:02 GMT, Michael Bien wrote: > > > would the doc need `@since 18` tags? Sure; added. ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Wed Oct 27 04:53:43 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 27 Oct 2021 04:53:43 GMT Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v3] In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com> References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com> Message-ID: <7nvpo0zJqStgfMEI0b4yltVJTOlYScAkAHHsdwBB-jM=.f1083b32-5a44-49a7-a46c-1f4d26deeb72@github.com> > Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type. 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: - Merge branch 'master' into JDK-8224922 - Merge branch 'master' into JDK-8224922 - 8224922: Access JavaFileObject from Element(s) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5038/files - new: https://git.openjdk.java.net/jdk/pull/5038/files/e2acf39d..a9a4f367 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=01-02 Stats: 112288 lines in 3199 files changed: 76661 ins; 20685 del; 14942 mod Patch: https://git.openjdk.java.net/jdk/pull/5038.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038 PR: https://git.openjdk.java.net/jdk/pull/5038 From darcy at openjdk.java.net Wed Oct 27 14:10:11 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 27 Oct 2021 14:10:11 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v6] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 22:28:44 GMT, Joe Darcy wrote: >> I wanted to get input on the design of API of the method before writing the tests. >> >> The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. >> >> Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. >> >> Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. >> >> CSR to follow once the API is nailed down. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add @since tags. Any more comments on this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Wed Oct 27 16:52:11 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 27 Oct 2021 16:52:11 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v3] In-Reply-To: References: <1nbt9ae0FrEPifrgzUbuxMEDR9GT3o2hiGLUjTl4Qbc=.44960153-27a6-4c3b-bc97-66771b4fa35a@github.com> <7RbSC49wUH6TZeKBAp06elQ9uUXoyUuFGvRY6nLnVw0=.e5c1fdef-3b3c-4c15-b1ac-5d2f79fa6bd8@github.com> Message-ID: <2EMdzvD7tge_vv9hmb07CZGrrO6l3xa7VtN7HH2ny84=.04aa93b9-e578-4e62-9004-670983761fc9@github.com> On Mon, 25 Oct 2021 21:58:01 GMT, Joe Darcy wrote: >> if could be potentially dropped since valueOf("RELEASE_" + feature) is throwing IAE already. > > Updated as suggested. > > > Using `Runtime.version()` as a stand-in for the max `SourceVersion` seems non-obvious. Would it be better to use `SourceVersion.latest().runtimeVersion()` instead? > > What about when running this API on JDK N-1? Updated the supported range to go up to the feature corresponding to SourceVersion.latest(). ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From jjg at openjdk.java.net Wed Oct 27 17:09:19 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 27 Oct 2021 17:09:19 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v3] In-Reply-To: <2EMdzvD7tge_vv9hmb07CZGrrO6l3xa7VtN7HH2ny84=.04aa93b9-e578-4e62-9004-670983761fc9@github.com> References: <1nbt9ae0FrEPifrgzUbuxMEDR9GT3o2hiGLUjTl4Qbc=.44960153-27a6-4c3b-bc97-66771b4fa35a@github.com> <7RbSC49wUH6TZeKBAp06elQ9uUXoyUuFGvRY6nLnVw0=.e5c1fdef-3b3c-4c15-b1ac-5d2f79fa6bd8@github.com> <2EMdzvD7tge_vv9hmb07CZGrrO6l3xa7VtN7HH2ny84=.04aa93b9-e578-4e62-9004-670983761fc9@github.com> Message-ID: On Wed, 27 Oct 2021 16:48:11 GMT, Joe Darcy wrote: >> Updated as suggested. > >> >> >> Using `Runtime.version()` as a stand-in for the max `SourceVersion` seems non-obvious. Would it be better to use `SourceVersion.latest().runtimeVersion()` instead? >> >> What about when running this API on JDK N-1? > > Updated the supported range to go up to the feature corresponding to SourceVersion.latest(). I think this affects the doc comment and CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Wed Oct 27 20:45:14 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 27 Oct 2021 20:45:14 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v3] In-Reply-To: References: <1nbt9ae0FrEPifrgzUbuxMEDR9GT3o2hiGLUjTl4Qbc=.44960153-27a6-4c3b-bc97-66771b4fa35a@github.com> <7RbSC49wUH6TZeKBAp06elQ9uUXoyUuFGvRY6nLnVw0=.e5c1fdef-3b3c-4c15-b1ac-5d2f79fa6bd8@github.com> <2EMdzvD7tge_vv9hmb07CZGrrO6l3xa7VtN7HH2ny84=.04aa93b9-e578-4e62-9004-670983761fc9@github.com> Message-ID: On Wed, 27 Oct 2021 17:05:54 GMT, Jonathan Gibbons wrote: >>> >>> >>> Using `Runtime.version()` as a stand-in for the max `SourceVersion` seems non-obvious. Would it be better to use `SourceVersion.latest().runtimeVersion()` instead? >>> >>> What about when running this API on JDK N-1? >> >> Updated the supported range to go up to the feature corresponding to SourceVersion.latest(). > > I think this affects the doc comment and CSR. Right; I think the the current spec * ... If the runtime version's {@linkplain * Runtime.Version#feature() feature} is greater than the feature * of the {@linkplain #runtimeVersion() runtime version} of the * {@linkplain #latest() latest source version}, an {@code * IllegalArgumentException} is thrown. does reflect that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From jjg at openjdk.java.net Thu Oct 28 21:03:14 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 28 Oct 2021 21:03:14 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v6] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 22:28:44 GMT, Joe Darcy wrote: >> I wanted to get input on the design of API of the method before writing the tests. >> >> The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. >> >> Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. >> >> Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. >> >> CSR to follow once the API is nailed down. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add @since tags. Marked as reviewed by jjg (Reviewer). src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 502: > 500: * of the {@linkplain #runtimeVersion() runtime version} of the > 501: * {@linkplain #latest() latest source version}, an {@code > 502: * IllegalArgumentException} is thrown. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Thu Oct 28 22:09:53 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Oct 2021 22:09:53 GMT Subject: RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v7] In-Reply-To: References: Message-ID: <03wBXgEZYUGOlf12umOA86m9QziOkWVK_w-0wnbuLdQ=.2ac4ba5e-7d9e-42b9-9e0d-365d97323529@github.com> > I wanted to get input on the design of API of the method before writing the tests. > > The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. > > Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. > > Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. > > CSR to follow once the API is nailed down. 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: - Adjust copyrights and add bug id to test. - Merge branch 'master' into JDK-8275308 - Merge branch 'master' into JDK-8275308 - Add @since tags. - Respond to review feedback. - Appease jcheck. - Initial test support. - Merge branch 'master' into JDK-8275308 - Add support for reverse conversion. - Merge branch 'master' into JDK-8275308 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/1f0e7692...f33fa42b ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5973/files - new: https://git.openjdk.java.net/jdk/pull/5973/files/4517e54e..f33fa42b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5973&range=05-06 Stats: 12283 lines in 368 files changed: 9506 ins; 1284 del; 1493 mod Patch: https://git.openjdk.java.net/jdk/pull/5973.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5973/head:pull/5973 PR: https://git.openjdk.java.net/jdk/pull/5973 From darcy at openjdk.java.net Thu Oct 28 22:14:18 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Oct 2021 22:14:18 GMT Subject: Integrated: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 23:17:50 GMT, Joe Darcy wrote: > I wanted to get input on the design of API of the method before writing the tests. > > The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object. > > Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method. > > Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly. > > CSR to follow once the API is nailed down. This pull request has now been integrated. Changeset: 48f3fcab Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/48f3fcab518ccea4dbbc856132f82407f7974028 Stats: 115 lines in 2 files changed: 113 ins; 0 del; 2 mod 8275308: Add valueOf(Runtime.Version) factory to SourceVersion Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/5973 From serb at openjdk.java.net Fri Oct 29 05:53:13 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 29 Oct 2021 05:53:13 GMT Subject: RFR: 8272358: Some tests may fail when executed with other locales than the US In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com> References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com> Message-ID: On Thu, 12 Aug 2021 08:46:07 GMT, Sergey Bylokhov wrote: > As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14). @aivanov-jdk Alexey do you have any comments or suggestions? ------------- PR: https://git.openjdk.java.net/jdk/pull/5098 From aivanov at openjdk.java.net Fri Oct 29 10:47:13 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 29 Oct 2021 10:47:13 GMT Subject: RFR: 8272358: Some tests may fail when executed with other locales than the US In-Reply-To: References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com> Message-ID: On Fri, 29 Oct 2021 05:50:12 GMT, Sergey Bylokhov wrote: > @aivanov-jdk Alexey do you have any comments or suggestions? Sorry for my delayed reply. I have never used Russian locale when working with JDK, if I remember correctly, I even experienced JDK build failures with Russian locale. To me, the change looks good: it makes the tests more stable, these updated tests should pass even if the current locale is different than the US. I believe it's a common practice, as it's mentioned in [Testing the JDK](https://openjdk.java.net/groups/build/doc/testing.html#non-us-locale): > If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. However, I haven't tried running the tests under Russian or French locale yet. As for translations, I believe the tests which specifically verify translations should also set the locale explicitly and check the expected output. ------------- PR: https://git.openjdk.java.net/jdk/pull/5098 From darcy at openjdk.java.net Sat Oct 30 20:40:19 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 30 Oct 2021 20:40:19 GMT Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v4] In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com> References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com> Message-ID: > Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type. 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 five additional commits since the last revision: - Update spec. - Merge branch 'master' into JDK-8224922 - Merge branch 'master' into JDK-8224922 - Merge branch 'master' into JDK-8224922 - 8224922: Access JavaFileObject from Element(s) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5038/files - new: https://git.openjdk.java.net/jdk/pull/5038/files/a9a4f367..9cdb6c93 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=02-03 Stats: 10821 lines in 283 files changed: 8709 ins; 973 del; 1139 mod Patch: https://git.openjdk.java.net/jdk/pull/5038.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038 PR: https://git.openjdk.java.net/jdk/pull/5038