From jjg at openjdk.java.net Mon Aug 2 15:37:35 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 2 Aug 2021 15:37:35 GMT Subject: RFR: 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 I suggest using a text block in the test, unless there is a compelling reason why you can't. 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? ------------- PR: https://git.openjdk.java.net/jdk/pull/4613 From darcy at openjdk.java.net Tue Aug 3 00:48:47 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 3 Aug 2021 00:48:47 GMT Subject: RFR: 8225488: Examine ExecutableType.getReceiverType behavior when source receiver parameter is absent Message-ID: A belated companion fix to JDK-8222369, this change updates ExecutableType.getReceiverType to have its specified behavior: Returns the return type of this executable. Returns a NoType with kind VOID if this executable is not a method, or is a method that does not return a value. rather than returning null, as the implementation did before. The ExecutableElement implementation in Symbol is updated accordingly to take advantage of the change in Type, along with augmenting the test from JDK-8222369 to cover the receiver type from the ExecutableType too. BasicAnnoTests.java is updated for revised offsets. All langtools tests pass with these changes and TestExecutableReceiverType.java fails with an unmodified javac in JDK 18. Please also review the companion CSR JDK-8271703, https://bugs.openjdk.java.net/browse/JDK-8271703 ------------- Commit messages: - Appease jcheck. - 8225488: Examine ExecutableType.getReceiverType behavior when source receiver parameter is absent Changes: https://git.openjdk.java.net/jdk/pull/4965/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4965&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225488 Stats: 32 lines in 4 files changed: 18 ins; 1 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/4965.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4965/head:pull/4965 PR: https://git.openjdk.java.net/jdk/pull/4965 From cushon at openjdk.java.net Tue Aug 3 04:21:51 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Tue, 3 Aug 2021 04:21:51 GMT Subject: RFR: 8271623: Omit enclosing instance fields from inner classes that don't use it Message-ID: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state. ------------- Commit messages: - 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=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271623 Stats: 261 lines in 14 files changed: 216 ins; 15 del; 30 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 github.com+7806504+liach at openjdk.java.net Tue Aug 3 07:02:32 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Tue, 3 Aug 2021 07:02:32 GMT Subject: RFR: 8271623: Omit enclosing instance fields from inner classes that don't use it 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: <5Spxx3wzen48ZPfwjbOlwlM9992rcTi42Vk7RHnGc1M=.71f542fc-ebfd-4cfe-ae80-754f1ec38ec7@github.com> On Tue, 3 Aug 2021 03:19:13 GMT, Liam Miller-Cushon wrote: > This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state. I hope we have a test case that ensures the field is not erroneously removed when this nested class doesn't use the field, but another nested class within this nested class does. An example: public class Second { int t = 3; public static void main(String... a) { var q = new Second(); var p = q.new Third().new Fourth(); q.t = 6; p.print(); } public class Third { public class Fourth { public void print() { System.out.println(Second.this.t); } } } } ------------- PR: https://git.openjdk.java.net/jdk/pull/4966 From cushon at openjdk.java.net Tue Aug 3 18:48:04 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Tue, 3 Aug 2021 18:48:04 GMT Subject: RFR: 8271623: Omit enclosing instance fields from inner classes that don't use it In-Reply-To: <5Spxx3wzen48ZPfwjbOlwlM9992rcTi42Vk7RHnGc1M=.71f542fc-ebfd-4cfe-ae80-754f1ec38ec7@github.com> References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com> <5Spxx3wzen48ZPfwjbOlwlM9992rcTi42Vk7RHnGc1M=.71f542fc-ebfd-4cfe-ae80-754f1ec38ec7@github.com> Message-ID: On Tue, 3 Aug 2021 06:59:36 GMT, liach wrote: >> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state. > > I hope we have a test case that ensures the field is not erroneously removed when this nested class doesn't use the field, but another nested class within this nested class does. An example: > > > public class Second { > > int t = 3; > > public static void main(String... a) { > var q = new Second(); > var p = q.new Third().new Fourth(); > q.t = 6; > p.print(); > } > > public class Third { > public class Fourth { > public void print() { > System.out.println(Second.this.t); > } > } > } > } @liach thanks, I added another test case with nested inner classes. The current implementation handles that correctly, because the nested classes are lowered first, so any uses of the enclosing instance's `this$` field will be recorded before it is finished being lowered. ------------- PR: https://git.openjdk.java.net/jdk/pull/4966 From cushon at openjdk.java.net Tue Aug 3 18:48:00 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Tue, 3 Aug 2021 18:48:00 GMT Subject: RFR: 8271623: Omit enclosing instance fields from inner classes that don't use it [v2] 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 incrementally with one additional commit since the last revision: Add a test case with nested inner classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4966/files - new: https://git.openjdk.java.net/jdk/pull/4966/files/0ff3a3b9..3db4488c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4966&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4966&range=00-01 Stats: 31 lines in 1 file changed: 23 ins; 0 del; 8 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 rafael.wth at gmail.com Tue Aug 3 19:56:23 2021 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Tue, 3 Aug 2021 21:56:23 +0200 Subject: RFR: 8271623: Omit enclosing instance fields from inner classes that don't use it Message-ID: Hi, I remember remotely that this has been a discussion several times before, this would especially be useful if it was also applied to anonymous inner classes. The argument against, if I recall correctly, is that adding a field access can create unexpected behavioral change, for example by introducing memory leaks where there has not been one before only as the result of an inline access change. With consistent handling, at least the outcome is consistent and errors are not first introduced after minor changes. I could however not find the threads on it, and I do personally agree that there is potential for improvement. I do however think that you must retain the constructor to accept the outer instance, no matter if it is stored in a field or not. Otherwise, a public inner class might change its constructor and introduce a binary incompatible change if a field access of the outer class is removed or added and this class is recompiled independently. If the constructor only stores the field depending on the need to use it or not, the same effect is achieved without risking such API breakage. Without this, API developers would need to be very careful to include a field access also if it is no longer required, after changing a class. For instance, class Outer { class Inner { } } would compile to bytecode for instantiation of Inner similar to: new Outer.Inner(); after adding a field access from outer to inner, the bytecode would change to: new Outer.Inner(new Outer()); That's why the desugared code should look like this I think: class Outer { class Inner { Inner(Outer this$) { } } } where the field is only added if required. Best regards, Rafael -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.java.net Tue Aug 3 21:42:31 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 3 Aug 2021 21:42:31 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 For the CSR review of this change, I'll request a corpus run be initiated. Depending on the results of that run, the use of the new code generation idiom here may be triggered on -source/--release level. In other words, always use this$ in -source/--release 17 and earlier and omit it (when possible) on 18 and later. If you have not done so already, please also run the core reflection regression tests with this change. While the code generation idioms of javac are not a supported contract, applications can come to reply on them and change this idiom for earlier source levels may by too large of a behavioral compatibility change in that use-case. ------------- PR: https://git.openjdk.java.net/jdk/pull/4966 From alex.buckley at oracle.com Tue Aug 3 23:34:10 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 3 Aug 2021 16:34:10 -0700 Subject: RFR: 8271623: Omit enclosing instance fields from inner classes that don't use it In-Reply-To: References: Message-ID: <0420dc9f-4371-f73d-448c-e7a2a64f75bb@oracle.com> On 8/3/2021 12:56 PM, Rafael Winterhalter wrote: > I do however think that you must retain the constructor to accept the > outer instance, no matter if it is stored in a field or not. Otherwise, > a public inner class might change its constructor and introduce a binary > incompatible change if a field access of the outer class is removed or > added and this class is recompiled independently. ... The JLS mandates a constructor parameter for the outer instance -- https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.8.1-200 -- and nothing in the patch appears to do away with that parameter. There's even a comment in Lower.java that "If the variable is never accessed, we skip creating an outer instance field and saving the constructor parameter to it." -- implying the parameter still exists. It would be good for the CSR (JDK-8271717) to clarify that the T-accepting constructor in class T$I is still present after the change, and merely invokes a super constructor. Alex From john.r.rose at oracle.com Tue Aug 3 23:47:52 2021 From: john.r.rose at oracle.com (John Rose) Date: Tue, 3 Aug 2021 23:47:52 +0000 Subject: RFR: 8271623: Omit enclosing instance fields from inner classes that don't use it In-Reply-To: References: Message-ID: On Aug 3, 2021, at 12:56 PM, Rafael Winterhalter > wrote: I do however think that you must retain the constructor to accept the outer instance, no matter if it is stored in a field or not. Otherwise, a public inner class might change its constructor and introduce a binary incompatible change if a field access of the outer class is removed or added and this class is recompiled independently. If the constructor only stores the field depending on the need to use it or not, the same effect is achieved without risking such API breakage. Good point. The named inner classes are supposed to have a predictable shape at the VM level, to make use of reflection and debuggers a little easier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From graeme.rocher at oracle.com Wed Aug 4 07:48:41 2021 From: graeme.rocher at oracle.com (Graeme Keith Rocher) Date: Wed, 4 Aug 2021 07:48:41 +0000 Subject: Scanning for resources on the user classpath from an annotation processor Message-ID: Hi all, Apologies in advance if I am sending this to the wrong place. We have a requirement in the upcoming CDI lite specification to find ?beans.xml? files in the user classpath from an annotation processor (Micronaut). The issue is that as far as I am aware there is no way to do this from an annotation processor since the ?JavaFileManager? interface is inaccessible which provides this functionality via the ?getClassLoader? method that accepts a location that can be the user classpath: https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaFileManager.html#getClassLoader(javax.tools.JavaFileManager.Location) We have an experimental and not officially supported hack in the Micronaut annotation processor to attempt to work around this which retrieves the ?JavaFileManager? via reflection: https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142 However clearly this violates the JDKs direction in terms of closing more of the internals. I would like to request the addition of an officially supported way to do this via the APT API and am happy to contribute a proposal / JEP + PR if it means it can be taken forward since without this functionality it would mean that users will have to unnecessarily pollute the annotation processor classpath with JARs that aren?t required on that classpath. Thanks in advance for any feedback. Graeme -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.langer at oracle.com Wed Aug 4 12:15:04 2021 From: tomas.langer at oracle.com (Tomas Langer) Date: Wed, 4 Aug 2021 12:15:04 +0000 Subject: Scanning for resources on the user classpath from an annotation processor Message-ID: Hello, I have also tried to do this and failed. I have tried the workaround - it works fine with Java 11, but fails with Java 17: java.lang.IllegalAccessException: class MyAnnotationProcessor cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module @78a0dabb at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392) at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) at java.base/java.lang.reflect.Method.invoke(Method.java:560) at MyAnnotationProcessor.fileManager(MyAnnotationProcessor.java:644) Thanks, Tomas > Hi all, > > Apologies in advance if I am sending this to the wrong place. > > We have a requirement in the upcoming CDI lite specification to find ?beans.xml? files in the user classpath from an annotation processor (Micronaut). > > The issue is that as far as I am aware there is no way to do this from an annotation processor since the ?JavaFileManager? interface is inaccessible which provides this functionality via the ?getClassLoader? method that accepts a location that can be the user classpath: > > https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaFileManager.html#getClassLoader(javax.tools.JavaFileManager.Location) > > We have an experimental and not officially supported hack in the Micronaut annotation processor to attempt to work around this which retrieves the ?JavaFileManager? via reflection: > > https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142 > > However clearly this violates the JDKs direction in terms of closing more of the internals. > > I would like to request the addition of an officially supported way to do this via the APT API and am happy to contribute a proposal / JEP + PR if it means it can be taken forward since without this functionality it would mean that users will have to unnecessarily pollute the annotation processor classpath with JARs that aren?t required on that classpath. > > Thanks in advance for any feedback. > > Graeme -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.java.net Wed Aug 4 22:51:46 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 4 Aug 2021 22:51:46 GMT Subject: RFR: 8140442: Add getOutermostTypeElement to javax.lang.model utility class Message-ID: Please review this change to add a getOutermostTypeElement method to javax.lang.model.Elements along with the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8271903. ------------- Commit messages: - Appease jcheck. - Now with tests and javac Elements implementation. - Merge branch 'master' into JDK-8140442 - Merge branch 'master' into JDK-8140442 - Initial version pre-tests. Changes: https://git.openjdk.java.net/jdk/pull/5007/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5007&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8140442 Stats: 322 lines in 6 files changed: 268 ins; 53 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5007.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5007/head:pull/5007 PR: https://git.openjdk.java.net/jdk/pull/5007 From asotona at openjdk.java.net Thu Aug 5 09:02:30 2021 From: asotona at openjdk.java.net (Adam Sotona) Date: Thu, 5 Aug 2021 09:02:30 GMT Subject: RFR: 8268869: java in source-file mode suggests javac-only Xlint flags In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 15:33:41 GMT, Jonathan Gibbons 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 > > 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 jlahoda at openjdk.java.net Thu Aug 5 11:37:45 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 5 Aug 2021 11:37:45 GMT Subject: RFR: 8271928: ErroneousTree with start position -1 Message-ID: For some (very) erroneous code, the javac's parser may create an `ErroneousTree`, which contains an empty `ModifiersTree`. The empty `ModifiersTree` will not have the position, set but the `ModifiersTree`'s position will be used as the start position of the `ErroneousTree`, leading to start position `-1`. The proposal is to fall back on the the `ErroneousTree`'s `pos` when the nested tree does not have any position set. ------------- Commit messages: - 8271928: ErroneousTree with start position -1 Changes: https://git.openjdk.java.net/jdk/pull/5018/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5018&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271928 Stats: 33 lines in 2 files changed: 30 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5018.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5018/head:pull/5018 PR: https://git.openjdk.java.net/jdk/pull/5018 From jlaskey at openjdk.java.net Thu Aug 5 11:49:32 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 5 Aug 2021 11:49:32 GMT Subject: RFR: 8271928: ErroneousTree with start position -1 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 11:30:50 GMT, Jan Lahoda wrote: > For some (very) erroneous code, the javac's parser may create an `ErroneousTree`, which contains an empty `ModifiersTree`. The empty `ModifiersTree` will not have the position, set but the `ModifiersTree`'s position will be used as the start position of the `ErroneousTree`, leading to start position `-1`. The proposal is to fall back on the the `ErroneousTree`'s `pos` when the nested tree does not have any position set. Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5018 From vromero at openjdk.java.net Thu Aug 5 17:04:30 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 5 Aug 2021 17:04:30 GMT Subject: RFR: 8271928: ErroneousTree with start position -1 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 11:30:50 GMT, Jan Lahoda wrote: > For some (very) erroneous code, the javac's parser may create an `ErroneousTree`, which contains an empty `ModifiersTree`. The empty `ModifiersTree` will not have the position, set but the `ModifiersTree`'s position will be used as the start position of the `ErroneousTree`, leading to start position `-1`. The proposal is to fall back on the the `ErroneousTree`'s `pos` when the nested tree does not have any position set. Marked as reviewed by vromero (Reviewer). looks good ------------- PR: https://git.openjdk.java.net/jdk/pull/5018Marked as reviewed by vromero (Reviewer). From jjg at openjdk.java.net Thu Aug 5 19:26:50 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 5 Aug 2021 19:26:50 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 Message-ID: Please review a semi-automatic update of the nroff man pages from the upstream files. ------------- Commit messages: - JDK-8270872: Final nroff manpage update for JDK 17 Changes: https://git.openjdk.java.net/jdk17/pull/303/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=303&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270872 Stats: 289 lines in 27 files changed: 117 ins; 31 del; 141 mod Patch: https://git.openjdk.java.net/jdk17/pull/303.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/303/head:pull/303 PR: https://git.openjdk.java.net/jdk17/pull/303 From darcy at openjdk.java.net Thu Aug 5 19:44:37 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 5 Aug 2021 19:44:37 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the upstream files. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From naoto at openjdk.java.net Thu Aug 5 20:01:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 5 Aug 2021 20:01:37 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the upstream files. src/jdk.hotspot.agent/share/man/jhsdb.1 line 1: > 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved. This seems not correct? ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From mr at openjdk.java.net Thu Aug 5 20:13:39 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 5 Aug 2021 20:13:39 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the upstream files. Marked as reviewed by mr (Lead). ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From iris at openjdk.java.net Thu Aug 5 20:40:40 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 5 Aug 2021 20:40:40 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the upstream files. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From jjg at openjdk.java.net Thu Aug 5 21:39:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 5 Aug 2021 21:39:38 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> References: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> Message-ID: <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com> On Thu, 5 Aug 2021 19:57:59 GMT, Naoto Sato wrote: >> Please review a semi-automatic update of the nroff man pages from the upstream files. > > src/jdk.hotspot.agent/share/man/jhsdb.1 line 1: > >> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved. > > This seems not correct? According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file. I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1. This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem. I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command. ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From naoto at openjdk.java.net Thu Aug 5 21:44:35 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 5 Aug 2021 21:44:35 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the upstream files. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From naoto at openjdk.java.net Thu Aug 5 21:44:36 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 5 Aug 2021 21:44:36 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com> References: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com> Message-ID: On Thu, 5 Aug 2021 21:36:58 GMT, Jonathan Gibbons wrote: >> src/jdk.hotspot.agent/share/man/jhsdb.1 line 1: >> >>> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved. >> >> This seems not correct? > > According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file. > > I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1. > > This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem. > > I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command. Thanks for the explanation, Jon. Fine by me. ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From mr at openjdk.java.net Thu Aug 5 21:44:36 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 5 Aug 2021 21:44:36 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com> Message-ID: On Thu, 5 Aug 2021 21:40:40 GMT, Naoto Sato wrote: >> According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file. >> >> I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1. >> >> This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem. >> >> I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command. > > Thanks for the explanation, Jon. Fine by me. I agree that fixing this date is not necessary at this time. ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From jjg at openjdk.java.net Thu Aug 5 22:15:29 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 5 Aug 2021 22:15:29 GMT Subject: [jdk17] Integrated: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the upstream files. This pull request has now been integrated. Changeset: dfacda48 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk17/commit/dfacda488bfbe2e11e8d607a6d08527710286982 Stats: 289 lines in 27 files changed: 117 ins; 31 del; 141 mod 8270872: Final nroff manpage update for JDK 17 Reviewed-by: darcy, mr, iris, naoto ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From jwilhelm at openjdk.java.net Thu Aug 5 23:57:59 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 5 Aug 2021 23:57:59 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8270872: Final nroff manpage update for JDK 17 - 8271588: JFR Recorder Thread crashed with SIGSEGV in write_klass - 8271863: ProblemList serviceability/sa/TestJmapCore.java on linux-x64 with ZGC The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/5026/files Stats: 307 lines in 32 files changed: 129 ins; 33 del; 145 mod Patch: https://git.openjdk.java.net/jdk/pull/5026.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5026/head:pull/5026 PR: https://git.openjdk.java.net/jdk/pull/5026 From jwilhelm at openjdk.java.net Fri Aug 6 01:27:33 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 6 Aug 2021 01:27:33 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 23:49:48 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 14692d5e Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/14692d5ed0652b867fcf28baafa498a9441683ac Stats: 307 lines in 32 files changed: 129 ins; 33 del; 145 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/5026 From jwilhelm at openjdk.java.net Fri Aug 6 01:27:32 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 6 Aug 2021 01:27:32 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: <1oUovSIU_RoljyN5VHPljZLMI5NpHqK3ys9BDhsuLI8=.15d53c62-802e-4982-9415-527c302b8ab4@github.com> > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 440 commits: - Merge - 8271293: Monitor class should use ThreadBlockInVMPreprocess Reviewed-by: dholmes, dcubed - 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS Reviewed-by: psadhukhan, aivanov - 8271905: mark hotspot runtime/Metaspace tests which ignore external VM flags Reviewed-by: stuefe - 8271308: (fc) FileChannel.transferTo() transfers no more than Integer.MAX_VALUE bytes in one call Reviewed-by: alanb, vtewari - 8271953: fix mis-merge in JDK-8271878 Reviewed-by: jwilhelm, ctornqvi - 8267840: Improve URLStreamHandler.parseURL() Reviewed-by: dfuchs, redestad - 8271840: Add simple Integer.toString microbenchmarks Reviewed-by: shade - 8271121: ZGC: stack overflow (segv) when -Xlog:gc+start=debug Reviewed-by: ayang, eosterlund - 8270903: sun.net.httpserver.HttpConnection: Improve toString Reviewed-by: chegar, vtewari - ... and 430 more: https://git.openjdk.java.net/jdk/compare/dfacda48...7e069880 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5026/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=01 Stats: 97370 lines in 1522 files changed: 61891 ins; 27834 del; 7645 mod Patch: https://git.openjdk.java.net/jdk/pull/5026.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5026/head:pull/5026 PR: https://git.openjdk.java.net/jdk/pull/5026 From prappo at openjdk.java.net Fri Aug 6 12:24:06 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 6 Aug 2021 12:24:06 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Pass through FIXMEs and TODOs Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/0a47e9c2..22d1e07d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=05-06 Stats: 11 lines in 5 files changed: 3 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From darcy at openjdk.java.net Fri Aug 6 21:21:51 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 6 Aug 2021 21:21:51 GMT Subject: RFR: 8224922: Access JavaFileObject from Element(s) Message-ID: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@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. ------------- Commit messages: - 8224922: Access JavaFileObject from Element(s) Changes: https://git.openjdk.java.net/jdk/pull/5038/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8224922 Stats: 74 lines in 2 files changed: 74 ins; 0 del; 0 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 graeme.rocher at oracle.com Mon Aug 9 08:03:54 2021 From: graeme.rocher at oracle.com (Graeme Keith Rocher) Date: Mon, 9 Aug 2021 08:03:54 +0000 Subject: Scanning for resources on the user classpath from an annotation processor In-Reply-To: References: Message-ID: Having thought about this some more, this request can be ignored as it would be better to implement the required functionality at the build tooling layer whereby the build tooling collects the beans.xml resources needed by the processor and specifies them as inputs (annotation processor arguments) in order for incremental compilation to work. Apologies for the noise. Graeme From: Graeme Keith Rocher Date: Wednesday, 4 August 2021 at 09:48 To: compiler-dev at openjdk.java.net Subject: Scanning for resources on the user classpath from an annotation processor Hi all, Apologies in advance if I am sending this to the wrong place. We have a requirement in the upcoming CDI lite specification to find ?beans.xml? files in the user classpath from an annotation processor (Micronaut). The issue is that as far as I am aware there is no way to do this from an annotation processor since the ?JavaFileManager? interface is inaccessible which provides this functionality via the ?getClassLoader? method that accepts a location that can be the user classpath: https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaFileManager.html#getClassLoader(javax.tools.JavaFileManager.Location) We have an experimental and not officially supported hack in the Micronaut annotation processor to attempt to work around this which retrieves the ?JavaFileManager? via reflection: https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142 However clearly this violates the JDKs direction in terms of closing more of the internals. I would like to request the addition of an officially supported way to do this via the APT API and am happy to contribute a proposal / JEP + PR if it means it can be taken forward since without this functionality it would mean that users will have to unnecessarily pollute the annotation processor classpath with JARs that aren?t required on that classpath. Thanks in advance for any feedback. Graeme -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon Aug 9 09:28:56 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 9 Aug 2021 11:28:56 +0200 (CEST) Subject: Scanning for resources on the user classpath from an annotation processor In-Reply-To: References: Message-ID: <1021925133.103217.1628501336757.JavaMail.zimbra@u-pem.fr> > From: "Graeme Keith Rocher" > To: "compiler-dev" > Sent: Monday, August 9, 2021 10:03:54 AM > Subject: Re: Scanning for resources on the user classpath from an annotation > processor > Having thought about this some more, this request can be ignored as it would be > better to implement the required functionality at the build tooling layer > whereby the build tooling collects the beans.xml resources needed by the > processor and specifies them as inputs (annotation processor arguments) in > order for incremental compilation to work. yes, it seems a better design :) > Apologies for the noise. > Graeme R?mi > From: Graeme Keith Rocher > Date: Wednesday, 4 August 2021 at 09:48 > To: compiler-dev at openjdk.java.net > Subject: Scanning for resources on the user classpath from an annotation > processor > Hi all, > Apologies in advance if I am sending this to the wrong place. > We have a requirement in the upcoming CDI lite specification to find ?beans.xml? > files in the user classpath from an annotation processor (Micronaut). > The issue is that as far as I am aware there is no way to do this from an > annotation processor since the ?JavaFileManager? interface is inaccessible > which provides this functionality via the ?getClassLoader? method that accepts > a location that can be the user classpath: > [ > https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaFileManager.html#getClassLoader%28javax.tools.JavaFileManager.Location%29 > | > https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaFileManager.html#getClassLoader(javax.tools.JavaFileManager.Location) > ] > We have an experimental and not officially supported hack in the Micronaut > annotation processor to attempt to work around this which retrieves the > ?JavaFileManager? via reflection: > [ > https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142 > | > https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142 > ] > However clearly this violates the JDKs direction in terms of closing more of the > internals. > I would like to request the addition of an officially supported way to do this > via the APT API and am happy to contribute a proposal / JEP + PR if it means it > can be taken forward since without this functionality it would mean that users > will have to unnecessarily pollute the annotation processor classpath with JARs > that aren?t required on that classpath. > Thanks in advance for any feedback. > Graeme -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjg at openjdk.java.net Mon Aug 9 18:00:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 9 Aug 2021 18:00:38 GMT Subject: RFR: 8225488: Examine ExecutableType.getReceiverType behavior when source receiver parameter is absent In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 00:06:37 GMT, Joe Darcy wrote: > A belated companion fix to JDK-8222369, this change updates ExecutableType.getReceiverType to have its specified behavior: > > Returns the return type of this executable. Returns a NoType with kind VOID if this executable is not a method, or is a method that does not return a value. > > rather than returning null, as the implementation did before. The ExecutableElement implementation in Symbol is updated accordingly to take advantage of the change in Type, along with augmenting the test from JDK-8222369 to cover the receiver type from the ExecutableType too. > > BasicAnnoTests.java is updated for revised offsets. > > All langtools tests pass with these changes and TestExecutableReceiverType.java fails with an unmodified javac in JDK 18. > > Please also review the companion CSR JDK-8271703, https://bugs.openjdk.java.net/browse/JDK-8271703 Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4965 From darcy at openjdk.java.net Mon Aug 9 18:10:12 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 9 Aug 2021 18:10:12 GMT Subject: RFR: 8225488: Examine ExecutableType.getReceiverType behavior when source receiver parameter is absent [v2] In-Reply-To: References: Message-ID: <_uz2pKdslmqy2W5rofgUOt-DDGzWv1GC-UVKJX2ww10=.f0b8850e-3a57-4e3a-b764-35ed64aeae63@github.com> > A belated companion fix to JDK-8222369, this change updates ExecutableType.getReceiverType to have its specified behavior: > > Returns the return type of this executable. Returns a NoType with kind VOID if this executable is not a method, or is a method that does not return a value. > > rather than returning null, as the implementation did before. The ExecutableElement implementation in Symbol is updated accordingly to take advantage of the change in Type, along with augmenting the test from JDK-8222369 to cover the receiver type from the ExecutableType too. > > BasicAnnoTests.java is updated for revised offsets. > > All langtools tests pass with these changes and TestExecutableReceiverType.java fails with an unmodified javac in JDK 18. > > Please also review the companion CSR JDK-8271703, https://bugs.openjdk.java.net/browse/JDK-8271703 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: - Merge and update copyrights. - Merge branch 'master' into 8225488 - Appease jcheck. - 8225488: Examine ExecutableType.getReceiverType behavior when source receiver parameter is absent ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4965/files - new: https://git.openjdk.java.net/jdk/pull/4965/files/ed3bed58..c9df1003 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4965&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4965&range=00-01 Stats: 11405 lines in 361 files changed: 9000 ins; 1427 del; 978 mod Patch: https://git.openjdk.java.net/jdk/pull/4965.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4965/head:pull/4965 PR: https://git.openjdk.java.net/jdk/pull/4965 From darcy at openjdk.java.net Mon Aug 9 18:36:36 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 9 Aug 2021 18:36:36 GMT Subject: Integrated: 8225488: Examine ExecutableType.getReceiverType behavior when source receiver parameter is absent In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 00:06:37 GMT, Joe Darcy wrote: > A belated companion fix to JDK-8222369, this change updates ExecutableType.getReceiverType to have its specified behavior: > > Returns the return type of this executable. Returns a NoType with kind VOID if this executable is not a method, or is a method that does not return a value. > > rather than returning null, as the implementation did before. The ExecutableElement implementation in Symbol is updated accordingly to take advantage of the change in Type, along with augmenting the test from JDK-8222369 to cover the receiver type from the ExecutableType too. > > BasicAnnoTests.java is updated for revised offsets. > > All langtools tests pass with these changes and TestExecutableReceiverType.java fails with an unmodified javac in JDK 18. > > Please also review the companion CSR JDK-8271703, https://bugs.openjdk.java.net/browse/JDK-8271703 This pull request has now been integrated. Changeset: 7fc99cf9 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/7fc99cf9b69f99fc78709e57b92cd88e09577d0f Stats: 34 lines in 4 files changed: 18 ins; 1 del; 15 mod 8225488: Examine ExecutableType.getReceiverType behavior when source receiver parameter is absent Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4965 From thartmann at openjdk.java.net Tue Aug 10 07:02:29 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 10 Aug 2021 07:02:29 GMT Subject: RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack [v3] In-Reply-To: References: Message-ID: <1yrVMHVq7Q4cI9GvLEvITL_tSGYX96ntJDzCiz-x8NE=.0242dbb2-23f2-4a3d-befd-a4271dac63ca@github.com> On Mon, 26 Jul 2021 07:43:39 GMT, Yi Yang wrote: >> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash. >> >> ---- >> >> The attached test generates the following bytecode: >> >> void test(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=1 >> 0: iconst_1 >> 1: istore_1 >> 2: iload_1 >> 3: bipush 100 >> 5: if_icmpge 29 >> 8: iinc 1, 1 >> 11: goto 2 >> 14: astore_2 >> 15: iload_1 >> 16: bipush 100 >> 18: if_icmpge 27 >> 21: iinc 1, 1 >> 24: goto 15 >> 27: aload_2 >> 28: athrow >> 29: return >> >> >> >> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug. >> >> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this: >> >> void test(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=1 >> 0: iconst_1 >> 1: istore_1 >> 2: nop >> 3: iload_1 >> 4: bipush 100 >> 6: if_icmpge 30 >> 9: iinc 1, 1 >> 12: goto 3 >> 15: astore_2 >> 16: iload_1 >> 17: bipush 100 >> 19: if_icmpge 28 >> 22: iinc 1, 1 >> 25: goto 16 >> 28: aload_2 >> 29: athrow >> 30: return >> Exception table: >> from to target type >> 2 3 15 any >> >> >> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > remove usenewcode HotSpot and javac should be fixed independently, please file a new bug for javac. Regarding the change to `GenerateOopMap::do_exception_edge`, is that sufficient to fix the bug even without the change to javac? Because HotSpot should also handle bytecode not generated by javac. The fix looks reasonable to me but someone from runtime who knows that code better should have a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/4902 From yyang at openjdk.java.net Tue Aug 10 07:46:31 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 10 Aug 2021 07:46:31 GMT Subject: RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack [v3] In-Reply-To: <1yrVMHVq7Q4cI9GvLEvITL_tSGYX96ntJDzCiz-x8NE=.0242dbb2-23f2-4a3d-befd-a4271dac63ca@github.com> References: <1yrVMHVq7Q4cI9GvLEvITL_tSGYX96ntJDzCiz-x8NE=.0242dbb2-23f2-4a3d-befd-a4271dac63ca@github.com> Message-ID: <5WUlshFIZfiqx73HIQ9vPSihWC0XfeGQSZ8aCJ8ECD8=.af0e4262-4fd1-4d61-8504-4795d588fa7c@github.com> On Tue, 10 Aug 2021 06:59:57 GMT, Tobias Hartmann wrote: > HotSpot and javac should be fixed independently, please file a new bug for javac. > > Regarding the change to `GenerateOopMap::do_exception_edge`, is that sufficient to fix the bug even without the change to javac? Because HotSpot should also handle bytecode not generated by javac. > > The fix looks reasonable to me but someone from runtime who knows that code better should have a look. Hi Tobias, It's not sufficient to fix this bug without javac changes. But it reveals [another crash](https://github.com/openjdk/jdk/pull/4902#issuecomment-886774027) that I posted above. Maybe I should file a new issue for that and fix it? Later when javac bug is solved, this bug can also be set to resolve. ------------- PR: https://git.openjdk.java.net/jdk/pull/4902 From thartmann at openjdk.java.net Tue Aug 10 08:17:40 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 10 Aug 2021 08:17:40 GMT Subject: RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 07:43:39 GMT, Yi Yang wrote: >> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash. >> >> ---- >> >> The attached test generates the following bytecode: >> >> void test(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=1 >> 0: iconst_1 >> 1: istore_1 >> 2: iload_1 >> 3: bipush 100 >> 5: if_icmpge 29 >> 8: iinc 1, 1 >> 11: goto 2 >> 14: astore_2 >> 15: iload_1 >> 16: bipush 100 >> 18: if_icmpge 27 >> 21: iinc 1, 1 >> 24: goto 15 >> 27: aload_2 >> 28: athrow >> 29: return >> >> >> >> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug. >> >> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this: >> >> void test(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=1 >> 0: iconst_1 >> 1: istore_1 >> 2: nop >> 3: iload_1 >> 4: bipush 100 >> 6: if_icmpge 30 >> 9: iinc 1, 1 >> 12: goto 3 >> 15: astore_2 >> 16: iload_1 >> 17: bipush 100 >> 19: if_icmpge 28 >> 22: iinc 1, 1 >> 25: goto 16 >> 28: aload_2 >> 29: athrow >> 30: return >> Exception table: >> from to target type >> 2 3 15 any >> >> >> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > remove usenewcode Okay but then the fix is incomplete because the VM also needs to handle bytecode not generated by javac. Other compilers or hand written bytecode might still miss these traps.Of course, if the bytecode violates the Spec, the verifier should catch this but otherwise the VM should not crash or assert. > Maybe I should file a new issue for that and fix it? I think it's just a different failure mode and should be fixed with this bug. > Later when javac bug is solved, this bug can also be set to resolve. No, as explained above, other compilers could still generate this bytecode shape. We need to handle it properly in the VM. ------------- PR: https://git.openjdk.java.net/jdk/pull/4902 From yyang at openjdk.java.net Tue Aug 10 08:32:30 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 10 Aug 2021 08:32:30 GMT Subject: RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack [v3] In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 08:14:27 GMT, Tobias Hartmann wrote: > Okay but then the fix is incomplete because the VM also needs to handle bytecode not generated by javac. Other compilers or hand written bytecode might still miss these traps.Of course, if the bytecode violates the Spec, the verifier should catch this but otherwise the VM should not crash or assert. > > > Maybe I should file a new issue for that and fix it? > > I think it's just a different failure mode and should be fixed with this bug. > > > Later when javac bug is solved, this bug can also be set to resolve. > > No, as explained above, other compilers could still generate this bytecode shape. We need to handle it properly in the VM. Make sense! I will prepare a more proper fix to solve this even without javac change. (But it may take a while since I'm busy on other stuffs now...) ------------- PR: https://git.openjdk.java.net/jdk/pull/4902 From jlahoda at openjdk.java.net Tue Aug 10 13:00:30 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 10 Aug 2021 13:00:30 GMT Subject: RFR: 8140442: Add getOutermostTypeElement to javax.lang.model utility class In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 22:41:22 GMT, Joe Darcy wrote: > Please review this change to add a getOutermostTypeElement method to javax.lang.model.Elements along with the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8271903. To me, looks good, with some nits inlined. src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 581: > 579: // for misbehaving element implementations. > 580: while (true) { > 581: // Conceptual instanceof TypeElment check. If the Nit: Suggestion: // Conceptual instanceof TypeElement check. If the test/langtools/tools/javac/processing/model/util/elements/TestOutermostTypeElement.java line 78: > 76: @Override > 77: public Void scan(Element e, Elements elts) { > 78: // System.out.println(e.getSimpleName() + " " + e.getKind()); Nit: Suggestion: ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5007 From darcy at openjdk.java.net Tue Aug 10 16:35:38 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 10 Aug 2021 16:35:38 GMT Subject: RFR: 8140442: Add getOutermostTypeElement to javax.lang.model utility class [v2] In-Reply-To: References: Message-ID: > Please review this change to add a getOutermostTypeElement method to javax.lang.model.Elements along with the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8271903. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback and update copyright. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5007/files - new: https://git.openjdk.java.net/jdk/pull/5007/files/bc1de3f0..3ac05554 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5007&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5007&range=00-01 Stats: 5 lines in 3 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5007.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5007/head:pull/5007 PR: https://git.openjdk.java.net/jdk/pull/5007 From darcy at openjdk.java.net Tue Aug 10 16:42:39 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 10 Aug 2021 16:42:39 GMT Subject: RFR: 8140442: Add getOutermostTypeElement to javax.lang.model utility class [v3] In-Reply-To: References: Message-ID: > Please review this change to add a getOutermostTypeElement method to javax.lang.model.Elements along with the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8271903. 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: - Merge branch 'master' into JDK-8140442 - Respond to review feedback and update copyright. - Appease jcheck. - Now with tests and javac Elements implementation. - Merge branch 'master' into JDK-8140442 - Merge branch 'master' into JDK-8140442 - Initial version pre-tests. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5007/files - new: https://git.openjdk.java.net/jdk/pull/5007/files/3ac05554..7f58ab5b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5007&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5007&range=01-02 Stats: 6854 lines in 191 files changed: 5916 ins; 432 del; 506 mod Patch: https://git.openjdk.java.net/jdk/pull/5007.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5007/head:pull/5007 PR: https://git.openjdk.java.net/jdk/pull/5007 From darcy at openjdk.java.net Tue Aug 10 16:46:00 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 10 Aug 2021 16:46:00 GMT Subject: RFR: 8140442: Add getOutermostTypeElement to javax.lang.model utility class [v3] In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 12:55:52 GMT, Jan Lahoda 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 seven additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8140442 >> - Respond to review feedback and update copyright. >> - Appease jcheck. >> - Now with tests and javac Elements implementation. >> - Merge branch 'master' into JDK-8140442 >> - Merge branch 'master' into JDK-8140442 >> - Initial version pre-tests. > > src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 581: > >> 579: // for misbehaving element implementations. >> 580: while (true) { >> 581: // Conceptual instanceof TypeElment check. If the > > Nit: > Suggestion: > > // Conceptual instanceof TypeElement check. If the Nits fixed; thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5007 From darcy at openjdk.java.net Tue Aug 10 16:52:59 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 10 Aug 2021 16:52:59 GMT Subject: Integrated: 8140442: Add getOutermostTypeElement to javax.lang.model utility class In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 22:41:22 GMT, Joe Darcy wrote: > Please review this change to add a getOutermostTypeElement method to javax.lang.model.Elements along with the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8271903. This pull request has now been integrated. Changeset: 57ae9fbe Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/57ae9fbe779e63f9606077047137b00220c6b3a2 Stats: 322 lines in 6 files changed: 267 ins; 53 del; 2 mod 8140442: Add getOutermostTypeElement to javax.lang.model utility class Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/5007 From darcy at openjdk.java.net Tue Aug 10 20:06:56 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 10 Aug 2021 20:06:56 GMT Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v2] 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 two additional commits since the last revision: - 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/70547512..e2acf39d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=00-01 Stats: 8572 lines in 241 files changed: 6930 ins; 813 del; 829 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 jlahoda at openjdk.java.net Tue Aug 10 20:51:40 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 10 Aug 2021 20:51:40 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) Seems useful to me. A possible conversion from Element to FileObject is needed elsewhere as well, I've tried to write it here: https://github.com/openjdk/jdk/blob/aa61e594b96acba1bcb7e5ea57b1631d917cf545/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java#L526 ------------- PR: https://git.openjdk.java.net/jdk/pull/5038 From jlahoda at openjdk.java.net Tue Aug 10 20:54:45 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 10 Aug 2021 20:54:45 GMT Subject: RFR: 8272234: Pass originating elements from Filer to JavaFileManager Message-ID: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@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. ------------- Commit messages: - 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 - Improving the patch and API. - Merge branch 'master' into ap-keep-originating-elements - Fixing the TestClientCodeWrapper.java test, - ... and 3 more: https://git.openjdk.java.net/jdk/compare/a86ac0d1...aa61e594 Changes: https://git.openjdk.java.net/jdk/pull/5076/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5076&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272234 Stats: 575 lines in 8 files changed: 564 ins; 1 del; 10 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 jlahoda at openjdk.java.net Wed Aug 11 08:57:31 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 11 Aug 2021 08:57:31 GMT Subject: Integrated: 8271928: ErroneousTree with start position -1 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 11:30:50 GMT, Jan Lahoda wrote: > For some (very) erroneous code, the javac's parser may create an `ErroneousTree`, which contains an empty `ModifiersTree`. The empty `ModifiersTree` will not have the position, set but the `ModifiersTree`'s position will be used as the start position of the `ErroneousTree`, leading to start position `-1`. The proposal is to fall back on the the `ErroneousTree`'s `pos` when the nested tree does not have any position set. This pull request has now been integrated. Changeset: 3215dbc8 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/3215dbc8b8e5f2c1454741dc7f94b0232c5d911f Stats: 33 lines in 2 files changed: 30 ins; 0 del; 3 mod 8271928: ErroneousTree with start position -1 Reviewed-by: jlaskey, vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/5018 From jjg at openjdk.java.net Wed Aug 11 17:45:48 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 11 Aug 2021 17:45:48 GMT Subject: RFR: JDK-8271159: [REDO] JDK-8249634 doclint should report implicit constructor as missing javadoc comments Message-ID: Please review a do-over of JDK-8249634, to report a missing doc comment when an implicit/default constructor is used. The `src` code is the same as before. The previous version had missing test files (now added), and had a test fail because an interaction with another changeset that was pushed while the previous version was in review. The solution for that is the use of `-Xdoclint:all,-missing` in `TestDocTreeDiags.java`. ------------- Commit messages: - JDK-8271159: [REDO] JDK-8249634 doclint should report implicit constructor as missing javadoc comments Changes: https://git.openjdk.java.net/jdk/pull/5088/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5088&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271159 Stats: 240 lines in 77 files changed: 125 ins; 4 del; 111 mod Patch: https://git.openjdk.java.net/jdk/pull/5088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5088/head:pull/5088 PR: https://git.openjdk.java.net/jdk/pull/5088 From darcy at openjdk.java.net Wed Aug 11 18:03:25 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 11 Aug 2021 18:03:25 GMT Subject: RFR: JDK-8271159: [REDO] JDK-8249634 doclint should report implicit constructor as missing javadoc comments In-Reply-To: References: Message-ID: <8-v6822Vfm_SfsnPuuWA6hb5cRcDykIrPuT1XQRZUUc=.7aa297aa-8deb-49de-bb7c-e53cc2a02bf6@github.com> On Wed, 11 Aug 2021 17:38:49 GMT, Jonathan Gibbons wrote: > Please review a do-over of JDK-8249634, to report a missing doc comment when an implicit/default constructor is used. > > The `src` code is the same as before. The previous version had missing test files (now added), and had a test fail because an interaction with another changeset that was pushed while the previous version was in review. The solution for that is the use of `-Xdoclint:all,-missing` in `TestDocTreeDiags.java`. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5088 From jjg at openjdk.java.net Wed Aug 11 18:06:30 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 11 Aug 2021 18:06:30 GMT Subject: Integrated: JDK-8271159: [REDO] JDK-8249634 doclint should report implicit constructor as missing javadoc comments In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 17:38:49 GMT, Jonathan Gibbons wrote: > Please review a do-over of JDK-8249634, to report a missing doc comment when an implicit/default constructor is used. > > The `src` code is the same as before. The previous version had missing test files (now added), and had a test fail because an interaction with another changeset that was pushed while the previous version was in review. The solution for that is the use of `-Xdoclint:all,-missing` in `TestDocTreeDiags.java`. This pull request has now been integrated. Changeset: ec8d3bad Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/ec8d3badc869be7898b5a49fa5f9ba447bbbcf8d Stats: 240 lines in 77 files changed: 125 ins; 4 del; 111 mod 8271159: [REDO] JDK-8249634 doclint should report implicit constructor as missing javadoc comments Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/5088 From jlahoda at openjdk.java.net Thu Aug 12 08:31:39 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 12 Aug 2021 08:31:39 GMT Subject: RFR: 8259039: Passing different version to --release flag than javac version output warning Message-ID: For code like: com.sun.nio.file.ExtendedOpenOption o; certain combination of command line options produce a proprietary warnings: $ javac --release 11 T.java T.java:2: warning: ExtendedOpenOption is internal proprietary API and may be removed in a future release com.sun.nio.file.ExtendedOpenOption o; ^ 1 warning But some do not: $ javac -source 8 T.java warning: [options] bootstrap class path not set in conjunction with -source 8 1 warning The reason is that the `ct.properties` files does not mark `com.sun.nio.file` as proprietary. The proposed fix has two parts: -adds `proprietary` to the `com.sun.nio.file` package in `ct.properties` -limits the `ct.properties` so that it is only used for `-source 8`. The `ct.properties` contains 3 types of information: it hides some packages, it marks some packages as "proprietary" (so that they produce the warning), and assigns packages to compact profiles. For `-source 9+`, most of these is not needed - packages are hidden using the module system, the only packages that need a warning are from the `jdk.unsupported` module, and there are no compact profiles. So for `-source 9+`, we don't need to use the `ct.properties`. (Note none of this applies to `--release` - it uses a different database.) ------------- Commit messages: - Removing trailing whitespace. - 8259039: Passing different version to --release flag than javac version output warning Changes: https://git.openjdk.java.net/jdk/pull/5053/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5053&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259039 Stats: 162 lines in 4 files changed: 152 ins; 4 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5053.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5053/head:pull/5053 PR: https://git.openjdk.java.net/jdk/pull/5053 From serb at openjdk.java.net Thu Aug 12 19:54:33 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 12 Aug 2021 19:54:33 GMT Subject: RFR: 8272358: Some tests may fail when executed with other locales than the US Message-ID: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com> 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). ------------- Commit messages: - Initial fix of JDK-8272358 Changes: https://git.openjdk.java.net/jdk/pull/5098/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5098&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272358 Stats: 9 lines in 4 files changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5098.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5098/head:pull/5098 PR: https://git.openjdk.java.net/jdk/pull/5098 From jjg at openjdk.java.net Fri Aug 13 03:59:49 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 13 Aug 2021 03:59:49 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments Message-ID: Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. There are three cases to consider: * The comment itself is missing: this was already checked and reported as "missing comment". * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. A new test is added, focussing on the different forms of empty/missing descriptions, as described above. ------------- Commit messages: - JDK-8272374: doclint should report missing "body" comments Changes: https://git.openjdk.java.net/jdk/pull/5106/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5106&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272374 Stats: 281 lines in 37 files changed: 152 ins; 10 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/5106.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5106/head:pull/5106 PR: https://git.openjdk.java.net/jdk/pull/5106 From kcr at openjdk.java.net Fri Aug 13 15:46:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Aug 2021 15:46:27 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 03:51:23 GMT, Jonathan Gibbons wrote: > Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. > > It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. > > There are three cases to consider: > > * The comment itself is missing: this was already checked and reported as "missing comment". > * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". > * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". > > No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. > > Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) > > Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. > > A new test is added, focussing on the different forms of empty/missing descriptions, as described above. I tested this by using it to generate the JavaFX docs. We have 62 new warnings for methods with empty descriptions that we otherwise would not have easily found. ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/5106 From duke at openjdk.java.net Sat Aug 14 12:28:30 2021 From: duke at openjdk.java.net (duke) Date: Sat, 14 Aug 2021 12:28:30 GMT Subject: Withdrawn: 8263926: JavacFileManager.hasExplicitLocation fails with NPE while compiling In-Reply-To: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com> References: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com> Message-ID: On Thu, 17 Jun 2021 15:41:46 GMT, Guoxiong Li wrote: > Hi all, > > The compiler fails with NullPointerException while building the maven project provided by the user in [JDK-8263926](https://bugs.openjdk.java.net/browse/JDK-8263926). > > Actually, the patch is simple. We only need to add a `null` check before using the `msym.sourceLocation`. > > > - if (fileManager.contains(msym.sourceLocation, fo)) > + if (msym.sourceLocation != null && fileManager.contains(msym.sourceLocation, fo)) > > > But we can't verify whether the problem is solved because the code provided by the user is complex so that we have no way to wtite a regression test. > > Recently, I deeply researched the relationship of the source code provided by the user > and construct a minimal test case to verify the patch. > The minimal test was attached to the JBS just now. > The attached test reproduces the bug by using the shell script instead of maven. > And the test case `SourceLocationNotExist.java` at this patch is another way to reproduce the bug. > The steps in `SourceLocationNotExist.java` is the same as the shell script mentioned above. > > Given that the bug is hard to be reproduced, I give some comments here. > > 1. We need to construct a jar file which has both `*.java` files and `*.class` files and has no named module. > First, I compile the file `test/TestUnnamedModule.java` into `test/TestUnnamedModule.class`. > Then I use the `jar` tool to construct the jar file `test.jar`, which contains both `test/TestUnnamedModule.java` and `test/TestUnnamedModule.class`. > Commands are like: > `javac test/TestUnnamedModule.java` and > `jar -c -f test.jar test/TestUnnamedModule.class test/TestUnnamedModule.java` > > 2. The last modified time of the `*.java` files should be newer than that of the `*.class` files. > Because the compiler implicitly choose the last modified file if both source files and class files are present. > We need the compiler the choose the `*.java` files to reproduce the bug. > So before using the `jar` command, we need to update the modified time of the `*.java` files to let it newer than `*.class` files. > Command is like: `touch test/TestUnnamedModule.java`. > > 3. We need to use the class of the `test.jar` in a named module. > I construct a module named `use`, which has a module file `module-info.java` and a source file `TestUse.java`. > You can see the `TestUse.java` has a statement `import test.TestUnnamedModule;` to use the `test.jar`. > > 4. The `module-info.java` of the module `use` can't have the directive `requires test`. Because the name `test` is the automatic module name of the jar file `test.jar`. > > 5. When compiling the module `use` mentioned above, we must use the option `-sourcepath` and the `test.jar` is not the argument of the `-sourcepath` and `--module-path`. > Command is like: `javac -classpath test.jar -d use -sourcepath use use/module-info.java use/TestUse.java` > > We can see that these five requirements are difficult to meet. > - Generally, our jar files shouldn't have the `*.java` files and only have the `*.class` files. But some libs that the user uses have these `*.java`files unexpectedly . > - And the class files are always compiled from the source files so that it is almost impossible that the last modified time of the `*.java` files is newer than `*.class` files. > - Generally, if we use the module system to construct our source code, we should compile the source code by using option `--module-path` instead of `-classpath`. > Command is like: javac **--module-path** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java > instead of: javac **-classpath** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java > However, the option `-classpath` is used by the maven at this situation (which no `requires` directive is in the `module-info.java`). > > It is a combination of the java compiler(has no null check), the maven building tools(use `-classpath`), > the extra libraries(have `*.java` files in the jar file) and the user's moduled project codes(have no corresponding module directive). > > Anyway, we actually meet it now which is provided by the user. > Hope you are not confused by these descriptions. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4523 From hannesw at openjdk.java.net Mon Aug 16 11:45:25 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 16 Aug 2021 11:45:25 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments In-Reply-To: References: Message-ID: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com> On Fri, 13 Aug 2021 03:51:23 GMT, Jonathan Gibbons wrote: > Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. > > It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. > > There are three cases to consider: > > * The comment itself is missing: this was already checked and reported as "missing comment". > * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". > * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". > > No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. > > Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) > > Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. > > A new test is added, focussing on the different forms of empty/missing descriptions, as described above. Looks good. One thing I wonder about is why you only look for `@deprecated` in the first block tag. I guess it is just a convention to add this tag at the first position? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 203: > 201: // Don't report an empty description if the comment begins with @deprecated, > 202: // because javadoc will use the content of that tag in summary tables. > 203: if (firstTag.getKind() != DocTree.Kind.DEPRECATED) { Why do we only check the first block tag here? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 204: > 202: // because javadoc will use the content of that tag in summary tables. > 203: if (firstTag.getKind() != DocTree.Kind.DEPRECATED) { > 204: env.messages.report(MISSING, Kind.WARNING, tree, "dc.empty.description"); Is there a reason to not use `reportMissing` here? ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5106 From jjg at openjdk.java.net Mon Aug 16 17:11:29 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 16 Aug 2021 17:11:29 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments In-Reply-To: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com> References: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com> Message-ID: <8_n_Wcn6QF4nXLkgtIgrlTSKESOi5HmTpC_a4pcUKMM=.c9499fce-31b5-40ee-a806-2e92d5894bd6@github.com> On Fri, 13 Aug 2021 09:20:19 GMT, Hannes Walln?fer wrote: >> Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. >> >> It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. >> >> There are three cases to consider: >> >> * The comment itself is missing: this was already checked and reported as "missing comment". >> * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". >> * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". >> >> No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. >> >> Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) >> >> Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. >> >> A new test is added, focussing on the different forms of empty/missing descriptions, as described above. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 203: > >> 201: // Don't report an empty description if the comment begins with @deprecated, >> 202: // because javadoc will use the content of that tag in summary tables. >> 203: if (firstTag.getKind() != DocTree.Kind.DEPRECATED) { > > Why do we only check the first block tag here? Various reasons, 1. It seems the convention is to simply prefix an existing comment with `@deprecated` or to replace the existing body description with `@deprecated reason-why-deprecated` 2. This is only for the case when there is no body description; it seems hard to imagine that someone would start a comment with `@see` `@param` `@return` etc and then have the `@deprecated` tag. That being said, it would be easy enough to change the code to check for any instance of `@deprecated`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5106 From jjg at openjdk.java.net Mon Aug 16 17:18:29 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 16 Aug 2021 17:18:29 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments In-Reply-To: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com> References: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com> Message-ID: On Fri, 13 Aug 2021 09:21:40 GMT, Hannes Walln?fer wrote: >> Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. >> >> It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. >> >> There are three cases to consider: >> >> * The comment itself is missing: this was already checked and reported as "missing comment". >> * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". >> * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". >> >> No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. >> >> Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) >> >> Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. >> >> A new test is added, focussing on the different forms of empty/missing descriptions, as described above. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 204: > >> 202: // because javadoc will use the content of that tag in summary tables. >> 203: if (firstTag.getKind() != DocTree.Kind.DEPRECATED) { >> 204: env.messages.report(MISSING, Kind.WARNING, tree, "dc.empty.description"); > > Is there a reason to not use `reportMissing` here? It doesn't have the right signature. `reportMissing` reports a missing comment on an element; here, we're reporting a missing description within a `DocTree`. There's a similar occurrence at line 1214. ------------- PR: https://git.openjdk.java.net/jdk/pull/5106 From jjg at openjdk.java.net Mon Aug 16 17:22:31 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 16 Aug 2021 17:22:31 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments In-Reply-To: <8_n_Wcn6QF4nXLkgtIgrlTSKESOi5HmTpC_a4pcUKMM=.c9499fce-31b5-40ee-a806-2e92d5894bd6@github.com> References: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com> <8_n_Wcn6QF4nXLkgtIgrlTSKESOi5HmTpC_a4pcUKMM=.c9499fce-31b5-40ee-a806-2e92d5894bd6@github.com> Message-ID: <2nzruNweIsajakC9eWy6UFJVrR6m5T4TDQuSvxP5PaY=.ec56f7db-f398-4d74-aa9f-f8c0b47a690b@github.com> On Mon, 16 Aug 2021 17:08:13 GMT, Jonathan Gibbons wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 203: >> >>> 201: // Don't report an empty description if the comment begins with @deprecated, >>> 202: // because javadoc will use the content of that tag in summary tables. >>> 203: if (firstTag.getKind() != DocTree.Kind.DEPRECATED) { >> >> Why do we only check the first block tag here? > > Various reasons, > 1. It seems the convention is to simply prefix an existing comment with `@deprecated` or to replace the existing body description with `@deprecated reason-why-deprecated` > 2. This is only for the case when there is no body description; it seems hard to imagine that someone would start a comment with `@see` `@param` `@return` etc and then have the `@deprecated` tag. > > That being said, it would be easy enough to change the code to check for any instance of `@deprecated`. Given that the downstream code does not impose any ordering restrictions on the tags, it is probably with doing the same here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5106 From jjg at openjdk.java.net Mon Aug 16 17:38:05 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 16 Aug 2021 17:38:05 GMT Subject: RFR: JDK-8272374: doclint should report missing "body" comments [v2] In-Reply-To: References: Message-ID: > Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. > > It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. > > There are three cases to consider: > > * The comment itself is missing: this was already checked and reported as "missing comment". > * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". > * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". > > No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. > > Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) > > Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. > > A new test is added, focussing on the different forms of empty/missing descriptions, as described above. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: address review comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5106/files - new: https://git.openjdk.java.net/jdk/pull/5106/files/60c6f569..6c875688 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5106&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5106&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5106.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5106/head:pull/5106 PR: https://git.openjdk.java.net/jdk/pull/5106 From jjg at openjdk.java.net Mon Aug 16 20:51:32 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 16 Aug 2021 20:51:32 GMT Subject: Integrated: JDK-8272374: doclint should report missing "body" comments In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 03:51:23 GMT, Jonathan Gibbons wrote: > Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. > > It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. > > There are three cases to consider: > > * The comment itself is missing: this was already checked and reported as "missing comment". > * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". > * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". > > No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. > > Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) > > Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. > > A new test is added, focussing on the different forms of empty/missing descriptions, as described above. This pull request has now been integrated. Changeset: ae45592d Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/ae45592d3304f50aa9e8e114416a41e7899fe37b Stats: 280 lines in 37 files changed: 151 ins; 10 del; 119 mod 8272374: doclint should report missing "body" comments Reviewed-by: kcr, hannesw ------------- PR: https://git.openjdk.java.net/jdk/pull/5106 From jjg at openjdk.java.net Mon Aug 16 22:45:41 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 16 Aug 2021 22:45:41 GMT Subject: RFR: JDK-8271227: Missing `{@code }` in com.sun.source.* Message-ID: Please review a simple `noreg-doc` update to files in the `com.sun.source.*` API, to enclose type names in the descriptions in doc comments with `{@code }`. Apart from fixing one typo, the changes are all formatting changes, with no changes to the content of the spec, so no CSR. ------------- Commit messages: - JDK-8271227: Missing `{@code }` in com.sun.source.* Changes: https://git.openjdk.java.net/jdk/pull/5133/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5133&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271227 Stats: 133 lines in 3 files changed: 0 ins; 0 del; 133 mod Patch: https://git.openjdk.java.net/jdk/pull/5133.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5133/head:pull/5133 PR: https://git.openjdk.java.net/jdk/pull/5133 From iris at openjdk.java.net Mon Aug 16 22:55:30 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 16 Aug 2021 22:55:30 GMT Subject: RFR: JDK-8271227: Missing `{@code }` in com.sun.source.* In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 22:37:25 GMT, Jonathan Gibbons wrote: > Please review a simple `noreg-doc` update to files in the `com.sun.source.*` API, to enclose type names in the descriptions in doc comments with `{@code }`. > > Apart from fixing one typo, the changes are all formatting changes, with no changes to the content of the spec, so no CSR. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5133 From jjg at openjdk.java.net Mon Aug 16 22:58:31 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 16 Aug 2021 22:58:31 GMT Subject: Integrated: JDK-8271227: Missing `{@code }` in com.sun.source.* In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 22:37:25 GMT, Jonathan Gibbons wrote: > Please review a simple `noreg-doc` update to files in the `com.sun.source.*` API, to enclose type names in the descriptions in doc comments with `{@code }`. > > Apart from fixing one typo, the changes are all formatting changes, with no changes to the content of the spec, so no CSR. This pull request has now been integrated. Changeset: 3fb19279 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/3fb19279da240ecabee04148ba8907f036450575 Stats: 133 lines in 3 files changed: 0 ins; 0 del; 133 mod 8271227: Missing `{@code }` in com.sun.source.* Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5133 From vromero at openjdk.java.net Tue Aug 17 17:05:43 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 17 Aug 2021 17:05:43 GMT Subject: RFR: 8270835: regression after JDK-8261006 Message-ID: This patch is fixing a regression introduced by the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006), which was trying to fix a long standing bug in javac. These are the related sections in the spec: According to: 8.1.3 Inner Classes and Enclosing Instances: A construct (statement, local variable declaration statement, local class declaration, local interface declaration, or expression) occurs in a static context if the innermost: ... ? explicit constructor invocation statement which encloses the construct is one of the following: ? an explicit constructor invocation statement (?8.8.7.1) ... ... The purpose of a static context is to demarcate code that must not refer explicitly or implicitly to the current instance of the class whose declaration lexically encloses the static context. Consequently, code that occurs in a static context is restricted in the following ways: ? Field accesses, method invocations, and method references may not be qualified by super (?15.11.2, ?15.12.3, ?15.13.1). also from: 15.13 Method Reference Expressions: If a method reference expression has the form super :: [TypeArguments] Identifier or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if the expression occurs in a static context (?8.1.3). Meaning that code like: this(Feature.super::getString); or this(Feature.super.getString()); should be rejected by the compiler and it wasn't before the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006). The regression was introduced because after [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006) this code was rejected when it shouldn't: class A extends B { A(int i) {} class C extends B { class D extends S { D(float f) { C.super.ref.super(); // ok } } } } class B { B ref; class S {} } so it is OK to use `super` in the constructor's invocation qualifier but not in its arguments. So while processing the arguments or the qualifier of a constructor invocation, the compiler needs to know precisely what portion of the expression it is dealing with as different rules apply for the use of `this` or `super` in them. This is why this fix is adding a new flag to AttrContext to indicate if we are dealing with a constructor invocation argument or not. TIA ------------- Commit messages: - 8270835: regression after JDK-8261006 Changes: https://git.openjdk.java.net/jdk/pull/5149/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5149&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270835 Stats: 52 lines in 4 files changed: 51 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5149.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5149/head:pull/5149 PR: https://git.openjdk.java.net/jdk/pull/5149 From jlahoda at openjdk.java.net Tue Aug 17 20:41:22 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 17 Aug 2021 20:41:22 GMT Subject: RFR: 8270835: regression after JDK-8261006 In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 16:57:26 GMT, Vicente Romero wrote: > This patch is fixing a regression introduced by the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006), which was trying to fix a long standing bug in javac. These are the related sections in the spec: > > > According to: 8.1.3 Inner Classes and Enclosing Instances: > > A construct (statement, local variable declaration statement, local class declaration, > local interface declaration, or expression) occurs in a static context if the innermost: > ... > ? explicit constructor invocation statement > > which encloses the construct is one of the following: > ? an explicit constructor invocation statement (?8.8.7.1) > ... > ... > The purpose of a static context is to demarcate code that must not refer explicitly or > implicitly to the current instance of the class whose declaration lexically encloses the static > context. Consequently, code that occurs in a static context is restricted in the following > ways: > ? Field accesses, method invocations, and method references may not be qualified by super (?15.11.2, ?15.12.3, ?15.13.1). > > also from: 15.13 Method Reference Expressions: > > If a method reference expression has the form super :: [TypeArguments] Identifier > or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if > the expression occurs in a static context (?8.1.3). > > Meaning that code like: > > this(Feature.super::getString); or > this(Feature.super.getString()); > > should be rejected by the compiler and it wasn't before the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006). The regression was introduced because after [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006) this code was rejected when it shouldn't: > > class A extends B { > A(int i) {} > > class C extends B { > class D extends S { > D(float f) { > C.super.ref.super(); // ok > } > } > } > } > > class B { > B ref; > class S {} > } > > so it is OK to use `super` in the constructor's invocation qualifier but not in its arguments. So while processing the arguments or the qualifier of a constructor invocation, the compiler needs to know precisely what portion of the expression it is dealing with as different rules apply for the use of `this` or `super` in them. This is why this fix is adding a new flag to AttrContext to indicate if we are dealing with a constructor invocation argument or not. > > TIA Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5149 From vromero at openjdk.java.net Tue Aug 17 20:51:28 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 17 Aug 2021 20:51:28 GMT Subject: RFR: 8270835: regression after JDK-8261006 In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 16:57:26 GMT, Vicente Romero wrote: > This patch is fixing a regression introduced by the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006), which was trying to fix a long standing bug in javac. These are the related sections in the spec: > > > According to: 8.1.3 Inner Classes and Enclosing Instances: > > A construct (statement, local variable declaration statement, local class declaration, > local interface declaration, or expression) occurs in a static context if the innermost: > ... > ? explicit constructor invocation statement > > which encloses the construct is one of the following: > ? an explicit constructor invocation statement (?8.8.7.1) > ... > ... > The purpose of a static context is to demarcate code that must not refer explicitly or > implicitly to the current instance of the class whose declaration lexically encloses the static > context. Consequently, code that occurs in a static context is restricted in the following > ways: > ? Field accesses, method invocations, and method references may not be qualified by super (?15.11.2, ?15.12.3, ?15.13.1). > > also from: 15.13 Method Reference Expressions: > > If a method reference expression has the form super :: [TypeArguments] Identifier > or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if > the expression occurs in a static context (?8.1.3). > > Meaning that code like: > > this(Feature.super::getString); or > this(Feature.super.getString()); > > should be rejected by the compiler and it wasn't before the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006). The regression was introduced because after [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006) this code was rejected when it shouldn't: > > class A extends B { > A(int i) {} > > class C extends B { > class D extends S { > D(float f) { > C.super.ref.super(); // ok > } > } > } > } > > class B { > B ref; > class S {} > } > > so it is OK to use `super` in the constructor's invocation qualifier but not in its arguments. So while processing the arguments or the qualifier of a constructor invocation, the compiler needs to know precisely what portion of the expression it is dealing with as different rules apply for the use of `this` or `super` in them. This is why this fix is adding a new flag to AttrContext to indicate if we are dealing with a constructor invocation argument or not. > > TIA thanks for the review ------------- PR: https://git.openjdk.java.net/jdk/pull/5149 From vromero at openjdk.java.net Tue Aug 17 20:51:30 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 17 Aug 2021 20:51:30 GMT Subject: Integrated: 8270835: regression after JDK-8261006 In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 16:57:26 GMT, Vicente Romero wrote: > This patch is fixing a regression introduced by the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006), which was trying to fix a long standing bug in javac. These are the related sections in the spec: > > > According to: 8.1.3 Inner Classes and Enclosing Instances: > > A construct (statement, local variable declaration statement, local class declaration, > local interface declaration, or expression) occurs in a static context if the innermost: > ... > ? explicit constructor invocation statement > > which encloses the construct is one of the following: > ? an explicit constructor invocation statement (?8.8.7.1) > ... > ... > The purpose of a static context is to demarcate code that must not refer explicitly or > implicitly to the current instance of the class whose declaration lexically encloses the static > context. Consequently, code that occurs in a static context is restricted in the following > ways: > ? Field accesses, method invocations, and method references may not be qualified by super (?15.11.2, ?15.12.3, ?15.13.1). > > also from: 15.13 Method Reference Expressions: > > If a method reference expression has the form super :: [TypeArguments] Identifier > or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if > the expression occurs in a static context (?8.1.3). > > Meaning that code like: > > this(Feature.super::getString); or > this(Feature.super.getString()); > > should be rejected by the compiler and it wasn't before the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006). The regression was introduced because after [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006) this code was rejected when it shouldn't: > > class A extends B { > A(int i) {} > > class C extends B { > class D extends S { > D(float f) { > C.super.ref.super(); // ok > } > } > } > } > > class B { > B ref; > class S {} > } > > so it is OK to use `super` in the constructor's invocation qualifier but not in its arguments. So while processing the arguments or the qualifier of a constructor invocation, the compiler needs to know precisely what portion of the expression it is dealing with as different rules apply for the use of `this` or `super` in them. This is why this fix is adding a new flag to AttrContext to indicate if we are dealing with a constructor invocation argument or not. > > TIA This pull request has now been integrated. Changeset: 14623cde Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/14623cde3a20962e902043b556c5058ac208711f Stats: 52 lines in 4 files changed: 51 ins; 0 del; 1 mod 8270835: regression after JDK-8261006 Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/5149 From turbanoff at gmail.com Wed Aug 18 07:50:25 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Wed, 18 Aug 2021 10:50:25 +0300 Subject: Suspicious 'noOuterThisPath' variable in com.sun.tools.javac.comp.Attr#visitIdent Message-ID: Hello. During investigation of results of IDEA inspections I found suspicious code in a method 'com.sun.tools.javac.comp.Attr#visitIdent' https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L4194 Env symEnv = env; boolean noOuterThisPath = false; if (env.enclClass.sym.owner.kind != PCK && // we are in an inner class sym.kind.matches(KindSelector.VAL_MTH) && sym.owner.kind == TYP && tree.name != names._this && tree.name != names._super) { // Find environment in which identifier is defined. while (symEnv.outer != null && !sym.isMemberOf(symEnv.enclClass.sym, types)) { if ((symEnv.enclClass.sym.flags() & NOOUTERTHIS) != 0) noOuterThisPath = false; symEnv = symEnv.outer; } } Variable 'noOuterThisPath' has initially assigned a 'false' value. And then in cycle it again can be set to 'false'. There are only 2 places where noOuterThisPath is assigned. It seems it should be set to 'true' in one of the places. Andrey Turbanov From jan.lahoda at oracle.com Wed Aug 18 08:37:21 2021 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 18 Aug 2021 10:37:21 +0200 Subject: Suspicious 'noOuterThisPath' variable in com.sun.tools.javac.comp.Attr#visitIdent In-Reply-To: References: Message-ID: <2e70abbd-f956-e1be-f1ec-6922ee4b8ec4@oracle.com> Hi Andrey, Thanks for the report. I believe this is a leftover from -source <= 5 removal. The original code was: noOuterThisPath = !allowAnonOuterThis; where allowAnonOuterThis was true for -source >= 5, and with the removal, "!allowAnonOuterThis" was changed to always be false. I've filled: https://bugs.openjdk.java.net/browse/JDK-8272618 Thanks, ???? Jan On 18. 08. 21 9:50, Andrey Turbanov wrote: > Hello. > > During investigation of results of IDEA inspections I found suspicious > code in a method 'com.sun.tools.javac.comp.Attr#visitIdent' > https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L4194 > > Env symEnv = env; > boolean noOuterThisPath = false; > if (env.enclClass.sym.owner.kind != PCK && // we are in an inner class > sym.kind.matches(KindSelector.VAL_MTH) && > sym.owner.kind == TYP && > tree.name != names._this && tree.name != names._super) { > > // Find environment in which identifier is defined. > while (symEnv.outer != null && > !sym.isMemberOf(symEnv.enclClass.sym, types)) { > if ((symEnv.enclClass.sym.flags() & NOOUTERTHIS) != 0) > noOuterThisPath = false; > symEnv = symEnv.outer; > } > } > > > Variable 'noOuterThisPath' has initially assigned a 'false' value. > And then in cycle it again can be set to 'false'. > There are only 2 places where noOuterThisPath is assigned. > It seems it should be set to 'true' in one of the places. > > > Andrey Turbanov From jlahoda at openjdk.java.net Wed Aug 18 11:50:35 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 18 Aug 2021 11:50:35 GMT Subject: RFR: 8272618: Unnecessary Attr.visitIdent.noOuterThisPath Message-ID: This patch removes an unnecessary variable, which was not removed when `-source <= 5` was removed: https://bugs.openjdk.java.net/browse/JDK-8011044 ------------- Commit messages: - 8272618: Unnecessary Attr.visitIndent.noOuterThisPath Changes: https://git.openjdk.java.net/jdk/pull/5163/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5163&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272618 Stats: 11 lines in 1 file changed: 0 ins; 8 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5163.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5163/head:pull/5163 PR: https://git.openjdk.java.net/jdk/pull/5163 From jlahoda at openjdk.java.net Wed Aug 18 13:55:45 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 18 Aug 2021 13:55:45 GMT Subject: RFR: 8272564: Incorrect attribution of method invocations of Object methods on interfaces Message-ID: 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. ------------- Commit messages: - 8272564: Incorrect attribution of method invocations of Object methods on interfaces Changes: https://git.openjdk.java.net/jdk/pull/5165/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5165&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272564 Stats: 169 lines in 5 files changed: 166 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5165.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5165/head:pull/5165 PR: https://git.openjdk.java.net/jdk/pull/5165 From jlaskey at openjdk.java.net Wed Aug 18 14:19:29 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 18 Aug 2021 14:19:29 GMT Subject: RFR: 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. Marked as reviewed by jlaskey (Reviewer). test/langtools/tools/javac/api/TestIsAccessible.java line 61: > 59: for (Element member : ct.getElements().getAllMembers(name)) { > 60: if (!trees.isAccessible(s, member, (DeclaredType) name.asType())) { > 61: trees.isAccessible(s, member, (DeclaredType) name.asType()); Why is this statement necessary? ------------- PR: https://git.openjdk.java.net/jdk/pull/5165 From vromero at openjdk.java.net Wed Aug 18 15:38:24 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 18 Aug 2021 15:38:24 GMT Subject: RFR: 8272618: Unnecessary Attr.visitIdent.noOuterThisPath In-Reply-To: References: Message-ID: <2IK3bQ_WDRtYs057Vdmv0KyadEzOFx0i8WVMsYFAAcA=.03f971ac-b661-4eb1-b169-6889557e90d9@github.com> On Wed, 18 Aug 2021 11:42:55 GMT, Jan Lahoda wrote: > This patch removes an unnecessary variable, which was not removed when `-source <= 5` was removed: > https://bugs.openjdk.java.net/browse/JDK-8011044 lgtm ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5163 From vromero at openjdk.java.net Wed Aug 18 18:59:24 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 18 Aug 2021 18:59:24 GMT Subject: RFR: 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. I think that this one deserves a CSR, plus please consider also running the JCK tests just to double check ------------- PR: https://git.openjdk.java.net/jdk/pull/5165 From vromero at openjdk.java.net Thu Aug 19 02:59:22 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 19 Aug 2021 02:59:22 GMT Subject: RFR: 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. question shouldn't field `supertype_field` in ClassType be assigned something different than j.l.Objet for interfaces with no super interface after your change? ------------- PR: https://git.openjdk.java.net/jdk/pull/5165 From jlahoda at openjdk.java.net Thu Aug 19 12:56:58 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 19 Aug 2021 12:56:58 GMT Subject: RFR: 8272564: Incorrect attribution of method invocations of Object methods on interfaces [v2] In-Reply-To: References: Message-ID: > 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. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Removing unnecessary method call. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5165/files - new: https://git.openjdk.java.net/jdk/pull/5165/files/1a672cef..9ea15dcc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5165&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5165&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5165.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5165/head:pull/5165 PR: https://git.openjdk.java.net/jdk/pull/5165 From jlahoda at openjdk.java.net Thu Aug 19 12:57:00 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 19 Aug 2021 12:57:00 GMT Subject: RFR: 8272564: Incorrect attribution of method invocations of Object methods on interfaces In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 18:55:28 GMT, Vicente Romero wrote: > I think that this one deserves a CSR, plus please consider also running the JCK tests just to double check Thanks, I've started to file the CSR here, please take a look: https://bugs.openjdk.java.net/browse/JDK-8272564 > question shouldn't field `supertype_field` in ClassType be assigned something different than j.l.Objet for interfaces with no super interface after your change? Not having interfaces "subclass" `j.l.Object` would be an alternative variant of the fix (it would probably remove the need to these changes altogether). In my experiments, it seemed quite complex to do, however. I can try again, if desired. Thanks for the comments! ------------- PR: https://git.openjdk.java.net/jdk/pull/5165 From jlahoda at openjdk.java.net Thu Aug 19 12:57:06 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 19 Aug 2021 12:57:06 GMT Subject: RFR: 8272564: Incorrect attribution of method invocations of Object methods on interfaces [v2] In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 14:16:10 GMT, Jim Laskey wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing unnecessary method call. > > test/langtools/tools/javac/api/TestIsAccessible.java line 61: > >> 59: for (Element member : ct.getElements().getAllMembers(name)) { >> 60: if (!trees.isAccessible(s, member, (DeclaredType) name.asType())) { >> 61: trees.isAccessible(s, member, (DeclaredType) name.asType()); > > Why is this statement necessary? Ooops, that is a leftover from testing (so that I can easily put a breakpoint on the call when false). ------------- PR: https://git.openjdk.java.net/jdk/pull/5165 From vromero at openjdk.java.net Thu Aug 19 14:32:27 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 19 Aug 2021 14:32:27 GMT Subject: RFR: 8272564: Incorrect attribution of method invocations of Object methods on interfaces In-Reply-To: References: Message-ID: <5CVG_-l9Av-hjgiJDz58Admat4eMHeCedv_X0hDKxGg=.2e376193-c2b5-49ce-a804-75b82fd2316e@github.com> On Thu, 19 Aug 2021 12:53:26 GMT, Jan Lahoda wrote: > > I think that this one deserves a CSR, plus please consider also running the JCK tests just to double check > > Thanks, I've started to file the CSR here, please take a look: > https://bugs.openjdk.java.net/browse/JDK-8272564 > > > question shouldn't field `supertype_field` in ClassType be assigned something different than j.l.Objet for interfaces with no super interface after your change? > > Not having interfaces "subclass" `j.l.Object` would be an alternative variant of the fix (it would probably remove the need to these changes altogether). In my experiments, it seemed quite complex to do, however. I can try again, if desired. > > Thanks for the comments! yep I was also considering that it would be a big change, but seems like the right thing to do, I let it to your consideration ------------- PR: https://git.openjdk.java.net/jdk/pull/5165 From github.com+741251+turbanoff at openjdk.java.net Thu Aug 19 21:13:24 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 19 Aug 2021 21:13:24 GMT Subject: RFR: 8272618: Unnecessary Attr.visitIdent.noOuterThisPath In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 11:42:55 GMT, Jan Lahoda wrote: > This patch removes an unnecessary variable, which was not removed when `-source <= 5` was removed: > https://bugs.openjdk.java.net/browse/JDK-8011044 Marked as reviewed by turbanoff at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/5163 From manoj.palat at in.ibm.com Fri Aug 20 11:37:16 2021 From: manoj.palat at in.ibm.com (Manoj Palat) Date: Fri, 20 Aug 2021 11:37:16 +0000 Subject: [17][Pattern Switch] NPE not thrown for a null with default, (non-total) type pattern case labels Message-ID: An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Fri Aug 20 12:41:58 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 20 Aug 2021 08:41:58 -0400 Subject: [17][Pattern Switch] NPE not thrown for a null with default, (non-total) type pattern case labels In-Reply-To: References: Message-ID: Agree, this should NPE. On 8/20/2021 7:37 AM, Manoj Palat wrote: > Hi, > ?Consider the following case: > class X { > public void foo(Object o) { > switch (o) { > default: break; > case String s :System.out.println(s); break; > } > } > public static void main(String[] args) { > (new X()).foo(null); // NPE expected, but prints null > } > } > javac (17+ea35)? prints a null rather than an NPE. I believe it should > throw NullPointerException (rather? javac should generate code for > Null check to raise NPE at run-time). > Reasoning behind this is [based on > https://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html#jls-14.11.3 > ]: > section 14.11.3, see the second rule: > ... > Otherwise, if the result of evaluating the selector expression is null, and no switch label in the resolved switch block applies then a NullPointerException is thrown... > I don't think?either of the switch labels?apply here > [based on sec 14.11.1 > If the value is the null reference, then we determine the first (if any) switch label in the switch block that applies to the value as follows: > > A switch label...] > Hence I believe an NPE should be thrown for null. > [A longer version of reasoning at: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=575051#c4 > ] > Please let me know your take on this. > Regards, > Manoj > [Note: If the case labels are swapped, ie if its in the order shown > below, NPE is thrown at run-time > case String s :System.out.println(s); break; > default: break; ] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Aug 20 13:04:56 2021 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 20 Aug 2021 15:04:56 +0200 Subject: [17][Pattern Switch] NPE not thrown for a null with default, (non-total) type pattern case labels In-Reply-To: References: Message-ID: Hi Manoj, Thanks for the report, filled as: https://bugs.openjdk.java.net/browse/JDK-8272776 Jan On 20. 08. 21 13:37, Manoj Palat wrote: > Hi, > ?Consider the following case: > class X { > public void foo(Object o) { > switch (o) { > default: break; > case String s :System.out.println(s); break; > } > } > public static void main(String[] args) { > (new X()).foo(null); // NPE expected, but prints null > } > } > javac (17+ea35)? prints a null rather than an NPE. I believe it should > throw NullPointerException (rather? javac should generate code for > Null check to raise NPE at run-time). > Reasoning behind this is [based on > https://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html#jls-14.11.3 > ]: > section 14.11.3, see the second rule: > ... > Otherwise, if the result of evaluating the selector expression is null, and no switch label in the resolved switch block applies then a NullPointerException is thrown... > I don't think?either of the switch labels?apply here > [based on sec 14.11.1 > If the value is the null reference, then we determine the first (if any) switch label in the switch block that applies to the value as follows: > > A switch label...] > Hence I believe an NPE should be thrown for null. > [A longer version of reasoning at: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=575051#c4 > ] > Please let me know your take on this. > Regards, > Manoj > [Note: If the case labels are swapped, ie if its in the order shown > below, NPE is thrown at run-time > case String s :System.out.println(s); break; > default: break; ] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Fri Aug 20 17:20:57 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 20 Aug 2021 10:20:57 -0700 Subject: [17][Pattern Switch] NPE not thrown for a null with default, (non-total) type pattern case labels In-Reply-To: References: Message-ID: It would be ideal for 14.11.1 to say, in a note, what every reader will otherwise be pondering: "Note that a default switch label never applies to a null value." Alex On 8/20/2021 5:41 AM, Brian Goetz wrote: > Agree, this should NPE. > > On 8/20/2021 7:37 AM, Manoj Palat wrote: >> Hi, >> ?Consider the following case: >> class X { >> public void foo(Object o) { >> switch (o) { >> default: break; >> case String s :System.out.println(s); break; >> } >> } >> public static void main(String[] args) { >> (new X()).foo(null); // NPE expected, but prints null >> } >> } >> javac (17+ea35)? prints a null rather than an NPE. I believe it should >> throw NullPointerException (rather? javac should generate code for >> Null check to raise NPE at run-time). >> Reasoning behind this is [based on >> https://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html#jls-14.11.3 >> ]: >> section 14.11.3, see the second rule: >> ... >> Otherwise, if the result of evaluating the selector expression is null, and no switch label in the resolved switch block applies then a NullPointerException is thrown... >> I don't think?either of the switch labels?apply here >> [based on sec 14.11.1 >> If the value is the null reference, then we determine the first (if any) switch label in the switch block that applies to the value as follows: >> >> A switch label...] >> Hence I believe an NPE should be thrown for null. >> [A longer version of reasoning at: >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=575051#c4 >> ] >> Please let me know your take on this. >> Regards, >> Manoj >> [Note: If the case labels are swapped, ie if its in the order shown >> below, NPE is thrown at run-time >> case String s :System.out.println(s); break; >> default: break; ] >> >> > From jjg at openjdk.java.net Fri Aug 20 18:53:33 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 20 Aug 2021 18:53:33 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 12:24:06 GMT, Pavel Rappo wrote: >> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Pass through FIXMEs and TODOs > > Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. Generally impressive piece of work. src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java line 291: > 289: > 290: /** > 291: * Visits a SnippetTree node. There's been a recent update, and these class names should now be wrapped in `{@code }` src/jdk.compiler/share/classes/com/sun/source/doctree/SnippetTree.java line 32: > 30: /** > 31: * A tree node for an {@code @snippet} inline tag, as specified by > 32: * JEP 413. The reference to a JEP is unusual. The public spec for a snippet should be in the tag spec. src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 513: > 511: > 512: /** > 513: * {@inheritDoc} This implementation scans the children in left to right order. (minor) I would suggest/recommend a line-break after the `{@inheritDoc}` Likewise for similar occurrences elsewhere. src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 516: > 514: * > 515: * @param node {@inheritDoc} > 516: * @param p {@inheritDoc} Do you need the `{@inheritDoc}` ... isn't that the default behavior if no tag is specified? Likewise for similar occurrences elsewhere. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 923: > 921: * probably be considered on a case-by-case basis, for an attribute > 922: * value of the {@snippet} tag we do not recurse. > 923: */ This discussion does not belong here. We should specify simple defensible rules (in the spec) and implement them accordingly. If there is nothing more obvious, I suggest the rules for (Unicode) identifiers. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1249: > 1247: // messages.warning( > 1248: // ch.getDocTreePath(see), "doclet.see.class_or_package_not_found", > 1249: // tagName, seeText); FIXME src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 399: > 397: classes.add(n.name()); > 398: } else if (s instanceof Style.Link l) { > 399: assert !linkEncountered; // FIXME: do not assert; pick the first link FIXME src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 406: > 404: // diagnostic output > 405: } > 406: } else if (s instanceof Style.Markup) { Is the empty `if` expected? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java line 87: > 85: snippet, > 86: // > 87: Suggest removing the editor-fold comments. It'll be listed as not-yet-categorized by virtue of being in the initial list. If the code generates standard styles, they should be listed here, so that they get documented in the sometime-forthcoming stylesheet spec. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 360: > 358: > 359: doclet.tag.attribute.repeated=\ > 360: repeated attribute: "{0}" check the resource file for other quoted values; I think you'll find single quotes are the prevailing standard. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 39: > 37: import jdk.javadoc.internal.doclets.toolkit.taglets.snippet.Parser; > 38: import jdk.javadoc.internal.doclets.toolkit.taglets.snippet.StyledText; > 39: import jdk.javadoc.internal.doclets.toolkit.util.Utils; The langtools/javac/javadoc convention is to put standard JavaSE imports (`java.*`, `javax.*` ) first. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 96: > 94: // recently encountered of two, the iteration order might differ > 95: // from the source order > 96: error(writer, holder, a, "doclet.tag.attribute.repeated", a.getName().toString()); Can we use a `LinkedHashMap` or similar to preserve encounter order? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 178: > 176: } > 177: > 178: // FIXME cache parsed external snippet (WeakHashMap) FIXME src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 260: > 258: * There's a separate issue of mapping discrepancies back to their > 259: * originating source in the doc comment and the external file. Maybe there > 260: * is a value in it, or may be there isn't. In any case, accurate mapping "maybe" src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 274: > 272: private StyledText parse(String content) throws ParseException { > 273: // FIXME: need to be able to process more fine-grained, i.e. around a particular region... > 274: // or, which is even better, cache the styled text FIXME src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 287: > 285: > 286: // FIXME: figure out how to do that correctly > 287: // FIXME: consider returning null from this method so it can be used as oneliner FIXME src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 69: > 67: // FIXME: How to treat Form Feed? (i.e. is it vertical or horizontal whitespace?) > 68: // FIXME: what to do with lines not covered by any markup? (i.e. in between markup) > 69: // FIXME: all parsing errors must be localized. FIXME src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 134: > 132: this.eolMarker = eolMarker; > 133: // capture the rightmost eolMarker (e.g. "//") > 134: // The bellow Pattern.compile should never throw PatternSyntaxException "below" ? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 177: > 175: } > 176: thisLineTags.addAll(parsedTags); > 177: for (var tagIterator = thisLineTags.iterator(); tagIterator.hasNext(); ) { oooh, not wrong; just unexpected mix of styles ;-) src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 186: > 184: } > 185: if (parsedTags.isEmpty()) { // (2) > 186: // TODO: log this with NOTICE; does this need to be addressed? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 207: > 205: > 206: append(text, Set.of(), line); > 207: // FIXME: mark up trailing whitespace! FIXME src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 376: > 374: > 375: public TypeElement getReferencedClass(Element e) { > 376: Utils utils = configuration.utils; Whinge. This new method does not really belong here, also implying that the body of the old method does not belong here (in the class) either. Generally, queries on elements belong in `Utils`, not `CommentHelper`. But, OK for now, I guess. -- As a one-off, it was OK to let this slide. Given there are repeated similar occurrences later on, can you file an RFE to move the `Element` / non-`DocTree` methods to `Utils`. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 406: > 404: > 405: public Element getReferencedMember(Element e) { > 406: Utils utils = configuration.utils; Same whinge as above. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 431: > 429: } > 430: > 431: public PackageElement getReferencedPackage(Element e) { ditto src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 444: > 442: } > 443: > 444: public ModuleElement getReferencedModule(Element e) { ditto test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 27: > 25: * @test > 26: * @bug 8201533 > 27: * @library /tools/lib ../../lib need @summary test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 81: > 79: > 80: public static void main(String... args) throws Exception { > 81: new TestSnippetTag().runTests(m -> new Object[]{Paths.get(m.getName())}); This is just a suggestion for future convenience. For big tests like this, for ease of debugging, it can be useful to be able to specify the method(s) to be executed. Maybe there should be a variants of `runTests` that takes a `String[]` or `List` test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 1508: > 1506: ) > 1507: // Uncomment when parser has improved (this would allow to write meta snippets, > 1508: // i.e. snippets showing how to write snippets. Just a question: what are the limitations in the parser that are getting in the way here? test/langtools/tools/javac/doctree/SnippetTest.java line 26: > 24: /* > 25: * @test > 26: * @bug 8201533 Need `@summary` ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From jjg at openjdk.java.net Sat Aug 21 03:16:39 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 21 Aug 2021 03:16:39 GMT Subject: RFR: JDK-8265253: javac -Xdoclint:all gives "no comment" warning for code that can't be commented Message-ID: Please review a simple update for doclint, to suppress "missing comment" warnings on the internally-synthesized class resulting from use of an anonymous class body in a member declaration in an enum class.. ------------- Commit messages: - JDK-8265253: javac -Xdoclint:all gives "no comment" warning for code that can't be commented Changes: https://git.openjdk.java.net/jdk/pull/5206/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5206&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265253 Stats: 60 lines in 3 files changed: 59 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5206.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5206/head:pull/5206 PR: https://git.openjdk.java.net/jdk/pull/5206 From serb at openjdk.java.net Sun Aug 22 06:28:18 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 22 Aug 2021 06:28:18 GMT Subject: RFR: 8272805: Avoid looking up standard charsets Message-ID: This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. See https://github.com/openjdk/jdk/pull/5063 and https://github.com/openjdk/jdk/pull/4951 In many places standard charsets are looked up via their names, for example: absolutePath.getBytes("UTF-8"); This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: absolutePath.getBytes(StandardCharsets.UTF_8); The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. This change includes: * demo/utils * jdk.xx packages * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. Also checked for "aliases" usage. Some performance discussion: https://github.com/openjdk/jdk/pull/5063 Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the "java.naming"(the change there is not straightforward, will do it later). Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. ------------- Commit messages: - Fix related imports - Merge branch 'master' into standard-encodings-in-non-public-modules - Cleanup UnsupportedEncodingException - Update PacketStream.java - Rollback TextTests, should be compatible with jdk1.4 - Rollback TextRenderTests, should be compatible with jdk1.4 - Cleanup the UnsupportedEncodingException - aliases for ISO_8859_1 - Update imageio - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/5210/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272805 Stats: 333 lines in 48 files changed: 91 ins; 123 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/5210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210 PR: https://git.openjdk.java.net/jdk/pull/5210 From weijun at openjdk.java.net Sun Aug 22 13:22:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 22 Aug 2021 13:22:38 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: <0eO4SD_N9lrP5k5bhEejUKXeMauRC8zuc_slUJSrc5c=.c886ae36-5039-450f-9293-5f9910ce432d@github.com> On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. The security related change looks fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5210 From alanb at openjdk.java.net Sun Aug 22 15:12:26 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 22 Aug 2021 15:12:26 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342: > 340: > 341: try { > 342: for (String line : Files.readAllLines(statusPath, UTF_8)) { The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want. ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From github.com+741251+turbanoff at openjdk.java.net Sun Aug 22 18:34:26 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 22 Aug 2021 18:34:26 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too. ![???????????](https://user-images.githubusercontent.com/741251/130366051-ef093bf1-d7d9-4ad1-91e7-5df5af8678af.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From serb at openjdk.java.net Sun Aug 22 23:02:06 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 22 Aug 2021 23:02:06 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Sergey Bylokhov 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 14 additional commits since the last revision: - Update the usage of Files.readAllLines() - Update datatransfer - Merge branch 'master' into standard-encodings-in-non-public-modules - Merge branch 'master' into standard-encodings-in-non-public-modules - Fix related imports - Merge branch 'master' into standard-encodings-in-non-public-modules - Cleanup UnsupportedEncodingException - Update PacketStream.java - Rollback TextTests, should be compatible with jdk1.4 - Rollback TextRenderTests, should be compatible with jdk1.4 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/37357100...e7127644 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5210/files - new: https://git.openjdk.java.net/jdk/pull/5210/files/2d9c80b8..e7127644 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=00-01 Stats: 3598 lines in 210 files changed: 2055 ins; 1115 del; 428 mod Patch: https://git.openjdk.java.net/jdk/pull/5210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210 PR: https://git.openjdk.java.net/jdk/pull/5210 From naoto at openjdk.java.net Mon Aug 23 00:26:31 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 23 Aug 2021 00:26:31 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/c262b06f...e7127644 Looks good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5210 From dfuchs at openjdk.java.net Mon Aug 23 09:36:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 23 Aug 2021 09:36:40 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/db47f6e1...e7127644 Changes to http server look good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5210 From hannesw at openjdk.java.net Mon Aug 23 12:59:31 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 23 Aug 2021 12:59:31 GMT Subject: RFR: JDK-8265253: javac -Xdoclint:all gives "no comment" warning for code that can't be commented In-Reply-To: References: Message-ID: <1ekvRzAVGtgHy_BxyZJ3sgckF327v-71dtrLJhlxwp4=.d5d5af05-212d-4c30-aede-7e657e719736@github.com> On Sat, 21 Aug 2021 03:08:41 GMT, Jonathan Gibbons wrote: > Please review a simple update for doclint, to suppress "missing comment" warnings on the internally-synthesized class resulting from use of an anonymous class body in a member declaration in an enum class.. Looks good. ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5206 From prappo at openjdk.java.net Mon Aug 23 14:08:52 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 23 Aug 2021 14:08:52 GMT Subject: RFR: 8266666: Implementation for snippets [v8] In-Reply-To: References: Message-ID: <3xHiNyTqxKK4xHo1s5mucwvbIc9x8T0O7pbKCFGZ_4o=.5d7f6a13-e185-4df6-b92f-91c6520a5ad0@github.com> > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into 8266666 - Pass through FIXMEs and TODOs Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Co-authored-by: Hannes Wallnoefer - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Co-authored-by: Hannes Wallnoefer - Change AnnotatedText to StyledText Renames the class, removes its generic parameter, and changes the related terminology from "annotate" to "style". - Restructure ...toolkit.taglets.snippet.** packages This commit moves the contents of the jdk.javadoc.internal.doclets.toolkit.taglets.snippet.{action,parser,text} packages into the jdk.javadoc.internal.doclets.toolkit.taglets.snippet package. - Make CSS rules more specific - Improve comments This commit adds trivial commentary to some of the Java declarations. This commit also adds the "This is NOT part of any supported API..." disclaimer. - Update @since tags - Update copyright years - ... and 2 more: https://git.openjdk.java.net/jdk/compare/b7f75c0a...e1dbd98d ------------- Changes: https://git.openjdk.java.net/jdk/pull/4795/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=07 Stats: 4716 lines in 44 files changed: 4689 ins; 4 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Mon Aug 23 14:08:53 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 23 Aug 2021 14:08:53 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: <0Wi4TkCH6CinNMMZnY56KyT1YWBz34P2kwiXOo0ZrUg=.80c9f0ab-1af9-446e-9d36-697104019f64@github.com> On Fri, 20 Aug 2021 17:45:21 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java line 291: > >> 289: >> 290: /** >> 291: * Visits a SnippetTree node. > > There's been a recent update, and these class names should now be wrapped in `{@code }` I was aware of that update and hoped to incorporate it properly with the next merge, which I've just done: e1dbd98dfa51f7568e787b1b72a6e30bfc6f4987 ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Mon Aug 23 15:22:35 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 23 Aug 2021 15:22:35 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 17:49:03 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 513: > >> 511: >> 512: /** >> 513: * {@inheritDoc} This implementation scans the children in left to right order. > > (minor) > I would suggest/recommend a line-break after the `{@inheritDoc}` > Likewise for similar occurrences elsewhere. See https://github.com/openjdk/jdk/pull/4795#discussion_r694070081. Let's NOT do it in this PR. > src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 516: > >> 514: * >> 515: * @param node {@inheritDoc} >> 516: * @param p {@inheritDoc} > > Do you need the `{@inheritDoc}` ... isn't that the default behavior if no tag is specified? > > Likewise for similar occurrences elsewhere. I don't think that I need `{@inheritDoc}` to inherit the comments in that and the similar cases in that file. I used that style because other parts of the file use it and I didn't want to update the file inconsistently. If we don't like that style, we are free to change it. That said, let's NOT do it in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Mon Aug 23 15:31:08 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 23 Aug 2021 15:31:08 GMT Subject: RFR: 8266666: Implementation for snippets [v9] In-Reply-To: References: Message-ID: <8npES8SI6DiPj2CIU2FPqcFUw6G10V-cfCQVNus6ZfU=.f7f7e83f-a68a-4a89-9300-4c14397851d7@github.com> > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Remove JEP link from SnippetTree ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/e1dbd98d..942b1e98 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Mon Aug 23 15:31:13 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 23 Aug 2021 15:31:13 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 17:46:38 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > src/jdk.compiler/share/classes/com/sun/source/doctree/SnippetTree.java line 32: > >> 30: /** >> 31: * A tree node for an {@code @snippet} inline tag, as specified by >> 32: * JEP 413. > > The reference to a JEP is unusual. The public spec for a snippet should be in the tag spec. Fixed in 942b1e9874f1f103b75c9d1b737b289296254dc7. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Mon Aug 23 16:04:34 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 23 Aug 2021 16:04:34 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 17:54:37 GMT, Jonathan Gibbons wrote: > This discussion does not belong here. I've hoped to specify tag syntax before we push this PR. Until the syntax has been specified, the comment has to be stored somewhere. What would be an appropriate place to store that comment in? > I suggest the rules for (Unicode) identifiers What do those rules look like? Do you have a link handy? ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Mon Aug 23 16:12:00 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 23 Aug 2021 16:12:00 GMT Subject: RFR: 8266666: Implementation for snippets [v10] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Remove superfluous editor-fold ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/942b1e98..731a1a6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=08-09 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Mon Aug 23 16:12:05 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 23 Aug 2021 16:12:05 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 18:03:12 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java line 87: > >> 85: snippet, >> 86: // >> 87: > > Suggest removing the editor-fold comments. It'll be listed as not-yet-categorized by virtue of being in the initial list. > > If the code generates standard styles, they should be listed here, so that they get documented in the sometime-forthcoming stylesheet spec. Fixed in 731a1a6be1a. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From vromero at openjdk.java.net Mon Aug 23 16:25:44 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 23 Aug 2021 16:25:44 GMT Subject: RFR: 8268148: unchecked warnings handle ? and ? extends Object differently Message-ID: Please review this PR. Currently javac handles differently `?` and `? extends Object` when reporting unchecked warnings when according to the spec they should be handled the same way. This PR is fixing this. TIA ------------- Commit messages: - 8268148: unchecked warnings handle ? and ? extends Object differently Changes: https://git.openjdk.java.net/jdk/pull/5224/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5224&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268148 Stats: 46 lines in 3 files changed: 43 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5224/head:pull/5224 PR: https://git.openjdk.java.net/jdk/pull/5224 From prappo at openjdk.java.net Mon Aug 23 17:18:33 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 23 Aug 2021 17:18:33 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: <2iWH0I7EWTfC6BjytMqzwNiGfz4ThWzW06SpDyM6urY=.10eb237b-b287-4a4c-a243-bf42f330a17b@github.com> On Fri, 20 Aug 2021 18:25:02 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 177: > >> 175: } >> 176: thisLineTags.addAll(parsedTags); >> 177: for (var tagIterator = thisLineTags.iterator(); tagIterator.hasNext(); ) { > > oooh, not wrong; just unexpected mix of styles ;-) Can you be more specific? In what sense is this unexpected? > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 186: > >> 184: } >> 185: if (parsedTags.isEmpty()) { // (2) >> 186: // TODO: log this with NOTICE; > > does this need to be addressed? I think that it does. It's the case of spurious markup. Such a case likely requires author's attention. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From jjg at openjdk.java.net Mon Aug 23 17:34:34 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 23 Aug 2021 17:34:34 GMT Subject: Integrated: JDK-8265253: javac -Xdoclint:all gives "no comment" warning for code that can't be commented In-Reply-To: References: Message-ID: On Sat, 21 Aug 2021 03:08:41 GMT, Jonathan Gibbons wrote: > Please review a simple update for doclint, to suppress "missing comment" warnings on the internally-synthesized class resulting from use of an anonymous class body in a member declaration in an enum class.. This pull request has now been integrated. Changeset: 18840724 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/18840724749c839259688bfa052652a1f34a378a Stats: 60 lines in 3 files changed: 59 ins; 0 del; 1 mod 8265253: javac -Xdoclint:all gives "no comment" warning for code that can't be commented Reviewed-by: hannesw ------------- PR: https://git.openjdk.java.net/jdk/pull/5206 From jjg at openjdk.java.net Mon Aug 23 17:39:36 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 23 Aug 2021 17:39:36 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:01:51 GMT, Pavel Rappo wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 923: >> >>> 921: * probably be considered on a case-by-case basis, for an attribute >>> 922: * value of the {@snippet} tag we do not recurse. >>> 923: */ >> >> This discussion does not belong here. >> >> We should specify simple defensible rules (in the spec) and implement them accordingly. >> If there is nothing more obvious, I suggest the rules for (Unicode) identifiers. > >> This discussion does not belong here. > > I've hoped to specify tag syntax before we push this PR. Until the syntax has been specified, the comment has to be stored somewhere. What would be an appropriate place to store that comment in? > >> I suggest the rules for (Unicode) identifiers > > What do those rules look like? Do you have a link handy? Check `Character.isUnicodeIdentifierStart` / `Character.isUnicodeIdentifierPart` Variant suggestion (if different) ... use the identifier rules for the name of the attribute ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From jjg at openjdk.java.net Mon Aug 23 17:44:28 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 23 Aug 2021 17:44:28 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 17:36:02 GMT, Jonathan Gibbons wrote: >>> This discussion does not belong here. >> >> I've hoped to specify tag syntax before we push this PR. Until the syntax has been specified, the comment has to be stored somewhere. What would be an appropriate place to store that comment in? >> >>> I suggest the rules for (Unicode) identifiers >> >> What do those rules look like? Do you have a link handy? > > Check `Character.isUnicodeIdentifierStart` / `Character.isUnicodeIdentifierPart` > Variant suggestion (if different) ... use the identifier rules for the name of the attribute A discussion like that belongs in JBS. The result of the discussion belongs in spec and/or code. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From jjg at openjdk.java.net Mon Aug 23 17:44:29 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 23 Aug 2021 17:44:29 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 18:46:43 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 81: > >> 79: >> 80: public static void main(String... args) throws Exception { >> 81: new TestSnippetTag().runTests(m -> new Object[]{Paths.get(m.getName())}); > > This is just a suggestion for future convenience. > For big tests like this, for ease of debugging, it can be useful to be able to specify the method(s) to be executed. Maybe there should be a variants of `runTests` that takes a `String[]` or `List` I filed JDK-8272853 for us. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Mon Aug 23 18:06:33 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 23 Aug 2021 18:06:33 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: <0qVuBDPSH0SVQCGtJC0jj03eNdjdFrPYXhYlhoAktC8=.8be3b169-bbc6-440d-9846-59f21848e5e8@github.com> On Fri, 20 Aug 2021 18:09:47 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 39: > >> 37: import jdk.javadoc.internal.doclets.toolkit.taglets.snippet.Parser; >> 38: import jdk.javadoc.internal.doclets.toolkit.taglets.snippet.StyledText; >> 39: import jdk.javadoc.internal.doclets.toolkit.util.Utils; > > The langtools/javac/javadoc convention is to put standard JavaSE imports (`java.*`, `javax.*` ) first. Since we are here, is there any langtools convention for when to collapse a span of single-import declarations into an import-on-demand (.*) declaration? ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Mon Aug 23 18:13:56 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 23 Aug 2021 18:13:56 GMT Subject: RFR: 8266666: Implementation for snippets [v11] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Add @summary to tests From https://openjdk.java.net/jtreg/faq.html: The @summary tag describes the condition that is checked by the test. It is especially useful for non-regression tests, which by definition don't have bug numbers, but even if there's a bug number it's helpful to include a summary. Note that a test summary is generally not the same thing as a Bugtraq synopsis, since the latter describes the bug rather than the condition that the bug violates. That said, the JBS synopsis for 8266666 suits those tests just fine. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/731a1a6b..0510287e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=09-10 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From serb at openjdk.java.net Mon Aug 23 19:34:34 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 Aug 2021 19:34:34 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 18:31:02 GMT, Andrey Turbanov wrote: > I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too. Updated as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From serb at openjdk.java.net Mon Aug 23 19:34:38 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 Aug 2021 19:34:38 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 15:09:26 GMT, Alan Bateman wrote: >> Sergey Bylokhov 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 14 additional commits since the last revision: >> >> - Update the usage of Files.readAllLines() >> - Update datatransfer >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Fix related imports >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Cleanup UnsupportedEncodingException >> - Update PacketStream.java >> - Rollback TextTests, should be compatible with jdk1.4 >> - Rollback TextRenderTests, should be compatible with jdk1.4 >> - ... and 4 more: https://git.openjdk.java.net/jdk/compare/465eb90c...e7127644 > > src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342: > >> 340: >> 341: try { >> 342: for (String line : Files.readAllLines(statusPath, UTF_8)) { > > The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want. Thank you for the suggestion, I have fixed this and a few other places as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From github.com+741251+turbanoff at openjdk.java.net Mon Aug 23 20:54:36 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 23 Aug 2021 20:54:36 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/aaa7beaf...e7127644 Marked as reviewed by turbanoff at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From vromero at openjdk.java.net Mon Aug 23 23:35:49 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 23 Aug 2021 23:35:49 GMT Subject: RFR: 8268885: duplicate checkcast when destination type is not first type of intersection type Message-ID: Please review this PR which is fixing the following bug: javac is generating duplicate checkcast for cases like: class IntersectionTypeTest { interface I1 {} interface I2 {} static class C {} void test() { I2 i = (I1 & I2) new C(); } } basically when an intersection type is used in a cast expression and the target is not the type in the intersection. TIA ------------- Commit messages: - 8268885: duplicate checkcast when destination type is not first type of intersection type Changes: https://git.openjdk.java.net/jdk/pull/5235/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5235&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268885 Stats: 37 lines in 2 files changed: 24 ins; 3 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5235.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5235/head:pull/5235 PR: https://git.openjdk.java.net/jdk/pull/5235 From prappo at openjdk.java.net Tue Aug 24 10:27:56 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 24 Aug 2021 10:27:56 GMT Subject: RFR: 8266666: Implementation for snippets [v12] In-Reply-To: References: Message-ID: <5pYpCnvgOSaVG_1lJtlHEXNrwrmaDtyw0SyRa1jQBgM=.130e1005-309e-4357-8eff-e2468d0502f1@github.com> > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Fix import layout and typos ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/0510287e..a7cd1551 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=10-11 Stats: 31 lines in 2 files changed: 15 ins; 14 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Tue Aug 24 10:27:59 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 24 Aug 2021 10:27:59 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: <0qVuBDPSH0SVQCGtJC0jj03eNdjdFrPYXhYlhoAktC8=.8be3b169-bbc6-440d-9846-59f21848e5e8@github.com> References: <0qVuBDPSH0SVQCGtJC0jj03eNdjdFrPYXhYlhoAktC8=.8be3b169-bbc6-440d-9846-59f21848e5e8@github.com> Message-ID: On Mon, 23 Aug 2021 18:03:51 GMT, Pavel Rappo wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 39: >> >>> 37: import jdk.javadoc.internal.doclets.toolkit.taglets.snippet.Parser; >>> 38: import jdk.javadoc.internal.doclets.toolkit.taglets.snippet.StyledText; >>> 39: import jdk.javadoc.internal.doclets.toolkit.util.Utils; >> >> The langtools/javac/javadoc convention is to put standard JavaSE imports (`java.*`, `javax.*` ) first. > > Since we are here, is there any langtools convention for when to collapse a span of single-import declarations into an import-on-demand (.*) declaration? Fixed in a7cd155. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Tue Aug 24 10:28:05 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 24 Aug 2021 10:28:05 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 18:13:32 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 260: > >> 258: * There's a separate issue of mapping discrepancies back to their >> 259: * originating source in the doc comment and the external file. Maybe there >> 260: * is a value in it, or may be there isn't. In any case, accurate mapping > > "maybe" Fixed in a7cd155. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 134: > >> 132: this.eolMarker = eolMarker; >> 133: // capture the rightmost eolMarker (e.g. "//") >> 134: // The bellow Pattern.compile should never throw PatternSyntaxException > > "below" ? Fixed in a7cd155. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Tue Aug 24 11:33:33 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 24 Aug 2021 11:33:33 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 18:07:30 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 360: > >> 358: >> 359: doclet.tag.attribute.repeated=\ >> 360: repeated attribute: "{0}" > > check the resource file for other quoted values; I think you'll find single quotes are the prevailing standard. I didn't find single quotes to be the prevailing standard neither in `doclet.properties` nor in `compiler.properties`. In fact, it seems to be the opposite: whenever a parameter (not constant) is output, it's either unquoted or double-quoted. Did I look in the right place? ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From azvegint at openjdk.java.net Tue Aug 24 13:09:37 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 24 Aug 2021 13:09:37 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8c6e27c3...e7127644 Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From prappo at openjdk.java.net Tue Aug 24 13:14:57 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 24 Aug 2021 13:14:57 GMT Subject: RFR: 8266666: Implementation for snippets [v13] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Clarify the attributes order comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/a7cd1551..26de3408 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Tue Aug 24 13:15:00 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 24 Aug 2021 13:15:00 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 18:11:05 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 96: > >> 94: // recently encountered of two, the iteration order might differ >> 95: // from the source order >> 96: error(writer, holder, a, "doclet.tag.attribute.repeated", a.getName().toString()); > > Can we use a `LinkedHashMap` or similar to preserve encounter order? If you look closely, you will see that the ordering characteristics of the `Map` implementation used to collect attributes is immaterial. My comment was about the implied (but unspecified) order of attributes in the list returned from the `SnippetTree.getAttributes()` method; see the third paragraph in the description of https://bugs.openjdk.java.net/browse/JDK-8266826 I clarified the comment in 26de34083a3. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From jjg at openjdk.java.net Tue Aug 24 14:27:31 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 24 Aug 2021 14:27:31 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: <0qVuBDPSH0SVQCGtJC0jj03eNdjdFrPYXhYlhoAktC8=.8be3b169-bbc6-440d-9846-59f21848e5e8@github.com> Message-ID: On Tue, 24 Aug 2021 10:24:35 GMT, Pavel Rappo wrote: >> Since we are here, is there any langtools convention for when to collapse a span of single-import declarations into an import-on-demand (.*) declaration? > > Fixed in a7cd155. > Since we are here, is there any langtools convention for when to collapse a span of single-import declarations into an import-on-demand (.*) declaration? langtools does not use import-on-demand, and it is practice e to expand them to single imports if any creep into the code. Also, imports are ordered with Java SE (`java.*` `javax.*`) imports first, before others. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From jjg at openjdk.java.net Tue Aug 24 14:36:34 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 24 Aug 2021 14:36:34 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 11:30:54 GMT, Pavel Rappo wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 360: >> >>> 358: >>> 359: doclet.tag.attribute.repeated=\ >>> 360: repeated attribute: "{0}" >> >> check the resource file for other quoted values; I think you'll find single quotes are the prevailing standard. > > I didn't find single quotes to be the prevailing standard neither in `doclet.properties` nor in `compiler.properties`. In fact, it seems to be the opposite: whenever a parameter (not constant) is output, it's either unquoted or double-quoted. Did I look in the right place? OK, it's not as dominant as I thought ... 2 to 1. Grepping through English properties files `jdk.compiler` and `jdk.javadoc`, there are 142 lines containing `'` and 75 lines containing `"` Maybe we should have a separate cleanup, after figuring out which form we should use. >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 177: >> >>> 175: } >>> 176: thisLineTags.addAll(parsedTags); >>> 177: for (var tagIterator = thisLineTags.iterator(); tagIterator.hasNext(); ) { >> >> oooh, not wrong; just unexpected mix of styles ;-) > > Can you be more specific? In what sense is this unexpected? Just the combination of `var`, iterators, and a `for `(;;)` loop, that's all. Not wrong, just uncommon; it took me a double-take to parse it, that's all. The code is OK, no need to change it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Tue Aug 24 16:55:39 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 24 Aug 2021 16:55:39 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: <-hDrj20tKNB2jnaL3i6ygSGR10XC1XX8Lx9NUV6ZMAs=.e9042f9f-40a2-4cf0-a515-4238d0e1effc@github.com> On Fri, 20 Aug 2021 18:50:44 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > Generally impressive piece of work. @jonathan-gibbons, do we need to mention the semantic change to `com.sun.source.doctree.AttributeTree` in the release notes? Before this PR, `AttributeTree` used to only represent HTML attributes. After this PR has been integrated, that interface will also represent attributes of the standard doclet tags. (Currently, the only such tag is `{@snippet}`.) ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From jjg at openjdk.java.net Tue Aug 24 17:25:30 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 24 Aug 2021 17:25:30 GMT Subject: RFR: 8266666: Implementation for snippets [v13] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 13:14:57 GMT, Pavel Rappo wrote: >> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Clarify the attributes order comment src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java line 82: > 80: */ > 81: snippet, > 82: This is OK for now, given that we do not have a "public" way to process these comments at this time. However, we should probably do a cleanup later on (soon), and maybe create a new section in `HtmlStyle` for all snippet related styles ... i.e. including `bold`, `italic` etc, so that all styles end up in the upcoming documentation. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From jjg at openjdk.java.net Tue Aug 24 17:32:32 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 24 Aug 2021 17:32:32 GMT Subject: RFR: 8266666: Implementation for snippets [v13] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 14:31:27 GMT, Hannes Walln?fer wrote: > I would prefer if variables such as this that are used farther than a few lines from their definition had more meaningful names. It's also confusing that `r` is a `String` but `r1`, `r2` (lines 209-211) are `StyledText` ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Tue Aug 24 17:46:51 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 24 Aug 2021 17:46:51 GMT Subject: RFR: 8266666: Implementation for snippets [v14] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge branch 'master' into 8266666 This merge is to promptly resolve a conflict in src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java. - Clarify the attributes order comment - Fix import layout and typos - Add @summary to tests From https://openjdk.java.net/jtreg/faq.html: The @summary tag describes the condition that is checked by the test. It is especially useful for non-regression tests, which by definition don't have bug numbers, but even if there's a bug number it's helpful to include a summary. Note that a test summary is generally not the same thing as a Bugtraq synopsis, since the latter describes the bug rather than the condition that the bug violates. That said, the JBS synopsis for 8266666 suits those tests just fine. - Remove superfluous editor-fold - Remove JEP link from SnippetTree - Merge branch 'master' into 8266666 - Pass through FIXMEs and TODOs Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Co-authored-by: Hannes Wallnoefer - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Co-authored-by: Hannes Wallnoefer - ... and 8 more: https://git.openjdk.java.net/jdk/compare/d34f17c6...4c5e92b7 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4795/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=13 Stats: 4812 lines in 59 files changed: 4708 ins; 12 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From jjg at openjdk.java.net Tue Aug 24 21:59:29 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 24 Aug 2021 21:59:29 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 18:50:44 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > Generally impressive piece of work. > @jonathan-gibbons, do we need to mention the semantic change to `com.sun.source.doctree.AttributeTree` in the release notes? Before this PR, `AttributeTree` used to only represent HTML attributes. After this PR has been integrated, that interface will also represent attributes of the standard doclet tags. (Currently, the only such tag is `{@snippet}`.) It doesn't seem worth a release note ... we're just using the tree in more places ... ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Tue Aug 24 21:59:30 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 24 Aug 2021 21:59:30 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 18:42:53 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass through FIXMEs and TODOs >> >> Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > > test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 1508: > >> 1506: ) >> 1507: // Uncomment when parser has improved (this would allow to write meta snippets, >> 1508: // i.e. snippets showing how to write snippets. > > Just a question: what are the limitations in the parser that are getting in the way here? Both the commented-out code and its description are from a previous version of markup; you can see that the syntax is slightly different from what we have in JEP today. It's good that you asked this question, because this piece is outdated. Although the markup syntax has changed, the idea for the test remained: there has to be a way to produce a snippet that showcases markup. I will have to implement that idea. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Tue Aug 24 22:12:34 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 24 Aug 2021 22:12:34 GMT Subject: RFR: 8266666: Implementation for snippets [v14] In-Reply-To: References: Message-ID: <4Q-TLoinrffkDvPKnmpo9478OEe8ZqDNErClMKXml6Q=.34c649f6-28fb-480a-8b5b-b10f3fdc66c0@github.com> On Tue, 24 Aug 2021 17:46:51 GMT, Pavel Rappo wrote: >> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'master' into 8266666 > > This merge is to promptly resolve a conflict in src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java. > - Clarify the attributes order comment > - Fix import layout and typos > - Add @summary to tests > > From https://openjdk.java.net/jtreg/faq.html: > > The @summary tag describes the condition that is checked by the test. It is especially useful for non-regression tests, which by definition don't have bug numbers, but even if there's a bug number it's helpful to include a summary. Note that a test summary is generally not the same thing as a Bugtraq synopsis, since the latter describes the bug rather than the condition that the bug violates. > > That said, the JBS synopsis for 8266666 suits those tests just fine. > - Remove superfluous editor-fold > - Remove JEP link from SnippetTree > - Merge branch 'master' into 8266666 > - Pass through FIXMEs and TODOs > > Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. > - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css > > Co-authored-by: Hannes Wallnoefer > - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css > > Co-authored-by: Hannes Wallnoefer > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/d34f17c6...4c5e92b7 Heads-up: the recent merge 4c5e92b from openjdk:master seems faulty. It fails a test and reports unexpected entries in this PR's "Files changed" tab. Because that merge is the most recent commit in the PR branch, instead of carefully repairing the history with a revert and remerge, I will force push a correct merge. Apologies for any noise or inconvenience. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Tue Aug 24 22:22:34 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 24 Aug 2021 22:22:34 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 21:56:05 GMT, Jonathan Gibbons wrote: > > @jonathan-gibbons, do we need to mention the semantic change to `com.sun.source.doctree.AttributeTree` in the release notes? Before this PR, `AttributeTree` used to only represent HTML attributes. After this PR has been integrated, that interface will also represent attributes of the standard doclet tags. (Currently, the only such tag is `{@snippet}`.) > > It doesn't seem worth a release note ... we're just using the tree in more places ... but it wouldn't be wrong to create one ... after all, I guess we did have to change doclint to accommodate the new usage. Look at it this way. Previously, if you had an instance of `AttributeTree`, you could be sure that it belonged to an instance of `StartElementTree`. After this PR has been merged, this will no longer be the case. I think that this fact should be recorded somewhere besides the API itself. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Tue Aug 24 22:26:48 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 24 Aug 2021 22:26:48 GMT Subject: RFR: 8266666: Implementation for snippets [v15] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge branch 'master' into 8266666 Redoing a faulty merge and pushing the result forcefully. - Clarify the attributes order comment - Fix import layout and typos - Add @summary to tests From https://openjdk.java.net/jtreg/faq.html: The @summary tag describes the condition that is checked by the test. It is especially useful for non-regression tests, which by definition don't have bug numbers, but even if there's a bug number it's helpful to include a summary. Note that a test summary is generally not the same thing as a Bugtraq synopsis, since the latter describes the bug rather than the condition that the bug violates. That said, the JBS synopsis for 8266666 suits those tests just fine. - Remove superfluous editor-fold - Remove JEP link from SnippetTree - Merge branch 'master' into 8266666 - Pass through FIXMEs and TODOs Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed. - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Co-authored-by: Hannes Wallnoefer - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Co-authored-by: Hannes Wallnoefer - ... and 8 more: https://git.openjdk.java.net/jdk/compare/b17b821a...be7ffe5b ------------- Changes: https://git.openjdk.java.net/jdk/pull/4795/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=14 Stats: 4713 lines in 44 files changed: 4686 ins; 4 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From github.com+223869+mryan43 at openjdk.java.net Wed Aug 25 13:52:23 2021 From: github.com+223869+mryan43 at openjdk.java.net (Manuel Ryan) Date: Wed, 25 Aug 2021 13:52:23 GMT Subject: RFR: 8268894: ArrayIndexOutOfBoundsException in jdk compiler: at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writePosition(ClassWriter.java:671) In-Reply-To: References: Message-ID: On Sun, 11 Jul 2021 09:36:53 GMT, Guoxiong Li wrote: > Hi all, > > The method `TypeAnnotationPosition.updatePosOffset` sets the `lvarOffset` unnecessarily. After invoking `TypeAnnotationPosition.updatePosOffset`, the lengths of (`lvarOffset`, `lvarLength`, `lvarIndex`) are respectively (1, 0, 0). Then `Code.fillLocalVarPosition` fills the `lvarOffset`, `lvarLength`, `lvarIndex` which make their lengths become (N, N-1, N-1). At last, the method `ClassWrite.writePosition` uses these three arrays whose lengths are not the same so that the `ArrayIndexOutOfBoundsException` occurs. > > The `lvarOffset` should be always changed along with `lvarLength` and `lvarIndex` so that their lengths can be the same. > > This patch removes the unnecessary `lvarOffset = new int[]{to};` of the method `TypeAnnotationPosition.updatePosOffset` and add a corresponding test. > > --- > Steps to reproduce the issue: > > 1. Construct a annotation processor which set the `pos` of the method sub-tree nodes to the same position. Please see the file `TypeAnnotationPositionProcessor.java` for more details. > 2. Compile the code which has the corresponding method with the annotated local variable by using the annotation processor generated at the step 1. Please see the file `TypeAnnotationPositionTest.java` for more details. > 3. Then the crash occurs. > > Actually, this bug may never occur if the users use the compiler friendly. Because the method `TypeAnnotationPosition.updatePosOffset`, which we mentioned at the beginning, may never be invoked at the situation that the different trees has different and right position. > > The lib `lombok` constructs some new tree nodes by using the internal method of the compiler. But it doesn't set the `pos` correctly and uses the same fake position. The unfriendly code of the `lombok` is in the method [JavacHandlerUtil.setGeneratedBy](https://github.com/projectlombok/lombok/blob/master/src/core/lombok/javac/handlers/JavacHandlerUtil.java#L167). At much time, the fake same position works well, but this time, it crashes the compiler. > > --- > A brief history: > > According to the git's records, I found the code `ta.position.lvarOffset = new int[] { code.cp };` was firstly added at [8006775: JSR 308: Compiler changes in JDK8](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l52.35) . > > Then, [8013852: update reference impl for type-annotations](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ddb4a2bfcd82#l8.52) moved the code to `TypeAnnotationPosition.updatePosOffset`. > > The bug didn't occur at that time, because the old [Code.fillLocalVarPosition](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l51.21) always created a new array instead of using the old array. > > But later, [8231826: Implement javac changes for pattern matching for instanceof](https://hg.openjdk.java.net/jdk/jdk/rev/7799a51dbe30#l24.27) revised the method `Code.fillLocalVarPosition` to reuse the old array so that the bug occurs. > > Concluded, this is an issue introduced at JDK8 when implementing the type annotation. But it was hidden by other code at the past. > > --- > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This is still preventing me to upgrade from 11 to 15. Please don't let this issue be automatically deleted because of inactivity. ------------- PR: https://git.openjdk.java.net/jdk/pull/4749 From jonathan.gibbons at oracle.com Wed Aug 25 15:49:10 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 Aug 2021 08:49:10 -0700 Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On 8/24/21 2:59 PM, Pavel Rappo wrote: > Both the commented-out code and its description are from a previous version of markup; you can see that the syntax is slightly different from what we have in JEP today. It's good that you asked this question, because this piece is outdated. > > Although the markup syntax has changed, the idea for the test remained: there has to be a way to produce a snippet that showcases markup. I will have to implement that idea. OK, I see that the markup is potentially an issue. Does it help that markup uses the last instance of `//` ... meaning you could protect markup that should not be interpreted with an additional trailing `//` (possibly including a "dummy" markup tag?) -- Jon From prappo at openjdk.java.net Wed Aug 25 16:00:08 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 25 Aug 2021 16:00:08 GMT Subject: RFR: 8266666: Implementation for snippets [v16] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Format code closer to the ambient style Makes new constructs look more natural in their context by adopting the surrounding style. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/be7ffe5b..6c33cb6a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=14-15 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Wed Aug 25 16:16:00 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 25 Aug 2021 16:16:00 GMT Subject: RFR: 8266666: Implementation for snippets [v16] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 16:00:08 GMT, Pavel Rappo wrote: >> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Format code closer to the ambient style > > Makes new constructs look more natural in their context by adopting the surrounding style. Apologies for the recent series of consecutive force pushes. I had muddled the history with two commits before figured out that my IDE was reformatting doc comments behind my back. Every time I formatted the doc comment, the IDE reformatted it immediately before committing the change to the repo. I've configured the IDE not to do it from now on. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Wed Aug 25 16:15:57 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 25 Aug 2021 16:15:57 GMT Subject: RFR: 8266666: Implementation for snippets [v17] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Format code closer to the ambient style Makes new constructs look more natural in their context by adopting the surrounding style. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/6c33cb6a..9ab2cbdd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Wed Aug 25 16:21:55 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 25 Aug 2021 16:21:55 GMT Subject: RFR: 8266666: Implementation for snippets [v18] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Format code closer to the ambient style Makes new constructs look more natural in their context by adopting the surrounding style. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/9ab2cbdd..87e765b0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=16-17 Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Wed Aug 25 17:09:58 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 25 Aug 2021 17:09:58 GMT Subject: RFR: 8266666: Implementation for snippets [v19] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Recover from a sloppy merge Apparently, I've performed at least one sloppy merge while developing the feature in sandbox. As a result, some changes brought by e4d045402fa1992a1d91586bd4f67362d07f543c were discarded. The specdiff for the CSR actually shows this and has to be regenerated. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/87e765b0..0d9c53a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=17-18 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From vromero at openjdk.java.net Wed Aug 25 20:05:25 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 25 Aug 2021 20:05:25 GMT Subject: RFR: 8268894: ArrayIndexOutOfBoundsException in jdk compiler: at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writePosition(ClassWriter.java:671) In-Reply-To: References: Message-ID: <9RihaG2Ggia1hQLdq2a82g1X4vKkmH7kUZRufadWzz4=.c64d61bc-089c-492b-a99b-92356d32a946@github.com> On Sun, 11 Jul 2021 09:36:53 GMT, Guoxiong Li wrote: > Hi all, > > The method `TypeAnnotationPosition.updatePosOffset` sets the `lvarOffset` unnecessarily. After invoking `TypeAnnotationPosition.updatePosOffset`, the lengths of (`lvarOffset`, `lvarLength`, `lvarIndex`) are respectively (1, 0, 0). Then `Code.fillLocalVarPosition` fills the `lvarOffset`, `lvarLength`, `lvarIndex` which make their lengths become (N, N-1, N-1). At last, the method `ClassWrite.writePosition` uses these three arrays whose lengths are not the same so that the `ArrayIndexOutOfBoundsException` occurs. > > The `lvarOffset` should be always changed along with `lvarLength` and `lvarIndex` so that their lengths can be the same. > > This patch removes the unnecessary `lvarOffset = new int[]{to};` of the method `TypeAnnotationPosition.updatePosOffset` and add a corresponding test. > > --- > Steps to reproduce the issue: > > 1. Construct a annotation processor which set the `pos` of the method sub-tree nodes to the same position. Please see the file `TypeAnnotationPositionProcessor.java` for more details. > 2. Compile the code which has the corresponding method with the annotated local variable by using the annotation processor generated at the step 1. Please see the file `TypeAnnotationPositionTest.java` for more details. > 3. Then the crash occurs. > > Actually, this bug may never occur if the users use the compiler friendly. Because the method `TypeAnnotationPosition.updatePosOffset`, which we mentioned at the beginning, may never be invoked at the situation that the different trees has different and right position. > > The lib `lombok` constructs some new tree nodes by using the internal method of the compiler. But it doesn't set the `pos` correctly and uses the same fake position. The unfriendly code of the `lombok` is in the method [JavacHandlerUtil.setGeneratedBy](https://github.com/projectlombok/lombok/blob/master/src/core/lombok/javac/handlers/JavacHandlerUtil.java#L167). At much time, the fake same position works well, but this time, it crashes the compiler. > > --- > A brief history: > > According to the git's records, I found the code `ta.position.lvarOffset = new int[] { code.cp };` was firstly added at [8006775: JSR 308: Compiler changes in JDK8](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l52.35) . > > Then, [8013852: update reference impl for type-annotations](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ddb4a2bfcd82#l8.52) moved the code to `TypeAnnotationPosition.updatePosOffset`. > > The bug didn't occur at that time, because the old [Code.fillLocalVarPosition](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l51.21) always created a new array instead of using the old array. > > But later, [8231826: Implement javac changes for pattern matching for instanceof](https://hg.openjdk.java.net/jdk/jdk/rev/7799a51dbe30#l24.27) revised the method `Code.fillLocalVarPosition` to reuse the old array so that the bug occurs. > > Concluded, this is an issue introduced at JDK8 when implementing the type annotation. But it was hidden by other code at the past. > > --- > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong from your description it seems like the bug is more on the lombok side than in javac's, if I understand correctly you are saying that the bug is provoked by lombok because it is not generating completely correct ASTs right?, it could be that we need to make sure that the 3 arrays are in sync before generating the class file, but still the information in `lvarOffset` seems to be used so not generating it doesn't seem like the best option. Please let me know if I'm missing something ------------- PR: https://git.openjdk.java.net/jdk/pull/4749 From prappo at openjdk.java.net Wed Aug 25 21:15:35 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 25 Aug 2021 21:15:35 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 21:56:05 GMT, Jonathan Gibbons wrote: >> Generally impressive piece of work. > >> @jonathan-gibbons, do we need to mention the semantic change to `com.sun.source.doctree.AttributeTree` in the release notes? Before this PR, `AttributeTree` used to only represent HTML attributes. After this PR has been integrated, that interface will also represent attributes of the standard doclet tags. (Currently, the only such tag is `{@snippet}`.) > > It doesn't seem worth a release note ... we're just using the tree in more places ... but it wouldn't be wrong to create one ... after all, I guess we did have to change doclint to accommodate the new usage. @jonathan-gibbons, I'm currently cleaning up this PR of unrelated changes. What would you say if I ask you to extract this change of yours into a separate cleanup PR while I delete it from this PR? https://github.com/openjdk/jdk-sandbox/commit/405c89c35076e73daf7b38d5a20ae83075fb8ae1#diff-e7650e24c581f8df74f8d2bc24110c15c22fd32308f690fba0349c7170f320dfR495-R499 Adding `tagletpath.parameters` and changing `tagletpath.description` has value, but I think you would agree that it's unrelated to snippets. Separately, when extracting the diff note that that change is a bit inconsistent: while you changed the resource value to `The path for custom taglets`, the option doc comment still refers to `The path to Taglets`: https://github.com/openjdk/jdk-sandbox/blob/405c89c35076e73daf7b38d5a20ae83075fb8ae1/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L268 ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From jjg at openjdk.java.net Wed Aug 25 21:53:30 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 25 Aug 2021 21:53:30 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 21:56:05 GMT, Jonathan Gibbons wrote: >> Generally impressive piece of work. > >> @jonathan-gibbons, do we need to mention the semantic change to `com.sun.source.doctree.AttributeTree` in the release notes? Before this PR, `AttributeTree` used to only represent HTML attributes. After this PR has been integrated, that interface will also represent attributes of the standard doclet tags. (Currently, the only such tag is `{@snippet}`.) > > It doesn't seem worth a release note ... we're just using the tree in more places ... but it wouldn't be wrong to create one ... after all, I guess we did have to change doclint to accommodate the new usage. > @jonathan-gibbons, I'm currently cleaning up this PR of unrelated changes. What would you say if I ask you to extract this change of yours into a separate cleanup PR while I delete it from this PR? > > [openjdk/jdk-sandbox at 405c89c#diff-e7650e24c581f8df74f8d2bc24110c15c22fd32308f690fba0349c7170f320dfR495-R499](https://github.com/openjdk/jdk-sandbox/commit/405c89c35076e73daf7b38d5a20ae83075fb8ae1#diff-e7650e24c581f8df74f8d2bc24110c15c22fd32308f690fba0349c7170f320dfR495-R499) > > Adding `tagletpath.parameters` and changing `tagletpath.description` has value, but I think you would agree that it's unrelated to snippets. > > Separately, when extracting the diff note that that change is a bit inconsistent: while you changed the resource value to `The path for custom taglets`, the option doc comment still refers to `The path to Taglets`: https://github.com/openjdk/jdk-sandbox/blob/405c89c35076e73daf7b38d5a20ae83075fb8ae1/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L268 So you're just suggesting that I should handle the parts related to tagletPath, right? If so, OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Wed Aug 25 22:43:01 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 25 Aug 2021 22:43:01 GMT Subject: RFR: 8266666: Implementation for snippets [v20] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Exclude unrelated changes to resources Also fixes a typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/0d9c53a6..a473e9a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=18-19 Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Wed Aug 25 22:58:31 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 25 Aug 2021 22:58:31 GMT Subject: RFR: 8266666: Implementation for snippets [v7] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 21:50:34 GMT, Jonathan Gibbons wrote: > So you're just suggesting that I should handle the parts related to tagletPath, right? If so, OK. Yes, I am. I have created a separate bug, where I suggested a patch: https://bugs.openjdk.java.net/browse/JDK-8273001 ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From gli at openjdk.java.net Thu Aug 26 08:51:30 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 26 Aug 2021 08:51:30 GMT Subject: RFR: 8268894: ArrayIndexOutOfBoundsException in jdk compiler: at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writePosition(ClassWriter.java:671) In-Reply-To: <9RihaG2Ggia1hQLdq2a82g1X4vKkmH7kUZRufadWzz4=.c64d61bc-089c-492b-a99b-92356d32a946@github.com> References: <9RihaG2Ggia1hQLdq2a82g1X4vKkmH7kUZRufadWzz4=.c64d61bc-089c-492b-a99b-92356d32a946@github.com> Message-ID: On Wed, 25 Aug 2021 20:00:06 GMT, Vicente Romero wrote: > from your description it seems like the bug is more on the lombok side than in javac's, if I understand correctly you are saying that the bug is provoked by lombok because it is not generating completely correct ASTs right The lombok may need to be improved. But javac shouldn't crash at this situation. It should compile the sources successfully or report a related warning(maybe a new warning `Wrong Position`). Because the wrong source positions may only affect the positions of the errors or warnings and have not much impact to the syntax and semantics. > but still the information in `lvarOffset` seems to be used so not generating it doesn't seem like the best option I can't find a place that the variable `lvarOffset` is used individually without `lvarLength` and `lvarIndex`. I find the `lvarOffset` always be used like the following code. So we should generate or use `lvarOffset`, `lvarLength` and `lvarIndex` together and couldn't use or generate one of them individually. // com.sun.tools.javac.jvm.ClassWriter case RESOURCE_VARIABLE: databuf.appendChar(p.lvarOffset.length); // for table length for (int i = 0; i < p.lvarOffset.length; ++i) { databuf.appendChar(p.lvarOffset[i]); databuf.appendChar(p.lvarLength[i]); databuf.appendChar(p.lvarIndex[i]); } break; @vicente-romero-oracle can you find the code that `lvarOffset` is used independently after `lvarOffset = new int[]{to};`? Or I am missing something, too. > it could be that we need to make sure that the 3 arrays are in sync before generating the class file Good idea. But I still want to remove `lvarOffset = new int[]{to};` if we can comfirm it is redundant. And maybe I can `sync before generating the class file` and remove `lvarOffset = new int[]{to};` at the same time to improve the code and prevent the wrong usage in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/4749 From serb at openjdk.java.net Thu Aug 26 17:42:33 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 26 Aug 2021 17:42:33 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/be695a9b...e7127644 Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer? ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From github.com+5709644+fdesu at openjdk.java.net Thu Aug 26 18:33:27 2021 From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko) Date: Thu, 26 Aug 2021 18:33:27 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov wrote: >> Sergey Bylokhov 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 14 additional commits since the last revision: >> >> - Update the usage of Files.readAllLines() >> - Update datatransfer >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Fix related imports >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Cleanup UnsupportedEncodingException >> - Update PacketStream.java >> - Rollback TextTests, should be compatible with jdk1.4 >> - Rollback TextRenderTests, should be compatible with jdk1.4 >> - ... and 4 more: https://git.openjdk.java.net/jdk/compare/810191b6...e7127644 > > Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer? @mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. Here they are: - src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java - src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyURIDV.java - src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java - src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java would it make sense to go through them as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From serb at openjdk.java.net Thu Aug 26 18:38:26 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 26 Aug 2021 18:38:26 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov wrote: >> Sergey Bylokhov 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 14 additional commits since the last revision: >> >> - Update the usage of Files.readAllLines() >> - Update datatransfer >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Fix related imports >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Cleanup UnsupportedEncodingException >> - Update PacketStream.java >> - Rollback TextTests, should be compatible with jdk1.4 >> - Rollback TextRenderTests, should be compatible with jdk1.4 >> - ... and 4 more: https://git.openjdk.java.net/jdk/compare/e5c71cd0...e7127644 > > Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer? > @mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. > would it make sense to go through them as well? Most of the cases in the XML module are related to the Xerces library, I have skipped it to make the future merges from upstream of that library simpler. ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From erikj at openjdk.java.net Fri Aug 27 17:51:31 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 27 Aug 2021 17:51:31 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/6af90a19...e7127644 Build tool change looks good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5210 From vromero at openjdk.java.net Fri Aug 27 20:35:28 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 27 Aug 2021 20:35:28 GMT Subject: RFR: 8268894: ArrayIndexOutOfBoundsException in jdk compiler: at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writePosition(ClassWriter.java:671) In-Reply-To: References: Message-ID: On Sun, 11 Jul 2021 09:36:53 GMT, Guoxiong Li wrote: > Hi all, > > The method `TypeAnnotationPosition.updatePosOffset` sets the `lvarOffset` unnecessarily. After invoking `TypeAnnotationPosition.updatePosOffset`, the lengths of (`lvarOffset`, `lvarLength`, `lvarIndex`) are respectively (1, 0, 0). Then `Code.fillLocalVarPosition` fills the `lvarOffset`, `lvarLength`, `lvarIndex` which make their lengths become (N, N-1, N-1). At last, the method `ClassWrite.writePosition` uses these three arrays whose lengths are not the same so that the `ArrayIndexOutOfBoundsException` occurs. > > The `lvarOffset` should be always changed along with `lvarLength` and `lvarIndex` so that their lengths can be the same. > > This patch removes the unnecessary `lvarOffset = new int[]{to};` of the method `TypeAnnotationPosition.updatePosOffset` and add a corresponding test. > > --- > Steps to reproduce the issue: > > 1. Construct a annotation processor which set the `pos` of the method sub-tree nodes to the same position. Please see the file `TypeAnnotationPositionProcessor.java` for more details. > 2. Compile the code which has the corresponding method with the annotated local variable by using the annotation processor generated at the step 1. Please see the file `TypeAnnotationPositionTest.java` for more details. > 3. Then the crash occurs. > > Actually, this bug may never occur if the users use the compiler friendly. Because the method `TypeAnnotationPosition.updatePosOffset`, which we mentioned at the beginning, may never be invoked at the situation that the different trees has different and right position. > > The lib `lombok` constructs some new tree nodes by using the internal method of the compiler. But it doesn't set the `pos` correctly and uses the same fake position. The unfriendly code of the `lombok` is in the method [JavacHandlerUtil.setGeneratedBy](https://github.com/projectlombok/lombok/blob/master/src/core/lombok/javac/handlers/JavacHandlerUtil.java#L167). At much time, the fake same position works well, but this time, it crashes the compiler. > > --- > A brief history: > > According to the git's records, I found the code `ta.position.lvarOffset = new int[] { code.cp };` was firstly added at [8006775: JSR 308: Compiler changes in JDK8](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l52.35) . > > Then, [8013852: update reference impl for type-annotations](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ddb4a2bfcd82#l8.52) moved the code to `TypeAnnotationPosition.updatePosOffset`. > > The bug didn't occur at that time, because the old [Code.fillLocalVarPosition](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l51.21) always created a new array instead of using the old array. > > But later, [8231826: Implement javac changes for pattern matching for instanceof](https://hg.openjdk.java.net/jdk/jdk/rev/7799a51dbe30#l24.27) revised the method `Code.fillLocalVarPosition` to reuse the old array so that the bug occurs. > > Concluded, this is an issue introduced at JDK8 when implementing the type annotation. But it was hidden by other code at the past. > > --- > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong looks good, thanks for the additional info. I also agree that javac shouldn't fail. I checked the code again and I think that you fix is good, thanks please update the PR title with the last bug title: "8268894: forged ASTs can provoke an AIOOBE at com.sun.tools.javac.jvm.ClassWriter::writePosition" or please sync both to another version you like better before pushing ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4749 From gli at openjdk.java.net Sun Aug 29 06:39:47 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Sun, 29 Aug 2021 06:39:47 GMT Subject: RFR: 8268894: forged ASTs can provoke an AIOOBE at com.sun.tools.javac.jvm.ClassWriter::writePosition In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 20:32:00 GMT, Vicente Romero wrote: >> Hi all, >> >> The method `TypeAnnotationPosition.updatePosOffset` sets the `lvarOffset` unnecessarily. After invoking `TypeAnnotationPosition.updatePosOffset`, the lengths of (`lvarOffset`, `lvarLength`, `lvarIndex`) are respectively (1, 0, 0). Then `Code.fillLocalVarPosition` fills the `lvarOffset`, `lvarLength`, `lvarIndex` which make their lengths become (N, N-1, N-1). At last, the method `ClassWrite.writePosition` uses these three arrays whose lengths are not the same so that the `ArrayIndexOutOfBoundsException` occurs. >> >> The `lvarOffset` should be always changed along with `lvarLength` and `lvarIndex` so that their lengths can be the same. >> >> This patch removes the unnecessary `lvarOffset = new int[]{to};` of the method `TypeAnnotationPosition.updatePosOffset` and add a corresponding test. >> >> --- >> Steps to reproduce the issue: >> >> 1. Construct a annotation processor which set the `pos` of the method sub-tree nodes to the same position. Please see the file `TypeAnnotationPositionProcessor.java` for more details. >> 2. Compile the code which has the corresponding method with the annotated local variable by using the annotation processor generated at the step 1. Please see the file `TypeAnnotationPositionTest.java` for more details. >> 3. Then the crash occurs. >> >> Actually, this bug may never occur if the users use the compiler friendly. Because the method `TypeAnnotationPosition.updatePosOffset`, which we mentioned at the beginning, may never be invoked at the situation that the different trees has different and right position. >> >> The lib `lombok` constructs some new tree nodes by using the internal method of the compiler. But it doesn't set the `pos` correctly and uses the same fake position. The unfriendly code of the `lombok` is in the method [JavacHandlerUtil.setGeneratedBy](https://github.com/projectlombok/lombok/blob/master/src/core/lombok/javac/handlers/JavacHandlerUtil.java#L167). At much time, the fake same position works well, but this time, it crashes the compiler. >> >> --- >> A brief history: >> >> According to the git's records, I found the code `ta.position.lvarOffset = new int[] { code.cp };` was firstly added at [8006775: JSR 308: Compiler changes in JDK8](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l52.35) . >> >> Then, [8013852: update reference impl for type-annotations](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ddb4a2bfcd82#l8.52) moved the code to `TypeAnnotationPosition.updatePosOffset`. >> >> The bug didn't occur at that time, because the old [Code.fillLocalVarPosition](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l51.21) always created a new array instead of using the old array. >> >> But later, [8231826: Implement javac changes for pattern matching for instanceof](https://hg.openjdk.java.net/jdk/jdk/rev/7799a51dbe30#l24.27) revised the method `Code.fillLocalVarPosition` to reuse the old array so that the bug occurs. >> >> Concluded, this is an issue introduced at JDK8 when implementing the type annotation. But it was hidden by other code at the past. >> >> --- >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > please update the PR title with the last bug title: "8268894: forged ASTs can provoke an AIOOBE at com.sun.tools.javac.jvm.ClassWriter::writePosition" or please sync both to another version you like better before pushing @vicente-romero-oracle Thanks for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4749 From gli at openjdk.java.net Sun Aug 29 07:03:32 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Sun, 29 Aug 2021 07:03:32 GMT Subject: RFR: 8266239: Some duplicated javac command-line options have repeated effect In-Reply-To: References: Message-ID: On Fri, 28 May 2021 12:29:45 GMT, Guoxiong Li wrote: > Hi all, > > Some duplicated info options (`--version`, `--help`, `--help-extra`, `--help-lint`, `--full-version`) have repeated effect. Please see the following example. > > > $ javac -version -version > javac 17-internal > javac 17-internal > > > The patch fixes it and adds a corresponding test case. > Thank you for taking the time to review. > > Best Regards, > -- Guoxiong The CSR has been approved. Ping for review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4244 From gli at openjdk.java.net Sun Aug 29 07:30:01 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Sun, 29 Aug 2021 07:30:01 GMT Subject: Integrated: 8268894: forged ASTs can provoke an AIOOBE at com.sun.tools.javac.jvm.ClassWriter::writePosition In-Reply-To: References: Message-ID: On Sun, 11 Jul 2021 09:36:53 GMT, Guoxiong Li wrote: > Hi all, > > The method `TypeAnnotationPosition.updatePosOffset` sets the `lvarOffset` unnecessarily. After invoking `TypeAnnotationPosition.updatePosOffset`, the lengths of (`lvarOffset`, `lvarLength`, `lvarIndex`) are respectively (1, 0, 0). Then `Code.fillLocalVarPosition` fills the `lvarOffset`, `lvarLength`, `lvarIndex` which make their lengths become (N, N-1, N-1). At last, the method `ClassWrite.writePosition` uses these three arrays whose lengths are not the same so that the `ArrayIndexOutOfBoundsException` occurs. > > The `lvarOffset` should be always changed along with `lvarLength` and `lvarIndex` so that their lengths can be the same. > > This patch removes the unnecessary `lvarOffset = new int[]{to};` of the method `TypeAnnotationPosition.updatePosOffset` and add a corresponding test. > > --- > Steps to reproduce the issue: > > 1. Construct a annotation processor which set the `pos` of the method sub-tree nodes to the same position. Please see the file `TypeAnnotationPositionProcessor.java` for more details. > 2. Compile the code which has the corresponding method with the annotated local variable by using the annotation processor generated at the step 1. Please see the file `TypeAnnotationPositionTest.java` for more details. > 3. Then the crash occurs. > > Actually, this bug may never occur if the users use the compiler friendly. Because the method `TypeAnnotationPosition.updatePosOffset`, which we mentioned at the beginning, may never be invoked at the situation that the different trees has different and right position. > > The lib `lombok` constructs some new tree nodes by using the internal method of the compiler. But it doesn't set the `pos` correctly and uses the same fake position. The unfriendly code of the `lombok` is in the method [JavacHandlerUtil.setGeneratedBy](https://github.com/projectlombok/lombok/blob/master/src/core/lombok/javac/handlers/JavacHandlerUtil.java#L167). At much time, the fake same position works well, but this time, it crashes the compiler. > > --- > A brief history: > > According to the git's records, I found the code `ta.position.lvarOffset = new int[] { code.cp };` was firstly added at [8006775: JSR 308: Compiler changes in JDK8](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l52.35) . > > Then, [8013852: update reference impl for type-annotations](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ddb4a2bfcd82#l8.52) moved the code to `TypeAnnotationPosition.updatePosOffset`. > > The bug didn't occur at that time, because the old [Code.fillLocalVarPosition](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l51.21) always created a new array instead of using the old array. > > But later, [8231826: Implement javac changes for pattern matching for instanceof](https://hg.openjdk.java.net/jdk/jdk/rev/7799a51dbe30#l24.27) revised the method `Code.fillLocalVarPosition` to reuse the old array so that the bug occurs. > > Concluded, this is an issue introduced at JDK8 when implementing the type annotation. But it was hidden by other code at the past. > > --- > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: a9188f23 Author: Guoxiong Li URL: https://git.openjdk.java.net/jdk/commit/a9188f237ec23d4ca2a172e9a7897cb6e2b69857 Stats: 134 lines in 3 files changed: 133 ins; 1 del; 0 mod 8268894: forged ASTs can provoke an AIOOBE at com.sun.tools.javac.jvm.ClassWriter::writePosition Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/4749 From attila.kelemen85 at gmail.com Sun Aug 29 10:19:25 2021 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Sun, 29 Aug 2021 12:19:25 +0200 Subject: JEP 400 - UTF-8 by Default Message-ID: Hi, I have read the description of JEP 400, but it does not mention the default source encoding. Will javac be changed as well? Given that standard APIs change, it would be nice, since platform dependent encoding was just a nuisance anyway, and (at least to me) seems a lot less risky than the standard API change. Thanks, Attila -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Aug 30 08:17:27 2021 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 30 Aug 2021 10:17:27 +0200 Subject: JEP 400 - UTF-8 by Default In-Reply-To: References: Message-ID: <74dbf871-e6fe-5dce-600d-6a652f371ad8@oracle.com> On 29. 08. 21 12:19, Attila Kelemen wrote: > Hi, > > I have read the description of JEP 400, but it does not mention the > default source encoding. Will javac be changed as well? As far as I can tell, the default encoding that javac itself uses is `Charset.defaultCharset().name()`. So I think that when `Charset.defaultCharset().name()` starts to return "UTF-8", javac will start to read the source files in the UTF-8 encoding, unless a different encoding is specified in a javac option, or unless the javac is invoked with a custom JavaFileManager which does the conversion on its own. Jan > > Given that standard APIs change, it would be nice, since platform > dependent encoding was just a?nuisance anyway, and (at least to me) > seems a lot less risky than the standard API change. > > Thanks, > Attila From naoto.sato at oracle.com Mon Aug 30 17:00:05 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 30 Aug 2021 10:00:05 -0700 Subject: JEP 400 - UTF-8 by Default In-Reply-To: <74dbf871-e6fe-5dce-600d-6a652f371ad8@oracle.com> References: <74dbf871-e6fe-5dce-600d-6a652f371ad8@oracle.com> Message-ID: Yes, that is correct. As long as javac uses the default encoding from `Charset.defaultCharset()`, it will automatically use `UTF-8` as the default encoding for the input source files. Naoto On 8/30/21 1:17 AM, Jan Lahoda wrote: > On 29. 08. 21 12:19, Attila Kelemen wrote: > >> Hi, >> >> I have read the description of JEP 400, but it does not mention the >> default source encoding. Will javac be changed as well? > > > As far as I can tell, the default encoding that javac itself uses is > `Charset.defaultCharset().name()`. So I think that when > `Charset.defaultCharset().name()` starts to return "UTF-8", javac will > start to read the source files in the UTF-8 encoding, unless a different > encoding is specified in a javac option, or unless the javac is invoked > with a custom JavaFileManager which does the conversion on its own. > > > Jan > > >> >> Given that standard APIs change, it would be nice, since platform >> dependent encoding was just a?nuisance anyway, and (at least to me) >> seems a lot less risky than the standard API change. >> >> Thanks, >> Attila From vromero at openjdk.java.net Mon Aug 30 18:16:44 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 30 Aug 2021 18:16:44 GMT Subject: RFR: 8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot invoke getThrownTypes because tree.meth.type is null Message-ID: Please review this PR which is not filtering errors for cases when the error is reported in a lambda expression. Before the fix for [JDK-8205418](https://bugs.openjdk.java.net/browse/JDK-8205418) javac was a bit more aggressive reporting errors found during recovery. After the fix mentioned above, the intention was to try to generate better error messages by attributing deferred nodes with more precise targets. But for some cases like the one reported in the bug entry, javac would swallow the error report. This fix is just reporting the errors right away if its position is a lambda expression. Thanks, Vicente ------------- Commit messages: - 8262095: NPE in Flow.visitApply: Cannot invoke getThrownTypes because tree.meth.type is null Changes: https://git.openjdk.java.net/jdk/pull/5307/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5307&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262095 Stats: 26 lines in 3 files changed: 25 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5307.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5307/head:pull/5307 PR: https://git.openjdk.java.net/jdk/pull/5307 From vromero at openjdk.java.net Mon Aug 30 21:14:31 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 30 Aug 2021 21:14:31 GMT Subject: RFR: 8268885: duplicate checkcast when destination type is not first type of intersection type In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 23:29:15 GMT, Vicente Romero wrote: > Please review this PR which is fixing the following bug: javac is generating duplicate checkcast for cases like: > > > class IntersectionTypeTest { > interface I1 {} > interface I2 {} > static class C {} > void test() { > I2 i = (I1 & I2) new C(); > } > } > > basically when an intersection type is used in a cast expression and the target is not the type in the intersection. > > TIA > > PS. I also ran the JCK tests for this patch, same results as without the patch ping ------------- PR: https://git.openjdk.java.net/jdk/pull/5235 From vromero at openjdk.java.net Mon Aug 30 21:46:32 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 30 Aug 2021 21:46:32 GMT Subject: RFR: 8268148: unchecked warnings handle ? and ? extends Object differently In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:17:36 GMT, Vicente Romero wrote: > Please review this PR. Currently javac handles differently `?` and `? extends Object` when reporting unchecked warnings when according to the spec they should be handled the same way. This PR is fixing this. > > TIA ping ------------- PR: https://git.openjdk.java.net/jdk/pull/5224 From serb at openjdk.java.net Mon Aug 30 23:46:15 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 30 Aug 2021 23:46:15 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v3] In-Reply-To: References: Message-ID: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Sergey Bylokhov 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 15 additional commits since the last revision: - Merge branch 'master' into standard-encodings-in-non-public-modules - Update the usage of Files.readAllLines() - Update datatransfer - Merge branch 'master' into standard-encodings-in-non-public-modules - Merge branch 'master' into standard-encodings-in-non-public-modules - Fix related imports - Merge branch 'master' into standard-encodings-in-non-public-modules - Cleanup UnsupportedEncodingException - Update PacketStream.java - Rollback TextTests, should be compatible with jdk1.4 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/22865adf...79829ec8 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5210/files - new: https://git.openjdk.java.net/jdk/pull/5210/files/e7127644..79829ec8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=01-02 Stats: 9423 lines in 339 files changed: 5247 ins; 1917 del; 2259 mod Patch: https://git.openjdk.java.net/jdk/pull/5210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210 PR: https://git.openjdk.java.net/jdk/pull/5210 From darcy at openjdk.java.net Tue Aug 31 05:15:46 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 31 Aug 2021 05:15:46 GMT Subject: RFR: 8273157: Add convenience methods to Messager Message-ID: <2110DPlELadese0h1e8tBUHZ4uL0nWyCz16GcfYZkM0=.f52f5de8-f3ff-4149-810b-6a95a54230f6@github.com> Hello, Please review the addition of a half dozen convenience methods to Messager to allow code like m.printError("Error message") rather than m.printMessage(Kind.ERROR, "Error message") For each of notes, warnings, and errors, two methods are added: one taking a message, the second taking a message and an element. There are other overloads of the printMessage method with additional arguments, but they are less commonly used and weren't judged to merit dedicated convenience methods. The changeset also refactors ~125 of ~150 call sites of printMessage in the langtools regression tests to use the new methods. The updated tests (or tests using the updated files) all pass. I became more convinced of the utility of the new methods after using them in the refactoring. I'll run a script to update the copyright years before any integration. CSR for review: https://bugs.openjdk.java.net/browse/JDK-8273160 ------------- Commit messages: - 8273157 Changes: https://git.openjdk.java.net/jdk/pull/5309/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5309&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273157 Stats: 297 lines in 85 files changed: 88 ins; 30 del; 179 mod Patch: https://git.openjdk.java.net/jdk/pull/5309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5309/head:pull/5309 PR: https://git.openjdk.java.net/jdk/pull/5309 From jlahoda at openjdk.java.net Tue Aug 31 07:32:39 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 31 Aug 2021 07:32:39 GMT Subject: RFR: 8272776: NullPointerException not reported Message-ID: <4Fld7kLSi-ib_IkmeS04RUU7RFt-Trb9oZ2If5D3FJc=.2a82a5e1-d68e-4062-ad41-94e3ee5e4a74@github.com> Code like: public void foo(Object o) { switch (o) { default: break; case String s :System.out.println(s); break; } } public static void main(String[] args) { (new X()).foo(null); // NPE expected, but prints null } Should lead to a NPE when executed, because `default` does not cover `null` and there is no total pattern in the switch, but the NPE is not thrown. The reason is that when generating the code, a `hasTotalPattern` flag is used, which means "has a total pattern or default". The code needs to check whether there is a real total pattern (which covers `null`) or not. That is done by looking for the `default` case label, but the code only checks the last case for `default`. It needs to check all cases to differentiate between a switch with a real total pattern and a switch with a `default`. ------------- Commit messages: - 8272776: NullPointerException not reported Changes: https://git.openjdk.java.net/jdk/pull/5312/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5312&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272776 Stats: 18 lines in 2 files changed: 14 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5312/head:pull/5312 PR: https://git.openjdk.java.net/jdk/pull/5312 From prappo at openjdk.java.net Tue Aug 31 12:16:47 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 31 Aug 2021 12:16:47 GMT Subject: RFR: 8266666: Implementation for snippets [v21] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Merge branch 'master' into 8266666 - Clean up tag parsing Removes two methods from an older implementation where HTML and javadoc tag attributes were modelled by different DocTree subtypes. Moves the `tagAttrs` method to TagParser responsible for parsing `@snippet` because `:` attribute terminator is specific to `@snippet`. Makes parser stop on `:`. Removes chatty discussion comments from code as suggested by Jonathan Gibbons. - Exclude unrelated changes to resources Also fixes a typo. - Recover from a sloppy merge Apparently, I've performed at least one sloppy merge while developing the feature in sandbox. As a result, some changes brought by e4d045402fa1992a1d91586bd4f67362d07f543c were discarded. The specdiff for the CSR actually shows this and has to be regenerated. - Format code closer to the ambient style Makes new constructs look more natural in their context by adopting the surrounding style. - Merge branch 'master' into 8266666 Redoing a faulty merge and pushing the result forcefully. - Clarify the attributes order comment - Fix import layout and typos - Add @summary to tests From https://openjdk.java.net/jtreg/faq.html: The @summary tag describes the condition that is checked by the test. It is especially useful for non-regression tests, which by definition don't have bug numbers, but even if there's a bug number it's helpful to include a summary. Note that a test summary is generally not the same thing as a Bugtraq synopsis, since the latter describes the bug rather than the condition that the bug violates. That said, the JBS synopsis for 8266666 suits those tests just fine. - Remove superfluous editor-fold - ... and 13 more: https://git.openjdk.java.net/jdk/compare/5185dbde...b2b604fb ------------- Changes: https://git.openjdk.java.net/jdk/pull/4795/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=20 Stats: 4657 lines in 44 files changed: 4631 ins; 4 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From jlahoda at openjdk.java.net Tue Aug 31 15:09:28 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 31 Aug 2021 15:09:28 GMT Subject: RFR: 8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot invoke getThrownTypes because tree.meth.type is null In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 18:08:49 GMT, Vicente Romero wrote: > Please review this PR which is not filtering errors for cases when the error is reported in a lambda expression. Before the fix for [JDK-8205418](https://bugs.openjdk.java.net/browse/JDK-8205418) javac was a bit more aggressive reporting errors found during recovery. > > After the fix mentioned above, the intention was to try to generate better error messages by attributing deferred nodes with more precise targets. But for some cases like the one reported in the bug entry, javac would swallow the error report. This fix is just reporting the errors right away if its position is a lambda expression. > > Thanks, > Vicente Seems sensible to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5307 From vromero at openjdk.java.net Tue Aug 31 15:26:26 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 31 Aug 2021 15:26:26 GMT Subject: RFR: 8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot invoke getThrownTypes because tree.meth.type is null In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 18:08:49 GMT, Vicente Romero wrote: > Please review this PR which is not filtering errors for cases when the error is reported in a lambda expression. Before the fix for [JDK-8205418](https://bugs.openjdk.java.net/browse/JDK-8205418) javac was a bit more aggressive reporting errors found during recovery. > > After the fix mentioned above, the intention was to try to generate better error messages by attributing deferred nodes with more precise targets. But for some cases like the one reported in the bug entry, javac would swallow the error report. This fix is just reporting the errors right away if its position is a lambda expression. > > Thanks, > Vicente thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5307 From vromero at openjdk.java.net Tue Aug 31 15:43:33 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 31 Aug 2021 15:43:33 GMT Subject: Integrated: 8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot invoke getThrownTypes because tree.meth.type is null In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 18:08:49 GMT, Vicente Romero wrote: > Please review this PR which is not filtering errors for cases when the error is reported in a lambda expression. Before the fix for [JDK-8205418](https://bugs.openjdk.java.net/browse/JDK-8205418) javac was a bit more aggressive reporting errors found during recovery. > > After the fix mentioned above, the intention was to try to generate better error messages by attributing deferred nodes with more precise targets. But for some cases like the one reported in the bug entry, javac would swallow the error report. This fix is just reporting the errors right away if its position is a lambda expression. > > Thanks, > Vicente This pull request has now been integrated. Changeset: 75d987a0 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/75d987a0dd6f8cc41808f7ba566e914817e465dc Stats: 26 lines in 3 files changed: 25 ins; 0 del; 1 mod 8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot invoke getThrownTypes because tree.meth.type is null Co-authored-by: Jan Lahoda Co-authored-by: Vicente Romero Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/5307 From mullan at openjdk.java.net Tue Aug 31 19:03:46 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 31 Aug 2021 19:03:46 GMT Subject: RFR: 8269039: Disable SHA-1 Signed JARs Message-ID: This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155. Some additional notes about the fix: - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows: - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive. - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint. - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue. - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms. ------------- Commit messages: - Fix trailing whitespace. - Initial revision. Changes: https://git.openjdk.java.net/jdk/pull/5320/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5320&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269039 Stats: 643 lines in 27 files changed: 301 ins; 214 del; 128 mod Patch: https://git.openjdk.java.net/jdk/pull/5320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5320/head:pull/5320 PR: https://git.openjdk.java.net/jdk/pull/5320 From serb at openjdk.java.net Tue Aug 31 20:16:43 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 31 Aug 2021 20:16:43 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). Any volunteers to take a look at the tests update? ------------- PR: https://git.openjdk.java.net/jdk/pull/5098 From serb at openjdk.java.net Tue Aug 31 20:17:25 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 31 Aug 2021 20:17:25 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v4] In-Reply-To: References: Message-ID: <0BjXWeJE25KSeovjDycar9nGsqSQ4vehXgMBrqwWGHQ=.e83aec87-77a8-414d-9acb-bdbdd6bb27ca@github.com> > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Sergey Bylokhov 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 16 additional commits since the last revision: - Merge branch 'master' into standard-encodings-in-non-public-modules - Merge branch 'master' into standard-encodings-in-non-public-modules - Update the usage of Files.readAllLines() - Update datatransfer - Merge branch 'master' into standard-encodings-in-non-public-modules - Merge branch 'master' into standard-encodings-in-non-public-modules - Fix related imports - Merge branch 'master' into standard-encodings-in-non-public-modules - Cleanup UnsupportedEncodingException - Update PacketStream.java - ... and 6 more: https://git.openjdk.java.net/jdk/compare/7289121a...7fe0327e ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5210/files - new: https://git.openjdk.java.net/jdk/pull/5210/files/79829ec8..7fe0327e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=02-03 Stats: 949 lines in 30 files changed: 678 ins; 166 del; 105 mod Patch: https://git.openjdk.java.net/jdk/pull/5210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210 PR: https://git.openjdk.java.net/jdk/pull/5210 From forax at univ-mlv.fr Tue Aug 31 21:46:43 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 31 Aug 2021 23:46:43 +0200 (CEST) Subject: JShell does not recognize "non-sealed" as a keyword at top level Message-ID: <625284020.968439.1630446403486.JavaMail.zimbra@u-pem.fr> Hi all, this code does not work in JShell. sealed interface Component permits Label, Button, Canvas {} record Label(String name) implements Component {} final class Button implements Component {} non-sealed class Canvas implements Component {} We had a very similar bug with "sealed" not a long ago :( regards, R?mi