From jonathan.gibbons at oracle.com Fri Aug 4 21:13:59 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 04 Aug 2017 14:13:59 -0700 Subject: RFR: 8185756: JShell has broken links in its documentation Message-ID: <5984E397.5070409@oracle.com> Please review the following minor fixes for some broken links in the JShell API documentation. In all cases, a @link to a method needs to specify the parameter list, because of the existence of a like-named field, albeit one with private access. JBS: https://bugs.openjdk.java.net/browse/JDK-8185756 Webrev: http://cr.openjdk.java.net/~jjg/8185756/webrev.00/ -- Jon From robert.field at oracle.com Fri Aug 4 22:39:15 2017 From: robert.field at oracle.com (Robert Field) Date: Fri, 04 Aug 2017 15:39:15 -0700 Subject: RFR: 8185756: JShell has broken links in its documentation In-Reply-To: <5984E397.5070409@oracle.com> References: <5984E397.5070409@oracle.com> Message-ID: <15daf671638.2794.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Thumbs up! -Robert (a guy who hasn't returned to work yet) On August 4, 2017 2:14:08 PM Jonathan Gibbons wrote: > Please review the following minor fixes for some broken links in the > JShell API documentation. > > In all cases, a @link to a method needs to specify the parameter list, > because of the existence of a like-named field, albeit one with private > access. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185756 > Webrev: http://cr.openjdk.java.net/~jjg/8185756/webrev.00/ > > -- Jon From jonathan.gibbons at oracle.com Fri Aug 4 22:44:06 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 04 Aug 2017 15:44:06 -0700 Subject: RFR: 8185756: JShell has broken links in its documentation In-Reply-To: <15daf671638.2794.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <5984E397.5070409@oracle.com> <15daf671638.2794.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: <5984F8B6.2000404@oracle.com> Thanks; pushed. -- Jon On 08/04/2017 03:39 PM, Robert Field wrote: > Thumbs up! > > -Robert (a guy who hasn't returned to work yet) > > > > On August 4, 2017 2:14:08 PM Jonathan Gibbons > wrote: > >> Please review the following minor fixes for some broken links in the >> JShell API documentation. >> >> In all cases, a @link to a method needs to specify the parameter list, >> because of the existence of a like-named field, albeit one with private >> access. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8185756 >> Webrev: http://cr.openjdk.java.net/~jjg/8185756/webrev.00/ >> >> -- Jon > > From sundararajan.athijegannathan at oracle.com Sat Aug 5 01:13:44 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 04 Aug 2017 18:13:44 -0700 Subject: RFR: 8185756: JShell has broken links in its documentation In-Reply-To: <5984E397.5070409@oracle.com> References: <5984E397.5070409@oracle.com> Message-ID: <59851BC8.6060702@oracle.com> +1 -Sundar On 04/08/17, 2:13 PM, Jonathan Gibbons wrote: > Please review the following minor fixes for some broken links in the > JShell API documentation. > > In all cases, a @link to a method needs to specify the parameter list, > because of the existence of a like-named field, albeit one with > private access. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185756 > Webrev: http://cr.openjdk.java.net/~jjg/8185756/webrev.00/ > > -- Jon From rfscholte at apache.org Mon Aug 14 20:24:25 2017 From: rfscholte at apache.org (Robert Scholte) Date: Mon, 14 Aug 2017 22:24:25 +0200 Subject: Performance / JShell lightweight Message-ID: Hi, I've started a library which has the ability to divide a set of jars and output directories over the classpath and modulepath. In order to get the modulename it calls the Java 9 code for retrieving that name, i.e. via ModuleFinder. In case the library runs on Java 9, it can call the ModuleFinder directly. But in case the library runs on Java 7 or Java 8, it requires a reference to the Java 9 home. With JShell it has become very easy to execute this code, otherwise I need to have an executable-jar at runtime, put is somewhere where I can call it. However, this call to JShell takes several seconds to resolve, which feels quite long. I'm looking for a way to reduce this time. I'm not interested in interaction with JShell, only interested in the output. (in the end it is almost as simple as a main method with System.out.println("Hello World"); ) If the startup overhead is caused by building up the shell, can there be an option introduced to just execute code without interactive shell (and auto-exit at the end)? thanks, Robert From forax at univ-mlv.fr Mon Aug 14 20:33:11 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 14 Aug 2017 22:33:11 +0200 (CEST) Subject: Performance / JShell lightweight In-Reply-To: References: Message-ID: <1244866705.77161.1502742791644.JavaMail.zimbra@u-pem.fr> Hi Robert, It's due to the fact that by default JShell starts a new VM (the remote VM) that will execute the code, if you just want to run the code, i think there is a way to run the script inside the same VM. I will let the other Robert (Field) or anyone on this list explain how to do this, i'm also interested by the answer (and the auto-exit at the end). cheers, R?mi ----- Mail original ----- > De: "Robert Scholte" > ?: kulla-dev at openjdk.java.net > Envoy?: Lundi 14 Ao?t 2017 22:24:25 > Objet: Performance / JShell lightweight > Hi, > > I've started a library which has the ability to divide a set of jars and > output directories over the classpath and modulepath. In order to get the > modulename it calls the Java 9 code for retrieving that name, i.e. via > ModuleFinder. > In case the library runs on Java 9, it can call the ModuleFinder directly. > But in case the library runs on Java 7 or Java 8, it requires a reference > to the Java 9 home. > With JShell it has become very easy to execute this code, otherwise I need > to have an executable-jar at runtime, put is somewhere where I can call it. > > However, this call to JShell takes several seconds to resolve, which feels > quite long. I'm looking for a way to reduce this time. > > I'm not interested in interaction with JShell, only interested in the > output. (in the end it is almost as simple as a main method with > System.out.println("Hello World"); ) > > If the startup overhead is caused by building up the shell, can there be > an option introduced to just execute code without interactive shell (and > auto-exit at the end)? > > thanks, > Robert From robert.field at oracle.com Mon Aug 14 21:27:05 2017 From: robert.field at oracle.com (Robert Field) Date: Mon, 14 Aug 2017 14:27:05 -0700 Subject: Performance / JShell lightweight In-Reply-To: <1244866705.77161.1502742791644.JavaMail.zimbra@u-pem.fr> References: <1244866705.77161.1502742791644.JavaMail.zimbra@u-pem.fr> Message-ID: <599215A9.9010607@oracle.com> Yes, most of the time is spent in launching/setting-up the remote VM. You can get local execution with: jshell --execution local This has downsides, for example if the executed code crashes/exits, so does the shell. This is kinda documented in: jshell -X and the SPI/API: http://download.java.net/java/jdk9/docs/api/jdk/jshell/spi/package-summary.html http://download.java.net/java/jdk9/docs/api/jdk/jshell/execution/package-summary.html As to exiting a script, in general, simply use the "exit" command. -Robert On 08/14/17 13:33, Remi Forax wrote: > Hi Robert, > > It's due to the fact that by default JShell starts a new VM (the remote VM) that will execute the code, > if you just want to run the code, i think there is a way to run the script inside the same VM. > > I will let the other Robert (Field) or anyone on this list explain how to do this, > i'm also interested by the answer (and the auto-exit at the end). > > cheers, > R?mi > > ----- Mail original ----- >> De: "Robert Scholte" >> ?: kulla-dev at openjdk.java.net >> Envoy?: Lundi 14 Ao?t 2017 22:24:25 >> Objet: Performance / JShell lightweight >> Hi, >> >> I've started a library which has the ability to divide a set of jars and >> output directories over the classpath and modulepath. In order to get the >> modulename it calls the Java 9 code for retrieving that name, i.e. via >> ModuleFinder. >> In case the library runs on Java 9, it can call the ModuleFinder directly. >> But in case the library runs on Java 7 or Java 8, it requires a reference >> to the Java 9 home. >> With JShell it has become very easy to execute this code, otherwise I need >> to have an executable-jar at runtime, put is somewhere where I can call it. >> >> However, this call to JShell takes several seconds to resolve, which feels >> quite long. I'm looking for a way to reduce this time. >> >> I'm not interested in interaction with JShell, only interested in the >> output. (in the end it is almost as simple as a main method with >> System.out.println("Hello World"); ) >> >> If the startup overhead is caused by building up the shell, can there be >> an option introduced to just execute code without interactive shell (and >> auto-exit at the end)? >> >> thanks, >> Robert From sormuras at gmail.com Tue Aug 15 08:20:47 2017 From: sormuras at gmail.com (Christian Stein) Date: Tue, 15 Aug 2017 10:20:47 +0200 Subject: Example for "/exit 1" requested in JDK-8185840 Message-ID: See http://mail.openjdk.java.net/pipermail/kulla-dev/2017-June/002031.html for example of a "/exit 1" as requested in https://bugs.openjdk.java.net/browse/JDK-8185840 Cheers, Christian PS: I'd love to comment on https://bugs.openjdk.java.net/browse/JDK-8185840 directly, but the login does not work for me. From sormuras at gmail.com Tue Aug 15 09:39:13 2017 From: sormuras at gmail.com (Christian Stein) Date: Tue, 15 Aug 2017 11:39:13 +0200 Subject: Performance / JShell lightweight In-Reply-To: <599215A9.9010607@oracle.com> References: <1244866705.77161.1502742791644.JavaMail.zimbra@u-pem.fr> <599215A9.9010607@oracle.com> Message-ID: Slightly off-topic, but related: That local execution mode allows to "/exit 1" via "System.exit(1)". Like wished/requested here http://mail.openjdk.java. net/pipermail/kulla-dev/2017-August/002063.html Little proof of concept runnig on a DOS shell: jshell --execution local | Welcome to JShell -- Version 9 | For an introduction type: /help intro jshell> System.exit(123) echo Exit Code is %errorlevel% Exit Code is 123 On Mon, Aug 14, 2017 at 11:27 PM, Robert Field wrote: > Yes, most of the time is spent in launching/setting-up the remote VM. > > You can get local execution with: > > jshell --execution local > > This has downsides, for example if the executed code crashes/exits, so > does the shell. > > This is kinda documented in: > > jshell -X > > and the SPI/API: > > http://download.java.net/java/jdk9/docs/api/jdk/jshell/spi/p > ackage-summary.html > http://download.java.net/java/jdk9/docs/api/jdk/jshell/execu > tion/package-summary.html > > As to exiting a script, in general, simply use the "exit" command. > > -Robert > > > On 08/14/17 13:33, Remi Forax wrote: > >> Hi Robert, >> >> It's due to the fact that by default JShell starts a new VM (the remote >> VM) that will execute the code, >> if you just want to run the code, i think there is a way to run the >> script inside the same VM. >> >> I will let the other Robert (Field) or anyone on this list explain how to >> do this, >> i'm also interested by the answer (and the auto-exit at the end). >> >> cheers, >> R?mi >> >> ----- Mail original ----- >> >>> De: "Robert Scholte" >>> ?: kulla-dev at openjdk.java.net >>> Envoy?: Lundi 14 Ao?t 2017 22:24:25 >>> Objet: Performance / JShell lightweight >>> Hi, >>> >>> I've started a library which has the ability to divide a set of jars and >>> output directories over the classpath and modulepath. In order to get the >>> modulename it calls the Java 9 code for retrieving that name, i.e. via >>> ModuleFinder. >>> In case the library runs on Java 9, it can call the ModuleFinder >>> directly. >>> But in case the library runs on Java 7 or Java 8, it requires a reference >>> to the Java 9 home. >>> With JShell it has become very easy to execute this code, otherwise I >>> need >>> to have an executable-jar at runtime, put is somewhere where I can call >>> it. >>> >>> However, this call to JShell takes several seconds to resolve, which >>> feels >>> quite long. I'm looking for a way to reduce this time. >>> >>> I'm not interested in interaction with JShell, only interested in the >>> output. (in the end it is almost as simple as a main method with >>> System.out.println("Hello World"); ) >>> >>> If the startup overhead is caused by building up the shell, can there be >>> an option introduced to just execute code without interactive shell (and >>> auto-exit at the end)? >>> >>> thanks, >>> Robert >>> >> > From robert.field at oracle.com Tue Aug 15 15:40:33 2017 From: robert.field at oracle.com (Robert Field) Date: Tue, 15 Aug 2017 08:40:33 -0700 Subject: Example for "/exit 1" requested in JDK-8185840 In-Reply-To: References: Message-ID: <15de68db568.2794.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> What I was looking for was: if we implemented "/exit 1", show an example of how it would be used (given that commands can not be conditionally controlled). Robert On August 15, 2017 1:20:57 AM Christian Stein wrote: > See http://mail.openjdk.java.net/pipermail/kulla-dev/2017-June/002031.html > for example of a "/exit 1" as requested in > https://bugs.openjdk.java.net/browse/JDK-8185840 > > Cheers, > Christian > > PS: I'd love to comment on https://bugs.openjdk.java.net/browse/JDK-8185840 > directly, but the login does not work for me. From sormuras at gmail.com Tue Aug 15 15:42:34 2017 From: sormuras at gmail.com (Christian Stein) Date: Tue, 15 Aug 2017 17:42:34 +0200 Subject: Example for "/exit 1" requested in JDK-8185840 In-Reply-To: <15de68db568.2794.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <15de68db568.2794.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: What about a variable? int code = Random.nextInt() /exit code On Tue, Aug 15, 2017 at 5:40 PM, Robert Field wrote: > What I was looking for was: if we implemented "/exit 1", show an example > of how it would be used (given that commands can not be conditionally > controlled). > > Robert > > > > > On August 15, 2017 1:20:57 AM Christian Stein wrote: > > See http://mail.openjdk.java.net/pipermail/kulla-dev/2017-June/002031.html >> for example of a "/exit 1" as requested in >> https://bugs.openjdk.java.net/browse/JDK-8185840 >> >> Cheers, >> Christian >> >> PS: I'd love to comment on https://bugs.openjdk.java.net/ >> browse/JDK-8185840 >> directly, but the login does not work for me. >> > > > From rfscholte at apache.org Tue Aug 15 18:34:13 2017 From: rfscholte at apache.org (Robert Scholte) Date: Tue, 15 Aug 2017 20:34:13 +0200 Subject: Performance / JShell lightweight In-Reply-To: <599215A9.9010607@oracle.com> References: <1244866705.77161.1502742791644.JavaMail.zimbra@u-pem.fr> <599215A9.9010607@oracle.com> Message-ID: So yes, I end my script with /exit When I run "jshell --execution local myscript.jsh" the script is just a startup script, the shell is still initialized, even though I end my script with /exit Only because of the relatively long time to execute this script I am looking for a faster solution. One thing that comes to my mind is something like "jshell --execution batch myscript.jsh", which will never enter the shell, but simply executes the script and stops. This assumes that the initialization of the shell itself is also part of the time penalty. I still like it that JShell gives me quite a nice way to execute Java 9 code while I'm actually running on an older JRE. thanks, Robert On Mon, 14 Aug 2017 23:27:05 +0200, Robert Field wrote: > Yes, most of the time is spent in launching/setting-up the remote VM. > > You can get local execution with: > > jshell --execution local > > This has downsides, for example if the executed code crashes/exits, so > does the shell. > > This is kinda documented in: > > jshell -X > > and the SPI/API: > > http://download.java.net/java/jdk9/docs/api/jdk/jshell/spi/package-summary.html > http://download.java.net/java/jdk9/docs/api/jdk/jshell/execution/package-summary.html > > As to exiting a script, in general, simply use the "exit" command. > > -Robert > > On 08/14/17 13:33, Remi Forax wrote: >> Hi Robert, >> >> It's due to the fact that by default JShell starts a new VM (the remote >> VM) that will execute the code, >> if you just want to run the code, i think there is a way to run the >> script inside the same VM. >> >> I will let the other Robert (Field) or anyone on this list explain how >> to do this, >> i'm also interested by the answer (and the auto-exit at the end). >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "Robert Scholte" >>> ?: kulla-dev at openjdk.java.net >>> Envoy?: Lundi 14 Ao?t 2017 22:24:25 >>> Objet: Performance / JShell lightweight >>> Hi, >>> >>> I've started a library which has the ability to divide a set of jars >>> and >>> output directories over the classpath and modulepath. In order to get >>> the >>> modulename it calls the Java 9 code for retrieving that name, i.e. via >>> ModuleFinder. >>> In case the library runs on Java 9, it can call the ModuleFinder >>> directly. >>> But in case the library runs on Java 7 or Java 8, it requires a >>> reference >>> to the Java 9 home. >>> With JShell it has become very easy to execute this code, otherwise I >>> need >>> to have an executable-jar at runtime, put is somewhere where I can >>> call it. >>> >>> However, this call to JShell takes several seconds to resolve, which >>> feels >>> quite long. I'm looking for a way to reduce this time. >>> >>> I'm not interested in interaction with JShell, only interested in the >>> output. (in the end it is almost as simple as a main method with >>> System.out.println("Hello World"); ) >>> >>> If the startup overhead is caused by building up the shell, can there >>> be >>> an option introduced to just execute code without interactive shell >>> (and >>> auto-exit at the end)? >>> >>> thanks, >>> Robert From sormuras at gmail.com Tue Aug 15 18:48:48 2017 From: sormuras at gmail.com (Christian Stein) Date: Tue, 15 Aug 2017 20:48:48 +0200 Subject: Performance / JShell lightweight In-Reply-To: References: <1244866705.77161.1502742791644.JavaMail.zimbra@u-pem.fr> <599215A9.9010607@oracle.com> Message-ID: On Tue, Aug 15, 2017 at 8:34 PM, Robert Scholte wrote: > So yes, I end my script with /exit > > When I run "jshell --execution local myscript.jsh" the script is just a > startup script, the shell is still initialized, even though I end my script > with /exit > > Only because of the relatively long time to execute this script I am > looking for a faster solution. > One thing that comes to my mind is something like "jshell --execution > batch myscript.jsh", which will never enter the shell, but simply executes > the script and stops. > This assumes that the initialization of the shell itself is also part of > the time penalty. > > Interesting idea, indeed. Could need this for "forax/pro" and "sormuras/bach" too. But I guess, that falls into the same "hack" category as the missing "shebang" support. See this comment by Brian Goetz: "More generally, "hacks" like this always come back to bite you. What you want is a "no main, no compile java runner". Jshell looks like that, but it isn't. When you have nothing, a little of something seems like a really good idea; but the warts will become apparent almost immediately. I'd much rather do nothing for this now, and consider doing something better in the future, than doing something bad now -- which is what this would be." http://mail.openjdk.java.net/pipermail/kulla-dev/2016-October/001689.html From rfscholte at apache.org Tue Aug 15 19:12:29 2017 From: rfscholte at apache.org (Robert Scholte) Date: Tue, 15 Aug 2017 21:12:29 +0200 Subject: Performance / JShell lightweight In-Reply-To: References: <1244866705.77161.1502742791644.JavaMail.zimbra@u-pem.fr> <599215A9.9010607@oracle.com> Message-ID: They look quite the same, but I think there are subtle differences. What would be the alternative for me? At runtime copying a class from my jar to a temp location and then running it with java -cp . Main @args? You could wonder what is more hacky ;) The introduction of JShell looked like a nice opportunity to bridge this Java 9 issue. best, Robert On Tue, 15 Aug 2017 20:48:48 +0200, Christian Stein wrote: > On Tue, Aug 15, 2017 at 8:34 PM, Robert Scholte > wrote: > >> So yes, I end my script with /exit >> >> When I run "jshell --execution local myscript.jsh" the script is just a >> startup script, the shell is still initialized, even though I end my >> script >> with /exit >> >> Only because of the relatively long time to execute this script I am >> looking for a faster solution. >> One thing that comes to my mind is something like "jshell --execution >> batch myscript.jsh", which will never enter the shell, but simply >> executes >> the script and stops. >> This assumes that the initialization of the shell itself is also part of >> the time penalty. >> >> > > Interesting idea, indeed. Could need this for "forax/pro" and > "sormuras/bach" too. > But I guess, that falls into the same "hack" category as the missing > "shebang" > support. See this comment by Brian Goetz: > > "More generally, "hacks" like this always come back to bite you. What > you > want is a "no main, no compile java runner". Jshell looks like that, but > it isn't. > When you have nothing, a little of something seems like a really good > idea; > but the warts will become apparent almost immediately. I'd much rather > do > nothing for this now, and consider doing something better in the future, > than > doing something bad now -- which is what this would be." > > http://mail.openjdk.java.net/pipermail/kulla-dev/2016-October/001689.html From robert.field at oracle.com Wed Aug 16 17:48:23 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 16 Aug 2017 10:48:23 -0700 Subject: RFR: 8182297: jshell tool: pasting multiple lines of code truncated In-Reply-To: <5952A07C.2080901@oracle.com> References: <5952A07C.2080901@oracle.com> Message-ID: <59948567.1040008@oracle.com> Thumbs up! -Robert On 06/27/17 11:14, Jan Lahoda wrote: > Hi, > > Currently, when pasting multiple lines into JShell, only the first two > lines are used. > > The cause is that when > jdk.internal.jline.console.ConsoleReader.readLine, we need to read the > cursor position. This is e.g. to avoid backspacing into the prompt. I > believe standard JLine is solving this by determining the length of > the prompt, but that does not work well for JShell, as the prompt is > not always known (e.g. when using System.in). > > So, there's a code to query the cursor position - this is done by > writing a query to the terminal and reading the answer from the > standard input. > > But if there's something in the standard input before the answer, it > needs to be read as well. So, this is read and stored in a > queue/stack, but the problem is that the stack is a local variable in > the readLine method. So only one line of the input is used and the > rest is dropped. The reason why two lines are used after paste is that > the above happens for the second pasted line; the measurements for the > first line are usually already done for the first line, which is not > so affected. > > The proposed solution is to store the todo stack in a field. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8182297 > > Webrev: > jdk repository: > http://cr.openjdk.java.net/~jlahoda/8182297/jdk.00/ > langtools repository (test): > http://cr.openjdk.java.net/~jlahoda/8182297/langtools.00/ > > Thanks, > Jan From robert.field at oracle.com Thu Aug 17 00:18:12 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 16 Aug 2017 17:18:12 -0700 Subject: RFR: JDK-8185426: Jshell crashing on autocompletion In-Reply-To: <597B4DF9.8020407@oracle.com> References: <597B4DF9.8020407@oracle.com> Message-ID: <5994E0C4.4080400@oracle.com> On 07/28/17 07:45, Jan Lahoda wrote: > I'd like to ask for a review of a fix for bug: > https://bugs.openjdk.java.net/browse/JDK-8185426 > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8185426/webrev.00/ > > The problem here is that: jshell has a stateful completion, pressing > several times will produce different outputs. The state of the > completion is currently reset when the user performs action different > than "COMPLETE" as determined by KeyMap. Sadly, even if the action is > COMPLETE, JLine may (if there are further characters in the input) > decide it won't perform the complete action, rather print the tab > character. See: > http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/0861f2298fd7/src/jdk.internal.le/share/classes/jdk/internal/jline/console/ConsoleReader.java#l2669 > > > This then can lead to the problem, as the completion may be using the > stale state. > > So the patch is trying to ensure the completion state is reset if > complete is not called: the state is reset always, and the complete > method will restore it if needed. > > How does this look? > > Thanks, > Jan The change makes ConsoleIOContext public, adds two static fields and embeds some test-specific code to the class. This complicates the class and mixes it with test code. I think it would be better to add a public test access class, which holds these statics and the test-specific code. You would still need a simple hook to get to this test support. Nit: the initialization of todo (line 252) is placed after a comment that does not document it -- they should be switched. The meanings, invariants, and transitions of the new CompletionState fields should be documented. In general, ConsoleIOContext should be documented. The one existing comment (on the ConsoleIOContext.complete() method) needs update. -Robert From robert.field at oracle.com Thu Aug 17 01:43:57 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 16 Aug 2017 18:43:57 -0700 Subject: RFR 8182270: JShell API: snippet information / 8166334: jshell tool: shortcut: expression/statement to method In-Reply-To: <594D3E2F.5090706@oracle.com> References: <59437729.6040108@oracle.com> <5949DA24.8000109@oracle.com> <594D3E2F.5090706@oracle.com> Message-ID: <5994F4DD.5020400@oracle.com> Thanks for the review. Typo fixed. CSR approved while I out. Pushed to 10. -Robert On 06/23/17 09:13, Jan Lahoda wrote: > Typo: > ToolShiftTabTest.java: > @summary test shift-tab shortcuts "fixs" > => > @summary test shift-tab shortcuts "fixes" > > Otherwise looks good. > > Jan > > On 21.6.2017 04:29, Robert Field wrote: >> Please review: Adds new shift-tab-m shortcut for converting expressions >> or statements into methods. And adds to the JShell API, non-evaluative >> Snippet information access, required the new tool functionality, and >> generally useful for analyzing source snippets before evaluation. >> >> Update... >> >> With input from Jan, added direct UI level tests of, not only the new >> shift-tab-m functionality, but, of all shift-tab functionality. >> >> Fixed an obscure issue of temp variable numbering after ctrl-C'ing a >> shift-tab-m. >> >> >> On 06/15/17 23:14, Robert Field wrote: >>> Please review -- >>> >>> Bugs: >>> >>> JShell API: Tools need snippet information without evaluating >>> snippet >>> https://bugs.openjdk.java.net/browse/JDK-8182270 >>> >>> jshell tool: shortcut: expression/statement to method >>> https://bugs.openjdk.java.net/browse/JDK-8166334 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8182270v0.webrev/ >>> >>> Thanks, >>> Robert >>> >> From robert.field at oracle.com Sat Aug 19 00:00:47 2017 From: robert.field at oracle.com (Robert Field) Date: Fri, 18 Aug 2017 17:00:47 -0700 Subject: RFR 8185108: JShell: NullPointerException when throwing exception with null message under local ExecutionControl Message-ID: <59977FAF.7040109@oracle.com> Please review fixes to handling of SnippetEvent.exception().getMessage() Bug: https://bugs.openjdk.java.net/browse/JDK-8185108 Webrev: http://cr.openjdk.java.net/~rfield/8185108v0.webrev/ Issues addressed -- (1) Original issue: using API and DirectExecutionControl (which was not intended for direct use), user exceptions with no message (null message) crashes eval() (2) Like (1) above with LocalExecutionControlProvider (which is intended for direct use) (3) Because of (2), "jshell --execution local" crashes with the input "throw new java.io.IOException();" (4) Under default ExecutionControl, exceptions with null messages actually return an empty string message in the API. (5) Because of (4), the default configuration of the jshell tool displays a colon that it shouldn't for "throw new java.io.IOException();" (6) Handling of the streaming representation of a null message was being handled in the jdk.jshell package (Eval.java) whereas it should be handled in the streaming ExecutionControl support. (7) The poorly placed implementation of (6) was out-of-sync with the behavior of the streaming ExecutionControl support, being the immediate cause of (4) From jonathan.gibbons at oracle.com Sat Aug 19 00:18:31 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 18 Aug 2017 17:18:31 -0700 Subject: small HTML issue Message-ID: <599783D7.2040109@oracle.com> The "

" in the following text, at about line 156 in SourceCodeAnalysis.java is redundant, and shows up in reports by "tidy" on the generated docs. * Only preliminary compilation is performed, sufficient to build the * {@code Snippet}. Snippets known to be erroneous, are returned as * {@link ErroneousSnippet}, other snippets may or may not be in error. *

* @param input The input String to convert * @return usually a singleton list of Snippet, but may be empty or multiple * @throws IllegalStateException if the {@code JShell} instance is closed. The

should be deleted. As a general rule, only use

at the beginning of a paragraph, when it is immediately followed by text to appear in that paragraph. Don't use

at the end of a paragraph or before block tags. -- Jon From robert.field at oracle.com Sat Aug 19 00:58:48 2017 From: robert.field at oracle.com (Robert Field) Date: Fri, 18 Aug 2017 17:58:48 -0700 Subject: small HTML issue In-Reply-To: <599783D7.2040109@oracle.com> References: <599783D7.2040109@oracle.com> Message-ID: <59978D48.4060204@oracle.com> I've created: https://bugs.openjdk.java.net/browse/JDK-8186475 -Robert On 08/18/17 17:18, Jonathan Gibbons wrote: > The "

" in the following text, at about line 156 in > SourceCodeAnalysis.java is redundant, > and shows up in reports by "tidy" on the generated docs. > > > * Only preliminary compilation is performed, sufficient to build the > * {@code Snippet}. Snippets known to be erroneous, are returned as > * {@link ErroneousSnippet}, other snippets may or may not be in > error. > *

> * @param input The input String to convert > * @return usually a singleton list of Snippet, but may be empty > or multiple > * @throws IllegalStateException if the {@code JShell} instance is > closed. > > The

should be deleted. > > As a general rule, only use

at the beginning of a paragraph, when > it is immediately > followed by text to appear in that paragraph. > > Don't use

at the end of a paragraph or before block tags. > > -- Jon From robert.field at oracle.com Mon Aug 21 01:42:04 2017 From: robert.field at oracle.com (Robert Field) Date: Sun, 20 Aug 2017 18:42:04 -0700 Subject: RFR (xxs)8186475: JShell API: remove trailing HTML paragraph tag Message-ID: <599A3A6C.60501@oracle.com> Please doc clean-up --- Bug: https://bugs.openjdk.java.net/browse/JDK-8186475 Webrev: http://cr.openjdk.java.net/~rfield/8186475v0.webrev/ -Robert P.S. Or, probably easier, the diff.... diff -r 76066b4d5a9b src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java --- a/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java Fri Aug 18 04:37:00 2017 +0000 +++ b/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java Sun Aug 20 18:26:37 2017 -0700 @@ -153,7 +153,7 @@ * Only preliminary compilation is performed, sufficient to build the * {@code Snippet}. Snippets known to be erroneous, are returned as * {@link ErroneousSnippet}, other snippets may or may not be in error. - *

+ * * @param input The input String to convert * @return usually a singleton list of Snippet, but may be empty or multiple * @throws IllegalStateException if the {@code JShell} instance is closed. From jan.lahoda at oracle.com Mon Aug 21 15:04:50 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 21 Aug 2017 17:04:50 +0200 Subject: RFR (xxs)8186475: JShell API: remove trailing HTML paragraph tag In-Reply-To: <599A3A6C.60501@oracle.com> References: <599A3A6C.60501@oracle.com> Message-ID: <599AF692.9010809@oracle.com> Seems OK. Jan On 21.8.2017 03:42, Robert Field wrote: > Please doc clean-up --- > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8186475 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8186475v0.webrev/ > > -Robert > > P.S. Or, probably easier, the diff.... > > diff -r 76066b4d5a9b > src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java > --- a/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java > Fri Aug 18 04:37:00 2017 +0000 > +++ b/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java > Sun Aug 20 18:26:37 2017 -0700 > @@ -153,7 +153,7 @@ > * Only preliminary compilation is performed, sufficient to build the > * {@code Snippet}. Snippets known to be erroneous, are returned as > * {@link ErroneousSnippet}, other snippets may or may not be in > error. > - *

> + * > * @param input The input String to convert > * @return usually a singleton list of Snippet, but may be empty > or multiple > * @throws IllegalStateException if the {@code JShell} instance is > closed. From robert.field at oracle.com Wed Aug 23 04:05:30 2017 From: robert.field at oracle.com (Robert Field) Date: Tue, 22 Aug 2017 21:05:30 -0700 Subject: RFR 8186636: JShell tests: jtreg_4.2-b08 breaks ComputeFQNsTest.testAddImport() Message-ID: <599CFF0A.9090908@oracle.com> Please review fix for test failure -- Bug: https://bugs.openjdk.java.net/browse/JDK-8186636 Webrev: http://cr.openjdk.java.net/~rfield/8186636v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Wed Aug 23 05:01:18 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 23 Aug 2017 07:01:18 +0200 Subject: RFR 8186636: JShell tests: jtreg_4.2-b08 breaks ComputeFQNsTest.testAddImport() In-Reply-To: <599CFF0A.9090908@oracle.com> References: <599CFF0A.9090908@oracle.com> Message-ID: <599D0C1E.3020407@oracle.com> Seems good. Jan On 23.8.2017 06:05, Robert Field wrote: > Please review fix for test failure -- > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8186636 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8186636v0.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Wed Aug 23 19:42:04 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 23 Aug 2017 21:42:04 +0200 Subject: RFR 8185108: JShell: NullPointerException when throwing exception with null message under local ExecutionControl In-Reply-To: <59977FAF.7040109@oracle.com> References: <59977FAF.7040109@oracle.com> Message-ID: <599DDA8C.9090503@oracle.com> Overall, looks OK. I wonder if we can send a marker bit (null/non-null) optionally followed by the UTF String instead of a marker UTF/text? Thanks, Jan On 19.8.2017 02:00, Robert Field wrote: > Please review fixes to handling of SnippetEvent.exception().getMessage() > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8185108 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8185108v0.webrev/ > > Issues addressed -- > > (1) Original issue: using API and DirectExecutionControl (which was not > intended for direct use), user exceptions with no message (null message) > crashes eval() > > (2) Like (1) above with LocalExecutionControlProvider (which is intended > for direct use) > > (3) Because of (2), "jshell --execution local" crashes with the input > "throw new java.io.IOException();" > > (4) Under default ExecutionControl, exceptions with null messages > actually return an empty string message in the API. > > (5) Because of (4), the default configuration of the jshell tool > displays a colon that it shouldn't for "throw new java.io.IOException();" > > (6) Handling of the streaming representation of a null message was being > handled in the jdk.jshell package (Eval.java) whereas it should be > handled in the streaming ExecutionControl support. > > (7) The poorly placed implementation of (6) was out-of-sync with the > behavior of the streaming ExecutionControl support, being the immediate > cause of (4) > > From robert.field at oracle.com Wed Aug 23 20:28:42 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 23 Aug 2017 13:28:42 -0700 Subject: RFR 8185108: JShell: NullPointerException when throwing exception with null message under local ExecutionControl In-Reply-To: <599DDA8C.9090503@oracle.com> References: <59977FAF.7040109@oracle.com> <599DDA8C.9090503@oracle.com> Message-ID: <599DE57A.6050401@oracle.com> On 08/23/17 12:42, Jan Lahoda wrote: > Overall, looks OK. > > I wonder if we can send a marker bit (null/non-null) optionally > followed by the UTF String instead of a marker UTF/text? That would be cleaner, but I choose not to do that as it would make the protocol incompatible between 9 and 10. Thanks, Robert > > Thanks, > Jan > > On 19.8.2017 02:00, Robert Field wrote: >> Please review fixes to handling of SnippetEvent.exception().getMessage() >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8185108 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8185108v0.webrev/ >> >> Issues addressed -- >> >> (1) Original issue: using API and DirectExecutionControl (which was not >> intended for direct use), user exceptions with no message (null message) >> crashes eval() >> >> (2) Like (1) above with LocalExecutionControlProvider (which is intended >> for direct use) >> >> (3) Because of (2), "jshell --execution local" crashes with the input >> "throw new java.io.IOException();" >> >> (4) Under default ExecutionControl, exceptions with null messages >> actually return an empty string message in the API. >> >> (5) Because of (4), the default configuration of the jshell tool >> displays a colon that it shouldn't for "throw new >> java.io.IOException();" >> >> (6) Handling of the streaming representation of a null message was being >> handled in the jdk.jshell package (Eval.java) whereas it should be >> handled in the streaming ExecutionControl support. >> >> (7) The poorly placed implementation of (6) was out-of-sync with the >> behavior of the streaming ExecutionControl support, being the immediate >> cause of (4) >> >> From robert.field at oracle.com Thu Aug 24 04:35:39 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 23 Aug 2017 21:35:39 -0700 Subject: RFR 8179856: jshell tool: not suitable for pipeline use Message-ID: <599E579B.1020900@oracle.com> Please review -- Bugs: 8179856: jshell tool: not suitable for pipeline use https://bugs.openjdk.java.net/browse/JDK-8179856 8186708: jshell tool: bad load file garbles message and does not abort https://bugs.openjdk.java.net/browse/JDK-8186708 Webrev: http://cr.openjdk.java.net/~rfield/8179856v1.webrev/ Thanks, Robert From jan.lahoda at oracle.com Thu Aug 24 10:40:05 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 24 Aug 2017 12:40:05 +0200 Subject: RFR: JDK-8185426: Jshell crashing on autocompletion In-Reply-To: <5994E0C4.4080400@oracle.com> References: <597B4DF9.8020407@oracle.com> <5994E0C4.4080400@oracle.com> Message-ID: <599EAD05.4090402@oracle.com> Thanks for the comments. An updated webrev is here: http://cr.openjdk.java.net/~jlahoda/8185426/webrev.01/ Thanks, Jan On 17.8.2017 02:18, Robert Field wrote: > > On 07/28/17 07:45, Jan Lahoda wrote: >> I'd like to ask for a review of a fix for bug: >> https://bugs.openjdk.java.net/browse/JDK-8185426 >> >> Proposed webrev: >> http://cr.openjdk.java.net/~jlahoda/8185426/webrev.00/ >> >> The problem here is that: jshell has a stateful completion, pressing >> several times will produce different outputs. The state of the >> completion is currently reset when the user performs action different >> than "COMPLETE" as determined by KeyMap. Sadly, even if the action is >> COMPLETE, JLine may (if there are further characters in the input) >> decide it won't perform the complete action, rather print the tab >> character. See: >> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/0861f2298fd7/src/jdk.internal.le/share/classes/jdk/internal/jline/console/ConsoleReader.java#l2669 >> >> >> This then can lead to the problem, as the completion may be using the >> stale state. >> >> So the patch is trying to ensure the completion state is reset if >> complete is not called: the state is reset always, and the complete >> method will restore it if needed. >> >> How does this look? >> >> Thanks, >> Jan > > The change makes ConsoleIOContext public, adds two static fields and > embeds some test-specific code to the class. This complicates the class > and mixes it with test code. > I think it would be better to add a public test access class, which > holds these statics and the test-specific code. You would still need a > simple hook to get to this test support. > > Nit: the initialization of todo (line 252) is placed after a comment > that does not document it -- they should be switched. > > The meanings, invariants, and transitions of the new CompletionState > fields should be documented. In general, ConsoleIOContext should be > documented. The one existing comment (on the > ConsoleIOContext.complete() method) needs update. > > -Robert > > From nazzareno.sileno at gmail.com Thu Aug 24 16:36:53 2017 From: nazzareno.sileno at gmail.com (Nazzareno Sileno) Date: Thu, 24 Aug 2017 18:36:53 +0200 Subject: Asking help to find tips on JShell source code parsing Message-ID: Hi all, I'm trying to develop an educational tool that uses Jshell as a programming language. The tool must track the source code execution and it must produce commands. Commands are the inputs of the JavaFX 3D engine, they are used to transfer the minimal set of informations needed to reproduce the animations about the running source code. I want to use a consistent metaphor to teach the fundamental concepts about the procedural programming and the object oriented programming. I'm looking for something like a source code parser that I can use to extract informations about the execution flow to fill the commands. In particular I am interested in reproduce every single: declaration of variable, expression evaluation, passing parameters operation, method execution and termination, object creation, control flow statement, input and output stream. Could you suggest a solution to address these issues? The SnippetEvents are not enought to achieve the goal. They do not track every single line of code execution. I need to symulate the source code execution step-by-step. -- Regards Nazzareno Sileno From robert.field at oracle.com Thu Aug 24 17:24:49 2017 From: robert.field at oracle.com (Robert Field) Date: Thu, 24 Aug 2017 10:24:49 -0700 Subject: Asking help to find tips on JShell source code parsing In-Reply-To: References: Message-ID: <15e154666e8.2774.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Hi, Right, Snippets give static information and SnippetEvents give execution results, while, if I am understanding correctly, you are looking for execution tracing. Execution is in compiled code rather than source, although it can be tied back to source. The debugger architecture provides functionality for tracing execution (the same functionality that is used for single step); Search for demos of tracing in JDI (there is one that was one of the original demos). The default execution engine for JShell is built on JDI. The idk.jshell.spi package provides a Service Provider Interface for configuring execution engines. The jdk.jshell.execution package provides execution engines and components. You could start from the default JDI engine and add tracing feeding to your JavaFX animation. Enjoy, Robert On August 24, 2017 9:37:25 AM Nazzareno Sileno wrote: > Hi all, > I'm trying to develop an educational tool that uses Jshell as a programming > language. The tool must track the source code execution and it must produce > commands. Commands are the inputs of the JavaFX 3D engine, they are used to > transfer the minimal set of informations needed to reproduce the animations > about the running source code. I want to use a consistent metaphor to teach > the fundamental concepts about the procedural programming and the object > oriented programming. > I'm looking for something like a source code parser that I can use to > extract informations about the execution flow to fill the commands. In > particular I am interested in reproduce every single: declaration of > variable, expression evaluation, passing parameters operation, method > execution and termination, object creation, control flow statement, input > and output stream. > Could you suggest a solution to address these issues? > > The SnippetEvents are not enought to achieve the goal. They do not track > every single line of code execution. I need to symulate the source code > execution step-by-step. > > > -- > Regards > Nazzareno Sileno From Robert.Field at oracle.com Thu Aug 24 19:04:08 2017 From: Robert.Field at oracle.com (Robert Field) Date: Thu, 24 Aug 2017 12:04:08 -0700 Subject: RFR: JDK-8185426: Jshell crashing on autocompletion In-Reply-To: <599EAD05.4090402@oracle.com> References: <597B4DF9.8020407@oracle.com> <5994E0C4.4080400@oracle.com> <599EAD05.4090402@oracle.com> Message-ID: <45afbb6e-fc9c-aaae-50eb-a700c8f6cf4d@oracle.com> Looks fine. It adds an import for CountDownLatch to ConsoleIOContext.java, which is not longer needed. -Robert On 08/24/2017 03:40 AM, Jan Lahoda wrote: > Thanks for the comments. An updated webrev is here: > http://cr.openjdk.java.net/~jlahoda/8185426/webrev.01/ > > Thanks, > Jan > > On 17.8.2017 02:18, Robert Field wrote: >> >> On 07/28/17 07:45, Jan Lahoda wrote: >>> I'd like to ask for a review of a fix for bug: >>> https://bugs.openjdk.java.net/browse/JDK-8185426 >>> >>> Proposed webrev: >>> http://cr.openjdk.java.net/~jlahoda/8185426/webrev.00/ >>> >>> The problem here is that: jshell has a stateful completion, pressing >>> several times will produce different outputs. The state of the >>> completion is currently reset when the user performs action different >>> than "COMPLETE" as determined by KeyMap. Sadly, even if the action is >>> COMPLETE, JLine may (if there are further characters in the input) >>> decide it won't perform the complete action, rather print the tab >>> character. See: >>> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/0861f2298fd7/src/jdk.internal.le/share/classes/jdk/internal/jline/console/ConsoleReader.java#l2669 >>> >>> >>> >>> This then can lead to the problem, as the completion may be using the >>> stale state. >>> >>> So the patch is trying to ensure the completion state is reset if >>> complete is not called: the state is reset always, and the complete >>> method will restore it if needed. >>> >>> How does this look? >>> >>> Thanks, >>> Jan >> >> The change makes ConsoleIOContext public, adds two static fields and >> embeds some test-specific code to the class. This complicates the class >> and mixes it with test code. >> I think it would be better to add a public test access class, which >> holds these statics and the test-specific code. You would still need a >> simple hook to get to this test support. >> >> Nit: the initialization of todo (line 252) is placed after a comment >> that does not document it -- they should be switched. >> >> The meanings, invariants, and transitions of the new CompletionState >> fields should be documented. In general, ConsoleIOContext should be >> documented. The one existing comment (on the >> ConsoleIOContext.complete() method) needs update. >> >> -Robert >> >> From jan.lahoda at oracle.com Fri Aug 25 11:50:42 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 25 Aug 2017 13:50:42 +0200 Subject: RFR: JDK-8185426: Jshell crashing on autocompletion In-Reply-To: <45afbb6e-fc9c-aaae-50eb-a700c8f6cf4d@oracle.com> References: <597B4DF9.8020407@oracle.com> <5994E0C4.4080400@oracle.com> <599EAD05.4090402@oracle.com> <45afbb6e-fc9c-aaae-50eb-a700c8f6cf4d@oracle.com> Message-ID: <59A00F12.40009@oracle.com> On 24.8.2017 21:04, Robert Field wrote: > Looks fine. Thanks. > > It adds an import for CountDownLatch to ConsoleIOContext.java, which is > not longer needed. Ooops, thanks for noticing. Removed and pushed. Jan > > -Robert > > > On 08/24/2017 03:40 AM, Jan Lahoda wrote: >> Thanks for the comments. An updated webrev is here: >> http://cr.openjdk.java.net/~jlahoda/8185426/webrev.01/ >> >> Thanks, >> Jan >> >> On 17.8.2017 02:18, Robert Field wrote: >>> >>> On 07/28/17 07:45, Jan Lahoda wrote: >>>> I'd like to ask for a review of a fix for bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8185426 >>>> >>>> Proposed webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8185426/webrev.00/ >>>> >>>> The problem here is that: jshell has a stateful completion, pressing >>>> several times will produce different outputs. The state of the >>>> completion is currently reset when the user performs action different >>>> than "COMPLETE" as determined by KeyMap. Sadly, even if the action is >>>> COMPLETE, JLine may (if there are further characters in the input) >>>> decide it won't perform the complete action, rather print the tab >>>> character. See: >>>> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/0861f2298fd7/src/jdk.internal.le/share/classes/jdk/internal/jline/console/ConsoleReader.java#l2669 >>>> >>>> >>>> >>>> This then can lead to the problem, as the completion may be using the >>>> stale state. >>>> >>>> So the patch is trying to ensure the completion state is reset if >>>> complete is not called: the state is reset always, and the complete >>>> method will restore it if needed. >>>> >>>> How does this look? >>>> >>>> Thanks, >>>> Jan >>> >>> The change makes ConsoleIOContext public, adds two static fields and >>> embeds some test-specific code to the class. This complicates the class >>> and mixes it with test code. >>> I think it would be better to add a public test access class, which >>> holds these statics and the test-specific code. You would still need a >>> simple hook to get to this test support. >>> >>> Nit: the initialization of todo (line 252) is placed after a comment >>> that does not document it -- they should be switched. >>> >>> The meanings, invariants, and transitions of the new CompletionState >>> fields should be documented. In general, ConsoleIOContext should be >>> documented. The one existing comment (on the >>> ConsoleIOContext.complete() method) needs update. >>> >>> -Robert >>> >>> > From nazzareno.sileno at gmail.com Tue Aug 29 08:44:41 2017 From: nazzareno.sileno at gmail.com (Nazzareno Sileno) Date: Tue, 29 Aug 2017 10:44:41 +0200 Subject: Asking help to find tips on JShell source code parsing In-Reply-To: <15e154666e8.2774.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <15e154666e8.2774.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: Hi Robert, at first I would say thank you very much for the hints and sorry for the delay in response but this is an activity that I can do in my spare time. I saw your signature in the head of some execution engine source files! I am trying to apply your suggestions. I wrote few lines of code and I am trying to follow the code execution using the Netbeans debugger. I want to analyze the code execution to learn something of usefull to reach my goals. I am using the *JDIExecutionControl *component, it seems that every time a single JShell instruction is executed the method *String invoke(String classname, String methodname)* is called. The *invoke *method sends the invoke command to a remote agent. I have found the JShell test code at this link: http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/65bfdabaab9c/test/jdk/jshell and I am studying it looking for something of usefull. At this moment I am trying to launch a local java debugger instance (*java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y*) to analyze the execution, I want to test the received data input coming from the *JDIExecutionControl *component. The next target should be to write a *JDIExecutonControl *extension class customizing the invoke method. The new method should be capable of produce the command beans. The use of the JDI API should be fundamental in tracking the code execution and catching the desidered elements. Is it right? I downloaded the JDI demo code https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/examples.html looking for existing JDI java code examples as you previously suggested. I must study in deep the *JDIExecutionControl *component's invoke method behaviour. I am not completely aware of the full data set used to send information to the remote JDI and how it can be sufficient to track the source code execution using the *JDI API* For now I would say thank your for your time. Regards 2017-08-24 19:24 GMT+02:00 Robert Field : > Hi, > > Right, Snippets give static information and SnippetEvents give execution > results, while, if I am understanding correctly, you are looking for > execution tracing. Execution is in compiled code rather than source, > although it can be tied back to source. > > The debugger architecture provides functionality for tracing execution > (the same functionality that is used for single step); Search for demos of > tracing in JDI (there is one that was one of the original demos). > > The default execution engine for JShell is built on JDI. The > idk.jshell.spi package provides a Service Provider Interface for > configuring execution engines. The jdk.jshell.execution package provides > execution engines and components. You could start from the default JDI > engine and add tracing feeding to your JavaFX animation. > > Enjoy, > Robert > > > > > On August 24, 2017 9:37:25 AM Nazzareno Sileno > wrote: > > Hi all, >> I'm trying to develop an educational tool that uses Jshell as a >> programming >> language. The tool must track the source code execution and it must >> produce >> commands. Commands are the inputs of the JavaFX 3D engine, they are used >> to >> transfer the minimal set of informations needed to reproduce the >> animations >> about the running source code. I want to use a consistent metaphor to >> teach >> the fundamental concepts about the procedural programming and the object >> oriented programming. >> I'm looking for something like a source code parser that I can use to >> extract informations about the execution flow to fill the commands. In >> particular I am interested in reproduce every single: declaration of >> variable, expression evaluation, passing parameters operation, method >> execution and termination, object creation, control flow statement, input >> and output stream. >> Could you suggest a solution to address these issues? >> >> The SnippetEvents are not enought to achieve the goal. They do not track >> every single line of code execution. I need to symulate the source code >> execution step-by-step. >> >> >> -- >> Regards >> Nazzareno Sileno >> > > > -- Saluti Nazzareno Sileno From jan.lahoda at oracle.com Tue Aug 29 19:58:46 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 29 Aug 2017 21:58:46 +0200 Subject: RFR: JDK-8186694: JShell: speed-up compilation by reusing compiler instances Message-ID: <59A5C776.9090209@oracle.com> Hello, When starting jshell like this (where "/tmp/script" is a file which has just "/exit"): $ jshell PRINTING --execution local /tmp/script It currently takes approx. 5-6s on my laptop. PRINTING will add quite a few startup snippets. Each of these snippets is processed separately and needs several instances of javac to be created to be processed correctly. So, the idea in this patch is to reuse the javac instances multiple (many) times. This avoids initializing the javac instances just to process a very small ("single line") input. This patch is based on the ReusableContext by Maurizio used in tests. The ReusableContext handling is wrapped in JavacTaskPool, which keeps the ReusableContext and issues JavacTask possibly based on a reused Context. The pool is not currently general purpose, but should work for tests for which ReusableContext worked and for JShell. One tricky thing is that in JShell, it is necessary to prune everything in the "REPL" package when reusing the Context, as it is necessary to reload the correct/updated classes again from the file manager (this is achieved by additional cleaning in TaskFactory). Overall, with this patch, the time to execute the above command is approx. 2.5s Bug: https://bugs.openjdk.java.net/browse/JDK-8186694 Webrev: http://cr.openjdk.java.net/~jlahoda/8186694/webrev.00/ How does this look? Thanks, Jan From jonathan.gibbons at oracle.com Tue Aug 29 20:11:41 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 29 Aug 2017 13:11:41 -0700 Subject: RFR: JDK-8186694: JShell: speed-up compilation by reusing compiler instances In-Reply-To: <59A5C776.9090209@oracle.com> References: <59A5C776.9090209@oracle.com> Message-ID: <59A5CA7D.5070304@oracle.com> I don't think JavacTaskPool belongs in the javac.util package. Unless there are good reasons for doing otherwise, how about using javac.api instead ... i..e closed to JavacTaskImpl and friend. -- Jon On 08/29/2017 12:58 PM, Jan Lahoda wrote: > Hello, > > When starting jshell like this (where "/tmp/script" is a file which > has just "/exit"): > $ jshell PRINTING --execution local /tmp/script > > It currently takes approx. 5-6s on my laptop. PRINTING will add quite > a few startup snippets. Each of these snippets is processed separately > and needs several instances of javac to be created to be processed > correctly. > > So, the idea in this patch is to reuse the javac instances multiple > (many) times. This avoids initializing the javac instances just to > process a very small ("single line") input. > > This patch is based on the ReusableContext by Maurizio used in tests. > The ReusableContext handling is wrapped in JavacTaskPool, which keeps > the ReusableContext and issues JavacTask possibly based on a reused > Context. The pool is not currently general purpose, but should work > for tests for which ReusableContext worked and for JShell. > > One tricky thing is that in JShell, it is necessary to prune > everything in the "REPL" package when reusing the Context, as it is > necessary to reload the correct/updated classes again from the file > manager (this is achieved by additional cleaning in TaskFactory). > > Overall, with this patch, the time to execute the above command is > approx. 2.5s > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8186694 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8186694/webrev.00/ > > How does this look? > > Thanks, > Jan From maurizio.cimadamore at oracle.com Wed Aug 30 10:43:11 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 30 Aug 2017 11:43:11 +0100 Subject: RFR: JDK-8186694: JShell: speed-up compilation by reusing compiler instances In-Reply-To: <59A5CA7D.5070304@oracle.com> References: <59A5C776.9090209@oracle.com> <59A5CA7D.5070304@oracle.com> Message-ID: Good work, some comments: * in the combo test API, who is calling returnTask()? * would it make sense to use try with resources for JavacPoolTask and jshell AnalyzeTask, to minimize chances of errors? * not sure about the getTask/returnTask handshake - the logic seems to work in this way: - when a new task is requested, you check the caches, and if a context is there (with given options) you return it, otherwise you create a fresh one - when a task is returned, if it's not polluted, you add it to the caches. Then you need to trim the caches to make sure there's room for the new context We badly miss a circular queue here (not a fault of this patch of course :-)). If we could reduce the state to the options2Context map, then we could probably use a CHM and get rid of synchronized block. Even w/ synchronized map, it seems like 'pool' is only used to get at the first cached context, so maybe a simple field (which you overwrite) might suffice? More generally, I tend to view pair of coupled methods such as getTask/returnTask as suspicious and error prone (in case somebody forgets to call the second method) - so I tend to try to avoid writing such APIs unless absolutely necessary - here I'm not 100% on why this is necessary... on the one hand I get the desire of knowing when a client is done with a task, on the other hand there's nothing stopping the same client from keep using same task after returning it, so... Maurizio On 29/08/17 21:11, Jonathan Gibbons wrote: > I don't think JavacTaskPool belongs in the javac.util package. > > Unless there are good reasons for doing otherwise, how about using > javac.api instead ... i..e closed to JavacTaskImpl and friend. > > -- Jon > > > On 08/29/2017 12:58 PM, Jan Lahoda wrote: >> Hello, >> >> When starting jshell like this (where "/tmp/script" is a file which >> has just "/exit"): >> $ jshell PRINTING --execution local /tmp/script >> >> It currently takes approx. 5-6s on my laptop. PRINTING will add quite >> a few startup snippets. Each of these snippets is processed >> separately and needs several instances of javac to be created to be >> processed correctly. >> >> So, the idea in this patch is to reuse the javac instances multiple >> (many) times. This avoids initializing the javac instances just to >> process a very small ("single line") input. >> >> This patch is based on the ReusableContext by Maurizio used in tests. >> The ReusableContext handling is wrapped in JavacTaskPool, which keeps >> the ReusableContext and issues JavacTask possibly based on a reused >> Context. The pool is not currently general purpose, but should work >> for tests for which ReusableContext worked and for JShell. >> >> One tricky thing is that in JShell, it is necessary to prune >> everything in the "REPL" package when reusing the Context, as it is >> necessary to reload the correct/updated classes again from the file >> manager (this is achieved by additional cleaning in TaskFactory). >> >> Overall, with this patch, the time to execute the above command is >> approx. 2.5s >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8186694 >> >> Webrev: >> http://cr.openjdk.java.net/~jlahoda/8186694/webrev.00/ >> >> How does this look? >> >> Thanks, >> Jan > From jan.lahoda at oracle.com Thu Aug 31 09:14:06 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 31 Aug 2017 11:14:06 +0200 Subject: RFR: JDK-8186694: JShell: speed-up compilation by reusing compiler instances In-Reply-To: References: <59A5C776.9090209@oracle.com> <59A5CA7D.5070304@oracle.com> Message-ID: <59A7D35E.8090102@oracle.com> Thanks for the comments so far. Updated webrev: http://cr.openjdk.java.net/~jlahoda/8186694/webrev.01/ I've moved the class to the javac.api package as suggested, and did more changes as noted below. One of the additional changes is a Scope related fix to TypeEnter and corresponding ScopeClassHeaderTest.java test, which is mostly independent to the rest of this patch, and I can split that out. (Some of the fixes in this webrev caused this bug was revealed.) On 30.8.2017 12:43, Maurizio Cimadamore wrote: > Good work, some comments: > > * in the combo test API, who is calling returnTask()? Ooops. Fixed (when a new task is to be issued, the previous one is closed). > > * would it make sense to use try with resources for JavacPoolTask and > jshell AnalyzeTask, to minimize chances of errors? Makes sense, done. > > * not sure about the getTask/returnTask handshake - the logic seems to > work in this way: > > - when a new task is requested, you check the caches, and if a context > is there (with given options) you return it, otherwise you create a > fresh one > - when a task is returned, if it's not polluted, you add it to the > caches. Then you need to trim the caches to make sure there's room for > the new context Yes, that's the intent. > > We badly miss a circular queue here (not a fault of this patch of course > :-)). > > If we could reduce the state to the options2Context map, then we could > probably use a CHM and get rid of synchronized block. > > Even w/ synchronized map, it seems like 'pool' is only used to get at > the first cached context, so maybe a simple field (which you overwrite) > might suffice? I've got rid of the pool field. But not sure if the code can be rewritten to CHM - might be safer to simply use a simple synchronized block. > > More generally, I tend to view pair of coupled methods such as > getTask/returnTask as suspicious and error prone (in case somebody > forgets to call the second method) - so I tend to try to avoid writing > such APIs unless absolutely necessary - here I'm not 100% on why this is > necessary... on the one hand I get the desire of knowing when a client > is done with a task, on the other hand there's nothing stopping the same > client from keep using same task after returning it, so... In principle I agree having a pair of methods can lead to errors. But the error here is that a Context won't be reused, which just should mean things will be somewhat slower, but the results should be OK. I can see there are some options, but I am not sure if they are better: a) when asked for a task, we could simply reuse the last Context, without checking if the previous user is finished with that. (This is what the tests are doing now.) I think this was OK for tests, and might work for JShell as well. But if the previous user would be still using the Context, the outcomes are hardly predictable (can lead to surprising broken results). So in JShell, each time we would create a new task, we would need to ask ourselves if there's another task currently in use. So this seems like complicating maintenance. b) make the tasks only available inside a worker method. Like: Z getTask(, Function worker) { ... } the task is only valid while "worker" is running. This is safer, as one cannot forget to close the task. (And I rewrote JShell to do this as an experiment.) But not sure if this is not too complex as this means significant changes to the callers, and is also inconsistent with JavaCompiler.getTask. Jan > > Maurizio > > > On 29/08/17 21:11, Jonathan Gibbons wrote: >> I don't think JavacTaskPool belongs in the javac.util package. >> >> Unless there are good reasons for doing otherwise, how about using >> javac.api instead ... i..e closed to JavacTaskImpl and friend. >> >> -- Jon >> >> >> On 08/29/2017 12:58 PM, Jan Lahoda wrote: >>> Hello, >>> >>> When starting jshell like this (where "/tmp/script" is a file which >>> has just "/exit"): >>> $ jshell PRINTING --execution local /tmp/script >>> >>> It currently takes approx. 5-6s on my laptop. PRINTING will add quite >>> a few startup snippets. Each of these snippets is processed >>> separately and needs several instances of javac to be created to be >>> processed correctly. >>> >>> So, the idea in this patch is to reuse the javac instances multiple >>> (many) times. This avoids initializing the javac instances just to >>> process a very small ("single line") input. >>> >>> This patch is based on the ReusableContext by Maurizio used in tests. >>> The ReusableContext handling is wrapped in JavacTaskPool, which keeps >>> the ReusableContext and issues JavacTask possibly based on a reused >>> Context. The pool is not currently general purpose, but should work >>> for tests for which ReusableContext worked and for JShell. >>> >>> One tricky thing is that in JShell, it is necessary to prune >>> everything in the "REPL" package when reusing the Context, as it is >>> necessary to reload the correct/updated classes again from the file >>> manager (this is achieved by additional cleaning in TaskFactory). >>> >>> Overall, with this patch, the time to execute the above command is >>> approx. 2.5s >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8186694 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~jlahoda/8186694/webrev.00/ >>> >>> How does this look? >>> >>> Thanks, >>> Jan >> > From maurizio.cimadamore at oracle.com Thu Aug 31 14:17:12 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 31 Aug 2017 15:17:12 +0100 Subject: RFR: JDK-8186694: JShell: speed-up compilation by reusing compiler instances In-Reply-To: <59A7D35E.8090102@oracle.com> References: <59A5C776.9090209@oracle.com> <59A5CA7D.5070304@oracle.com> <59A7D35E.8090102@oracle.com> Message-ID: <9a6dc679-7ff2-9984-58e4-b9f6ba3bec2c@oracle.com> Looks better, thanks. On the issue of getTask/returnTask, I think that either a lambda-accepting method or a TWR approach would be good in enforcing the 'right' idiom. Another alternative would be to return a task which overrides the parse()/analze()... methods so that the returnTask logic is called at the end. But that seems weaker than the lambda based approach. I'm not too worried w.r.t. inconsistencies with the JavaCompiler.getTask because (i) even having a pair of methods is inconsistent with that API and (ii) JavacPoolTask represents a pool of compilation tasks, so I'm not sure it has to be 100% consistent with what's done in JavaCompiler. Updating the clients would probably be the biggest chunk of work, so I leave with you as to whether this should be addressed. My sense is that some of the jshell clients have already changes because of this (with try/finally, so adding a method call with a lambda would probably be rather similar). But combo tests would also need same treatment (e.g. ComboInstance::newCompilationTask should probably become a lambda-accepting ComboInstance::withCompilatonTask). Maurizio On 31/08/17 10:14, Jan Lahoda wrote: > Thanks for the comments so far. > > Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8186694/webrev.01/ > > I've moved the class to the javac.api package as suggested, and did > more changes as noted below. > > One of the additional changes is a Scope related fix to TypeEnter and > corresponding ScopeClassHeaderTest.java test, which is mostly > independent to the rest of this patch, and I can split that out. (Some > of the fixes in this webrev caused this bug was revealed.) > > On 30.8.2017 12:43, Maurizio Cimadamore wrote: >> Good work, some comments: >> >> * in the combo test API, who is calling returnTask()? > > Ooops. Fixed (when a new task is to be issued, the previous one is > closed). > >> >> * would it make sense to use try with resources for JavacPoolTask and >> jshell AnalyzeTask, to minimize chances of errors? > > Makes sense, done. > >> >> * not sure about the getTask/returnTask handshake - the logic seems to >> work in this way: >> >> - when a new task is requested, you check the caches, and if a context >> is there (with given options) you return it, otherwise you create a >> fresh one >> - when a task is returned, if it's not polluted, you add it to the >> caches. Then you need to trim the caches to make sure there's room for >> the new context > > Yes, that's the intent. > >> >> We badly miss a circular queue here (not a fault of this patch of course >> :-)). >> >> If we could reduce the state to the options2Context map, then we could >> probably use a CHM and get rid of synchronized block. >> >> Even w/ synchronized map, it seems like 'pool' is only used to get at >> the first cached context, so maybe a simple field (which you overwrite) >> might suffice? > > I've got rid of the pool field. But not sure if the code can be > rewritten to CHM - might be safer to simply use a simple synchronized > block. > >> >> More generally, I tend to view pair of coupled methods such as >> getTask/returnTask as suspicious and error prone (in case somebody >> forgets to call the second method) - so I tend to try to avoid writing >> such APIs unless absolutely necessary - here I'm not 100% on why this is >> necessary... on the one hand I get the desire of knowing when a client >> is done with a task, on the other hand there's nothing stopping the same >> client from keep using same task after returning it, so... > > In principle I agree having a pair of methods can lead to errors. But > the error here is that a Context won't be reused, which just should > mean things will be somewhat slower, but the results should be OK. I > can see there are some options, but I am not sure if they are better: > a) when asked for a task, we could simply reuse the last Context, > without checking if the previous user is finished with that. (This is > what the tests are doing now.) I think this was OK for tests, and > might work for JShell as well. But if the previous user would be still > using the Context, the outcomes are hardly predictable (can lead to > surprising broken results). So in JShell, each time we would create a > new task, we would need to ask ourselves if there's another task > currently in use. So this seems like complicating maintenance. > > b) make the tasks only available inside a worker method. Like: > Z getTask(, Function worker) { > ... > } > > the task is only valid while "worker" is running. This is safer, as > one cannot forget to close the task. (And I rewrote JShell to do this > as an experiment.) But not sure if this is not too complex as this > means significant changes to the callers, and is also inconsistent > with JavaCompiler.getTask. > > Jan > >> >> Maurizio >> >> >> On 29/08/17 21:11, Jonathan Gibbons wrote: >>> I don't think JavacTaskPool belongs in the javac.util package. >>> >>> Unless there are good reasons for doing otherwise, how about using >>> javac.api instead ... i..e closed to JavacTaskImpl and friend. >>> >>> -- Jon >>> >>> >>> On 08/29/2017 12:58 PM, Jan Lahoda wrote: >>>> Hello, >>>> >>>> When starting jshell like this (where "/tmp/script" is a file which >>>> has just "/exit"): >>>> $ jshell PRINTING --execution local /tmp/script >>>> >>>> It currently takes approx. 5-6s on my laptop. PRINTING will add quite >>>> a few startup snippets. Each of these snippets is processed >>>> separately and needs several instances of javac to be created to be >>>> processed correctly. >>>> >>>> So, the idea in this patch is to reuse the javac instances multiple >>>> (many) times. This avoids initializing the javac instances just to >>>> process a very small ("single line") input. >>>> >>>> This patch is based on the ReusableContext by Maurizio used in tests. >>>> The ReusableContext handling is wrapped in JavacTaskPool, which keeps >>>> the ReusableContext and issues JavacTask possibly based on a reused >>>> Context. The pool is not currently general purpose, but should work >>>> for tests for which ReusableContext worked and for JShell. >>>> >>>> One tricky thing is that in JShell, it is necessary to prune >>>> everything in the "REPL" package when reusing the Context, as it is >>>> necessary to reload the correct/updated classes again from the file >>>> manager (this is achieved by additional cleaning in TaskFactory). >>>> >>>> Overall, with this patch, the time to execute the above command is >>>> approx. 2.5s >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8186694 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8186694/webrev.00/ >>>> >>>> How does this look? >>>> >>>> Thanks, >>>> Jan >>> >>