From jan.lahoda at oracle.com Fri Sep 1 12:21:50 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 1 Sep 2017 14:21:50 +0200 Subject: RFR: JDK-8186694: JShell: speed-up compilation by reusing compiler instances In-Reply-To: <9a6dc679-7ff2-9984-58e4-b9f6ba3bec2c@oracle.com> References: <59A5C776.9090209@oracle.com> <59A5CA7D.5070304@oracle.com> <59A7D35E.8090102@oracle.com> <9a6dc679-7ff2-9984-58e4-b9f6ba3bec2c@oracle.com> Message-ID: <59A950DE.6060206@oracle.com> Hi, Thanks. I've updated the patch so that the pool (and both JShell and tests) take a worker and the tasks are only valid while the worker is running: http://cr.openjdk.java.net/~jlahoda/8186694/webrev.02/ What do you think? Thanks, Jan On 31.8.2017 16:17, Maurizio Cimadamore wrote: > 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 >>>> >>> > From maurizio.cimadamore at oracle.com Fri Sep 1 15:57:23 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 Sep 2017 16:57:23 +0100 Subject: RFR: JDK-8186694: JShell: speed-up compilation by reusing compiler instances In-Reply-To: <59A950DE.6060206@oracle.com> References: <59A5C776.9090209@oracle.com> <59A5CA7D.5070304@oracle.com> <59A7D35E.8090102@oracle.com> <9a6dc679-7ff2-9984-58e4-b9f6ba3bec2c@oracle.com> <59A950DE.6060206@oracle.com> Message-ID: I like this - ship it! Thanks Maurizio On 01/09/17 13:21, Jan Lahoda wrote: > Hi, > > Thanks. I've updated the patch so that the pool (and both JShell and > tests) take a worker and the tasks are only valid while the worker is > running: > > http://cr.openjdk.java.net/~jlahoda/8186694/webrev.02/ > > What do you think? > > Thanks, > Jan > > On 31.8.2017 16:17, Maurizio Cimadamore wrote: >> 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 >>>>> >>>> >> From robert.field at oracle.com Fri Sep 8 05:38:43 2017 From: robert.field at oracle.com (Robert Field) Date: Thu, 07 Sep 2017 22:38:43 -0700 Subject: RFR 8187359: JShell: Give comprehensible error when user method name matches Object method Message-ID: <59B22CE3.2010609@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8187359 Webrev: http://cr.openjdk.java.net/~rfield/8187359v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Mon Sep 11 09:30:46 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 11 Sep 2017 11:30:46 +0200 Subject: RFR 8179856: jshell tool: not suitable for pipeline use In-Reply-To: <599E579B.1020900@oracle.com> References: <599E579B.1020900@oracle.com> Message-ID: <59B657C6.1090809@oracle.com> Hi Robert, Overall seems OK to me. One question: why use "--pipe" instead of simply "-" (which is AFAIK common option for "read stdin")? Jan On 24.8.2017 06:35, Robert Field wrote: > 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 robert.field at oracle.com Mon Sep 11 16:35:19 2017 From: robert.field at oracle.com (Robert Field) Date: Mon, 11 Sep 2017 09:35:19 -0700 Subject: RFR 8179856: jshell tool: not suitable for pipeline use In-Reply-To: <59B657C6.1090809@oracle.com> References: <599E579B.1020900@oracle.com> <59B657C6.1090809@oracle.com> Message-ID: <59B6BB47.6050605@oracle.com> On 09/11/17 02:30, Jan Lahoda wrote: > Hi Robert, > > Overall seems OK to me. One question: why use "--pipe" instead of > simply "-" (which is AFAIK common option for "read stdin")? From Linux "cat" ----- SYNOPSIS cat [OPTION]... [FILE]... DESCRIPTION ... With no FILE, or when FILE is -, read standard input. EXAMPLES cat f - g Output f's contents, then standard input, then g's contents. cat Copy standard input to standard output. ------------ The jshell tool always reads from standard in (unless somehow aborted). This "--pipe" argument is an option, whereas "-" in the *nix world is a file. The option does not change what is read, but how it is processed. But maybe that is too pedantic, and it still the natural choice. Thoughts? -Robert > > Jan > > On 24.8.2017 06:35, Robert Field wrote: >> 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 jonathan.gibbons at oracle.com Mon Sep 11 16:43:28 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 11 Sep 2017 09:43:28 -0700 Subject: RFR 8179856: jshell tool: not suitable for pipeline use In-Reply-To: <59B6BB47.6050605@oracle.com> References: <599E579B.1020900@oracle.com> <59B657C6.1090809@oracle.com> <59B6BB47.6050605@oracle.com> Message-ID: On 9/11/17 9:35 AM, Robert Field wrote: > > On 09/11/17 02:30, Jan Lahoda wrote: >> Hi Robert, >> >> Overall seems OK to me. One question: why use "--pipe" instead of >> simply "-" (which is AFAIK common option for "read stdin")? > > From Linux "cat" ----- > > SYNOPSIS > cat [OPTION]... [FILE]... > > DESCRIPTION > ... > > With no FILE, or when FILE is -, read standard input. > > EXAMPLES > cat f - g > Output f's contents, then standard input, then g's > contents. > > cat Copy standard input to standard output. > > ------------ > > The jshell tool always reads from standard in (unless somehow aborted). > This "--pipe" argument is an option, whereas "-" in the *nix world is > a file. > > The option does not change what is read, but how it is processed. > > But maybe that is too pedantic, and it still the natural choice. > > Thoughts? > > -Robert > > >> >> Jan >> >> On 24.8.2017 06:35, Robert Field wrote: >>> 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 >>> > I think it would be a sufficiently non-standard use of "-" that an explicit option like --pipe would be better. -- Jon From jan.lahoda at oracle.com Tue Sep 12 15:47:22 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 12 Sep 2017 17:47:22 +0200 Subject: RFR 8179856: jshell tool: not suitable for pipeline use In-Reply-To: <59B6BB47.6050605@oracle.com> References: <599E579B.1020900@oracle.com> <59B657C6.1090809@oracle.com> <59B6BB47.6050605@oracle.com> Message-ID: <59B8018A.9070809@oracle.com> What would happen if we processed "-" (stdin) as a file? One difference I see is that after processing the files, the interactive shell is started unless there is an explicit /exit in the files. But given we have already processed the stdin, it would seem OK to me to not start the interactive part (there's an EOF at the end of the stdin, I assume, which for stdin could be seen as an explicit /exit). I also tried bash: $ echo 'echo X' | bash - X Jan On 11.9.2017 18:35, Robert Field wrote: > > On 09/11/17 02:30, Jan Lahoda wrote: >> Hi Robert, >> >> Overall seems OK to me. One question: why use "--pipe" instead of >> simply "-" (which is AFAIK common option for "read stdin")? > > From Linux "cat" ----- > > SYNOPSIS > cat [OPTION]... [FILE]... > > DESCRIPTION > ... > > With no FILE, or when FILE is -, read standard input. > > EXAMPLES > cat f - g > Output f's contents, then standard input, then g's contents. > > cat Copy standard input to standard output. > > ------------ > > The jshell tool always reads from standard in (unless somehow aborted). > This "--pipe" argument is an option, whereas "-" in the *nix world is a > file. > > The option does not change what is read, but how it is processed. > > But maybe that is too pedantic, and it still the natural choice. > > Thoughts? > > -Robert > > >> >> Jan >> >> On 24.8.2017 06:35, Robert Field wrote: >>> 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 Tue Sep 12 19:50:31 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 12 Sep 2017 21:50:31 +0200 Subject: RFR 8187359: JShell: Give comprehensible error when user method name matches Object method In-Reply-To: <59B22CE3.2010609@oracle.com> References: <59B22CE3.2010609@oracle.com> Message-ID: <59B83A87.4070503@oracle.com> Seems OK. Jan On 8.9.2017 07:38, Robert Field wrote: > Please review. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8187359 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8187359v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Tue Sep 12 19:53:25 2017 From: robert.field at oracle.com (Robert Field) Date: Tue, 12 Sep 2017 12:53:25 -0700 Subject: RFR 8179856: jshell tool: not suitable for pipeline use In-Reply-To: <59B8018A.9070809@oracle.com> References: <599E579B.1020900@oracle.com> <59B657C6.1090809@oracle.com> <59B6BB47.6050605@oracle.com> <59B8018A.9070809@oracle.com> Message-ID: <80E15A95-A294-495A-B8D8-AC524C928B03@oracle.com> I like it! Both because it is clean and a standard. I agree that considering stdin exhausted (so exiting after) makes sense. It will mean somewhat of a rewrite, but that?s fine. I?ll redo and send out. -Robert > On Sep 12, 2017, at 8:47 AM, Jan Lahoda wrote: > > What would happen if we processed "-" (stdin) as a file? One difference I see is that after processing the files, the interactive shell is started unless there is an explicit /exit in the files. But given we have already processed the stdin, it would seem OK to me to not start the interactive part (there's an EOF at the end of the stdin, I assume, which for stdin could be seen as an explicit /exit). > > I also tried bash: > $ echo 'echo X' | bash - > X > > Jan > > On 11.9.2017 18:35, Robert Field wrote: >> >> On 09/11/17 02:30, Jan Lahoda wrote: >>> Hi Robert, >>> >>> Overall seems OK to me. One question: why use "--pipe" instead of >>> simply "-" (which is AFAIK common option for "read stdin")? >> >> From Linux "cat" ----- >> >> SYNOPSIS >> cat [OPTION]... [FILE]... >> >> DESCRIPTION >> ... >> >> With no FILE, or when FILE is -, read standard input. >> >> EXAMPLES >> cat f - g >> Output f's contents, then standard input, then g's contents. >> >> cat Copy standard input to standard output. >> >> ------------ >> >> The jshell tool always reads from standard in (unless somehow aborted). >> This "--pipe" argument is an option, whereas "-" in the *nix world is a >> file. >> >> The option does not change what is read, but how it is processed. >> >> But maybe that is too pedantic, and it still the natural choice. >> >> Thoughts? >> >> -Robert >> >> >>> >>> Jan >>> >>> On 24.8.2017 06:35, Robert Field wrote: >>>> 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 robert.field at oracle.com Wed Sep 13 22:08:45 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 13 Sep 2017 15:08:45 -0700 Subject: RFR 8179856: jshell tool: not suitable for pipeline use In-Reply-To: <80E15A95-A294-495A-B8D8-AC524C928B03@oracle.com> References: <599E579B.1020900@oracle.com> <59B657C6.1090809@oracle.com> <59B6BB47.6050605@oracle.com> <59B8018A.9070809@oracle.com> <80E15A95-A294-495A-B8D8-AC524C928B03@oracle.com> Message-ID: <59B9AC6D.3030506@oracle.com> Please review updated webrev (now uses file "-" rather than option "--pipe") -- 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/8179856v2.webrev/ The CSR also needs a review: https://bugs.openjdk.java.net/browse/JDK-8187439 Thanks, Robert On 09/12/17 12:53, Robert Field wrote: > I like it! > > Both because it is clean and a standard. > I agree that considering stdin exhausted (so exiting after) makes sense. > > It will mean somewhat of a rewrite, but that?s fine. > > I?ll redo and send out. > > -Robert > >> On Sep 12, 2017, at 8:47 AM, Jan Lahoda wrote: >> >> What would happen if we processed "-" (stdin) as a file? One difference I see is that after processing the files, the interactive shell is started unless there is an explicit /exit in the files. But given we have already processed the stdin, it would seem OK to me to not start the interactive part (there's an EOF at the end of the stdin, I assume, which for stdin could be seen as an explicit /exit). >> >> I also tried bash: >> $ echo 'echo X' | bash - >> X >> >> Jan >> >> On 11.9.2017 18:35, Robert Field wrote: >>> On 09/11/17 02:30, Jan Lahoda wrote: >>>> Hi Robert, >>>> >>>> Overall seems OK to me. One question: why use "--pipe" instead of >>>> simply "-" (which is AFAIK common option for "read stdin")? >>> From Linux "cat" ----- >>> >>> SYNOPSIS >>> cat [OPTION]... [FILE]... >>> >>> DESCRIPTION >>> ... >>> >>> With no FILE, or when FILE is -, read standard input. >>> >>> EXAMPLES >>> cat f - g >>> Output f's contents, then standard input, then g's contents. >>> >>> cat Copy standard input to standard output. >>> >>> ------------ >>> >>> The jshell tool always reads from standard in (unless somehow aborted). >>> This "--pipe" argument is an option, whereas "-" in the *nix world is a >>> file. >>> >>> The option does not change what is read, but how it is processed. >>> >>> But maybe that is too pedantic, and it still the natural choice. >>> >>> Thoughts? >>> >>> -Robert >>> >>> >>>> Jan >>>> >>>> On 24.8.2017 06:35, Robert Field wrote: >>>>> 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 Mon Sep 18 15:14:42 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 18 Sep 2017 17:14:42 +0200 Subject: RFR 8179856: jshell tool: not suitable for pipeline use In-Reply-To: <59B6BB47.6050605@oracle.com> References: <599E579B.1020900@oracle.com> <59B657C6.1090809@oracle.com> <59B6BB47.6050605@oracle.com> Message-ID: <59BFE2E2.9030501@oracle.com> Seems OK to me. Jan On 11.9.2017 18:35, Robert Field wrote: > > On 09/11/17 02:30, Jan Lahoda wrote: >> Hi Robert, >> >> Overall seems OK to me. One question: why use "--pipe" instead of >> simply "-" (which is AFAIK common option for "read stdin")? > > From Linux "cat" ----- > > SYNOPSIS > cat [OPTION]... [FILE]... > > DESCRIPTION > ... > > With no FILE, or when FILE is -, read standard input. > > EXAMPLES > cat f - g > Output f's contents, then standard input, then g's contents. > > cat Copy standard input to standard output. > > ------------ > > The jshell tool always reads from standard in (unless somehow aborted). > This "--pipe" argument is an option, whereas "-" in the *nix world is a > file. > > The option does not change what is read, but how it is processed. > > But maybe that is too pedantic, and it still the natural choice. > > Thoughts? > > -Robert > > >> >> Jan >> >> On 24.8.2017 06:35, Robert Field wrote: >>> 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 robert.field at oracle.com Thu Sep 21 23:37:22 2017 From: robert.field at oracle.com (Robert Field) Date: Thu, 21 Sep 2017 16:37:22 -0700 Subject: JShell officially released today! Message-ID: Java 9, and thus JShell, are now officially released! http://www.oracle.com/technetwork/java/javase/downloads/index.html The jshell tool User Guide (tutorial) is also released: https://docs.oracle.com/javase/9/jshell/introduction-jshell.htm As is the jshell Tool Reference: https://docs.oracle.com/javase/9/tools/jshell.htm Enjoy! -Robert From andrei.i.eremeev at mail.ru Fri Sep 22 12:03:43 2017 From: andrei.i.eremeev at mail.ru (=?UTF-8?B?QW5kcmVpIEVyZW1lZXY=?=) Date: Fri, 22 Sep 2017 15:03:43 +0300 Subject: =?UTF-8?B?UmU6IEpTaGVsbCBvZmZpY2lhbGx5IHJlbGVhc2VkIHRvZGF5IQ==?= In-Reply-To: References: Message-ID: <1506081823.723396027@f495.i.mail.ru> Good job, Robert! Congratulations! Best regards, Andrei Eremeev >Friday, September 22, 2017 2:37 AM +03:00 from Robert Field : > >Java 9, and thus JShell, are now officially released! > >???? http://www.oracle.com/technetwork/java/javase/downloads/index.html < http://www.oracle.com/technetwork/java/javase/downloads/index.html > > >The jshell tool User Guide (tutorial) is also released: > >???? https://docs.oracle.com/javase/9/jshell/introduction-jshell.htm < https://docs.oracle.com/javase/9/jshell/introduction-jshell.htm > > >As is the jshell Tool Reference: > >???? https://docs.oracle.com/javase/9/tools/jshell.htm < https://docs.oracle.com/javase/9/tools/jshell.htm > > >Enjoy! > >-Robert > From jonathan.gibbons at oracle.com Sat Sep 30 00:08:27 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 29 Sep 2017 17:08:27 -0700 Subject: jdk/jshell/ExternalEditorTest.java always times out Message-ID: <59CEE07B.5060705@oracle.com> This test always times out when running tests locally. Is this to be expected, or do I need to do anything to help it work? (like set an external editor?) -- Jon