From itakiguchi at openjdk.java.net Mon Nov 1 16:10:26 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 1 Nov 2021 16:10:26 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5] In-Reply-To: References: Message-ID: > JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. > After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. > These commands use PrintWriter instead of standard out/err with PrintStream. Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - 8274544: Langtools command's usage were garbled on Japanese Windows - 8274544: Langtools command's usage were garbled on Japanese Windows - 8274544: Langtools command's usage were garbled on Japanese Windows - 8274544: Langtools command's usage were garbled on Japanese Windows - Langtools command's usage were grabled on Japanese Windows ------------- Changes: https://git.openjdk.java.net/jdk/pull/5771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=04 Stats: 104 lines in 17 files changed: 74 ins; 0 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/5771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771 PR: https://git.openjdk.java.net/jdk/pull/5771 From itakiguchi at openjdk.java.net Tue Nov 2 00:19:15 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Tue, 2 Nov 2021 00:19:15 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5] In-Reply-To: References:

Message-ID: On Wed, 3 Nov 2021 18:41:19 GMT, Naoto Sato wrote: >> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - 8274544: Langtools command's usage were garbled on Japanese Windows >> - 8274544: Langtools command's usage were garbled on Japanese Windows >> - 8274544: Langtools command's usage were garbled on Japanese Windows >> - 8274544: Langtools command's usage were garbled on Japanese Windows >> - Langtools command's usage were grabled on Japanese Windows > > Firstly, please do NOT rebase your fix, as it will clobber the review history. Use merge instead. > As to the fix, I am not sure consolidating the code into Log.java would be OK as it would introduce module dependency. @naotoj I'm sorry about my bad operation. @jonathan-gibbons I appreciate if you give me some suggestions. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From ihse at openjdk.java.net Thu Nov 4 17:38:53 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 4 Nov 2021 17:38:53 GMT Subject: RFR: 8276641: Use blessed modifier order in jshell [v3] In-Reply-To: References: Message-ID: > I ran bin/blessed-modifier-order.sh on source owned by jshell/project Kulla. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Also update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6255/files - new: https://git.openjdk.java.net/jdk/pull/6255/files/31a6a917..295ed7ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6255&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6255&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6255.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6255/head:pull/6255 PR: https://git.openjdk.java.net/jdk/pull/6255 From iris at openjdk.java.net Thu Nov 4 17:51:14 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 4 Nov 2021 17:51:14 GMT Subject: RFR: 8276641: Use blessed modifier order in jshell [v3] In-Reply-To: References:

Message-ID: <9nWLY4bd-bX1YcXjbpLGup2U9SaDSsdbHU7jsgxgEAI=.cdf4c995-d2bb-4782-af1e-03786275d26e@github.com> On Thu, 4 Nov 2021 17:38:53 GMT, Magnus Ihse Bursie wrote: >> I ran bin/blessed-modifier-order.sh on source owned by jshell/project Kulla. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update copyright year Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6255 From ihse at openjdk.java.net Fri Nov 5 12:11:17 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 5 Nov 2021 12:11:17 GMT Subject: Integrated: 8276641: Use blessed modifier order in jshell In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 13:06:05 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by jshell/project Kulla. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. This pull request has now been integrated. Changeset: b9331360 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/b9331360f50afe5b4549d7003d4932ebc54a3c71 Stats: 11 lines in 5 files changed: 0 ins; 0 del; 11 mod 8276641: Use blessed modifier order in jshell Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk/pull/6255 From vromero at openjdk.java.net Fri Nov 5 15:04:15 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 5 Nov 2021 15:04:15 GMT Subject: RFR: 8276149: jshell throws EOF error when throwing exception inside switch expression In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 05:46:32 GMT, Jan Lahoda wrote: > The completeness analysis does not correctly handle `case ... -> throw`, as it does not expect that `->` can be followed by `throw`, and as an ultimate consequence, it will consider this to be a complete snippet: > > void t(int i) { > int v = switch (i) { > case 0 -> throw new IllegalStateException(); > > > While it apparently isn't a complete snippet. > > The proposed solution is to add a special-case handling for this specific combination, which will ensure JShell will wait for more input for this snippet. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6207 From vromero at openjdk.java.net Fri Nov 5 15:14:15 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 5 Nov 2021 15:14:15 GMT Subject: RFR: 8274734: the method jdk.jshell.SourceCodeAnalysis documentation not working In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 10:54:40 GMT, Jan Lahoda wrote: > The `SourceCodeAnalysisImpl` needs to open `src.zip` to read the sources to get javadoc. Unfortunately, it uses the variant of the `newFileSystem` method that can only be used one, and hence only one `SourceCodeAnalysisImpl` can provide documentation. The proposed solution is to use the variant of the `newFileSystem` method that can open the FileSystem multiple times, so that multiple independent SourceCodeAnalysisImpl instances can provide documentation. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6080 From vromero at openjdk.java.net Fri Nov 5 15:30:17 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 5 Nov 2021 15:30:17 GMT Subject: RFR: 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 16:48:07 GMT, Jan Lahoda wrote: > When JShell processes `int strictfp = 0;` (which is obviously erroneous), it will speculativelly try to parse and attribute code along these lines: > > package REPL; > import java.io.*;import java.math.*;import java.net.*;import java.nio.file.*;import java.util.*;import java.util.concurrent.*;import java.util.function.*;import java.util.prefs.*;import java.util.regex.*;import java.util.stream.*; > class $JShell$DOESNOTMATTER { > public static Object do_it$() throws Throwable { > return int strictfp = 0; > } > } > > > This crashes `Attr`, as the `strictfp` will be wrapped in `JCModifiers`, wrapped inside an erroneous tree, and `Attr` does not handle modifiers. > > The proposal is to let `Attr` "handle" the `JCModifiers` in an error-recovery situation. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5101: > 5099: > 5100: @Override > 5101: public void visitModifiers(JCModifiers tree) { question can't we report this error when the erroneous code is being parsed? adding this method to Attr makes me feel a bit uncomfortable, I can understand if this is the only / best way though ------------- PR: https://git.openjdk.java.net/jdk/pull/5897 From jlahoda at openjdk.java.net Fri Nov 5 18:30:33 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 5 Nov 2021 18:30:33 GMT Subject: RFR: 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" In-Reply-To: References:

Message-ID: On Fri, 5 Nov 2021 15:27:32 GMT, Vicente Romero wrote: >> When JShell processes `int strictfp = 0;` (which is obviously erroneous), it will speculativelly try to parse and attribute code along these lines: >> >> package REPL; >> import java.io.*;import java.math.*;import java.net.*;import java.nio.file.*;import java.util.*;import java.util.concurrent.*;import java.util.function.*;import java.util.prefs.*;import java.util.regex.*;import java.util.stream.*; >> class $JShell$DOESNOTMATTER { >> public static Object do_it$() throws Throwable { >> return int strictfp = 0; >> } >> } >> >> >> This crashes `Attr`, as the `strictfp` will be wrapped in `JCModifiers`, wrapped inside an erroneous tree, and `Attr` does not handle modifiers. >> >> The proposal is to let `Attr` "handle" the `JCModifiers` in an error-recovery situation. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5101: > >> 5099: >> 5100: @Override >> 5101: public void visitModifiers(JCModifiers tree) { > > question can't we report this error when the erroneous code is being parsed? adding this method to Attr makes me feel a bit uncomfortable, I can understand if this is the only / best way though Parser will report the error, and will wrap the (presumed) modifiers into an erroneous tree, so the AST is reasonable. But JShell runs javac with `--should-stop=at=FLOW`, so the error in parser will not stop the processing, and when `Attr` will look into the erroneous tree, it will fail. ------------- PR: https://git.openjdk.java.net/jdk/pull/5897 From vromero at openjdk.java.net Fri Nov 5 18:46:38 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 5 Nov 2021 18:46:38 GMT Subject: RFR: 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" In-Reply-To: References: Message-ID: <3y9A3pWIrfBR6UA9oNepWCfLG2KzNn9fDbp3obxoAMY=.000409f3-035a-4760-b727-4c92ce01d4a5@github.com> On Mon, 11 Oct 2021 16:48:07 GMT, Jan Lahoda wrote: > When JShell processes `int strictfp = 0;` (which is obviously erroneous), it will speculativelly try to parse and attribute code along these lines: > > package REPL; > import java.io.*;import java.math.*;import java.net.*;import java.nio.file.*;import java.util.*;import java.util.concurrent.*;import java.util.function.*;import java.util.prefs.*;import java.util.regex.*;import java.util.stream.*; > class $JShell$DOESNOTMATTER { > public static Object do_it$() throws Throwable { > return int strictfp = 0; > } > } > > > This crashes `Attr`, as the `strictfp` will be wrapped in `JCModifiers`, wrapped inside an erroneous tree, and `Attr` does not handle modifiers. > > The proposal is to let `Attr` "handle" the `JCModifiers` in an error-recovery situation. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5897 From vromero at openjdk.java.net Fri Nov 5 18:46:39 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 5 Nov 2021 18:46:39 GMT Subject: RFR: 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" In-Reply-To: References:

Message-ID: On Fri, 5 Nov 2021 18:27:58 GMT, Jan Lahoda wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5101: >> >>> 5099: >>> 5100: @Override >>> 5101: public void visitModifiers(JCModifiers tree) { >> >> question can't we report this error when the erroneous code is being parsed? adding this method to Attr makes me feel a bit uncomfortable, I can understand if this is the only / best way though > > Parser will report the error, and will wrap the (presumed) modifiers into an erroneous tree, so the AST is reasonable. But JShell runs javac with `--should-stop=at=FLOW`, so the error in parser will not stop the processing, and when `Attr` will look into the erroneous tree, it will fail. I see, thanks for the clarification ------------- PR: https://git.openjdk.java.net/jdk/pull/5897 From shade at openjdk.java.net Mon Nov 8 07:45:37 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 8 Nov 2021 07:45:37 GMT Subject: RFR: 8276306: jdk/jshell/CustomInputToolBuilder.java fails intermittently on storage acquisition In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 08:28:33 GMT, Aleksey Shipilev wrote: > This test intermittently fails in `tier1` runs on our highly parallel machines. I believe there is the interaction between the tests that use the preferences storage. See bug for the stack trace. I think we can fortify this test by overriding the default persistence storage. > > Additional testing: > - [x] 10x `langtools:tier1`, no failures now Anyone? :) ------------- PR: https://git.openjdk.java.net/jdk/pull/6208 From jlahoda at openjdk.java.net Mon Nov 8 08:02:36 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 8 Nov 2021 08:02:36 GMT Subject: RFR: 8276306: jdk/jshell/CustomInputToolBuilder.java fails intermittently on storage acquisition In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 08:28:33 GMT, Aleksey Shipilev wrote: > This test intermittently fails in `tier1` runs on our highly parallel machines. I believe there is the interaction between the tests that use the preferences storage. See bug for the stack trace. I think we can fortify this test by overriding the default persistence storage. > > Additional testing: > - [x] 10x `langtools:tier1`, no failures now Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6208 From shade at openjdk.java.net Mon Nov 8 08:11:36 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 8 Nov 2021 08:11:36 GMT Subject: RFR: 8276306: jdk/jshell/CustomInputToolBuilder.java fails intermittently on storage acquisition In-Reply-To: References: Message-ID: <1-9IxtidaRtkI4IKsDdQGS5BLdyZd9dAXV8WpWjSQCs=.37b48a74-66fb-4d5f-807d-2b252eb19822@github.com> On Tue, 2 Nov 2021 08:28:33 GMT, Aleksey Shipilev wrote: > This test intermittently fails in `tier1` runs on our highly parallel machines. I believe there is the interaction between the tests that use the preferences storage. See bug for the stack trace. I think we can fortify this test by overriding the default persistence storage. > > Additional testing: > - [x] 10x `langtools:tier1`, no failures now Thank you! Trivial, right? I'll integrate it soon then. ------------- PR: https://git.openjdk.java.net/jdk/pull/6208 From jlahoda at openjdk.java.net Mon Nov 8 13:23:39 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 8 Nov 2021 13:23:39 GMT Subject: Integrated: 8274734: the method jdk.jshell.SourceCodeAnalysis documentation not working In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 10:54:40 GMT, Jan Lahoda wrote: > The `SourceCodeAnalysisImpl` needs to open `src.zip` to read the sources to get javadoc. Unfortunately, it uses the variant of the `newFileSystem` method that can only be used one, and hence only one `SourceCodeAnalysisImpl` can provide documentation. The proposed solution is to use the variant of the `newFileSystem` method that can open the FileSystem multiple times, so that multiple independent SourceCodeAnalysisImpl instances can provide documentation. This pull request has now been integrated. Changeset: 4c14eddf Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/4c14eddf41f1d9984417dc5ac6aba6f268b31029 Stats: 78 lines in 2 files changed: 76 ins; 1 del; 1 mod 8274734: the method jdk.jshell.SourceCodeAnalysis documentation not working Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/6080 From jlahoda at openjdk.java.net Mon Nov 8 13:24:41 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 8 Nov 2021 13:24:41 GMT Subject: Integrated: 8276149: jshell throws EOF error when throwing exception inside switch expression In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 05:46:32 GMT, Jan Lahoda wrote: > The completeness analysis does not correctly handle `case ... -> throw`, as it does not expect that `->` can be followed by `throw`, and as an ultimate consequence, it will consider this to be a complete snippet: > > void t(int i) { > int v = switch (i) { > case 0 -> throw new IllegalStateException(); > > > While it apparently isn't a complete snippet. > > The proposed solution is to add a special-case handling for this specific combination, which will ensure JShell will wait for more input for this snippet. This pull request has now been integrated. Changeset: fa754b8f Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/fa754b8ffda0ae16cda03d896260870ff8fb6ae9 Stats: 13 lines in 2 files changed: 8 ins; 0 del; 5 mod 8276149: jshell throws EOF error when throwing exception inside switch expression Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/6207 From shade at openjdk.java.net Mon Nov 8 15:38:38 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 8 Nov 2021 15:38:38 GMT Subject: Integrated: 8276306: jdk/jshell/CustomInputToolBuilder.java fails intermittently on storage acquisition In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 08:28:33 GMT, Aleksey Shipilev wrote: > This test intermittently fails in `tier1` runs on our highly parallel machines. I believe there is the interaction between the tests that use the preferences storage. See bug for the stack trace. I think we can fortify this test by overriding the default persistence storage. > > Additional testing: > - [x] 10x `langtools:tier1`, no failures now This pull request has now been integrated. Changeset: 75adf54b Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/75adf54bdcc5e06fb8e8ca499a2f326d70b65f76 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8276306: jdk/jshell/CustomInputToolBuilder.java fails intermittently on storage acquisition Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/6208 From itakiguchi at openjdk.java.net Mon Nov 8 17:12:34 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 8 Nov 2021 17:12:34 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v3] In-Reply-To: <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com> References:

<4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com> Message-ID: On Tue, 19 Oct 2021 01:26:35 GMT, Jonathan Gibbons wrote: >> Ichiroh Takiguchi has 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. > > This is pretty ugly code to be replicating so many times. > > What if the tools have been run in an environment where `System.out` and `System.err` have already been redirected in some manner, with `System.setOut` or `System.setErr`? You should not assume that `System.out` and `System.err` will always refer to the console. Hello @jonathan-gibbons . I tested -Xstdout option for javac command on Linux and Windows platform. Output file encoding was UTF-8. I assume it's expected result. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From jjg at openjdk.java.net Wed Nov 10 19:19:36 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 10 Nov 2021 19:19:36 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5] In-Reply-To: References:

Message-ID: On Wed, 10 Nov 2021 19:16:58 GMT, Jonathan Gibbons wrote: > Generally, the issue is related to the fact that we wrap a PrintStream in a PrintWriter ... and, if I understand correctly, the writer ends up with the wrong character encoding. Is it possible to change PrintWriter and/or PrintStream so that the correct underlying encoding used by the PrintStream is also used by the PrintWriter. That way, all existing uses where a PrintWriter wraps a PrintStream would continue to work without any modification. JEP 400 has moved the JDK to using UTF-8 as the default charset, a long overdue change. So if you create a PrintStream or a PrintWriter without specifying the charset then it will default to UTF-8. The issue that I think we have with javac and a few other tools is that they are creating PrintWriters on PrintStreams where the underlying streams are stdout/stderr and so using the native encoding. There was exploration into special casing this scenario during JEP 400 that was rejected because it complicates the spec and may not be feasible in cases where there are many layers in the onion. If there is resistance to fixing the tools then we might have to re-visit this. Naoto may have more to say on this. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From alanb at openjdk.java.net Wed Nov 10 20:03:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 10 Nov 2021 20:03:38 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5] In-Reply-To: References:

Message-ID: On Wed, 10 Nov 2021 19:41:29 GMT, Jonathan Gibbons wrote: > 1. `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)` should be redefined so that they internally check if the stream arg is a PrintStream, in which case they use the encoding from the `PrinStream` instead of the default. I think you mean the PrintWriter constructors here. Yes, there is merit in that. PrintStream is a bit unusual in that it's an OutputStream but it has a charset because it prints text output. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From naoto at openjdk.java.net Wed Nov 10 21:22:35 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 10 Nov 2021 21:22:35 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5] In-Reply-To: References:

Message-ID: <9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com> On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - 8274544: Langtools command's usage were garbled on Japanese Windows > - 8274544: Langtools command's usage were garbled on Japanese Windows > - 8274544: Langtools command's usage were garbled on Japanese Windows > - 8274544: Langtools command's usage were garbled on Japanese Windows > - Langtools command's usage were grabled on Japanese Windows Good suggestions. Filed a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8276970 ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From jjg at openjdk.java.net Wed Nov 10 21:47:34 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 10 Nov 2021 21:47:34 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5] In-Reply-To: References:

Message-ID: On Wed, 10 Nov 2021 20:00:39 GMT, Alan Bateman wrote: > > 1. `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)` should be redefined so that they internally check if the stream arg is a PrintStream, in which case they use the encoding from the `PrinStream` instead of the default. > > I think you mean the PrintWriter constructors here. Yes, there is merit in that. PrintStream is a bit unusual in that it's an OutputStream but it has a charset because it prints text output. Yes, sorry for the confusion. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From jjg at openjdk.java.net Wed Nov 10 21:55:42 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 10 Nov 2021 21:55:42 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5] In-Reply-To: References:

Message-ID: <8ugE0AF10_pPZDg1PoaezIIz1m-VG12m24NqmPcQHOA=.a437b180-fa0b-43f3-9c32-84179893a4dd@github.com> On Wed, 10 Nov 2021 19:46:09 GMT, Alan Bateman wrote: > If there is resistance to fixing the tools then we might have to re-visit this. It's not just the JDK tools that are an issue. I think that wrapping some PrintStream into a PrintWriter is a common enough idiom that it is not reasonable to fix all occurrences -- i.e. including those outside of JDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From itakiguchi at openjdk.java.net Sun Nov 14 16:48:39 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Sun, 14 Nov 2021 16:48:39 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5] In-Reply-To: <9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com> References:

<9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com> Message-ID: <3zQ6qYDHh9mxWcS86kifh5L2NwXUR-EKc5k6SnqkD5I=.b5f0ec9a-fe26-420d-96c1-d06032d37191@github.com> On Wed, 10 Nov 2021 21:19:30 GMT, Naoto Sato wrote: >> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - 8274544: Langtools command's usage were garbled on Japanese Windows >> - 8274544: Langtools command's usage were garbled on Japanese Windows >> - 8274544: Langtools command's usage were garbled on Japanese Windows >> - 8274544: Langtools command's usage were garbled on Japanese Windows >> - Langtools command's usage were grabled on Japanese Windows > > Good suggestions. Filed a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8276970 Hello @naotoj . For PrintStream.getCharset(), following changes may be required. +++ src/java.base/share/classes/java/io/OutputStreamWriter.java + Charset getCharset() { + return se.getCharset(); + } +++ src/java.base/share/classes/java/io/PrintStream.java + public Charset getCharset() { + return charOut.getCharset(); + } +++ src/java.base/share/classes/sun/nio/cs/StreamEncoder.java + public Charset getCharset() { + return cs; + } For javac code, we may not use PrintStream.getCharset() directly because javac code is compiled by boot compiler. We need to use reflection, like: +++ src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java + private static Charset getCharset(PrintStream ps) { + try { + Method getCharset = PrintStream.class.getDeclaredMethod("getCharset"); + return (Charset)getCharset.invoke(ps); + } catch (Exception e) { + return Charset.defaultCharset(); + } + } If we add following constructors against PrintWriter, we just change javap and jshell code. But I cannot evaluate this code changes. +++ src/java.base/share/classes/java/io/PrintWriter.java + public PrintWriter(PrintStream ps) { + this((OutputStream)ps, false, ps.getCharset()); + } + public PrintWriter(PrintStream ps, boolean autoFlush) { + this((OutputStream)ps, autoFlush, ps.getCharset()); + } I really appreciate if you handle this kind of code change via JEP-400. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From jjg at openjdk.java.net Mon Nov 15 20:00:44 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 15 Nov 2021 20:00:44 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5] In-Reply-To: References:

Message-ID: On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi wrote: >> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. >> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows. >> These commands use PrintWriter instead of standard out/err with PrintStream. > > Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - 8274544: Langtools command's usage were garbled on Japanese Windows > - 8274544: Langtools command's usage were garbled on Japanese Windows > - 8274544: Langtools command's usage were garbled on Japanese Windows > - 8274544: Langtools command's usage were garbled on Japanese Windows > - Langtools command's usage were grabled on Japanese Windows The gist of the issue is that `PrintWriter` (w/o explicit charset) uses the default charset, ignoring `PrintStream`'s charset. So it basically is irrelevant of JEP400, but apparently, JEP400 made it visible as it keeps the System.out/err encoding in `native.encoding` while changing the default to `UTF-8`. I am now in the process of creating a PR for the issue JDK-8276970, and will submit it shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From serb at openjdk.java.net Tue Nov 16 20:30:23 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 16 Nov 2021 20:30:23 GMT Subject: RFR: 8272358: Some tests may fail when executed with other locales than the US [v2] 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: > 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). 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 two additional commits since the last revision: - Merge branch 'master' into JDK-8272358 - Initial fix of JDK-8272358 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5098/files - new: https://git.openjdk.java.net/jdk/pull/5098/files/1254951a..4860557e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5098&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5098&range=00-01 Stats: 994174 lines in 4051 files changed: 529940 ins; 443625 del; 20609 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 duke at openjdk.java.net Wed Nov 17 19:45:06 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 17 Nov 2021 19:45:06 GMT Subject: RFR: 8277348: Use String.stripTrailing() in jdk.jshell where applicable Message-ID: <9ZTNjFmoBgjdsjNcBVE9J0uAJK2ZeiPKu3fs3joLHbk=.76707c97-8bf0-4868-8cec-bf6b766df0fb@github.com> There are 2 methods in jdk.jshell module which trim trailing whitespace characters from String. 1. jdk.internal.jshell.tool.JShellTool#trimEnd 2. jdk.jshell.Util#trimEnd Since Java 11 we have a method String.stripTrailing which could be used instead. ------------- Commit messages: - [PATCH] Use String.stripTrailing() in jdk.jshell where applicable Changes: https://git.openjdk.java.net/jdk/pull/6365/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6365&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277348 Stats: 43 lines in 4 files changed: 0 ins; 33 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/6365.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6365/head:pull/6365 PR: https://git.openjdk.java.net/jdk/pull/6365 From serb at openjdk.java.net Wed Nov 17 22:24:47 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 17 Nov 2021 22:24:47 GMT Subject: Integrated: 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). This pull request has now been integrated. Changeset: 29e552c0 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/29e552c03a2825f9526330072668a1d63ac68fd4 Stats: 9 lines in 4 files changed: 1 ins; 0 del; 8 mod 8272358: Some tests may fail when executed with other locales than the US Reviewed-by: aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/5098 From jlahoda at openjdk.java.net Fri Nov 19 07:53:47 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 19 Nov 2021 07:53:47 GMT Subject: Integrated: 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" In-Reply-To: References: Message-ID: <8eLsx73SXjQDxthT8DCVdGK9PgXmbK7jl0LjTP_ltwA=.c7ca0345-da68-48d9-9256-2fa3af62069c@github.com> On Mon, 11 Oct 2021 16:48:07 GMT, Jan Lahoda wrote: > When JShell processes `int strictfp = 0;` (which is obviously erroneous), it will speculativelly try to parse and attribute code along these lines: > > package REPL; > import java.io.*;import java.math.*;import java.net.*;import java.nio.file.*;import java.util.*;import java.util.concurrent.*;import java.util.function.*;import java.util.prefs.*;import java.util.regex.*;import java.util.stream.*; > class $JShell$DOESNOTMATTER { > public static Object do_it$() throws Throwable { > return int strictfp = 0; > } > } > > > This crashes `Attr`, as the `strictfp` will be wrapped in `JCModifiers`, wrapped inside an erroneous tree, and `Attr` does not handle modifiers. > > The proposal is to let `Attr` "handle" the `JCModifiers` in an error-recovery situation. This pull request has now been integrated. Changeset: 2f20b0d8 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/2f20b0d8daca6bdc53b4b9e1837c428930d34236 Stats: 182 lines in 3 files changed: 181 ins; 0 del; 1 mod 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/5897 From naoto at openjdk.java.net Fri Nov 19 17:35:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 19 Nov 2021 17:35:09 GMT Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5] In-Reply-To: <3zQ6qYDHh9mxWcS86kifh5L2NwXUR-EKc5k6SnqkD5I=.b5f0ec9a-fe26-420d-96c1-d06032d37191@github.com> References:

<9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com> <3zQ6qYDHh9mxWcS86kifh5L2NwXUR-EKc5k6SnqkD5I=.b5f0ec9a-fe26-420d-96c1-d06032d37191@github.com> <7JYAnqIv4UFGDCnbFtovQrkFC-jUUmRPLrUfQsJn1po=.66ad8156-f70f-4ebe-8bc0-2a1ee8a6b1af@github.com> Message-ID: On Fri, 19 Nov 2021 16:48:03 GMT, Naoto Sato wrote: >> Hello @naotoj . >> For PrintStream.getCharset(), following changes may be required. >> >> +++ src/java.base/share/classes/java/io/OutputStreamWriter.java >> + Charset getCharset() { >> + return se.getCharset(); >> + } >> >> +++ src/java.base/share/classes/java/io/PrintStream.java >> + public Charset getCharset() { >> + return charOut.getCharset(); >> + } >> >> +++ src/java.base/share/classes/sun/nio/cs/StreamEncoder.java >> + public Charset getCharset() { >> + return cs; >> + } >> >> For javac code, we may not use PrintStream.getCharset() directly because javac code is compiled by boot compiler. >> We need to use reflection, like: >> >> +++ src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java >> + private static Charset getCharset(PrintStream ps) { >> + try { >> + Method getCharset = PrintStream.class.getDeclaredMethod("getCharset"); >> + return (Charset)getCharset.invoke(ps); >> + } catch (Exception e) { >> + return Charset.defaultCharset(); >> + } >> + } >> >> If we add following constructors against PrintWriter, we just change javap and jshell code. >> But I cannot evaluate this code changes. >> >> +++ src/java.base/share/classes/java/io/PrintWriter.java >> + public PrintWriter(PrintStream ps) { >> + this((OutputStream)ps, false, ps.getCharset()); >> + } >> + public PrintWriter(PrintStream ps, boolean autoFlush) { >> + this((OutputStream)ps, autoFlush, ps.getCharset()); >> + } >> >> I really appreciate if you handle this kind of code change via JEP-400. > > I think this PR can now safely be withdrawn, as https://github.com/openjdk/jdk/pull/6401 is now integrated. @takiguc, if you do not mind, I will create a PR for the remaining jshell issue. Please let me know. Thanks @naotoj . I opened new pr via 8274784. I'd like to close this pr since main issue was fixed by #6401. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771 From itakiguchi at openjdk.java.net Mon Nov 22 16:18:47 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 22 Nov 2021 16:18:47 GMT Subject: RFR: 8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows Message-ID: JEP-400 was implemented by JDK18-b13. After JDK18-b13, garbled character was displayed by following code on Japanese Windows' command prompt. System.out.println("\u3042") Japanese "A" should be display ed, but garbled character was displayed. Also saved jshell command list did not work as expected if Japanese character was there. Following issue has some information 8274544: Langtools command's usage were garbled on Japanese Windows #5771 https://github.com/openjdk/jdk/pull/5771 This issue also happens on Linux ja_JP.eucjp locale. RemoteExecutionControl.java change is required for this issue. Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal. AbstractTerminal.java change is required for this issue. ------------- Commit messages: - 8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows Changes: https://git.openjdk.java.net/jdk/pull/6505/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6505&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274784 Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6505/head:pull/6505 PR: https://git.openjdk.java.net/jdk/pull/6505 From naoto at openjdk.java.net Mon Nov 22 19:51:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 22 Nov 2021 19:51:09 GMT Subject: RFR: 8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows In-Reply-To: References: Message-ID: <2clDVhebPGtoMvQ2ARFZvyyVfKrDjwoXCYFLaHkhDa8=.73603161-69de-483f-bfe8-b752a0369624@github.com> On Mon, 22 Nov 2021 16:08:58 GMT, Ichiroh Takiguchi wrote: > JEP-400 was implemented by JDK18-b13. > After JDK18-b13, garbled character was displayed by following code on Japanese Windows' command prompt. > > System.out.println("\u3042") > > Japanese "A" should be display ed, but garbled character was displayed. > Also saved jshell command list did not work as expected if Japanese character was there. > > Following issue has some information > 8274544: Langtools command's usage were garbled on Japanese Windows #5771 > https://github.com/openjdk/jdk/pull/5771 > This issue also happens on Linux ja_JP.eucjp locale. > RemoteExecutionControl.java change is required for this issue. > > Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal. > AbstractTerminal.java change is required for this issue. src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractTerminal.java line 60: > 58: this.type = type != null ? type : "ansi"; > 59: this.encoding = encoding != null ? encoding : > 60: Charset.forName(new OutputStreamWriter(System.out).getEncoding(), Charset.defaultCharset()); I don't think `OutputStreamWriter` instance is needed here. System.out instanceof PrintStream ps ? ps.charset() : Charset.defaultEncoding(); would suffice. src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteExecutionControl.java line 80: > 78: Charset.defaultCharset()); > 79: } > 80: I'd prefer not to introduce this static method, but just embed it into each location. The other comment in `AbstractTerminal.java` applies here too. ------------- PR: https://git.openjdk.java.net/jdk/pull/6505 From itakiguchi at openjdk.java.net Tue Nov 23 16:36:07 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Tue, 23 Nov 2021 16:36:07 GMT Subject: RFR: 8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 16:08:58 GMT, Ichiroh Takiguchi wrote: > JEP-400 was implemented by JDK18-b13. > After JDK18-b13, garbled character was displayed by following code on Japanese Windows' command prompt. > > System.out.println("\u3042") > > Japanese "A" should be display ed, but garbled character was displayed. > Also saved jshell command list did not work as expected if Japanese character was there. > > Following issue has some information > 8274544: Langtools command's usage were garbled on Japanese Windows #5771 > https://github.com/openjdk/jdk/pull/5771 > This issue also happens on Linux ja_JP.eucjp locale. > RemoteExecutionControl.java change is required for this issue. > > Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal. > AbstractTerminal.java change is required for this issue. Thanks @naotoj . I appreciate your suggestion. I misread PrintStream.charset() spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/6505 From jlahoda at openjdk.java.net Tue Nov 23 16:49:18 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 23 Nov 2021 16:49:18 GMT Subject: Integrated: 8268725: jshell does not support the --enable-native-access option In-Reply-To: References: Message-ID: <-oxqylx6KIYvZ61ElZpXgXu8FU8ETHn1tMp0gsakC34=.ff5813a0-20f7-4b77-8439-e9b323414950@github.com> On Fri, 16 Jul 2021 12:26:01 GMT, Jan Lahoda wrote: > Adding `--enable-native-access` option to JShell. Set as a parameter to the remote agent (`--enable-native-access=ALL-UNNAMED`), but not the compiler, as the compiler does not have this option. This pull request has now been integrated. Changeset: 8a44e093 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/8a44e093dc3e192990fde8ab37ab08c737f06b39 Stats: 71 lines in 3 files changed: 71 ins; 0 del; 0 mod 8268725: jshell does not support the --enable-native-access option Reviewed-by: sundar ------------- PR: https://git.openjdk.java.net/jdk/pull/4810 From itakiguchi at openjdk.java.net Wed Nov 24 03:05:32 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Wed, 24 Nov 2021 03:05:32 GMT Subject: RFR: 8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows [v2] In-Reply-To: References: Message-ID: > JEP-400 was implemented by JDK18-b13. > After JDK18-b13, garbled character was displayed by following code on Japanese Windows' command prompt. > > System.out.println("\u3042") > > Japanese "A" should be display ed, but garbled character was displayed. > Also saved jshell command list did not work as expected if Japanese character was there. > > Following issue has some information > 8274544: Langtools command's usage were garbled on Japanese Windows #5771 > https://github.com/openjdk/jdk/pull/5771 > This issue also happens on Linux ja_JP.eucjp locale. > RemoteExecutionControl.java change is required for this issue. > > Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal. > AbstractTerminal.java change is required for this issue. Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: 8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6505/files - new: https://git.openjdk.java.net/jdk/pull/6505/files/63e6e7bd..8ca6252e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6505&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6505&range=00-01 Stats: 13 lines in 2 files changed: 0 ins; 10 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6505/head:pull/6505 PR: https://git.openjdk.java.net/jdk/pull/6505 From naoto at openjdk.java.net Wed Nov 24 18:46:15 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 24 Nov 2021 18:46:15 GMT Subject: RFR: 8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows [v2] In-Reply-To: References:

Message-ID: On Wed, 24 Nov 2021 03:05:32 GMT, Ichiroh Takiguchi wrote: >> JEP-400 was implemented by JDK18-b13. >> After JDK18-b13, garbled character was displayed by following code on Japanese Windows' command prompt. >> >> System.out.println("\u3042") >> >> Japanese "A" should be display ed, but garbled character was displayed. >> Also saved jshell command list did not work as expected if Japanese character was there. >> >> Following issue has some information >> 8274544: Langtools command's usage were garbled on Japanese Windows #5771 >> https://github.com/openjdk/jdk/pull/5771 >> This issue also happens on Linux ja_JP.eucjp locale. >> RemoteExecutionControl.java change is required for this issue. >> >> Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal. >> AbstractTerminal.java change is required for this issue. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > 8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows Looks good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6505 From duke at openjdk.java.net Wed Nov 24 23:13:26 2021 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 24 Nov 2021 23:13:26 GMT Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream Message-ID: JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream ------------- Commit messages: - Fixed @code and @link in some javadoc for JDK-8276674 Changes: https://git.openjdk.java.net/jdk/pull/6443/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6443&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276674 Stats: 14 lines in 9 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6443.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6443/head:pull/6443 PR: https://git.openjdk.java.net/jdk/pull/6443 From jjg at openjdk.java.net Wed Nov 24 23:13:26 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 24 Nov 2021 23:13:26 GMT Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream In-Reply-To: References: Message-ID: <7aknHgeAhXZtiJENc3MIvUBIl6vtlYSixOXcdRVfpuk=.590d68a2-df34-44ba-a111-7673e47c7351@github.com> On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing wrote: > JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream Remarkable to have not been noticed for so long! ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6443 From rriggs at openjdk.java.net Wed Nov 24 23:13:27 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 24 Nov 2021 23:13:27 GMT Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing wrote: > JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6443 From prappo at openjdk.java.net Thu Nov 25 00:24:04 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 25 Nov 2021 00:24:04 GMT Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream In-Reply-To: <7aknHgeAhXZtiJENc3MIvUBIl6vtlYSixOXcdRVfpuk=.590d68a2-df34-44ba-a111-7673e47c7351@github.com> References: <7aknHgeAhXZtiJENc3MIvUBIl6vtlYSixOXcdRVfpuk=.590d68a2-df34-44ba-a111-7673e47c7351@github.com> Message-ID: On Thu, 18 Nov 2021 19:18:24 GMT, Jonathan Gibbons wrote: > Remarkable to have not been noticed for so long! Remarkable, but not too surprising: the PR consists of source files and tests that are not part of the API Documentation. ------------- PR: https://git.openjdk.java.net/jdk/pull/6443 From prappo at openjdk.java.net Thu Nov 25 00:36:09 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 25 Nov 2021 00:36:09 GMT Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing wrote: > JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream Looks good. src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java line 63: > 61: * Helper class to generate stable positions for AST nodes occurring in diagnostic arguments. > 62: * If the AST node appears in the same line number as the main diagnostic, the line is information is omitted. > 63: * Otherwise both line and column information is included, using the format {@code line:col}". Not a showstopper by any means. But while you are at it, maybe you could also fix this? Suggestion: * If the AST node appears in the same line number as the main diagnostic, the line information is omitted. * Otherwise both line and column information is included, using the format {@code line:col}. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6443 From jlahoda at openjdk.java.net Fri Nov 26 14:51:32 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 26 Nov 2021 14:51:32 GMT Subject: RFR: 8277328: jdk/jshell/CommandCompletionTest.java failures on Windows Message-ID: The `CommandCompletionTest.java#testUserHome` test picks an existing file or directory in the user's home directory, and uses it to validate the behavior of completion after '~/'. The test fails if the test picks a directory with space. This is not solely a problem in the test - JShell does not handle paths with spaces. The proposed solution is to allow spaces in paths to be escaped with '', and adjust tests accordingly. ------------- Commit messages: - 8277328: jdk/jshell/CommandCompletionTest.java failures on Windows Changes: https://git.openjdk.java.net/jdk/pull/6578/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6578&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277328 Stats: 25 lines in 2 files changed: 17 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/6578.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6578/head:pull/6578 PR: https://git.openjdk.java.net/jdk/pull/6578 From itakiguchi at openjdk.java.net Mon Nov 29 00:15:06 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 29 Nov 2021 00:15:06 GMT Subject: Integrated: 8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 16:08:58 GMT, Ichiroh Takiguchi wrote: > JEP-400 was implemented by JDK18-b13. > After JDK18-b13, garbled character was displayed by following code on Japanese Windows' command prompt. > > System.out.println("\u3042") > > Japanese "A" should be display ed, but garbled character was displayed. > Also saved jshell command list did not work as expected if Japanese character was there. > > Following issue has some information > 8274544: Langtools command's usage were garbled on Japanese Windows #5771 > https://github.com/openjdk/jdk/pull/5771 > This issue also happens on Linux ja_JP.eucjp locale. > RemoteExecutionControl.java change is required for this issue. > > Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal. > AbstractTerminal.java change is required for this issue. This pull request has now been integrated. Changeset: 8f9eb620 Author: Ichiroh Takiguchi URL: https://git.openjdk.java.net/jdk/commit/8f9eb620acbc447cf9124b1fe5574a9f02115f45 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/6505 From prappo at openjdk.java.net Tue Nov 30 18:50:07 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 30 Nov 2021 18:50:07 GMT Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream In-Reply-To: References:

Message-ID: On Thu, 25 Nov 2021 00:31:46 GMT, Pavel Rappo wrote: >> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream > > src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java line 63: > >> 61: * Helper class to generate stable positions for AST nodes occurring in diagnostic arguments. >> 62: * If the AST node appears in the same line number as the main diagnostic, the line is information is omitted. >> 63: * Otherwise both line and column information is included, using the format {@code line:col}". > > Not a showstopper by any means. But while you are at it, maybe you could also fix this? > > Suggestion: > > * If the AST node appears in the same line number as the main diagnostic, the line information is omitted. > * Otherwise both line and column information is included, using the format {@code line:col}. This part was recently integrated in https://github.com/openjdk/jdk/pull/6602. I assume there will be a trivial merge conflict to resolve. ------------- PR: https://git.openjdk.java.net/jdk/pull/6443