From brian.goetz at oracle.com Mon Jan 2 21:10:50 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 2 Jan 2017 16:10:50 -0500 Subject: RFR 8172102: jshell tool: remove print method forwarding to System.out from default startup In-Reply-To: <5866C4BB.5080806@oracle.com> References: <5866A28C.6050407@oracle.com> <6b159d4c-8398-56f1-7062-9fbb6b027682@oracle.com> <5866C4BB.5080806@oracle.com> Message-ID: <49ede7be-712d-17dc-dc0b-a3673c89b25d@oracle.com> The readFile() method still uses paths, though the only call appears to provide a single file name. Could replace with readSingleFile(). At #1677, comparing the expanded startup to the *contents* of the default seems questionable, but unlikely to actually cause harm. Otherwise, +1. On 12/30/2016 3:34 PM, Robert Field wrote: > Thanks for the comments! > > Addressing the concerns.... > > Use of path-separator removed. Now multiple uses of --startup. > Make changes (sub-task) included below. > Dynamically generated includes removed. Fixed JAVASE added. > JDK 10 bug added for build-time generation: > https://bugs.openjdk.java.net/browse/JDK-8172154 > > Main bug:: > jshell tool: remove print method forwarding to System.out from > default startup > https://bugs.openjdk.java.net/browse/JDK-8172102 > > Sub-task bug: > jshell tool (make): include built-in startup scripts in image > https://bugs.openjdk.java.net/browse/JDK-8172155 > > Langtools webrev: > http://cr.openjdk.java.net/~rfield/8172102v2.webrev/ > > Top level webrev: > http://cr.openjdk.java.net/~rfield/8172155v2.webrev/make/CompileJavaModules.gmk.sdiff.html > > > -Robert > > On 12/30/16 10:17, Brian Goetz wrote: >> I think the use of path syntax here is a bit of an abuse. Typically, >> a path A:B represents a search path; first look in A, and then, if >> not found, look in B. But what you want to indicate is that we >> should process A *and* B at startup; this isn't a path. >> >> Unfortunately, there's not a universally accepted "and" character, >> where you could say "A,B" or "A+B" that people would immediately >> grok. So better to use repeated flags: >> >> jshell --startup A --startup B >> >> which is a bit verbose, but I think is more standard. >> >> I'd also prefer to see the standard startup be an actual, checked-in >> file called something like resources/DEFAULT.jsh, which is placed in >> the output directory alongside classfiles through the usual build >> mechanics, rather than living in code. I don't see that in the webrev? >> > From michael.mueller at mueller-bruehl.de Mon Jan 2 21:35:27 2017 From: michael.mueller at mueller-bruehl.de (=?UTF-8?Q?Michael_M=c3=bcller?=) Date: Mon, 2 Jan 2017 22:35:27 +0100 Subject: automatically add jars to classpath Message-ID: <21e291e0-0e72-8d95-255f-3b99bd4dfb1c@mueller-bruehl.de> Hi, If I start jshell from a folder of my choice, it would be nice to automatically add any jar (or class) files within that folder to the classpath. -- Herzliche Gr??e - Best Regards, Michael M?ller Br?hl, Germany blog.mueller-bruehl.de it-rezension.de @muellermi Read my books "Web Development with Java and JSF": https://leanpub.com/jsf "Java Lambdas and Parallel Streams": http://www.apress.com/de/book/9781484224861 "Visitors" a photographic image book: https://leanpub.com/visitors From brian.goetz at oracle.com Mon Jan 2 22:31:31 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 2 Jan 2017 17:31:31 -0500 Subject: automatically add jars to classpath In-Reply-To: <21e291e0-0e72-8d95-255f-3b99bd4dfb1c@mueller-bruehl.de> References: <21e291e0-0e72-8d95-255f-3b99bd4dfb1c@mueller-bruehl.de> Message-ID: <2ec25f4c-0b90-d2be-03ab-9b25c1bc1f7b@oracle.com> For JARs, you can get the effect of this by invoking with CLASSPATH=* jshell and no special jshell magic. On 1/2/2017 4:35 PM, Michael M?ller wrote: > Hi, > > > If I start jshell from a folder of my choice, it would be nice to > automatically add any jar (or class) files within that folder to the > classpath. > > From joe.darcy at oracle.com Wed Jan 4 01:09:02 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 3 Jan 2017 17:09:02 -0800 Subject: JDK 9 RFR of JDK-8172220: Mark UserInputTest.java as intermittently failing Message-ID: <5a79a2c4-01f4-85ec-2b18-dce1d7075582@oracle.com> Hello, The langtools test jdk/jshell/UserInputTest.java has been seen to intermittently fail and should be marked accordingly; patch below. Thanks, -Joe diff -r 4f348bd05341 test/jdk/jshell/UserInputTest.java --- a/test/jdk/jshell/UserInputTest.java Tue Jan 03 11:33:18 2017 +0000 +++ b/test/jdk/jshell/UserInputTest.java Tue Jan 03 16:49:22 2017 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -27,6 +27,7 @@ * @summary Verify that the user's code can read System.in * @build KullaTesting TestingInputStream * @run testng UserInputTest + * @key intermittent */ import java.io.IOException; From robert.field at oracle.com Thu Jan 5 04:11:20 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 04 Jan 2017 20:11:20 -0800 Subject: RFR 8165405: jshell tool: /classpath is inconsistent Message-ID: <586DC768.10208@oracle.com> Please review.... Bugs: jshell tool: /classpath is inconsistent https://bugs.openjdk.java.net/browse/JDK-8165405 JShell: crash in TaskFactory$WrapSourceHandler.diag https://bugs.openjdk.java.net/browse/JDK-8172103 Webrev: http://cr.openjdk.java.net/~rfield/8165405v1.webrev/ Thanks, Robert From jan.lahoda at oracle.com Fri Jan 6 16:31:03 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 6 Jan 2017 17:31:03 +0100 Subject: RFR 8165405: jshell tool: /classpath is inconsistent In-Reply-To: <586DC768.10208@oracle.com> References: <586DC768.10208@oracle.com> Message-ID: <586FC647.9020209@oracle.com> Seems OK to me. One nit, there is a (presumably) unneeded change here: test/jdk/jshell/ReplToolTesting.java Jan On 5.1.2017 05:11, Robert Field wrote: > Please review.... > > Bugs: > > jshell tool: /classpath is inconsistent > https://bugs.openjdk.java.net/browse/JDK-8165405 > > JShell: crash in TaskFactory$WrapSourceHandler.diag > https://bugs.openjdk.java.net/browse/JDK-8172103 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8165405v1.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Fri Jan 6 21:32:38 2017 From: robert.field at oracle.com (Robert Field) Date: Fri, 06 Jan 2017 13:32:38 -0800 Subject: RFR 8172255: JShell API: ExecutionControl/LoaderDelegate: Remove unused/unimplemented setClassPath Message-ID: <58700CF6.8050709@oracle.com> Please review.... Bug: https://bugs.openjdk.java.net/browse/JDK-8172255 Webrev: http://cr.openjdk.java.net/~rfield/8172255v0.webrev/ Thanks, Robert From robert.field at oracle.com Sun Jan 8 20:22:14 2017 From: robert.field at oracle.com (Robert Field) Date: Sun, 08 Jan 2017 12:22:14 -0800 Subject: RFR 8171981: JShell: Fails compilation: new Object().getClass().getSuperclass() Message-ID: <58729F76.9020502@oracle.com> Please review.... Bug: https://bugs.openjdk.java.net/browse/JDK-8171981 Webrev: http://cr.openjdk.java.net/~rfield/8171981v0.webrev/ Notes: There were two different mechanisms for determining type: one used in evaluation and one available in the API. Both had limitations/problems. Both used TypePrinter which was the cause of the reported problem. I've unified handling, discarded both old approaches, using a visitor instead. I've separated var type name determination (used in code generation -- no type variables) from other type printing (used in docs). Adopted Maurizo's handling of captured types. Added debugging support for wraps. Added lots more tests, including tests inspired by JEP-286. All new tests, test both entry-points. Thanks Maurizio and Dan! From maurizio.cimadamore at oracle.com Mon Jan 9 11:10:10 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 9 Jan 2017 11:10:10 +0000 Subject: RFR 8171981: JShell: Fails compilation: new Object().getClass().getSuperclass() In-Reply-To: <58729F76.9020502@oracle.com> References: <58729F76.9020502@oracle.com> Message-ID: Looks good. As we discussed privately, on lines 177 and 186, I think we want to use List.map instead of List.stream().map(). Note that List.map returns the original instance if map() doesn't change any of the elements, which then enables a simpler == comparison. This seems like a mistake in the JEP-286 code. Maurizio On 08/01/17 20:22, Robert Field wrote: > Please review.... > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8171981 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8171981v0.webrev/ > > Notes: > > There were two different mechanisms for determining type: one used in > evaluation and one available in the API. Both had > limitations/problems. Both used TypePrinter which was the cause of > the reported problem. > > I've unified handling, discarded both old approaches, using a visitor > instead. > I've separated var type name determination (used in code generation -- > no type variables) from other type printing (used in docs). > Adopted Maurizo's handling of captured types. > Added debugging support for wraps. > Added lots more tests, including tests inspired by JEP-286. All new > tests, test both entry-points. > Thanks Maurizio and Dan! > From maurizio.cimadamore at oracle.com Mon Jan 9 15:30:01 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 9 Jan 2017 15:30:01 +0000 Subject: RFR 8171981: JShell: Fails compilation: new Object().getClass().getSuperclass() In-Reply-To: References: <58729F76.9020502@oracle.com> Message-ID: Now that I think about it - in case where an intersection type is found, I think it would be great if jshell reported some kind of message like: found possible types: A, B defaulting to: A (please use an explicit type if the default choice is invalid) What do you think? Maurizio On 09/01/17 11:10, Maurizio Cimadamore wrote: > Looks good. As we discussed privately, on lines 177 and 186, I think > we want to use List.map instead of List.stream().map(). Note that > List.map returns the original instance if map() doesn't change any of > the elements, which then enables a simpler == comparison. This seems > like a mistake in the JEP-286 code. > > Maurizio > > > On 08/01/17 20:22, Robert Field wrote: >> Please review.... >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8171981 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8171981v0.webrev/ >> >> Notes: >> >> There were two different mechanisms for determining type: one used in >> evaluation and one available in the API. Both had >> limitations/problems. Both used TypePrinter which was the cause of >> the reported problem. >> >> I've unified handling, discarded both old approaches, using a visitor >> instead. >> I've separated var type name determination (used in code generation >> -- no type variables) from other type printing (used in docs). >> Adopted Maurizo's handling of captured types. >> Added debugging support for wraps. >> Added lots more tests, including tests inspired by JEP-286. All new >> tests, test both entry-points. >> Thanks Maurizio and Dan! >> > From jan.lahoda at oracle.com Mon Jan 9 16:01:44 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 9 Jan 2017 17:01:44 +0100 Subject: RFR JDK-8171385: jshell tool: unresponsive to ctrl-C in input wait on Windows Message-ID: <5873B3E8.2060901@oracle.com> Hi, I'd like to ask for a review of a fix for: https://bugs.openjdk.java.net/browse/JDK-8171385 Webrev: http://cr.openjdk.java.net/~jlahoda/8171385/webrev.00/ The problem is that the state of the StopDetectingInputStream changes while it is waiting for data. And when the first character read is Ctrl-C, the cancel might be sent the wrong direction. The proposed fix is to check the state again after reading from the input. Jan From jan.lahoda at oracle.com Mon Jan 9 16:09:34 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 9 Jan 2017 17:09:34 +0100 Subject: RFR JDK-8172414: jshell not working in exploded JDK build Message-ID: <5873B5BE.9020801@oracle.com> Hi, Currently, seems that jshell cannot be run on an exploded build: https://bugs.openjdk.java.net/browse/JDK-8172414 The reason appears to be an unconditional use of jrt URL, maybe just using Class.getResource(AsStream) would work? http://cr.openjdk.java.net/~jlahoda/8172414/webrev.00/ Thanks, Jan From robert.field at oracle.com Mon Jan 9 16:29:39 2017 From: robert.field at oracle.com (Robert Field) Date: Mon, 09 Jan 2017 08:29:39 -0800 Subject: RFR 8171981: JShell: Fails compilation: new Object().getClass().getSuperclass() In-Reply-To: References: <58729F76.9020502@oracle.com> Message-ID: <15984104d50.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> This inferencing is for the automatically generated scratch variables that get generated for every expression. A new user won't even know they exist. So we don't want messages about things being created behind the scenes (they are actually created behind the API layer, where there is no UI). In cases where it picks the wrong type, the user can explicitly create a variable. That said, picking a more specific type is more likely to be unsurprising when they use the variable than if Object is picked. I played with picking any common class if there are any and any interface if not. Wasn't sure the ideal location for that. Also, would need predictable ordering for testing purposes. Thanks, Robert On January 9, 2017 7:30:04 AM Maurizio Cimadamore wrote: > Now that I think about it - in case where an intersection type is found, > I think it would be great if jshell reported some kind of message like: > > found possible types: A, B > defaulting to: A > (please use an explicit type if the default choice is invalid) > > What do you think? > > Maurizio > > On 09/01/17 11:10, Maurizio Cimadamore wrote: >> Looks good. As we discussed privately, on lines 177 and 186, I think >> we want to use List.map instead of List.stream().map(). Note that >> List.map returns the original instance if map() doesn't change any of >> the elements, which then enables a simpler == comparison. This seems >> like a mistake in the JEP-286 code. >> >> Maurizio >> >> >> On 08/01/17 20:22, Robert Field wrote: >>> Please review.... >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8171981 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8171981v0.webrev/ >>> >>> Notes: >>> >>> There were two different mechanisms for determining type: one used in >>> evaluation and one available in the API. Both had >>> limitations/problems. Both used TypePrinter which was the cause of >>> the reported problem. >>> >>> I've unified handling, discarded both old approaches, using a visitor >>> instead. >>> I've separated var type name determination (used in code generation >>> -- no type variables) from other type printing (used in docs). >>> Adopted Maurizo's handling of captured types. >>> Added debugging support for wraps. >>> Added lots more tests, including tests inspired by JEP-286. All new >>> tests, test both entry-points. >>> Thanks Maurizio and Dan! >>> >> > From maurizio.cimadamore at oracle.com Mon Jan 9 17:35:17 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 9 Jan 2017 17:35:17 +0000 Subject: RFR 8171981: JShell: Fails compilation: new Object().getClass().getSuperclass() In-Reply-To: <15984104d50.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <58729F76.9020502@oracle.com> <15984104d50.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: <73b9097e-5c3f-9081-036e-25b233916e29@oracle.com> On 09/01/17 16:29, Robert Field wrote: > This inferencing is for the automatically generated scratch variables > that get generated for every expression. A new user won't even know > they exist. So we don't want messages about things being created > behind the scenes (they are actually created behind the API layer, > where there is no UI). In cases where it picks the wrong type, the > user can explicitly create a variable. That said, picking a more > specific type is more likely to be unsurprising when they use the > variable than if Object is picked. I played with picking any common > class if there are any and any interface if not. Wasn't sure the > ideal location for that. Also, would need predictable ordering for > testing purposes. I know that we are talking about synthetic variables where jshell stores expression values - but you can refer to these variables using $ID - so people referring to these variables will be able to see some edges and it would be nice to warn them that jshell picked something for them. Talking heuristics, I believe that, given an intersection like T1 & T2 ... Tn an acceptable normalization strategy is: * compute the minimal set of supertypes S = disjoint(T1, T2 ... Tn), where the set of disjoint types contains all types in T1 ... Tn for which there's no subtype in T1 ... Tn * if S contains just one type, use that type as the inferred type * if S contains multiple types, pick the first one I believe this heuristics should give good results and should also be deterministic. Of course this normalization should be done both at the top level (e.g. when the result of inference is an intersection type) and at the nested level (when the result of inference is some type like Foo). Maurizio > > Thanks, > Robert > > > > On January 9, 2017 7:30:04 AM Maurizio Cimadamore > wrote: > >> Now that I think about it - in case where an intersection type is found, >> I think it would be great if jshell reported some kind of message like: >> >> found possible types: A, B >> defaulting to: A >> (please use an explicit type if the default choice is invalid) >> >> What do you think? >> >> Maurizio >> >> On 09/01/17 11:10, Maurizio Cimadamore wrote: >>> Looks good. As we discussed privately, on lines 177 and 186, I think >>> we want to use List.map instead of List.stream().map(). Note that >>> List.map returns the original instance if map() doesn't change any of >>> the elements, which then enables a simpler == comparison. This seems >>> like a mistake in the JEP-286 code. >>> >>> Maurizio >>> >>> >>> On 08/01/17 20:22, Robert Field wrote: >>>> Please review.... >>>> >>>> Bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8171981 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~rfield/8171981v0.webrev/ >>>> >>>> Notes: >>>> >>>> There were two different mechanisms for determining type: one used in >>>> evaluation and one available in the API. Both had >>>> limitations/problems. Both used TypePrinter which was the cause of >>>> the reported problem. >>>> >>>> I've unified handling, discarded both old approaches, using a visitor >>>> instead. >>>> I've separated var type name determination (used in code generation >>>> -- no type variables) from other type printing (used in docs). >>>> Adopted Maurizo's handling of captured types. >>>> Added debugging support for wraps. >>>> Added lots more tests, including tests inspired by JEP-286. All new >>>> tests, test both entry-points. >>>> Thanks Maurizio and Dan! >>>> >>> >> > > From robert.field at oracle.com Mon Jan 9 21:17:18 2017 From: robert.field at oracle.com (Robert Field) Date: Mon, 9 Jan 2017 13:17:18 -0800 Subject: RFR JDK-8172414: jshell not working in exploded JDK build In-Reply-To: <5873B5BE.9020801@oracle.com> References: <5873B5BE.9020801@oracle.com> Message-ID: <43506798-EA6F-4415-8BF5-F9A2B93DCC1F@oracle.com> Other than the hyper-nit (extra indent of line 2249) looks good. -Robert > On Jan 9, 2017, at 8:09 AM, Jan Lahoda wrote: > > Hi, > > Currently, seems that jshell cannot be run on an exploded build: > https://bugs.openjdk.java.net/browse/JDK-8172414 > > The reason appears to be an unconditional use of jrt URL, maybe just using Class.getResource(AsStream) would work? > > http://cr.openjdk.java.net/~jlahoda/8172414/webrev.00/ > > Thanks, > Jan From jan.lahoda at oracle.com Mon Jan 9 21:22:55 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 9 Jan 2017 22:22:55 +0100 Subject: RFR 8172255: JShell API: ExecutionControl/LoaderDelegate: Remove unused/unimplemented setClassPath In-Reply-To: <58700CF6.8050709@oracle.com> References: <58700CF6.8050709@oracle.com> Message-ID: <5873FF2F.90004@oracle.com> Seems OK to me. Jan On 6.1.2017 22:32, Robert Field wrote: > Please review.... > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8172255 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8172255v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Mon Jan 9 21:24:33 2017 From: robert.field at oracle.com (Robert Field) Date: Mon, 9 Jan 2017 13:24:33 -0800 Subject: RFR JDK-8171385: jshell tool: unresponsive to ctrl-C in input wait on Windows In-Reply-To: <5873B3E8.2060901@oracle.com> References: <5873B3E8.2060901@oracle.com> Message-ID: <418623A4-D226-4FED-9C43-A555B80AEA74@oracle.com> Looks good. Nit: address, or not, currentState no longer needs to be a variable > On Jan 9, 2017, at 8:01 AM, Jan Lahoda wrote: > > Hi, > > I'd like to ask for a review of a fix for: > https://bugs.openjdk.java.net/browse/JDK-8171385 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8171385/webrev.00/ > > The problem is that the state of the StopDetectingInputStream changes while it is waiting for data. And when the first character read is Ctrl-C, the cancel might be sent the wrong direction. The proposed fix is to check the state again after reading from the input. > > Jan From jan.lahoda at oracle.com Mon Jan 9 21:37:26 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 9 Jan 2017 22:37:26 +0100 Subject: RFR JDK-8172414: jshell not working in exploded JDK build In-Reply-To: <43506798-EA6F-4415-8BF5-F9A2B93DCC1F@oracle.com> References: <5873B5BE.9020801@oracle.com> <43506798-EA6F-4415-8BF5-F9A2B93DCC1F@oracle.com> Message-ID: <58740296.8030109@oracle.com> On 9.1.2017 22:17, Robert Field wrote: > Other than the hyper-nit (extra indent of line 2249) looks good. Thanks. On line 2249, the intent was to keep the try resource aligned with the previous resource - but I can use a different formatting, as desired. Jan > > -Robert > >> On Jan 9, 2017, at 8:09 AM, Jan Lahoda wrote: >> >> Hi, >> >> Currently, seems that jshell cannot be run on an exploded build: >> https://bugs.openjdk.java.net/browse/JDK-8172414 >> >> The reason appears to be an unconditional use of jrt URL, maybe just using Class.getResource(AsStream) would work? >> >> http://cr.openjdk.java.net/~jlahoda/8172414/webrev.00/ >> >> Thanks, >> Jan > From robert.field at oracle.com Mon Jan 9 21:44:03 2017 From: robert.field at oracle.com (Robert Field) Date: Mon, 9 Jan 2017 13:44:03 -0800 Subject: RFR 8171981: JShell: Fails compilation: new Object().getClass().getSuperclass() In-Reply-To: <73b9097e-5c3f-9081-036e-25b233916e29@oracle.com> References: <58729F76.9020502@oracle.com> <15984104d50.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> <73b9097e-5c3f-9081-036e-25b233916e29@oracle.com> Message-ID: <0F8C55A8-9019-4625-8527-691CE094BE8C@oracle.com> Thanks. Will repair the list operation and push. I?ve create this issue for the refinement in handling intersection types: https://bugs.openjdk.java.net/browse/JDK-8172453 -Robert > On Jan 9, 2017, at 9:35 AM, Maurizio Cimadamore wrote: > > > > On 09/01/17 16:29, Robert Field wrote: >> This inferencing is for the automatically generated scratch variables that get generated for every expression. A new user won't even know they exist. So we don't want messages about things being created behind the scenes (they are actually created behind the API layer, where there is no UI). In cases where it picks the wrong type, the user can explicitly create a variable. That said, picking a more specific type is more likely to be unsurprising when they use the variable than if Object is picked. I played with picking any common class if there are any and any interface if not. Wasn't sure the ideal location for that. Also, would need predictable ordering for testing purposes. > I know that we are talking about synthetic variables where jshell stores expression values - but you can refer to these variables using $ID - so people referring to these variables will be able to see some edges and it would be nice to warn them that jshell picked something for them. > > Talking heuristics, I believe that, given an intersection like T1 & T2 ... Tn an acceptable normalization strategy is: > > * compute the minimal set of supertypes S = disjoint(T1, T2 ... Tn), where the set of disjoint types contains all types in T1 ... Tn for which there's no subtype in T1 ... Tn > * if S contains just one type, use that type as the inferred type > * if S contains multiple types, pick the first one > > I believe this heuristics should give good results and should also be deterministic. Of course this normalization should be done both at the top level (e.g. when the result of inference is an intersection type) and at the nested level (when the result of inference is some type like Foo). > > Maurizio >> >> Thanks, >> Robert >> >> >> >> On January 9, 2017 7:30:04 AM Maurizio Cimadamore wrote: >> >>> Now that I think about it - in case where an intersection type is found, >>> I think it would be great if jshell reported some kind of message like: >>> >>> found possible types: A, B >>> defaulting to: A >>> (please use an explicit type if the default choice is invalid) >>> >>> What do you think? >>> >>> Maurizio >>> >>> On 09/01/17 11:10, Maurizio Cimadamore wrote: >>>> Looks good. As we discussed privately, on lines 177 and 186, I think >>>> we want to use List.map instead of List.stream().map(). Note that >>>> List.map returns the original instance if map() doesn't change any of >>>> the elements, which then enables a simpler == comparison. This seems >>>> like a mistake in the JEP-286 code. >>>> >>>> Maurizio >>>> >>>> >>>> On 08/01/17 20:22, Robert Field wrote: >>>>> Please review.... >>>>> >>>>> Bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8171981 >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~rfield/8171981v0.webrev/ >>>>> >>>>> Notes: >>>>> >>>>> There were two different mechanisms for determining type: one used in >>>>> evaluation and one available in the API. Both had >>>>> limitations/problems. Both used TypePrinter which was the cause of >>>>> the reported problem. >>>>> >>>>> I've unified handling, discarded both old approaches, using a visitor >>>>> instead. >>>>> I've separated var type name determination (used in code generation >>>>> -- no type variables) from other type printing (used in docs). >>>>> Adopted Maurizo's handling of captured types. >>>>> Added debugging support for wraps. >>>>> Added lots more tests, including tests inspired by JEP-286. All new >>>>> tests, test both entry-points. >>>>> Thanks Maurizio and Dan! >>>>> >>>> >>> >> >> > From sundararajan.athijegannathan at oracle.com Tue Jan 10 03:07:13 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 10 Jan 2017 08:37:13 +0530 Subject: RFR JDK-8172414: jshell not working in exploded JDK build In-Reply-To: <5873B5BE.9020801@oracle.com> References: <5873B5BE.9020801@oracle.com> Message-ID: <58744FE1.7020606@oracle.com> +1 On 09/01/17, 9:39 PM, Jan Lahoda wrote: > Hi, > > Currently, seems that jshell cannot be run on an exploded build: > https://bugs.openjdk.java.net/browse/JDK-8172414 > > The reason appears to be an unconditional use of jrt URL, maybe just > using Class.getResource(AsStream) would work? > > http://cr.openjdk.java.net/~jlahoda/8172414/webrev.00/ > > Thanks, > Jan From maurizio.cimadamore at oracle.com Tue Jan 10 11:22:38 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 10 Jan 2017 11:22:38 +0000 Subject: RFR 8171981: JShell: Fails compilation: new Object().getClass().getSuperclass() In-Reply-To: <0F8C55A8-9019-4625-8527-691CE094BE8C@oracle.com> References: <58729F76.9020502@oracle.com> <15984104d50.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> <73b9097e-5c3f-9081-036e-25b233916e29@oracle.com> <0F8C55A8-9019-4625-8527-691CE094BE8C@oracle.com> Message-ID: Seems like list.stream().map() is still used instead of list.map() in at least one place? http://hg.openjdk.java.net/jdk9/dev/langtools/rev/9ed8e9a27b00#l10.187 Maurizio On 09/01/17 21:44, Robert Field wrote: > Thanks. > > Will repair the list operation and push. > > I?ve create this issue for the refinement in handling intersection types: > > https://bugs.openjdk.java.net/browse/JDK-8172453 > > -Robert > >> On Jan 9, 2017, at 9:35 AM, Maurizio Cimadamore >> > > wrote: >> >> >> >> On 09/01/17 16:29, Robert Field wrote: >>> This inferencing is for the automatically generated scratch >>> variables that get generated for every expression. A new user won't >>> even know they exist. So we don't want messages about things being >>> created behind the scenes (they are actually created behind the API >>> layer, where there is no UI). In cases where it picks the wrong >>> type, the user can explicitly create a variable. That said, picking >>> a more specific type is more likely to be unsurprising when they use >>> the variable than if Object is picked. I played with picking any >>> common class if there are any and any interface if not. Wasn't sure >>> the ideal location for that. Also, would need predictable ordering >>> for testing purposes. >> I know that we are talking about synthetic variables where jshell >> stores expression values - but you can refer to these variables using >> $ID - so people referring to these variables will be able to see some >> edges and it would be nice to warn them that jshell picked something >> for them. >> >> Talking heuristics, I believe that, given an intersection like T1 & >> T2 ... Tn an acceptable normalization strategy is: >> >> * compute the minimal set of supertypes S = disjoint(T1, T2 ... Tn), >> where the set of disjoint types contains all types in T1 ... Tn for >> which there's no subtype in T1 ... Tn >> * if S contains just one type, use that type as the inferred type >> * if S contains multiple types, pick the first one >> >> I believe this heuristics should give good results and should also be >> deterministic. Of course this normalization should be done both at >> the top level (e.g. when the result of inference is an intersection >> type) and at the nested level (when the result of inference is some >> type like Foo). >> >> Maurizio >>> >>> Thanks, >>> Robert >>> >>> >>> >>> On January 9, 2017 7:30:04 AM Maurizio Cimadamore >>> >> > wrote: >>> >>>> Now that I think about it - in case where an intersection type is >>>> found, >>>> I think it would be great if jshell reported some kind of message like: >>>> >>>> found possible types: A, B >>>> defaulting to: A >>>> (please use an explicit type if the default choice is invalid) >>>> >>>> What do you think? >>>> >>>> Maurizio >>>> >>>> On 09/01/17 11:10, Maurizio Cimadamore wrote: >>>>> Looks good. As we discussed privately, on lines 177 and 186, I think >>>>> we want to use List.map instead of List.stream().map(). Note that >>>>> List.map returns the original instance if map() doesn't change any of >>>>> the elements, which then enables a simpler == comparison. This seems >>>>> like a mistake in the JEP-286 code. >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> On 08/01/17 20:22, Robert Field wrote: >>>>>> Please review.... >>>>>> >>>>>> Bug: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8171981 >>>>>> >>>>>> Webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~rfield/8171981v0.webrev/ >>>>>> >>>>>> >>>>>> Notes: >>>>>> >>>>>> There were two different mechanisms for determining type: one used in >>>>>> evaluation and one available in the API. Both had >>>>>> limitations/problems. Both used TypePrinter which was the cause of >>>>>> the reported problem. >>>>>> >>>>>> I've unified handling, discarded both old approaches, using a visitor >>>>>> instead. >>>>>> I've separated var type name determination (used in code generation >>>>>> -- no type variables) from other type printing (used in docs). >>>>>> Adopted Maurizo's handling of captured types. >>>>>> Added debugging support for wraps. >>>>>> Added lots more tests, including tests inspired by JEP-286. All new >>>>>> tests, test both entry-points. >>>>>> Thanks Maurizio and Dan! >>>>>> >>>>> >>>> >>> >>> >> > From robert.field at oracle.com Tue Jan 10 16:10:10 2017 From: robert.field at oracle.com (Robert Field) Date: Tue, 10 Jan 2017 08:10:10 -0800 Subject: RFR 8171981: JShell: Fails compilation: new Object().getClass().getSuperclass() In-Reply-To: References: <58729F76.9020502@oracle.com> <15984104d50.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> <73b9097e-5c3f-9081-036e-25b233916e29@oracle.com> <0F8C55A8-9019-4625-8527-691CE094BE8C@oracle.com> Message-ID: <1598924d6d0.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Oops, I just changed the one location you highlighted before. I didn't notice there were more. Thanks for checking. Will fix. Robert On January 10, 2017 3:22:45 AM Maurizio Cimadamore wrote: > Seems like list.stream().map() is still used instead of list.map() in at > least one place? > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/9ed8e9a27b00#l10.187 > > Maurizio > > > On 09/01/17 21:44, Robert Field wrote: >> Thanks. >> >> Will repair the list operation and push. >> >> I?ve create this issue for the refinement in handling intersection types: >> >> https://bugs.openjdk.java.net/browse/JDK-8172453 >> >> -Robert >> >>> On Jan 9, 2017, at 9:35 AM, Maurizio Cimadamore >>> >> > wrote: >>> >>> >>> >>> On 09/01/17 16:29, Robert Field wrote: >>>> This inferencing is for the automatically generated scratch >>>> variables that get generated for every expression. A new user won't >>>> even know they exist. So we don't want messages about things being >>>> created behind the scenes (they are actually created behind the API >>>> layer, where there is no UI). In cases where it picks the wrong >>>> type, the user can explicitly create a variable. That said, picking >>>> a more specific type is more likely to be unsurprising when they use >>>> the variable than if Object is picked. I played with picking any >>>> common class if there are any and any interface if not. Wasn't sure >>>> the ideal location for that. Also, would need predictable ordering >>>> for testing purposes. >>> I know that we are talking about synthetic variables where jshell >>> stores expression values - but you can refer to these variables using >>> $ID - so people referring to these variables will be able to see some >>> edges and it would be nice to warn them that jshell picked something >>> for them. >>> >>> Talking heuristics, I believe that, given an intersection like T1 & >>> T2 ... Tn an acceptable normalization strategy is: >>> >>> * compute the minimal set of supertypes S = disjoint(T1, T2 ... Tn), >>> where the set of disjoint types contains all types in T1 ... Tn for >>> which there's no subtype in T1 ... Tn >>> * if S contains just one type, use that type as the inferred type >>> * if S contains multiple types, pick the first one >>> >>> I believe this heuristics should give good results and should also be >>> deterministic. Of course this normalization should be done both at >>> the top level (e.g. when the result of inference is an intersection >>> type) and at the nested level (when the result of inference is some >>> type like Foo). >>> >>> Maurizio >>>> >>>> Thanks, >>>> Robert >>>> >>>> >>>> >>>> On January 9, 2017 7:30:04 AM Maurizio Cimadamore >>>> >>> > wrote: >>>> >>>>> Now that I think about it - in case where an intersection type is >>>>> found, >>>>> I think it would be great if jshell reported some kind of message like: >>>>> >>>>> found possible types: A, B >>>>> defaulting to: A >>>>> (please use an explicit type if the default choice is invalid) >>>>> >>>>> What do you think? >>>>> >>>>> Maurizio >>>>> >>>>> On 09/01/17 11:10, Maurizio Cimadamore wrote: >>>>>> Looks good. As we discussed privately, on lines 177 and 186, I think >>>>>> we want to use List.map instead of List.stream().map(). Note that >>>>>> List.map returns the original instance if map() doesn't change any of >>>>>> the elements, which then enables a simpler == comparison. This seems >>>>>> like a mistake in the JEP-286 code. >>>>>> >>>>>> Maurizio >>>>>> >>>>>> >>>>>> On 08/01/17 20:22, Robert Field wrote: >>>>>>> Please review.... >>>>>>> >>>>>>> Bug: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171981 >>>>>>> >>>>>>> Webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~rfield/8171981v0.webrev/ >>>>>>> >>>>>>> >>>>>>> Notes: >>>>>>> >>>>>>> There were two different mechanisms for determining type: one used in >>>>>>> evaluation and one available in the API. Both had >>>>>>> limitations/problems. Both used TypePrinter which was the cause of >>>>>>> the reported problem. >>>>>>> >>>>>>> I've unified handling, discarded both old approaches, using a visitor >>>>>>> instead. >>>>>>> I've separated var type name determination (used in code generation >>>>>>> -- no type variables) from other type printing (used in docs). >>>>>>> Adopted Maurizo's handling of captured types. >>>>>>> Added debugging support for wraps. >>>>>>> Added lots more tests, including tests inspired by JEP-286. All new >>>>>>> tests, test both entry-points. >>>>>>> Thanks Maurizio and Dan! >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > From felix.yang at oracle.com Tue Jan 10 16:13:03 2017 From: felix.yang at oracle.com (Felix Yang) Date: Tue, 10 Jan 2017 08:13:03 -0800 Subject: RFR 8172456, Problem list jdk/jshell/ToolBasicTest.java In-Reply-To: <461B087C-52B2-4B85-81DF-EE0F208FB222@oracle.com> References: <461B087C-52B2-4B85-81DF-EE0F208FB222@oracle.com> Message-ID: <16D17781-5B2C-4F57-9D9D-494D92E7558A@oracle.com> Any comment? Thanks, Felix > On 9 Jan 2017, at 6:18 PM, Felix Yang wrote: > > Hi there, > please review the proposal to problem list jdk/jshell/ToolBasicTest.java. It is a tier1 test and has been observed to be failing intermittently(3 times out of recent 15 runs) on Linux. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172456 > > Thanks, > Felix > > diff -r ee620ff60730 test/ProblemList.txt > --- a/test/ProblemList.txt Mon Jan 09 13:50:45 2017 -0800 > +++ b/test/ProblemList.txt Mon Jan 09 18:04:02 2017 -0800 > @@ -39,6 +39,7 @@ > jdk/jshell/ToolFormatTest.java 8170216 solaris-sparcv9 > jdk/jshell/ReplaceTest.java 8170216 solaris-sparcv9 > jdk/jshell/UserInputTest.java 8169536 generic-all > +jdk/jshell/ToolBasicTest.java 8172295 linux-all ToolBasicTest fails with "package pkg does not exist" > > ########################################################################### > # > From felix.yang at oracle.com Tue Jan 10 02:18:59 2017 From: felix.yang at oracle.com (Felix Yang) Date: Mon, 9 Jan 2017 18:18:59 -0800 Subject: RFR 8172456, Problem list jdk/jshell/ToolBasicTest.java Message-ID: <461B087C-52B2-4B85-81DF-EE0F208FB222@oracle.com> Hi there, please review the proposal to problem list jdk/jshell/ToolBasicTest.java. It is a tier1 test and has been observed to be failing intermittently(3 times out of recent 15 runs) on Linux. Bug: https://bugs.openjdk.java.net/browse/JDK-8172456 Thanks, Felix diff -r ee620ff60730 test/ProblemList.txt --- a/test/ProblemList.txt Mon Jan 09 13:50:45 2017 -0800 +++ b/test/ProblemList.txt Mon Jan 09 18:04:02 2017 -0800 @@ -39,6 +39,7 @@ jdk/jshell/ToolFormatTest.java 8170216 solaris-sparcv9 jdk/jshell/ReplaceTest.java 8170216 solaris-sparcv9 jdk/jshell/UserInputTest.java 8169536 generic-all +jdk/jshell/ToolBasicTest.java 8172295 linux-all ToolBasicTest fails with "package pkg does not exist" ########################################################################### # From felix.yang at oracle.com Tue Jan 10 23:18:42 2017 From: felix.yang at oracle.com (Felix Yang) Date: Tue, 10 Jan 2017 15:18:42 -0800 Subject: RFR 8172456, Problem list jdk/jshell/ToolBasicTest.java In-Reply-To: <587542DC.1090903@oracle.com> References: <461B087C-52B2-4B85-81DF-EE0F208FB222@oracle.com> <16D17781-5B2C-4F57-9D9D-494D92E7558A@oracle.com> <587542DC.1090903@oracle.com> Message-ID: > On 10 Jan 2017, at 12:23 PM, Robert Field wrote: > > Hi Felix, > > With the fix for 8165405, it is using a new mechanism. So, this is now testing new functionality. > > Has it failed since that went back? Not yet. -Felix > > Thanks, > Robert > > On 01/10/17 08:13, Felix Yang wrote: >> Any comment? >> >> Thanks, >> Felix >>> On 9 Jan 2017, at 6:18 PM, Felix Yang > wrote: >>> >>> Hi there, >>> please review the proposal to problem list jdk/jshell/ToolBasicTest.java. It is a tier1 test and has been observed to be failing intermittently(3 times out of recent 15 runs) on Linux. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172456 >>> >>> Thanks, >>> Felix >>> >>> diff -r ee620ff60730 test/ProblemList.txt >>> --- a/test/ProblemList.txt Mon Jan 09 13:50:45 2017 -0800 >>> +++ b/test/ProblemList.txt Mon Jan 09 18:04:02 2017 -0800 >>> @@ -39,6 +39,7 @@ >>> jdk/jshell/ToolFormatTest.java 8170216 solaris-sparcv9 >>> jdk/jshell/ReplaceTest.java 8170216 solaris-sparcv9 >>> jdk/jshell/UserInputTest.java 8169536 generic-all >>> +jdk/jshell/ToolBasicTest.java 8172295 linux-all ToolBasicTest fails with "package pkg does not exist" >>> >>> ########################################################################### >>> # >>> >> > From robert.field at oracle.com Wed Jan 11 01:57:50 2017 From: robert.field at oracle.com (Robert Field) Date: Tue, 10 Jan 2017 17:57:50 -0800 Subject: RFR 8172530: JShell: TypeProjection .stream().map(...).collect(...) must be replaced with .map(...) Message-ID: <5875911E.5070303@oracle.com> Please review... Bug: https://bugs.openjdk.java.net/browse/JDK-8172530 Webrev: http://cr.openjdk.java.net/~rfield/8172530v0.webrev/ -Robert From maurizio.cimadamore at oracle.com Wed Jan 11 15:08:38 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 11 Jan 2017 15:08:38 +0000 Subject: RFR 8172530: JShell: TypeProjection .stream().map(...).collect(...) must be replaced with .map(...) In-Reply-To: <5875911E.5070303@oracle.com> References: <5875911E.5070303@oracle.com> Message-ID: Looks good! Maurizio On 11/01/17 01:57, Robert Field wrote: > Please review... > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8172530 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8172530v0.webrev/ > > -Robert > From robert.field at oracle.com Thu Jan 12 01:40:42 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 11 Jan 2017 17:40:42 -0800 Subject: RFR (xs) 8172678: JShell Tests: Disable CompletionSuggestionTest.testBrokenClassFile2() Message-ID: <5876DE9A.8030601@oracle.com> Please review... Bug: JShell Tests: Disable CompletionSuggestionTest.testBrokenClassFile2() https://bugs.openjdk.java.net/browse/JDK-8172678 Related issues: jdk/jshell/CompletionSuggestionTest.java failed with AssertionError https://bugs.openjdk.java.net/browse/JDK-8171829 JShell: addToClasspath fails intermittently https://bugs.openjdk.java.net/browse/JDK-8172676 Webrev: http://cr.openjdk.java.net/~rfield/8172678v0.webrev/ -Robert From jan.lahoda at oracle.com Fri Jan 13 09:53:38 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 13 Jan 2017 10:53:38 +0100 Subject: RFR JDK-8171386: jshell tool: paging of javadoc output broken on Windows Message-ID: <5878A3A2.6080808@oracle.com> Hello, The screen width and height detection is not working properly on Windows, because: -a wrong handle is passed to GetConsoleScreenBufferInfo (passed is input handle, needs to be output handle) -CONSOLE_SCREEN_BUFFER_INFO.dwSize.X/Y contains information about the size of the screen buffer, not the window - need to use CONSOLE_SCREEN_BUFFER_INFO.srWindow to find out the size of the window. (For width of the window the returned width is one character smaller than the actual width, as writing the very last character causes the cursor overflow to next line, breaking the formatting.) Bug: https://bugs.openjdk.java.net/browse/JDK-8171386 Webrev: http://cr.openjdk.java.net/~jlahoda/8171386/webrev.00/ Any feedback is welcome. Thanks, Jan From jan.lahoda at oracle.com Fri Jan 13 10:39:57 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 13 Jan 2017 11:39:57 +0100 Subject: RFR (xs) 8172678: JShell Tests: Disable CompletionSuggestionTest.testBrokenClassFile2() In-Reply-To: <5876DE9A.8030601@oracle.com> References: <5876DE9A.8030601@oracle.com> Message-ID: <5878AE7D.8090809@oracle.com> Seems OK. Jan On 12.1.2017 02:40, Robert Field wrote: > Please review... > > Bug: > > JShell Tests: Disable CompletionSuggestionTest.testBrokenClassFile2() > https://bugs.openjdk.java.net/browse/JDK-8172678 > > Related issues: > > jdk/jshell/CompletionSuggestionTest.java failed with AssertionError > https://bugs.openjdk.java.net/browse/JDK-8171829 > > JShell: addToClasspath fails intermittently > https://bugs.openjdk.java.net/browse/JDK-8172676 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8172678v0.webrev/ > > -Robert > From robert.field at oracle.com Fri Jan 13 22:13:16 2017 From: robert.field at oracle.com (Robert Field) Date: Fri, 13 Jan 2017 14:13:16 -0800 Subject: RFR 8172179: jshell tool: builtin startup settings should be by reference not content Message-ID: <587950FC.5090405@oracle.com> Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8172179 Webrev: http://cr.openjdk.java.net/~rfield/8172179v0.webrev/ Thanks, Robert From robert.field at oracle.com Sat Jan 14 19:55:27 2017 From: robert.field at oracle.com (Robert Field) Date: Sat, 14 Jan 2017 11:55:27 -0800 Subject: RFR JDK-8171386: jshell tool: paging of javadoc output broken on Windows In-Reply-To: <5878A3A2.6080808@oracle.com> References: <5878A3A2.6080808@oracle.com> Message-ID: <587A822F.2020301@oracle.com> Changes look fine. Shouldn't this be categorized as a jline2 bug in JBS? Can we submit it to jline2: https://github.com/jline/jline2/issues Thanks, Robert On 01/13/17 01:53, Jan Lahoda wrote: > Hello, > > The screen width and height detection is not working properly on > Windows, because: > -a wrong handle is passed to GetConsoleScreenBufferInfo (passed is > input handle, needs to be output handle) > -CONSOLE_SCREEN_BUFFER_INFO.dwSize.X/Y contains information about the > size of the screen buffer, not the window - need to use > CONSOLE_SCREEN_BUFFER_INFO.srWindow to find out the size of the > window. (For width of the window the returned width is one character > smaller than the actual width, as writing the very last character > causes the cursor overflow to next line, breaking the formatting.) > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8171386 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8171386/webrev.00/ > > Any feedback is welcome. > > Thanks, > Jan > > From jan.lahoda at oracle.com Mon Jan 16 14:02:57 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 16 Jan 2017 15:02:57 +0100 Subject: RFR JDK-8171386: jshell tool: paging of javadoc output broken on Windows In-Reply-To: <587A822F.2020301@oracle.com> References: <5878A3A2.6080808@oracle.com> <587A822F.2020301@oracle.com> Message-ID: <587CD291.4050308@oracle.com> On 14.1.2017 20:55, Robert Field wrote: > Changes look fine. Thanks! > > Shouldn't this be categorized as a jline2 bug in JBS? Done. > > Can we submit it to jline2: > > https://github.com/jline/jline2/issues This is in fact our code (replacement for jansi that jline is using). Jan > > Thanks, > Robert > > On 01/13/17 01:53, Jan Lahoda wrote: >> Hello, >> >> The screen width and height detection is not working properly on >> Windows, because: >> -a wrong handle is passed to GetConsoleScreenBufferInfo (passed is >> input handle, needs to be output handle) >> -CONSOLE_SCREEN_BUFFER_INFO.dwSize.X/Y contains information about the >> size of the screen buffer, not the window - need to use >> CONSOLE_SCREEN_BUFFER_INFO.srWindow to find out the size of the >> window. (For width of the window the returned width is one character >> smaller than the actual width, as writing the very last character >> causes the cursor overflow to next line, breaking the formatting.) >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8171386 >> >> Webrev: >> http://cr.openjdk.java.net/~jlahoda/8171386/webrev.00/ >> >> Any feedback is welcome. >> >> Thanks, >> Jan >> >> > From robert.field at oracle.com Thu Jan 19 02:49:31 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 18 Jan 2017 18:49:31 -0800 Subject: RFR 8171130: jshell tool: /edit adds empty statement.. / 8173007: JShell Tests: ToolFormatTest takes too long Message-ID: <5880293B.5070605@oracle.com> Please review... Bugs: jshell tool: /edit adds empty statement to brace terminated snippet https://bugs.openjdk.java.net/browse/JDK-8171130 JShell Tests: ToolFormatTest takes too long https://bugs.openjdk.java.net/browse/JDK-8173007 Webrev: http://cr.openjdk.java.net/~rfield/8171130v0.webrev/ -Robert From jan.lahoda at oracle.com Thu Jan 19 18:17:48 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 19 Jan 2017 19:17:48 +0100 Subject: RFR 8172179: jshell tool: builtin startup settings should be by reference not content In-Reply-To: <587950FC.5090405@oracle.com> References: <587950FC.5090405@oracle.com> Message-ID: <588102CC.1020104@oracle.com> Seems OK. Jan On 13.1.2017 23:13, Robert Field wrote: > Please review: > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8172179 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8172179v0.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Thu Jan 19 18:31:17 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 19 Jan 2017 19:31:17 +0100 Subject: RFR 8171130: jshell tool: /edit adds empty statement.. / 8173007: JShell Tests: ToolFormatTest takes too long In-Reply-To: <5880293B.5070605@oracle.com> References: <5880293B.5070605@oracle.com> Message-ID: <588105F5.9060705@oracle.com> Seems OK. Jan On 19.1.2017 03:49, Robert Field wrote: > Please review... > > Bugs: > > jshell tool: /edit adds empty statement to brace terminated snippet > https://bugs.openjdk.java.net/browse/JDK-8171130 > > JShell Tests: ToolFormatTest takes too long > https://bugs.openjdk.java.net/browse/JDK-8173007 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8171130v0.webrev/ > > -Robert > From robert.field at oracle.com Thu Jan 19 21:57:51 2017 From: robert.field at oracle.com (Robert Field) Date: Thu, 19 Jan 2017 13:57:51 -0800 Subject: RFR 8173073: jshell tool: blank lines removed from multiline snippets Message-ID: <5881365F.6050904@oracle.com> Please review... Bug: https://bugs.openjdk.java.net/browse/JDK-8173073 Webrev: http://cr.openjdk.java.net/~rfield/8173073v0.webrev/ Thanks, Robert z From jan.lahoda at oracle.com Fri Jan 20 17:44:08 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 20 Jan 2017 18:44:08 +0100 Subject: RFR 8173073: jshell tool: blank lines removed from multiline snippets In-Reply-To: <5881365F.6050904@oracle.com> References: <5881365F.6050904@oracle.com> Message-ID: <58824C68.4090307@oracle.com> Seems OK. Jan On 19.1.2017 22:57, Robert Field wrote: > Please review... > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8173073 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8173073v0.webrev/ > > Thanks, > Robert > > z > From jan.lahoda at oracle.com Mon Jan 23 18:14:10 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 23 Jan 2017 19:14:10 +0100 Subject: RFR JDK-8153759: jshell tool: Smart completion detection is not reliable Message-ID: <588647F2.6000602@oracle.com> Hi, When tab completion is invoked in the tool, there are two mode: "smart" and all/ordinary. Consecutive presses of should switch between these modes. But, the detection of the sequence of actions is not fully reliable - a tab followed by some other actions and followed by a tab may appear to be two consecutive tabs. This patch tries to improve the detection by actually watching the actions that are being performed. Bug: https://bugs.openjdk.java.net/browse/JDK-8153759 Webrev: http://cr.openjdk.java.net/~jlahoda/8153759/webrev.00/ Thanks, Jan From robert.field at oracle.com Tue Jan 24 03:54:23 2017 From: robert.field at oracle.com (Robert Field) Date: Mon, 23 Jan 2017 19:54:23 -0800 Subject: RFR 8173232/8173234/8173204 -- ProblemList fixes/updates Message-ID: <5886CFEF.7000901@oracle.com> Please review... Bugs: 8173232: JShell test: ReplaceTest takes too long https://bugs.openjdk.java.net/browse/JDK-8173232 break up the too big test into three 8173234: JShell tests: remove from ProblemList jdk/jshell/ToolFormatTest.java https://bugs.openjdk.java.net/browse/JDK-8173234 the underlying problem was fixed, the ProblemList entry should be removed 8173204: JShell tests: ProblemList jdk/jshell/UserJdiUserRemoteTest.java https://bugs.openjdk.java.net/browse/JDK-8173204 this one does fail intermittently because JDI fails intermittently and this doesn't (by definition) have failover Webrev: http://cr.openjdk.java.net/~rfield/8173232v0.webrev/ Thanks, Robert From robert.field at oracle.com Tue Jan 24 04:58:33 2017 From: robert.field at oracle.com (Robert Field) Date: Mon, 23 Jan 2017 20:58:33 -0800 Subject: RFR JDK-8153759: jshell tool: Smart completion detection is not reliable In-Reply-To: <588647F2.6000602@oracle.com> References: <588647F2.6000602@oracle.com> Message-ID: <5886DEF9.1080400@oracle.com> Makes sense. The bug will need a noreg. -Robert On 01/23/17 10:14, Jan Lahoda wrote: > Hi, > > When tab completion is invoked in the tool, there are two mode: > "smart" and all/ordinary. Consecutive presses of should switch > between these modes. But, the detection of the sequence of actions is > not fully reliable - a tab followed by some other actions and followed > by a tab may appear to be two consecutive tabs. This patch tries to > improve the detection by actually watching the actions that are being > performed. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8153759 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8153759/webrev.00/ > > Thanks, > Jan From robert.field at oracle.com Wed Jan 25 04:55:05 2017 From: robert.field at oracle.com (Robert Field) Date: Tue, 24 Jan 2017 20:55:05 -0800 Subject: RFR 8171343: jshell tool: missing options: --help-extra --show-version Message-ID: <58882FA9.50908@oracle.com> Please review... Bug: https://bugs.openjdk.java.net/browse/JDK-8171343 Webrev: http://cr.openjdk.java.net/~rfield/8171343v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Wed Jan 25 17:10:54 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Jan 2017 18:10:54 +0100 Subject: RFR 8173232/8173234/8173204 -- ProblemList fixes/updates In-Reply-To: <5886CFEF.7000901@oracle.com> References: <5886CFEF.7000901@oracle.com> Message-ID: <5888DC1E.80304@oracle.com> Seems OK to me. Jan On 24.1.2017 04:54, Robert Field wrote: > Please review... > > Bugs: > > 8173232: JShell test: ReplaceTest takes too long > https://bugs.openjdk.java.net/browse/JDK-8173232 > break up the too big test into three > > 8173234: JShell tests: remove from ProblemList > jdk/jshell/ToolFormatTest.java > https://bugs.openjdk.java.net/browse/JDK-8173234 > the underlying problem was fixed, the ProblemList entry should be > removed > > 8173204: JShell tests: ProblemList > jdk/jshell/UserJdiUserRemoteTest.java > https://bugs.openjdk.java.net/browse/JDK-8173204 > this one does fail intermittently because JDI fails intermittently > and this doesn't (by definition) have failover > > Webrev: > > http://cr.openjdk.java.net/~rfield/8173232v0.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Wed Jan 25 17:32:52 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Jan 2017 18:32:52 +0100 Subject: RFR 8171343: jshell tool: missing options: --help-extra --show-version In-Reply-To: <58882FA9.50908@oracle.com> References: <58882FA9.50908@oracle.com> Message-ID: <5888E144.50109@oracle.com> Seems OK. Jan On 25.1.2017 05:55, Robert Field wrote: > Please review... > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8171343 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8171343v0.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Fri Jan 27 15:28:11 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 27 Jan 2017 16:28:11 +0100 Subject: RFR: JDK-8166535: jshell tool: cannot handle non-ascii characters Message-ID: <588B670B.6040105@oracle.com> Hi, This is a basic patch to handle non-ASCII characters on Windows. The main change is use of ReadConsoleInputW instead of the current ReadConsoleInput. This should ensure the read characters are Unicode as opposed to current ASCII. So, if a non-ASCII character is typed, and is supported by the default encoding and the console output encoding, it should work. If the character is not supported by the default encoding, it will still be turned into '?'. AFAIK, this is consistent with JLine behavior (the code patched here is our replacement for jansi used by JLine). This differs from System.in behavior, where the unsupported characters with diacritics are converted to equivalent characters without diacritics. I think we could try to improve that in the future (I did some experiments, but the results were not perfect so far). For Linux, I am afraid I didn't see the problem there - I'll file a separate bug to investigate. Bug: https://bugs.openjdk.java.net/browse/JDK-8166535 Webrev: http://cr.openjdk.java.net/~jlahoda/8166535/webrev.00/ Thanks, Jan From peter.levart at gmail.com Fri Jan 27 16:22:21 2017 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 27 Jan 2017 17:22:21 +0100 Subject: Pasting multiple lines into jshell tool just pastes 1st two lines Message-ID: <771eae60-7d29-bc6d-68cf-d78f9740b43c@gmail.com> Hi, Recently I'm beginning to use jshell more an more and I'm pleasantly surprised by its capabilities as I go along. This is a hidden gem of JDK 9! Sometimes I want to paste a snippet of code into jshell which is started in a Linux terminal (Konsole on Fedora-KDE). Just 1st two lines get pasted so I have to transfer the snippet in multiple copy-paste actions, two lines at once... Are you aware of this inconvenience? Does it happen consistently or is this just in my environment? I tried using select+middle-mouse-button-press or copy+paste and it is all the same. First two lines is all I get pasted and they are always full lines - nothing is missing in them. Regards, Peter From robert.field at oracle.com Fri Jan 27 18:22:05 2017 From: robert.field at oracle.com (Robert Field) Date: Fri, 27 Jan 2017 10:22:05 -0800 Subject: RFR: JDK-8166535: jshell tool: cannot handle non-ascii characters In-Reply-To: <588B670B.6040105@oracle.com> References: <588B670B.6040105@oracle.com> Message-ID: <588B8FCD.60706@oracle.com> Looks fine. You will need a noreg-hard label. Thanks, Robert On 01/27/17 07:28, Jan Lahoda wrote: > Hi, > > This is a basic patch to handle non-ASCII characters on Windows. The > main change is use of ReadConsoleInputW instead of the current > ReadConsoleInput. This should ensure the read characters are Unicode > as opposed to current ASCII. > > So, if a non-ASCII character is typed, and is supported by the default > encoding and the console output encoding, it should work. > > If the character is not supported by the default encoding, it will > still be turned into '?'. AFAIK, this is consistent with JLine > behavior (the code patched here is our replacement for jansi used by > JLine). This differs from System.in behavior, where the unsupported > characters with diacritics are converted to equivalent characters > without diacritics. I think we could try to improve that in the future > (I did some experiments, but the results were not perfect so far). > > For Linux, I am afraid I didn't see the problem there - I'll file a > separate bug to investigate. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166535 > Webrev: > http://cr.openjdk.java.net/~jlahoda/8166535/webrev.00/ > > Thanks, > Jan From robert.field at oracle.com Tue Jan 31 05:28:54 2017 From: robert.field at oracle.com (Robert Field) Date: Mon, 30 Jan 2017 21:28:54 -0800 Subject: RFR 8173652: jshell tool: store history on fatal exit Message-ID: <58902096.2050704@oracle.com> Please review this fix to prevent data loss... Bug: https://bugs.openjdk.java.net/browse/JDK-8173652 Webrev: http://cr.openjdk.java.net/~rfield/8173652v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Tue Jan 31 19:52:06 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 31 Jan 2017 20:52:06 +0100 Subject: RFR 8173652: jshell tool: store history on fatal exit In-Reply-To: <58902096.2050704@oracle.com> References: <58902096.2050704@oracle.com> Message-ID: <5890EAE6.3050301@oracle.com> Seems fine to me. Jan On 31.1.2017 06:28, Robert Field wrote: > Please review this fix to prevent data loss... > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8173652 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8173652v0.webrev/ > > Thanks, > Robert >