From cay at horstmann.com  Fri May 14 18:27:45 2021
From: cay at horstmann.com (Cay Horstmann)
Date: Fri, 14 May 2021 20:27:45 +0200
Subject: JDK 17 jshell not working with Unicode on Linux
Message-ID: <b1007a1c-7366-d8ac-6aa6-9db5c8cd512b@horstmann.com>

Hi, I am having grief with JDK 17 jshell when trying to paste Unicode 
characters in Linux.

For example, in JDK 11 jshell, I can paste a ? (U+FE4F) into a terminal 
running JShell, and demonstrate, to the amazement of stunned onlookers, 
that it's a valid variable name:

~$ jshell
|  Welcome to JShell -- Version 11.0.4
|  For an introduction type: /help intro

jshell> var ? = 0
? ==> 0

But in JDK 17 (build 17-ea+21-1866), the pasting doesn't work.

~$ jshell
|  Welcome to JShell -- Version 17-ea
|  For an introduction type: /help intro

jshell> var ?? = 0

Here, I pasted ? into the terminal, just like I did with JShell 11, and 
instead of ? I got ??.

Cheers,

Cay


-- 

Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com

From duke at openjdk.java.net  Wed May 19 14:43:41 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 19 May 2021 14:43:41 GMT
Subject: Withdrawn: 8253354: A jshell command to open desktop browser with
 specific javadoc query
In-Reply-To: <Vh2pIs1ImTXhlJ32mUY7uXzYTUgZUNVWcrU0kZV2Swc=.4d933a71-4166-4ada-b669-979120841394@github.com>
References: <Vh2pIs1ImTXhlJ32mUY7uXzYTUgZUNVWcrU0kZV2Swc=.4d933a71-4166-4ada-b669-979120841394@github.com>
Message-ID: <u1j-ykZi6OkKChpcmHwDr47rkYSS7YkFbv50jf3E3Sk=.87faedf2-47a7-4c78-87c1-2eb3b81420b3@github.com>

On Thu, 4 Mar 2021 13:13:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 8253354: A jshell command to open desktop browser with specific javadoc query

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2828

From duke at openjdk.java.net  Wed May 19 15:50:44 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 19 May 2021 15:50:44 GMT
Subject: Withdrawn: 8241356: Use a more reliable way to encode Symbol flags
In-Reply-To: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
Message-ID: <0cdjiuSuy37cJp7SH1ogwlz5bRqvxI9YRKMsimK4kNY=.54c34a52-fb82-4266-8057-feba255d38a3@github.com>

On Fri, 29 Jan 2021 17:31:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> [This is a GitHub copy of: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014389.html ]
> 
> Currently, (com.sun.tools.javac.code.)Symbol/s have a long field "flags_field", which holds various one-bit information ("Flags") about the given Symbol.
> 
> We currently have around 64 such Flags, which means we are out of bits in the long field, and adding new flags is not easy.
> 
> We could change the "flags_field" to be a Set over enums, but this would increase the memory footprint notably, and would also slow-down access to flags. Currently, flags operations in javac are very fast and very common, so this is probably too much burden. There are also flags to which we need to access as bit masks, e.g. due to writing to classfile.
> 
> My proposal here is to use an intermediate solution, until we find a better solution, or until a better solution is possible (like due to Valhalla). The idea is as follows:
> -the current long-based Flags are split into 4 groups:
> --"flat" Flags, long based, work exactly as before.
> --enum-based TypeSymbolFlags, MethodSymbolFlags and VarSymbolFlags, which are only applicable to TypeSymbols, MethodSymbols and VarSymbols, respectively, and are checked using methods like Symbol.isFlagSet and set/clear using methods Symbol.setFlag and Symbol.clearFlag. So these flags are mostly encapsulated, even though physically they are currently stored in the flags_field as well.
> 
> There are ~~37~~ 40 "flat" flags and ~~16~~ 17 TypeSymbolFlags (methods and vars have less flags), 57 in total. This gives us at least 7 new flags before we run out of long bits in flags_field again - but even if we do, there are several easy mitigation strategies we could use, like:
> -create a new int/long field on TypeSymbols for the TypeSymbolFlags (probably preferable)
> -split TypeSymbolFlags into Class/Package/MethodSymbolFlags
> 
> The positives of this solution include:
> -safe(r) access to the flags - the access to the extra/symbol-kind-specific flags is mostly encapsulated, and hence mostly safe
> -improves the abstractions at least for some flags
> -reasonably complex patch (attempts to encapsulate all the flags were troublesome in previous experiments)
> -the performances appears to be acceptable.
> 
> The negative that I see is that the code includes several incompatible types of flags now. These cannot be easily confused by accident (as the type system will complain), but still we need to be aware of them when writing code.
> 
> Some more alternatives:
> -add a new field to Symbol, like long extraFlags, and continue with bit masks as we did so far using this new field. The drawback is that it is more error prone (it would be difficult to ensure only the new/extra flags would be stored and read from extraFlags).
> -have a new field, and "flat" and non-"flat" enum-based encapsulated Flags, but don't separate Type/Method/Var flags. Probably something to consider, even though I am a bit reluctant to add new fields without trying to avoid it .
> 
> Any feedback is welcome!

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2316

From jan.lahoda at oracle.com  Thu May 20 10:44:36 2021
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 20 May 2021 12:44:36 +0200
Subject: JDK 17 jshell not working with Unicode on Linux
In-Reply-To: <b1007a1c-7366-d8ac-6aa6-9db5c8cd512b@horstmann.com>
References: <b1007a1c-7366-d8ac-6aa6-9db5c8cd512b@horstmann.com>
Message-ID: <75bc1943-8751-f568-7fb7-8f9f7429bad5@oracle.com>

Hi Cay,

Thanks for the report! I've filled:

https://bugs.openjdk.java.net/browse/JDK-8267459


Jan


On 14. 05. 21 20:27, Cay Horstmann wrote:
> Hi, I am having grief with JDK 17 jshell when trying to paste Unicode 
> characters in Linux.
>
> For example, in JDK 11 jshell, I can paste a ? (U+FE4F) into a 
> terminal running JShell, and demonstrate, to the amazement of stunned 
> onlookers, that it's a valid variable name:
>
> ~$ jshell
> |? Welcome to JShell -- Version 11.0.4
> |? For an introduction type: /help intro
>
> jshell> var ? = 0
> ? ==> 0
>
> But in JDK 17 (build 17-ea+21-1866), the pasting doesn't work.
>
> ~$ jshell
> |? Welcome to JShell -- Version 17-ea
> |? For an introduction type: /help intro
>
> jshell> var ?? = 0
>
> Here, I pasted ? into the terminal, just like I did with JShell 11, 
> and instead of ? I got ??.
>
> Cheers,
>
> Cay
>
>

From jlahoda at openjdk.java.net  Thu May 20 13:22:44 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 20 May 2021 13:22:44 GMT
Subject: RFR: 8267459: Pasting Unicode characters into JShell does not work.
Message-ID: <vNl4e1jbEgfALsuDd7BGqZC4XX60BzrqiAtCBed2aqg=.12a0e800-44e5-4642-b2e2-5d500e12f85d@github.com>

The NonBlockingInputStreamReader.readBuffered method will read some bytes from the InputStream, and then try to convert them to characters. But, the input array may end in the middle of a sequence - e.g. it may end with a part of UTF-8 sequence, which will be only finished when the input is read next time.

The proposed fix is to store the trailing unused bytes into the `bytes` field, which is already used for a similar purpose by the other read method in this class, and use them on the next iteration.

-------------

Commit messages:
 - 8267459: Pasting Unicode characters into JShell does not work.

Changes: https://git.openjdk.java.net/jdk/pull/4128/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4128&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267459
  Stats: 34 lines in 2 files changed: 31 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4128.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4128/head:pull/4128

PR: https://git.openjdk.java.net/jdk/pull/4128

From vromero at openjdk.java.net  Fri May 21 14:27:40 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 21 May 2021 14:27:40 GMT
Subject: RFR: 8247403: JShell: No custom input (e.g. from GUI) possible
 with JavaShellToolBuilder [v2]
In-Reply-To: <HY6Hur1ebNUwlFzHUo15fW-454LLltwkp1mZS4XrHpI=.39b03cb2-67e6-479d-9826-371f713d58c4@github.com>
References: <LG3Ko-Xn6aySWkkgG2YXLUtVLhpiFcJ7prYtQm-Fzns=.b2c17f87-faef-46e6-ac0d-6f08187dde69@github.com>
 <HY6Hur1ebNUwlFzHUo15fW-454LLltwkp1mZS4XrHpI=.39b03cb2-67e6-479d-9826-371f713d58c4@github.com>
Message-ID: <7x1wNlW00Qe0mwLsi026fKN_fRAlefYFA7dseiyYu9k=.c59cf3b1-0180-4867-8c0b-b087bf39dcab@github.com>

On Mon, 26 Apr 2021 11:28:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Basically, JShell's ConsoleIOContext always uses the JLine's default terminal, which uses System.in, or equivalent, for input. But, if the JShell tool has been created using JavaShellToolBuilder, a different input might have been provided. The proposed solution is to use a different JLine's terminal in this case, based on the provided input.
>
> Jan Lahoda 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 eight additional commits since the last revision:
> 
>  - Restoring timeout.
>  - Improving test.
>  - Cleanup.
>  - Adding an experimental API to select the JavaShell output format and the output terminal size.
>  - Merge branch 'master' into JDK-8247404
>  - When using JavaShellToolBuilder programmatically, make the characters sent to the output stream more consistent with the legacy behavior.
>  - Merge branch 'master' into JDK-8247404
>  - 8247403: JShell: No custom input (e.g. from GUI) possible with JavaShellToolBuilder

in the CSR and in the new method spec, please consider adding in the @implSpec section a mention to that the provided default implementation does something in the lines of:

The default implementation of this method returns {@code this}.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2509

From vromero at openjdk.java.net  Fri May 21 15:00:16 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 21 May 2021 15:00:16 GMT
Subject: RFR: 8247403: JShell: No custom input (e.g. from GUI) possible
 with JavaShellToolBuilder [v2]
In-Reply-To: <HY6Hur1ebNUwlFzHUo15fW-454LLltwkp1mZS4XrHpI=.39b03cb2-67e6-479d-9826-371f713d58c4@github.com>
References: <LG3Ko-Xn6aySWkkgG2YXLUtVLhpiFcJ7prYtQm-Fzns=.b2c17f87-faef-46e6-ac0d-6f08187dde69@github.com>
 <HY6Hur1ebNUwlFzHUo15fW-454LLltwkp1mZS4XrHpI=.39b03cb2-67e6-479d-9826-371f713d58c4@github.com>
Message-ID: <TNfYckhANlH5jf8HwwoojCo7t4SNTqkL9612QnLiYUU=.a2ac90e0-9524-441c-b7e4-e740f1371818@github.com>

On Mon, 26 Apr 2021 11:28:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Basically, JShell's ConsoleIOContext always uses the JLine's default terminal, which uses System.in, or equivalent, for input. But, if the JShell tool has been created using JavaShellToolBuilder, a different input might have been provided. The proposed solution is to use a different JLine's terminal in this case, based on the provided input.
>
> Jan Lahoda 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 eight additional commits since the last revision:
> 
>  - Restoring timeout.
>  - Improving test.
>  - Cleanup.
>  - Adding an experimental API to select the JavaShell output format and the output terminal size.
>  - Merge branch 'master' into JDK-8247404
>  - When using JavaShellToolBuilder programmatically, make the characters sent to the output stream more consistent with the legacy behavior.
>  - Merge branch 'master' into JDK-8247404
>  - 8247403: JShell: No custom input (e.g. from GUI) possible with JavaShellToolBuilder

Marked as reviewed by vromero (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2509

From jlahoda at openjdk.java.net  Mon May 24 08:20:44 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 24 May 2021 08:20:44 GMT
Subject: RFR: 8247403: JShell: No custom input (e.g. from GUI) possible
 with JavaShellToolBuilder [v3]
In-Reply-To: <LG3Ko-Xn6aySWkkgG2YXLUtVLhpiFcJ7prYtQm-Fzns=.b2c17f87-faef-46e6-ac0d-6f08187dde69@github.com>
References: <LG3Ko-Xn6aySWkkgG2YXLUtVLhpiFcJ7prYtQm-Fzns=.b2c17f87-faef-46e6-ac0d-6f08187dde69@github.com>
Message-ID: <IlZSSWqIq_TKrhMFJWcDbgeRm8CEhFacsMhoOAjXpQk=.7ed1ea83-5bc7-4ea2-83b1-4333d1744bbd@github.com>

> Basically, JShell's ConsoleIOContext always uses the JLine's default terminal, which uses System.in, or equivalent, for input. But, if the JShell tool has been created using JavaShellToolBuilder, a different input might have been provided. The proposed solution is to use a different JLine's terminal in this case, based on the provided input.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adding note about the default behavior, as suggested.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2509/files
  - new: https://git.openjdk.java.net/jdk/pull/2509/files/d7eacd6a..6ee9855c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2509&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2509&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2509.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2509/head:pull/2509

PR: https://git.openjdk.java.net/jdk/pull/2509

From jlahoda at openjdk.java.net  Mon May 24 11:51:31 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 24 May 2021 11:51:31 GMT
Subject: RFR: 8267459: Pasting Unicode characters into JShell does not
 work. [v2]
In-Reply-To: <vNl4e1jbEgfALsuDd7BGqZC4XX60BzrqiAtCBed2aqg=.12a0e800-44e5-4642-b2e2-5d500e12f85d@github.com>
References: <vNl4e1jbEgfALsuDd7BGqZC4XX60BzrqiAtCBed2aqg=.12a0e800-44e5-4642-b2e2-5d500e12f85d@github.com>
Message-ID: <resK3wDUVGOQOuPJ5y-pu0LIAfEO2oxa7q-PVxds4yo=.795a7dc8-1ace-4349-a17c-a41added231b@github.com>

> The NonBlockingInputStreamReader.readBuffered method will read some bytes from the InputStream, and then try to convert them to characters. But, the input array may end in the middle of a sequence - e.g. it may end with a part of UTF-8 sequence, which will be only finished when the input is read next time.
> 
> The proposed fix is to store the trailing unused bytes into the `bytes` field, which is already used for a similar purpose by the other read method in this class, and use them on the next iteration.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Ensuring the test input is UTF-8, to allow tests pass regardless of configuration.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4128/files
  - new: https://git.openjdk.java.net/jdk/pull/4128/files/89a120fb..7ec1b9af

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4128&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4128&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4128.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4128/head:pull/4128

PR: https://git.openjdk.java.net/jdk/pull/4128

From jlahoda at openjdk.java.net  Tue May 25 15:38:20 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 25 May 2021 15:38:20 GMT
Subject: RFR: 8267221: jshell feedback is incorrect when creating method with
 array varargs parameter
Message-ID: <lKT_Ps1qHKhdUoCMBgFVlCpa6W3-C6GIcUmgDcS4pOs=.d76bce23-d716-4b9a-9d33-b5df6ca6f875@github.com>

When writing something like `void t(int[]... p) {}` into JShell, one gets:

jshell> void t(int[]... p) {}
|  created method t(int[])


Note the wrong parameter type `int[]` instead of `int[]...` or at least `int[][]`. The reason is that the span of the type is incorrect when the type is varargs. The proposed patch is an attempt to fix the span.

-------------

Commit messages:
 - 8267221: jshell feedback is incorrect when creating method with array varargs parameter

Changes: https://git.openjdk.java.net/jdk/pull/4187/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4187&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267221
  Stats: 34 lines in 3 files changed: 32 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4187.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4187/head:pull/4187

PR: https://git.openjdk.java.net/jdk/pull/4187

From vromero at openjdk.java.net  Tue May 25 16:26:56 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 25 May 2021 16:26:56 GMT
Subject: RFR: 8267221: jshell feedback is incorrect when creating method
 with array varargs parameter
In-Reply-To: <lKT_Ps1qHKhdUoCMBgFVlCpa6W3-C6GIcUmgDcS4pOs=.d76bce23-d716-4b9a-9d33-b5df6ca6f875@github.com>
References: <lKT_Ps1qHKhdUoCMBgFVlCpa6W3-C6GIcUmgDcS4pOs=.d76bce23-d716-4b9a-9d33-b5df6ca6f875@github.com>
Message-ID: <D6TDknvDb4nXOOg99lea8qfjLHjCP_3PND6qN2bEri4=.32ad4ebe-75e5-4d13-8470-b1a5f617e17c@github.com>

On Tue, 25 May 2021 15:30:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When writing something like `void t(int[]... p) {}` into JShell, one gets:
> 
> jshell> void t(int[]... p) {}
> |  created method t(int[])
> 
> 
> Note the wrong parameter type `int[]` instead of `int[]...` or at least `int[][]`. The reason is that the span of the type is incorrect when the type is varargs. The proposed patch is an attempt to fix the span.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4187

From jlahoda at openjdk.java.net  Wed May 26 11:15:17 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 26 May 2021 11:15:17 GMT
Subject: Integrated: 8267221: jshell feedback is incorrect when creating
 method with array varargs parameter
In-Reply-To: <lKT_Ps1qHKhdUoCMBgFVlCpa6W3-C6GIcUmgDcS4pOs=.d76bce23-d716-4b9a-9d33-b5df6ca6f875@github.com>
References: <lKT_Ps1qHKhdUoCMBgFVlCpa6W3-C6GIcUmgDcS4pOs=.d76bce23-d716-4b9a-9d33-b5df6ca6f875@github.com>
Message-ID: <TJbff7hiCiZgUU95hvGVheMumqEJahwLZh1UEIwt5i4=.10775896-5a07-4cf4-ab98-b4649751b899@github.com>

On Tue, 25 May 2021 15:30:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When writing something like `void t(int[]... p) {}` into JShell, one gets:
> 
> jshell> void t(int[]... p) {}
> |  created method t(int[])
> 
> 
> Note the wrong parameter type `int[]` instead of `int[]...` or at least `int[][]`. The reason is that the span of the type is incorrect when the type is varargs. The proposed patch is an attempt to fix the span.

This pull request has now been integrated.

Changeset: f6322549
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f632254943e335d0b4a76d03530309cd194b0813
Stats:     34 lines in 3 files changed: 32 ins; 0 del; 2 mod

8267221: jshell feedback is incorrect when creating method with array varargs parameter

Reviewed-by: vromero

-------------

PR: https://git.openjdk.java.net/jdk/pull/4187

From jlahoda at openjdk.java.net  Mon May 31 09:29:32 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 31 May 2021 09:29:32 GMT
Subject: Integrated: 8247403: JShell: No custom input (e.g. from GUI) possible
 with JavaShellToolBuilder
In-Reply-To: <LG3Ko-Xn6aySWkkgG2YXLUtVLhpiFcJ7prYtQm-Fzns=.b2c17f87-faef-46e6-ac0d-6f08187dde69@github.com>
References: <LG3Ko-Xn6aySWkkgG2YXLUtVLhpiFcJ7prYtQm-Fzns=.b2c17f87-faef-46e6-ac0d-6f08187dde69@github.com>
Message-ID: <zy6RJ_isi1XCZqPexFsbiwRDwr6zplxAur4G1m0cQ_Y=.c0be7a08-af18-4500-9177-e427249911ed@github.com>

On Wed, 10 Feb 2021 13:55:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Basically, JShell's ConsoleIOContext always uses the JLine's default terminal, which uses System.in, or equivalent, for input. But, if the JShell tool has been created using JavaShellToolBuilder, a different input might have been provided. The proposed solution is to use a different JLine's terminal in this case, based on the provided input.

This pull request has now been integrated.

Changeset: 2c8e94f6
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c8e94f6804fee269a882a3e92b7ce844451eb11
Stats:     255 lines in 14 files changed: 226 ins; 8 del; 21 mod

8247403: JShell: No custom input (e.g. from GUI) possible with JavaShellToolBuilder

Reviewed-by: vromero

-------------

PR: https://git.openjdk.java.net/jdk/pull/2509