From robert.field at oracle.com Fri Feb 1 00:32:59 2019 From: robert.field at oracle.com (Robert Field) Date: Thu, 31 Jan 2019 16:32:59 -0800 Subject: jshell + Bach.java compilation issues In-Reply-To: References: Message-ID: Hi Christian, JShell recovers from references to undeclared variables/classes -- as is needed for forward references, such as yours. It detects these based on (hidden to the user, "cannot find symbol") underlying javac error messages.? So, for example (extracted and simplified example): jshell> class C { void foo() { var action = Property.ACTION; }} |? created class C, however, it cannot be instantiated or its methods invoked until variable Property is declared /open and command-line do not show these messages. Your two layer deep reference to an undeclared identifier generated a different error message from javac, and displayed this error: jshell> class C { void foo() { var action = Property.ACTION.get(); }} |? Error: |? package Property does not exist |? class C { void foo() { var action = Property.ACTION.get(); }} |????????????????????????????????????? ^-------------^ When an error, rather than a recoverable undeclared variable occurs, all the error messages are shown. I've created a bug for this: ??? https://bugs.openjdk.java.net/browse/JDK-8218179 If it is any consolation, it took me a while to track down the cause. -Robert On 1/31/19 6:41 AM, Christian Stein wrote: > Hi kulla-dev, > > I'm still working on Bach.java (Java Shell Builder tool) and today > its compilation stopped working when `jshell Bach.java` is invoked. > Same goes for `/open Bach.java` within a jshell session. > > Calling `java Bach.java` (JEP 330) runs successfully for all revisions. > > I described the issue in more detail at [1] -- here is the gist: > - revision from yesterday [2] works > - revision from today [3] chokes. > > Here is the diff [4] of the two revisions. > > I tried hard to find the underlying issue... > - renamed types within Bach.java > - reduced total file size by > - removing unused enum constants > - removing all Javadoc > ...to no avail. > > What barrier am I hitting here? > > Cheers, > Christian > > [1]https://github.com/sormuras/bach/issues/43 > [2] > https://raw.githubusercontent.com/sormuras/bach/5e7165ef06c26423d8906038f2e061eb6cd8f374/src/bach/Bach.java > [3] > https://raw.githubusercontent.com/sormuras/bach/13cf5eb5a9045ac0158d6da585105d359591ba7f/src/bach/Bach.java > [4] > https://github.com/sormuras/bach/commit/13cf5eb5a9045ac0158d6da585105d359591ba7f From yamadamn at gmail.com Mon Feb 4 12:05:01 2019 From: yamadamn at gmail.com (Takahiro YAMADA) Date: Mon, 4 Feb 2019 21:05:01 +0900 Subject: JShell input behavior unstable after 12-ea+24 on Windows Message-ID: Hi, I have tried JShell on Windows 10. It works expectedly on JDK 11 and <=12-ea+23. But >=12-ea+24, some inputs are lacked especially when paste. e.g. If "import java.time.format.*" pastes to JShell, sometimes It could be below. -> mport java.time.format.* -> iport java.time.format.* -> iort java.time.format.* And, if I input Japanese characters like kanji, they are garbled. e.g. "var kanjiFormat = DateTimeFormatter.ofPattern("GGGGy?M?d?", Locale.JAPAN)" -> var kanjiFormat = DateTimeFormatter.ofPattern("GGGGy?NM??d?", Locale.JAPAN) e.g. "System.out.println("??")" -> System.out.println("????") ???? I think this unstable behavior comes from the JLine library. If so, could you replace it with the prior version? or could you fix this issue? -- Takahiro YAMADA From robert.field at oracle.com Mon Feb 4 16:05:48 2019 From: robert.field at oracle.com (Robert Field) Date: Mon, 4 Feb 2019 08:05:48 -0800 Subject: JShell input behavior unstable after 12-ea+24 on Windows In-Reply-To: References: Message-ID: Thank you for the report.? I have filed: ??? https://bugs.openjdk.java.net/browse/JDK-8218287 -Robert On 2/4/19 4:05 AM, Takahiro YAMADA wrote: > Hi, > > I have tried JShell on Windows 10. > It works expectedly on JDK 11 and <=12-ea+23. > But >=12-ea+24, some inputs are lacked especially when paste. > e.g. If "import java.time.format.*" pastes to JShell, sometimes It could be > below. > -> mport java.time.format.* > -> iport java.time.format.* > -> iort java.time.format.* > > And, if I input Japanese characters like kanji, they are garbled. > e.g. "var kanjiFormat = DateTimeFormatter.ofPattern("GGGGy?M?d?", > Locale.JAPAN)" > -> var kanjiFormat = DateTimeFormatter.ofPattern("GGGGy?NM??d?", > Locale.JAPAN) > > e.g. "System.out.println("??")" > -> System.out.println("????") > ???? > > I think this unstable behavior comes from the JLine library. > If so, could you replace it with the prior version? or could you fix this > issue? > > -- > Takahiro YAMADA From jan.lahoda at oracle.com Wed Feb 13 14:45:03 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 13 Feb 2019 15:45:03 +0100 Subject: RFR: JDK-8218287: jshell tool: input behavior unstable after 12-ea+24 on Windows Message-ID: <5C642D6F.8000000@oracle.com> Hi, When JShell was upgraded to use JLine 3.9.0, the input from which the Terminal is reading had to be wrapped, so that JShell can detect Ctrl-C while the user's code is running. The mechanism for this is that the StopDetectingInputStream is actively reading the input to find out if Ctrl-C was pressed. (And other characters are stored aside and returned from the StopDetectingInputStream when JLine is reading from it.) Unfortunately, it turns out this wrapping is not done as expected on Windows (when using the Windows terminal). The issue is that the source of input in the AbstractWindowsTerminal is a Reader, which is directly used to read the input by JLine, and is also converted to an InputStream, which is typically not used. And this InputStream is wrapped by the StopDetectingInputStream. So when the StopDetectingInputStream is trying to detect Ctrl-C, it may "steal" an input character, which is then missing in the Reader used by JLine, and hence is lost (the StopDetectingInputStream has it stored aside, but it is never read from it). The proposed patch is to not use the Reader that is the source of input directly, but rather create a new one based on the wrapped InputStream. Webrev: http://cr.openjdk.java.net/~jlahoda/8218287/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8218287 How does this look? Thanks, Jan From robert.field at oracle.com Fri Feb 15 20:05:08 2019 From: robert.field at oracle.com (Robert Field) Date: Fri, 15 Feb 2019 12:05:08 -0800 Subject: RFR: JDK-8218287: jshell tool: input behavior unstable after 12-ea+24 on Windows In-Reply-To: <5C642D6F.8000000@oracle.com> References: <5C642D6F.8000000@oracle.com> Message-ID: <0e1dac2f-387c-28d7-e595-a89c58aa853f@oracle.com> Thumbs up! This is important to fix.? Getting it in the JDK for full shake-out would be good. Per our discussion, let's try to find someone who can test multibyte encodings on Windows, with this in. -Robert On 2/13/19 6:45 AM, Jan Lahoda wrote: > Hi, > > When JShell was upgraded to use JLine 3.9.0, the input from which the > Terminal is reading had to be wrapped, so that JShell can detect > Ctrl-C while the user's code is running. The mechanism for this is > that the StopDetectingInputStream is actively reading the input to > find out if Ctrl-C was pressed. (And other characters are stored aside > and returned from the StopDetectingInputStream when JLine is reading > from it.) > > Unfortunately, it turns out this wrapping is not done as expected on > Windows (when using the Windows terminal). The issue is that the > source of input in the AbstractWindowsTerminal is a Reader, which is > directly used to read the input by JLine, and is also converted to an > InputStream, which is typically not used. And this InputStream is > wrapped by the StopDetectingInputStream. So when the > StopDetectingInputStream is trying to detect Ctrl-C, it may "steal" an > input character, which is then missing in the Reader used by JLine, > and hence is lost (the StopDetectingInputStream has it stored aside, > but it is never read from it). > > The proposed patch is to not use the Reader that is the source of > input directly, but rather create a new one based on the wrapped > InputStream. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8218287/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8218287 > > How does this look? > > Thanks, > ??? Jan From robert.field at oracle.com Fri Feb 15 20:09:23 2019 From: robert.field at oracle.com (Robert Field) Date: Fri, 15 Feb 2019 12:09:23 -0800 Subject: Kulla-fold: Need someone to test a fix with multibyte encodings on Window Message-ID: <93ca85b5-2f60-0be8-4871-2b84d674c32d@oracle.com> Jan has a fix for an important issue with the new JLine 3 base of the jshell tool in JDK 12, it is a Windows only issue. We want to be sure that after the fix it will still work well with Japanese, Chinese, .... Can you help us? Thanks From talden at gmail.com Fri Feb 15 21:42:38 2019 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Sat, 16 Feb 2019 10:42:38 +1300 Subject: RFR: JDK-8218287: jshell tool: input behavior unstable after 12-ea+24 on Windows In-Reply-To: <0e1dac2f-387c-28d7-e595-a89c58aa853f@oracle.com> References: <5C642D6F.8000000@oracle.com> <0e1dac2f-387c-28d7-e595-a89c58aa853f@oracle.com> Message-ID: I see that the release candidate didn't wait for this. JShell is completely unusable without this fix for these users. -- Aaron Scott-Boddendijk On Sat, Feb 16, 2019 at 9:05 AM Robert Field wrote: > Thumbs up! > > This is important to fix. Getting it in the JDK for full shake-out > would be good. > > Per our discussion, let's try to find someone who can test multibyte > encodings on Windows, with this in. > > -Robert > > > On 2/13/19 6:45 AM, Jan Lahoda wrote: > > Hi, > > > > When JShell was upgraded to use JLine 3.9.0, the input from which the > > Terminal is reading had to be wrapped, so that JShell can detect > > Ctrl-C while the user's code is running. The mechanism for this is > > that the StopDetectingInputStream is actively reading the input to > > find out if Ctrl-C was pressed. (And other characters are stored aside > > and returned from the StopDetectingInputStream when JLine is reading > > from it.) > > > > Unfortunately, it turns out this wrapping is not done as expected on > > Windows (when using the Windows terminal). The issue is that the > > source of input in the AbstractWindowsTerminal is a Reader, which is > > directly used to read the input by JLine, and is also converted to an > > InputStream, which is typically not used. And this InputStream is > > wrapped by the StopDetectingInputStream. So when the > > StopDetectingInputStream is trying to detect Ctrl-C, it may "steal" an > > input character, which is then missing in the Reader used by JLine, > > and hence is lost (the StopDetectingInputStream has it stored aside, > > but it is never read from it). > > > > The proposed patch is to not use the Reader that is the source of > > input directly, but rather create a new one based on the wrapped > > InputStream. > > > > Webrev: http://cr.openjdk.java.net/~jlahoda/8218287/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8218287 > > > > How does this look? > > > > Thanks, > > Jan > From yamadamn at gmail.com Sat Feb 16 08:39:23 2019 From: yamadamn at gmail.com (Takahiro YAMADA) Date: Sat, 16 Feb 2019 17:39:23 +0900 Subject: Kulla-fold: Need someone to test a fix with multibyte encodings on Window In-Reply-To: <93ca85b5-2f60-0be8-4871-2b84d674c32d@oracle.com> References: <93ca85b5-2f60-0be8-4871-2b84d674c32d@oracle.com> Message-ID: Hi Robert, I reported the issue and you have filed JDK-8218287. So, I'd like to test the fix. What should I do? If I can download a fixed build, I will easily check the behavior. 2019?2?16?(?) 5:09 Robert Field : > Jan has a fix for an important issue with the new JLine 3 base of the > jshell tool in JDK 12, it is a Windows only issue. > > We want to be sure that after the fix it will still work well with > Japanese, Chinese, .... > > Can you help us? > > Thanks > > > From jan.lahoda at oracle.com Mon Feb 18 16:37:55 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 18 Feb 2019 17:37:55 +0100 Subject: RFR: JDK-8218287: jshell tool: input behavior unstable after 12-ea+24 on Windows In-Reply-To: <0e1dac2f-387c-28d7-e595-a89c58aa853f@oracle.com> References: <5C642D6F.8000000@oracle.com> <0e1dac2f-387c-28d7-e595-a89c58aa853f@oracle.com> Message-ID: <5C6ADF63.4000107@oracle.com> On 15.2.2019 21:05, Robert Field wrote: > Thumbs up! > > This is important to fix. Getting it in the JDK for full shake-out > would be good. > > Per our discussion, let's try to find someone who can test multibyte > encodings on Windows, with this in. Unfortunately, turns out there are at least two problems: -currently (JDK 12/13) ReadConsoleInput is used to read input, but ReadConsoleInputW used to be used before - and ReadConsoleInput at least in some cases does not read non-ASCII characters correctly -the NonBlockingReaderInputStream that is created to convert Reader to InputStream is converting bytes to ints improperly - should be unsigned conversion, but is signed. As a result, the "int read()" method sometimes returns a negative integer, which is then ignored. An updated patch that strives to fix these is here: http://cr.openjdk.java.net/~jlahoda/8218287/webrev.01/ Jan > > -Robert > > > On 2/13/19 6:45 AM, Jan Lahoda wrote: >> Hi, >> >> When JShell was upgraded to use JLine 3.9.0, the input from which the >> Terminal is reading had to be wrapped, so that JShell can detect >> Ctrl-C while the user's code is running. The mechanism for this is >> that the StopDetectingInputStream is actively reading the input to >> find out if Ctrl-C was pressed. (And other characters are stored aside >> and returned from the StopDetectingInputStream when JLine is reading >> from it.) >> >> Unfortunately, it turns out this wrapping is not done as expected on >> Windows (when using the Windows terminal). The issue is that the >> source of input in the AbstractWindowsTerminal is a Reader, which is >> directly used to read the input by JLine, and is also converted to an >> InputStream, which is typically not used. And this InputStream is >> wrapped by the StopDetectingInputStream. So when the >> StopDetectingInputStream is trying to detect Ctrl-C, it may "steal" an >> input character, which is then missing in the Reader used by JLine, >> and hence is lost (the StopDetectingInputStream has it stored aside, >> but it is never read from it). >> >> The proposed patch is to not use the Reader that is the source of >> input directly, but rather create a new one based on the wrapped >> InputStream. >> >> Webrev: http://cr.openjdk.java.net/~jlahoda/8218287/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8218287 >> >> How does this look? >> >> Thanks, >> Jan From robert.field at oracle.com Tue Feb 19 21:23:16 2019 From: robert.field at oracle.com (Robert Field) Date: Tue, 19 Feb 2019 13:23:16 -0800 Subject: RFR: JDK-8218287: jshell tool: input behavior unstable after 12-ea+24 on Windows In-Reply-To: <5C6ADF63.4000107@oracle.com> References: <5C642D6F.8000000@oracle.com> <0e1dac2f-387c-28d7-e595-a89c58aa853f@oracle.com> <5C6ADF63.4000107@oracle.com> Message-ID: Thumbs up on the update. -Robert On 2/18/19 8:37 AM, Jan Lahoda wrote: > On 15.2.2019 21:05, Robert Field wrote: >> Thumbs up! >> >> This is important to fix.? Getting it in the JDK for full shake-out >> would be good. >> >> Per our discussion, let's try to find someone who can test multibyte >> encodings on Windows, with this in. > > Unfortunately, turns out there are at least two problems: > -currently (JDK 12/13) ReadConsoleInput is used to read input, but > ReadConsoleInputW used to be used before - and ReadConsoleInput at > least in some cases does not read non-ASCII characters correctly > -the NonBlockingReaderInputStream that is created to convert Reader to > InputStream is converting bytes to ints improperly - should be > unsigned conversion, but is signed. As a result, the "int read()" > method sometimes returns a negative integer, which is then ignored. > > An updated patch that strives to fix these is here: > http://cr.openjdk.java.net/~jlahoda/8218287/webrev.01/ > > Jan > >> >> -Robert >> >> >> On 2/13/19 6:45 AM, Jan Lahoda wrote: >>> Hi, >>> >>> When JShell was upgraded to use JLine 3.9.0, the input from which the >>> Terminal is reading had to be wrapped, so that JShell can detect >>> Ctrl-C while the user's code is running. The mechanism for this is >>> that the StopDetectingInputStream is actively reading the input to >>> find out if Ctrl-C was pressed. (And other characters are stored aside >>> and returned from the StopDetectingInputStream when JLine is reading >>> from it.) >>> >>> Unfortunately, it turns out this wrapping is not done as expected on >>> Windows (when using the Windows terminal). The issue is that the >>> source of input in the AbstractWindowsTerminal is a Reader, which is >>> directly used to read the input by JLine, and is also converted to an >>> InputStream, which is typically not used. And this InputStream is >>> wrapped by the StopDetectingInputStream. So when the >>> StopDetectingInputStream is trying to detect Ctrl-C, it may "steal" an >>> input character, which is then missing in the Reader used by JLine, >>> and hence is lost (the StopDetectingInputStream has it stored aside, >>> but it is never read from it). >>> >>> The proposed patch is to not use the Reader that is the source of >>> input directly, but rather create a new one based on the wrapped >>> InputStream. >>> >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8218287/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8218287 >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan From yamadamn at gmail.com Sat Feb 23 13:34:25 2019 From: yamadamn at gmail.com (Takahiro YAMADA) Date: Sat, 23 Feb 2019 22:34:25 +0900 Subject: Kulla-fold: Need someone to test a fix with multibyte encodings on Window In-Reply-To: References: <93ca85b5-2f60-0be8-4871-2b84d674c32d@oracle.com> Message-ID: Hi Robert and kulla-dev, I have noticed 13-ea+9 can download from http://jdk.java.net/13/. JDK-8218287 fixed by Jan looks good at me. Thank you so much! -- Takahiro YAMADA 2019?2?16?(?) 17:39 Takahiro YAMADA : > Hi Robert, > > I reported the issue and you have filed JDK-8218287. > So, I'd like to test the fix. What should I do? > If I can download a fixed build, I will easily check the behavior. > > 2019?2?16?(?) 5:09 Robert Field : > >> Jan has a fix for an important issue with the new JLine 3 base of the >> jshell tool in JDK 12, it is a Windows only issue. >> >> We want to be sure that after the fix it will still work well with >> Japanese, Chinese, .... >> >> Can you help us? >> >> Thanks >> >> >>