From robert.field at oracle.com Wed Nov 1 05:26:24 2017 From: robert.field at oracle.com (Robert Field) Date: Tue, 31 Oct 2017 22:26:24 -0700 Subject: RFR 8177076: jshell tool: allow non-zero /exit Message-ID: <59F95B00.4010509@oracle.com> The seed of this is the ability to exit the jshell tool with a user specified exit code. For example: /exit result > base ? 0 : 7 However, this requires the tool launching API to support passing on the exit code. In turn, this requires the tool to return exit codes, and do so correctly for tool errors. This is the first case of a command taking a snippet as an argument. Input continuation was tied to snippet input processing. Input, continuation, command, and snippet processing needed to be unraveled. Diagnostic display, formerly only needed for snippets, needed to be refactored. Tab completion needed to be handled in this new case (note integer context). On testing side, StartOptionTest and its subclass ToolProviderTest were a teetering pile of spaghetti that were not amenable to the additional demands of the new needed tests. They have been revamped. Bugs: 8177076: jshell tool: allow non-zero /exit https://bugs.openjdk.java.net/browse/JDK-8185840 8190383: JShell API: no way for the jshell tool to report exit status to provider https://bugs.openjdk.java.net/browse/JDK-8190383 Webrev: http://cr.openjdk.java.net/~rfield/8185840v0.webrev/ Thanks, Robert From robert.field at oracle.com Wed Nov 1 17:35:57 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 01 Nov 2017 10:35:57 -0700 Subject: RFR 8177076: jshell tool: allow non-zero /exit In-Reply-To: <59F95B00.4010509@oracle.com> References: <59F95B00.4010509@oracle.com> Message-ID: <59FA05FD.3080005@oracle.com> A minor update with improvements I was mulling over while I should have been sleeping: http://cr.openjdk.java.net/~rfield/8185840v1.webrev/ -Robert On 10/31/17 22:26, Robert Field wrote: > The seed of this is the ability to exit the jshell tool with a user > specified exit code. For example: > > /exit result > base ? 0 : 7 > > However, this requires the tool launching API to support passing on > the exit code. > In turn, this requires the tool to return exit codes, and do so > correctly for tool errors. > > This is the first case of a command taking a snippet as an argument. > Input continuation was tied to snippet input processing. > Input, continuation, command, and snippet processing needed to be > unraveled. > > Diagnostic display, formerly only needed for snippets, needed to be > refactored. > > Tab completion needed to be handled in this new case (note integer > context). > > On testing side, StartOptionTest and its subclass ToolProviderTest > were a teetering pile of spaghetti that were not amenable to > the additional demands of the new needed tests. They have been revamped. > > Bugs: > > 8177076: jshell tool: allow non-zero /exit > https://bugs.openjdk.java.net/browse/JDK-8185840 > > 8190383: JShell API: no way for the jshell tool to report exit > status to provider > https://bugs.openjdk.java.net/browse/JDK-8190383 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8185840v0.webrev/ > > Thanks, > Robert > From sormuras at gmail.com Wed Nov 1 17:49:35 2017 From: sormuras at gmail.com (Christian Stein) Date: Wed, 1 Nov 2017 18:49:35 +0100 Subject: RFR 8177076: jshell tool: allow non-zero /exit In-Reply-To: <59FA05FD.3080005@oracle.com> References: <59F95B00.4010509@oracle.com> <59FA05FD.3080005@oracle.com> Message-ID: Hi Robert, I'm looking forward to /exit with some code other than zero. Allowing a snippet that evaluates to an integer is more than expected. Great! The initial "snippet-less" /exit always returns zero -- this is not (yet) documented in the long help text, as far as I can see. ! Save any work before using this command\n\! \n\! /exit\n\t\! Leave the jshell tool\n\n\ Cheers, Christian On Wed, Nov 1, 2017 at 6:35 PM, Robert Field wrote: > A minor update with improvements I was mulling over while I should have > been sleeping: > > http://cr.openjdk.java.net/~rfield/8185840v1.webrev/ > > -Robert > > On 10/31/17 22:26, Robert Field wrote: > >> The seed of this is the ability to exit the jshell tool with a user >> specified exit code. For example: >> >> /exit result > base ? 0 : 7 >> >> However, this requires the tool launching API to support passing on the >> exit code. >> In turn, this requires the tool to return exit codes, and do so correctly >> for tool errors. >> >> This is the first case of a command taking a snippet as an argument. >> Input continuation was tied to snippet input processing. >> Input, continuation, command, and snippet processing needed to be >> unraveled. >> >> Diagnostic display, formerly only needed for snippets, needed to be >> refactored. >> >> Tab completion needed to be handled in this new case (note integer >> context). >> >> On testing side, StartOptionTest and its subclass ToolProviderTest were a >> teetering pile of spaghetti that were not amenable to >> the additional demands of the new needed tests. They have been revamped. >> >> Bugs: >> >> 8177076: jshell tool: allow non-zero /exit >> https://bugs.openjdk.java.net/browse/JDK-8185840 >> >> 8190383: JShell API: no way for the jshell tool to report exit status >> to provider >> https://bugs.openjdk.java.net/browse/JDK-8190383 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8185840v0.webrev/ >> >> Thanks, >> Robert >> >> > From robert.field at oracle.com Wed Nov 1 17:56:43 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 01 Nov 2017 10:56:43 -0700 Subject: RFR 8177076: jshell tool: allow non-zero /exit In-Reply-To: References: <59F95B00.4010509@oracle.com> <59FA05FD.3080005@oracle.com> Message-ID: <59FA0ADB.1000901@oracle.com> On 11/01/17 10:49, Christian Stein wrote: > Hi Robert, > > I'm looking forward to /exit with some code other than zero. > Allowing a snippet that evaluates to an integer is more than expected. > Great! :-) > > The initial "snippet-less" /exit always returns zero -- this is not (yet) > documented in the long help text, as far as I can see. > > ! Save any work before using this command\n\! \n\! /exit\n\t\! > Leave the jshell tool\n\n\ Good point, will fix. Thanks, Robert > > Cheers, > Christian > > On Wed, Nov 1, 2017 at 6:35 PM, Robert Field > wrote: > >> A minor update with improvements I was mulling over while I should have >> been sleeping: >> >> http://cr.openjdk.java.net/~rfield/8185840v1.webrev/ >> >> -Robert >> >> On 10/31/17 22:26, Robert Field wrote: >> >>> The seed of this is the ability to exit the jshell tool with a user >>> specified exit code. For example: >>> >>> /exit result > base ? 0 : 7 >>> >>> However, this requires the tool launching API to support passing on the >>> exit code. >>> In turn, this requires the tool to return exit codes, and do so correctly >>> for tool errors. >>> >>> This is the first case of a command taking a snippet as an argument. >>> Input continuation was tied to snippet input processing. >>> Input, continuation, command, and snippet processing needed to be >>> unraveled. >>> >>> Diagnostic display, formerly only needed for snippets, needed to be >>> refactored. >>> >>> Tab completion needed to be handled in this new case (note integer >>> context). >>> >>> On testing side, StartOptionTest and its subclass ToolProviderTest were a >>> teetering pile of spaghetti that were not amenable to >>> the additional demands of the new needed tests. They have been revamped. >>> >>> Bugs: >>> >>> 8177076: jshell tool: allow non-zero /exit >>> https://bugs.openjdk.java.net/browse/JDK-8185840 >>> >>> 8190383: JShell API: no way for the jshell tool to report exit status >>> to provider >>> https://bugs.openjdk.java.net/browse/JDK-8190383 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8185840v0.webrev/ >>> >>> Thanks, >>> Robert >>> >>> From robert.field at oracle.com Thu Nov 2 04:22:29 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 01 Nov 2017 21:22:29 -0700 Subject: RFR 8188072: JShell: NPE in SourceCodeAnalysis.completionSuggestions() Message-ID: <59FA9D85.5070104@oracle.com> JDK-8190510 has been filed to diagnose and address the underlying cause of this error. The more general and important fix is to assure that failures of this class do not crash the jshell tool -- so this addresses that. Catching this in SourceCodeAnalysisImpl.completionSuggestions() causes it move on to the same failure in SourceCodeAnalysisImpl.documentation(). Both now catch all Throwables, reporting the exception when debugging is on ("/debug", see JDK-8190510) and returning the empty list (the no result value). Bug: https://bugs.openjdk.java.net/browse/JDK-8188072 Webrev: http://cr.openjdk.java.net/~rfield/8188072v0.webrev/ -Robert From cay.horstmann at sjsu.edu Thu Nov 2 06:01:08 2017 From: cay.horstmann at sjsu.edu (Cay Horstmann) Date: Thu, 2 Nov 2017 09:01:08 +0300 Subject: JShell and illegal reflective access warning Message-ID: <3eca3e23-0b42-1bb2-a7b0-19d6de8d5031@gmail.com> With Java 9, I get a stern warning when running a program that executes String.class.getDeclaredField("value").setAccessible(true); But in JShell, the statement doesn't generate a warning. Wouldn't it be a good idea if it did? (You do get the expected warning when running jshell --execution local) Cheers, Cay -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From kumar.x.srinivasan at oracle.com Thu Nov 2 12:35:01 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 02 Nov 2017 05:35:01 -0700 Subject: RFR: JDK-8189778: Jshell crash on tab for StringBuilder.append( In-Reply-To: <59F8A8E6.6030609@oracle.com> References: <59F1AC72.4020202@oracle.com> <59F8A8E6.6030609@oracle.com> Message-ID: <59FB10F5.4000407@oracle.com> Hi Jan, Generally it looks fine to me, a few nits... JavadocHelper.java 1. - //which will be resolve in visitInheritDoc: suggest.... + //which will be resolved in visitInheritDoc: 2. Suggest adding a space after /** or /* makes it a little easier to read the comments. 3. - //insertPos (as future missing elements should be inserted behind + //insertPos (as future missing elements should be inserted before 4. - //if there is a newline immediatelly after this tree, insert after + //if there is a newline immediately after this tree, insert after 5. Several private methods have have javadoc comments /**, do you run javadoc -private on jshell sources ? You may want to get Jon's review on this, he is much more familiar with these things, than I. Thanks Kumar > I've updated to patch to have some comments at places that seemed > important: > http://cr.openjdk.java.net/~jlahoda/8189778/webrev.01/ > > Jan > > On 26.10.2017 11:35, Jan Lahoda wrote: >> Hi, >> >> Typing: >> jshell> StringBuilder sb = new StringBuilder(); >> jshell> sb.append( >> >> Will lead to an exception: >> jshell> sb.append(Exception in thread "main" >> java.lang.StringIndexOutOfBoundsException: start -59, end -59, length >> 238 >> [snip] >> jdk.compiler/jdk.internal.shellsupport.doc.JavadocHelper$OnDemandJavadocHelper.getResolvedDocComment(JavadocHelper.java:481) >> >> >> >> The reason is that the javadoc for StringBuilder.append(CharSequence, >> int, int) is: >> /** >> * @throws IndexOutOfBoundsException {@inheritDoc} >> */ >> >> The JavadocHelper tries to fill in the missing javadoc entries, but that >> fails because it tries to insert the preceding entries at an >> uninitialized place. >> >> The proposed patch: >> -fixes the above >> -adds a test that runs the JavadocHelper on all >> methods/fields/constructors of top-level types in all exported packages >> (this runs for a considerable time, and we may need to disable this test >> if it proves to be too heavyweight) >> -adds a few more test cases for problems found by the above test >> -fixes the javadoc resolution to treat missing javadoc body as >> {@inheritDoc} (so that the overridden method's javadoc text is used if >> missing in this method) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8189778 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8189778/webrev.00/ >> >> Feedback is welcome. >> >> Thanks, >> Jan From jan.lahoda at oracle.com Thu Nov 2 13:05:54 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 2 Nov 2017 14:05:54 +0100 Subject: RFR 8177076: jshell tool: allow non-zero /exit In-Reply-To: <59FA05FD.3080005@oracle.com> References: <59F95B00.4010509@oracle.com> <59FA05FD.3080005@oracle.com> Message-ID: <59FB1832.90905@oracle.com> Looks good to me! Jan On 1.11.2017 18:35, Robert Field wrote: > A minor update with improvements I was mulling over while I should have > been sleeping: > > http://cr.openjdk.java.net/~rfield/8185840v1.webrev/ > > -Robert > > On 10/31/17 22:26, Robert Field wrote: >> The seed of this is the ability to exit the jshell tool with a user >> specified exit code. For example: >> >> /exit result > base ? 0 : 7 >> >> However, this requires the tool launching API to support passing on >> the exit code. >> In turn, this requires the tool to return exit codes, and do so >> correctly for tool errors. >> >> This is the first case of a command taking a snippet as an argument. >> Input continuation was tied to snippet input processing. >> Input, continuation, command, and snippet processing needed to be >> unraveled. >> >> Diagnostic display, formerly only needed for snippets, needed to be >> refactored. >> >> Tab completion needed to be handled in this new case (note integer >> context). >> >> On testing side, StartOptionTest and its subclass ToolProviderTest >> were a teetering pile of spaghetti that were not amenable to >> the additional demands of the new needed tests. They have been revamped. >> >> Bugs: >> >> 8177076: jshell tool: allow non-zero /exit >> https://bugs.openjdk.java.net/browse/JDK-8185840 >> >> 8190383: JShell API: no way for the jshell tool to report exit >> status to provider >> https://bugs.openjdk.java.net/browse/JDK-8190383 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8185840v0.webrev/ >> >> Thanks, >> Robert >> > From jan.lahoda at oracle.com Thu Nov 2 13:16:19 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 2 Nov 2017 14:16:19 +0100 Subject: RFR 8188072: JShell: NPE in SourceCodeAnalysis.completionSuggestions() In-Reply-To: <59FA9D85.5070104@oracle.com> References: <59FA9D85.5070104@oracle.com> Message-ID: <59FB1AA3.6030609@oracle.com> +1 Jan On 2.11.2017 05:22, Robert Field wrote: > JDK-8190510 has been filed to diagnose and address the underlying cause > of this error. > > The more general and important fix is to assure that failures of this > class do not crash the jshell tool -- so this addresses that. > > Catching this in SourceCodeAnalysisImpl.completionSuggestions() causes > it move on to the same failure in SourceCodeAnalysisImpl.documentation(). > > Both now catch all Throwables, reporting the exception when debugging is > on ("/debug", see JDK-8190510) and returning the empty list (the no > result value). > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8188072 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8188072v0.webrev/ > > -Robert > From jan.lahoda at oracle.com Thu Nov 2 16:21:53 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 2 Nov 2017 17:21:53 +0100 Subject: RFR: JDK-8189778: Jshell crash on tab for StringBuilder.append( In-Reply-To: <59FB10F5.4000407@oracle.com> References: <59F1AC72.4020202@oracle.com> <59F8A8E6.6030609@oracle.com> <59FB10F5.4000407@oracle.com> Message-ID: <59FB4621.6010704@oracle.com> Hi Kumar, Thanks for the comments. On 2.11.2017 13:35, Kumar Srinivasan wrote: > > Hi Jan, > > Generally it looks fine to me, a few nits... > > JavadocHelper.java > > 1. > > - //which will be resolve in visitInheritDoc: > suggest.... > + //which will be resolved in visitInheritDoc: > > 2. Suggest adding a space after /** or /* makes it a little easier > to read the comments. > > 3. > > - //insertPos (as future missing elements should be inserted behind > + //insertPos (as future missing elements should be inserted before > > 4. > - //if there is a newline immediatelly after this tree, insert after > + //if there is a newline immediately after this tree, insert after Will do the above. > > 5. Several private methods have have javadoc comments /**, do you > run javadoc -private on jshell sources ? No, but a lot javac code uses /** comments to comment methods (even if they are not a full javadoc comment, like Attr.isType), so I simply kept using the same strategy. (IDEs may also be able to show the javadoc comments in code completion.) Thanks, Jan > > You may want to get Jon's review on this, he is much more familiar > with these things, than I. > > Thanks > Kumar > >> I've updated to patch to have some comments at places that seemed >> important: >> http://cr.openjdk.java.net/~jlahoda/8189778/webrev.01/ >> >> Jan >> >> On 26.10.2017 11:35, Jan Lahoda wrote: >>> Hi, >>> >>> Typing: >>> jshell> StringBuilder sb = new StringBuilder(); >>> jshell> sb.append( >>> >>> Will lead to an exception: >>> jshell> sb.append(Exception in thread "main" >>> java.lang.StringIndexOutOfBoundsException: start -59, end -59, length >>> 238 >>> [snip] >>> jdk.compiler/jdk.internal.shellsupport.doc.JavadocHelper$OnDemandJavadocHelper.getResolvedDocComment(JavadocHelper.java:481) >>> >>> >>> >>> The reason is that the javadoc for StringBuilder.append(CharSequence, >>> int, int) is: >>> /** >>> * @throws IndexOutOfBoundsException {@inheritDoc} >>> */ >>> >>> The JavadocHelper tries to fill in the missing javadoc entries, but that >>> fails because it tries to insert the preceding entries at an >>> uninitialized place. >>> >>> The proposed patch: >>> -fixes the above >>> -adds a test that runs the JavadocHelper on all >>> methods/fields/constructors of top-level types in all exported packages >>> (this runs for a considerable time, and we may need to disable this test >>> if it proves to be too heavyweight) >>> -adds a few more test cases for problems found by the above test >>> -fixes the javadoc resolution to treat missing javadoc body as >>> {@inheritDoc} (so that the overridden method's javadoc text is used if >>> missing in this method) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189778 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8189778/webrev.00/ >>> >>> Feedback is welcome. >>> >>> Thanks, >>> Jan > From robert.field at oracle.com Thu Nov 2 18:42:50 2017 From: robert.field at oracle.com (Robert Field) Date: Thu, 02 Nov 2017 11:42:50 -0700 Subject: RFR 8177076: jshell tool: allow non-zero /exit In-Reply-To: References: <59F95B00.4010509@oracle.com> <59FA05FD.3080005@oracle.com> Message-ID: <59FB672A.9030807@oracle.com> Christian, I've added "The exit status is zero." to the help -- jshell> /help /exit | | /exit | | Leave the jshell tool. No work is saved. | Save any work before using this command | | /exit | Leave the jshell tool. The exit status is zero. | | /exit | Evaluate the snippet. If the snippet fails or is not an integer expression, | display the error. Otherwise leave the jshell tool with the | value of the expression as the exit status Which highlights that the API docs should be explicit too. There is an internal comment on JShellToolProvider.run -- 65 * @return the exit code with which the tool explictly exited (if any), 66 * otherwise 0 for success or nonzero for failure I've changed "exit code" to "exit status" as that is what is used by both the javadoc for System.exit() and in the bash docs. I've fixed the missing "i" in "explictly". And, a user exit code is of limited use if it is unknown what the tool will return, so I've changed "nonzero" to "1" (which is what the tool uses). Yielding -- * @return the exit status with which the tool explicitly exited (if any), * otherwise 0 for success or 1 for failure I then changed the doc on the public API JavaShellToolBuilder.runWithExitCode() which was the below, to be the above -- * @return the exit code Thoughts? Jan, This still OK? Thanks, Robert On 11/01/17 10:49, Christian Stein wrote: > Hi Robert, > > I'm looking forward to /exit with some code other than zero. > Allowing a snippet that evaluates to an integer is more than expected. > Great! > > The initial "snippet-less" /exit always returns zero -- this is not (yet) > documented in the long help text, as far as I can see. > > ! Save any work before using this command\n\! \n\! /exit\n\t\! > Leave the jshell tool\n\n\ > > Cheers, > Christian > > On Wed, Nov 1, 2017 at 6:35 PM, Robert Field > wrote: > >> A minor update with improvements I was mulling over while I should have >> been sleeping: >> >> http://cr.openjdk.java.net/~rfield/8185840v1.webrev/ >> >> -Robert >> >> On 10/31/17 22:26, Robert Field wrote: >> >>> The seed of this is the ability to exit the jshell tool with a user >>> specified exit code. For example: >>> >>> /exit result > base ? 0 : 7 >>> >>> However, this requires the tool launching API to support passing on the >>> exit code. >>> In turn, this requires the tool to return exit codes, and do so correctly >>> for tool errors. >>> >>> This is the first case of a command taking a snippet as an argument. >>> Input continuation was tied to snippet input processing. >>> Input, continuation, command, and snippet processing needed to be >>> unraveled. >>> >>> Diagnostic display, formerly only needed for snippets, needed to be >>> refactored. >>> >>> Tab completion needed to be handled in this new case (note integer >>> context). >>> >>> On testing side, StartOptionTest and its subclass ToolProviderTest were a >>> teetering pile of spaghetti that were not amenable to >>> the additional demands of the new needed tests. They have been revamped. >>> >>> Bugs: >>> >>> 8177076: jshell tool: allow non-zero /exit >>> https://bugs.openjdk.java.net/browse/JDK-8185840 >>> >>> 8190383: JShell API: no way for the jshell tool to report exit status >>> to provider >>> https://bugs.openjdk.java.net/browse/JDK-8190383 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8185840v0.webrev/ >>> >>> Thanks, >>> Robert >>> >>> From robert.field at oracle.com Thu Nov 2 20:41:54 2017 From: robert.field at oracle.com (Robert Field) Date: Thu, 02 Nov 2017 13:41:54 -0700 Subject: Need reviewer for CSR: JShell API: no way for the jshell tool to report exit status to provider Message-ID: <59FB8312.20806@oracle.com> It can be found here: https://bugs.openjdk.java.net/browse/JDK-8190564 Thanks, Robert From robert.field at oracle.com Thu Nov 9 06:49:31 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 08 Nov 2017 22:49:31 -0800 Subject: RFR 8172154 : jshell tool: make all IMPORTS.jsh generated at build time Message-ID: <5A03FA7B.7070308@oracle.com> Please review... Bug: jshell tool: make all IMPORTS.jsh generated at build time https://bugs.openjdk.java.net/browse/JDK-8172154 Webrev: http://cr.openjdk.java.net/~rfield/8172154v0.webrev/ -Robert From robert.field at oracle.com Tue Nov 14 05:21:43 2017 From: robert.field at oracle.com (Robert Field) Date: Mon, 13 Nov 2017 21:21:43 -0800 Subject: RFR 8190939: JShell: gives a compiler error evaluating an expression of inaccessible type Message-ID: <5A0A7D67.5040108@oracle.com> Please review -- See my comments in bug, Bug: https://bugs.openjdk.java.net/browse/JDK-8190939 Webrev: http://cr.openjdk.java.net/~rfield/8190939v0.webrev/ -Robert From jan.lahoda at oracle.com Tue Nov 14 13:43:57 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 14 Nov 2017 14:43:57 +0100 Subject: RFR 8172154 : jshell tool: make all IMPORTS.jsh generated at build time In-Reply-To: <5A03FA7B.7070308@oracle.com> References: <5A03FA7B.7070308@oracle.com> Message-ID: <5A0AF31D.7070203@oracle.com> Seems OK. Jan On 9.11.2017 07:49, Robert Field wrote: > Please review... > > Bug: > > jshell tool: make all IMPORTS.jsh generated at build time > https://bugs.openjdk.java.net/browse/JDK-8172154 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8172154v0.webrev/ > > -Robert > From jan.lahoda at oracle.com Wed Nov 15 14:52:47 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 15 Nov 2017 15:52:47 +0100 Subject: RFR: JDK-8178109: More useful documentation on /help Message-ID: <5A0C54BF.30909@oracle.com> The proposal here is to change the synopsis/documentation for: /help to show the synopsis/documentation for rather than for /help. Bug: https://bugs.openjdk.java.net/browse/JDK-8178109 Webrev: http://cr.openjdk.java.net/~jlahoda/8178109/webrev.00/ How does it look? Thanks, Jan From jan.lahoda at oracle.com Wed Nov 15 20:24:55 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 15 Nov 2017 21:24:55 +0100 Subject: RFR 8190939: JShell: gives a compiler error evaluating an expression of inaccessible type Message-ID: <5A0CA297.7020703@oracle.com> Hi Robert, Looking at: http://cr.openjdk.java.net/~rfield/8190939v0.webrev/src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java.udiff.html isAccessible is handling immediate recursion on types, but is not preventing recursion with intermediate types (as I think is noted in the comment). Can the recursion with intermediate types happen? Thanks, Jan From robert.field at oracle.com Thu Nov 16 04:59:59 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 15 Nov 2017 20:59:59 -0800 Subject: RFR: JDK-8178109: More useful documentation on /help In-Reply-To: <5A0C54BF.30909@oracle.com> References: <5A0C54BF.30909@oracle.com> Message-ID: <5A0D1B4F.1020103@oracle.com> It looks like this code addresses the /help intro case. But there is a second case in the bug report of help on subcommands /help /set truncation For which I don't see code or tests, -Robert On 11/15/17 06:52, Jan Lahoda wrote: > The proposal here is to change the synopsis/documentation for: > /help > > to show the synopsis/documentation for rather than for /help. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178109 > Webrev: http://cr.openjdk.java.net/~jlahoda/8178109/webrev.00/ > > How does it look? > > Thanks, > Jan From ecki at zusammenkunft.net Thu Nov 16 05:43:49 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 16 Nov 2017 05:43:49 +0000 Subject: [JDK-8186876] Make Javadoc available Message-ID: Hello, Just wanted to give feedback: on stack overflow was a question for tabbing through external API documentation. I was not aware and googled for it. I came up with the open bug, that this is not yet implemented. People are missing it. In case there is a roadmap or plan for this, maybe it would be a nice thing to update the Bug. https://stackoverflow.com/questions/47245854/how-to-make-javadoc-documentation-available-in-jshell https://bugs.openjdk.java.net/browse/JDK-8186876 Gruss Bernd -- http://bernd.eckenfels.net From robert.field at oracle.com Thu Nov 16 07:35:59 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 15 Nov 2017 23:35:59 -0800 Subject: [JDK-8186876] Make Javadoc available In-Reply-To: References: Message-ID: <9D064E97-8EA1-4321-B5BB-ADBB03EB313D@oracle.com> I agree that this is an important issue. It is scheduled to be addressed in the next release ("10", "18.3", whatever you call it). There are other pressing issues, so that can't be guaranteed, but it certainly on our radar. Thanks, Robert Sent from my iPad > On Nov 15, 2017, at 9:43 PM, Bernd Eckenfels wrote: > > Hello, > > Just wanted to give feedback: on stack overflow was a question for tabbing through external API documentation. I was not aware and googled for it. I came up with the open bug, that this is not yet implemented. People are missing it. In case there is a roadmap or plan for this, maybe it would be a nice thing to update the Bug. > > https://stackoverflow.com/questions/47245854/how-to-make-javadoc-documentation-available-in-jshell > > https://bugs.openjdk.java.net/browse/JDK-8186876 > > Gruss > Bernd > -- > http://bernd.eckenfels.net From jan.lahoda at oracle.com Thu Nov 16 18:33:40 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 16 Nov 2017 19:33:40 +0100 Subject: RFR: JDK-8178109: More useful documentation on /help In-Reply-To: <5A0D1B4F.1020103@oracle.com> References: <5A0C54BF.30909@oracle.com> <5A0D1B4F.1020103@oracle.com> Message-ID: <5A0DDA04.6080204@oracle.com> Oops, I missed that, sorry. Updated webrev: http://cr.openjdk.java.net/~jlahoda/8178109/webrev.01/ (I tried to delegate to the command completion, but it turned out there are small but significant differences in how command completion and documentation needs to work, so only adding a support for /help /set .) Jan On 16.11.2017 05:59, Robert Field wrote: > It looks like this code addresses the > > /help intro > > case. > > But there is a second case in the bug report of help on subcommands > > /help /set truncation > > For which I don't see code or tests, > > -Robert > > > On 11/15/17 06:52, Jan Lahoda wrote: >> The proposal here is to change the synopsis/documentation for: >> /help >> >> to show the synopsis/documentation for rather than for /help. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8178109 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8178109/webrev.00/ >> >> How does it look? >> >> Thanks, >> Jan > From robert.field at oracle.com Thu Nov 16 19:08:58 2017 From: robert.field at oracle.com (Robert Field) Date: Thu, 16 Nov 2017 11:08:58 -0800 Subject: RFR 8190939: JShell: gives a compiler error evaluating an expression of inaccessible type In-Reply-To: <5A0CA297.7020703@oracle.com> References: <5A0CA297.7020703@oracle.com> Message-ID: <5A0DE24A.20700@oracle.com> On 11/15/17 12:24, Jan Lahoda wrote: > Hi Robert, > > Looking at: > http://cr.openjdk.java.net/~rfield/8190939v0.webrev/src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java.udiff.html > > > isAccessible is handling immediate recursion on types, but is not > preventing recursion with intermediate types (as I think is noted in > the comment). Can the recursion with intermediate types happen? > > Thanks, > Jan Thanks Jan, Excess paranoia on my part. The concrete types of expressions are trees. One cannot be nested within itself, directly or indirectly. I have removed the check, simplifying the code and removed the question (moving the valid part of the comment to the method comment). Updated webrev: http://cr.openjdk.java.net/~rfield/8190939v1.webrev/ Changes only the isAccessible(Type) method in: http://cr.openjdk.java.net/~rfield/8190939v1.webrev/src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java.sdiff.html -Robert From robert.field at oracle.com Thu Nov 16 19:42:54 2017 From: robert.field at oracle.com (Robert Field) Date: Thu, 16 Nov 2017 11:42:54 -0800 Subject: RFR: JDK-8178109: More useful documentation on /help In-Reply-To: <5A0DDA04.6080204@oracle.com> References: <5A0C54BF.30909@oracle.com> <5A0D1B4F.1020103@oracle.com> <5A0DDA04.6080204@oracle.com> Message-ID: <5A0DEA3E.7070406@oracle.com> Jan, Glad you are fixing this bug, it has annoyed me! /help, after user requests, accepts command names with or without the slash - / So, the patterns need to handle "/help set ..." Nit: you allow space or tab in the pattern but only space in the indexOf(). Were we covering all the bases we would use "\h" accepting any horizontal space (not sure of the importance of this for internationalization). But then indexOf() would still be an issue, Maybe the cleanest thing to do would be to do a replaceAll("\\h+", " ") on all of code, first thing; then all of patterns would be much simpler. BTW: "...[^ \t]..." has the "^" in the wrong place -- but that goes away with the replaceAll. Can you merge with the latest repo, the changeset doesn't apply -- so, I can't test. Thanks, Robert On 11/16/17 10:33, Jan Lahoda wrote: > Oops, I missed that, sorry. Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8178109/webrev.01/ > > (I tried to delegate to the command completion, but it turned out > there are small but significant differences in how command completion > and documentation needs to work, so only adding a support for /help > /set .) > > Jan > > On 16.11.2017 05:59, Robert Field wrote: >> It looks like this code addresses the >> >> /help intro >> >> case. >> >> But there is a second case in the bug report of help on subcommands >> >> /help /set truncation >> >> For which I don't see code or tests, >> >> -Robert >> >> >> On 11/15/17 06:52, Jan Lahoda wrote: >>> The proposal here is to change the synopsis/documentation for: >>> /help >>> >>> to show the synopsis/documentation for rather than for >>> /help. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178109 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8178109/webrev.00/ >>> >>> How does it look? >>> >>> Thanks, >>> Jan >> From jan.lahoda at oracle.com Fri Nov 17 20:17:14 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 17 Nov 2017 21:17:14 +0100 Subject: RFR: JDK-8178109: More useful documentation on /help In-Reply-To: <5A0DEA3E.7070406@oracle.com> References: <5A0C54BF.30909@oracle.com> <5A0D1B4F.1020103@oracle.com> <5A0DDA04.6080204@oracle.com> <5A0DEA3E.7070406@oracle.com> Message-ID: <5A0F43CA.4060601@oracle.com> Updated webrev: http://cr.openjdk.java.net/~jlahoda/8178109/webrev.02/ On 16.11.2017 20:42, Robert Field wrote: > Jan, > > Glad you are fixing this bug, it has annoyed me! > > /help, after user requests, accepts command names with or without the > slash - / > So, the patterns need to handle "/help set ..." Fixed. > > Nit: you allow space or tab in the pattern but only space in the > indexOf(). Were we covering all the bases we would use "\h" accepting > any horizontal space (not sure of the importance of this for > internationalization). But then indexOf() would still be an issue, Maybe > the cleanest thing to do would be to do a replaceAll("\\h+", " ") on all > of code, first thing; then all of patterns would be much simpler. BTW: Done. (I was afraid there could be a problem with changing the offsets/positions inside the code, but after checking, that shouldn't be a problem.) > "...[^ \t]..." has the "^" in the wrong place -- but that goes away with > the replaceAll. > > Can you merge with the latest repo, the changeset doesn't apply -- so, I > can't test. Done. Jan > > Thanks, > Robert > > On 11/16/17 10:33, Jan Lahoda wrote: >> Oops, I missed that, sorry. Updated webrev: >> http://cr.openjdk.java.net/~jlahoda/8178109/webrev.01/ >> >> (I tried to delegate to the command completion, but it turned out >> there are small but significant differences in how command completion >> and documentation needs to work, so only adding a support for /help >> /set .) >> >> Jan >> >> On 16.11.2017 05:59, Robert Field wrote: >>> It looks like this code addresses the >>> >>> /help intro >>> >>> case. >>> >>> But there is a second case in the bug report of help on subcommands >>> >>> /help /set truncation >>> >>> For which I don't see code or tests, >>> >>> -Robert >>> >>> >>> On 11/15/17 06:52, Jan Lahoda wrote: >>>> The proposal here is to change the synopsis/documentation for: >>>> /help >>>> >>>> to show the synopsis/documentation for rather than for >>>> /help. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178109 >>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8178109/webrev.00/ >>>> >>>> How does it look? >>>> >>>> Thanks, >>>> Jan >>> > From robert.field at oracle.com Fri Nov 17 22:23:09 2017 From: robert.field at oracle.com (Robert Field) Date: Fri, 17 Nov 2017 14:23:09 -0800 Subject: RFR: JDK-8178109: More useful documentation on /help In-Reply-To: <5A0F43CA.4060601@oracle.com> References: <5A0C54BF.30909@oracle.com> <5A0D1B4F.1020103@oracle.com> <5A0DDA04.6080204@oracle.com> <5A0DEA3E.7070406@oracle.com> <5A0F43CA.4060601@oracle.com> Message-ID: <0E11A147-A53B-443C-B3CF-B9E404CE667E@oracle.com> Looks good. -Robert Sent from my iPad > On Nov 17, 2017, at 12:17 PM, Jan Lahoda wrote: > > Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8178109/webrev.02/ > >> On 16.11.2017 20:42, Robert Field wrote: >> Jan, >> >> Glad you are fixing this bug, it has annoyed me! >> >> /help, after user requests, accepts command names with or without the >> slash - / >> So, the patterns need to handle "/help set ..." > > Fixed. > >> >> Nit: you allow space or tab in the pattern but only space in the >> indexOf(). Were we covering all the bases we would use "\h" accepting >> any horizontal space (not sure of the importance of this for >> internationalization). But then indexOf() would still be an issue, Maybe >> the cleanest thing to do would be to do a replaceAll("\\h+", " ") on all >> of code, first thing; then all of patterns would be much simpler. BTW: > > Done. (I was afraid there could be a problem with changing the offsets/positions inside the code, but after checking, that shouldn't be a problem.) > >> "...[^ \t]..." has the "^" in the wrong place -- but that goes away with >> the replaceAll. >> >> Can you merge with the latest repo, the changeset doesn't apply -- so, I >> can't test. > > Done. > > Jan > >> >> Thanks, >> Robert >> >>> On 11/16/17 10:33, Jan Lahoda wrote: >>> Oops, I missed that, sorry. Updated webrev: >>> http://cr.openjdk.java.net/~jlahoda/8178109/webrev.01/ >>> >>> (I tried to delegate to the command completion, but it turned out >>> there are small but significant differences in how command completion >>> and documentation needs to work, so only adding a support for /help >>> /set .) >>> >>> Jan >>> >>>> On 16.11.2017 05:59, Robert Field wrote: >>>> It looks like this code addresses the >>>> >>>> /help intro >>>> >>>> case. >>>> >>>> But there is a second case in the bug report of help on subcommands >>>> >>>> /help /set truncation >>>> >>>> For which I don't see code or tests, >>>> >>>> -Robert >>>> >>>> >>>>> On 11/15/17 06:52, Jan Lahoda wrote: >>>>> The proposal here is to change the synopsis/documentation for: >>>>> /help >>>>> >>>>> to show the synopsis/documentation for rather than for >>>>> /help. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178109 >>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8178109/webrev.00/ >>>>> >>>>> How does it look? >>>>> >>>>> Thanks, >>>>> Jan >>>> >> From xu.y.yin at oracle.com Tue Nov 21 02:54:24 2017 From: xu.y.yin at oracle.com (Chris Yin) Date: Tue, 21 Nov 2017 10:54:24 +0800 Subject: RFR 8191631/10, Problem list jdk/jshell/StartOptionTest.java, jdk/jshell/ToolProviderTest.java and jdk/jshell/ExternalEditorTest.java Message-ID: Hi, all Please review a minor change to problem list jdk/jshell/StartOptionTest.java, jdk/jshell/ToolProviderTest.java and jdk/jshell/ExternalEditorTest.java temporarily, they had been observed failure permanent recently, propose to problem-list them until the related issues been fixed Bug: https://bugs.openjdk.java.net/browse/JDK-8191631 Original issues: https://bugs.openjdk.java.net/browse/JDK-8191455 https://bugs.openjdk.java.net/browse/JDK-8191456 Patch: --- a/test/langtools/ProblemList.txt Mon Nov 20 14:27:20 2017 -0800 +++ b/test/langtools/ProblemList.txt Tue Nov 21 10:21:13 2017 +0800 @@ -38,6 +38,9 @@ jdk/jshell/UserJdiUserRemoteTest.java 8173079 linux-all jdk/jshell/UserInputTest.java 8169536 generic-all +jdk/jshell/StartOptionTest.java 8191455 windows-all +jdk/jshell/ToolProviderTest.java 8191455 windows-all +jdk/jshell/ExternalEditorTest.java 8191456 generic-all ########################################################################### # Thanks, Chris From robert.field at oracle.com Tue Nov 21 21:01:27 2017 From: robert.field at oracle.com (Robert Field) Date: Tue, 21 Nov 2017 13:01:27 -0800 Subject: RFR 8191631/10, Problem list jdk/jshell/StartOptionTest.java, jdk/jshell/ToolProviderTest.java and jdk/jshell/ExternalEditorTest.java In-Reply-To: References: Message-ID: <5A149427.8060903@oracle.com> Thumbs up. -Robert On 11/20/17 18:54, Chris Yin wrote: > Hi, all > > Please review a minor change to problem list jdk/jshell/StartOptionTest.java, jdk/jshell/ToolProviderTest.java and jdk/jshell/ExternalEditorTest.java temporarily, they had been observed failure permanent recently, propose to problem-list them until the related issues been fixed > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8191631 > > Original issues: > > https://bugs.openjdk.java.net/browse/JDK-8191455 > https://bugs.openjdk.java.net/browse/JDK-8191456 > > Patch: > > --- a/test/langtools/ProblemList.txt Mon Nov 20 14:27:20 2017 -0800 > +++ b/test/langtools/ProblemList.txt Tue Nov 21 10:21:13 2017 +0800 > @@ -38,6 +38,9 @@ > > jdk/jshell/UserJdiUserRemoteTest.java 8173079 linux-all > jdk/jshell/UserInputTest.java 8169536 generic-all > +jdk/jshell/StartOptionTest.java 8191455 windows-all > +jdk/jshell/ToolProviderTest.java 8191455 windows-all > +jdk/jshell/ExternalEditorTest.java 8191456 generic-all > > ########################################################################### > # > > > Thanks, > Chris From javaContractor at javacontractor.net Thu Nov 23 14:30:03 2017 From: javaContractor at javacontractor.net (javaContractor) Date: Thu, 23 Nov 2017 08:30:03 -0600 Subject: jshell Defectively Wraps Lines And Mangles Input in JDK 9 & JDK 10 On Windows Message-ID: <0ded80542c3b1e8465819ab70742446b.squirrel@secure.kgbinternet.com> I reported to Oracle's Bug Database, a defect that I have been encountering using jshell ever since JDK 9 ea+166; on Windows 7. I'm still experiencing the same defective behavior in my installation of JDK 9+179. Oracle has confirmed that it is also reproducible in JDK 9.1 and JDK 10. [1] The defect is ? in brief: jshell ignores a Windows command shell property and incorrectly wraps lines and horribly mangles input as a result. I describe the problem in detail in the aforementioned Oracle bug report. You can also observe the defect in action in a screen recording I uploaded. [2] I'm posting here for good measure. Maybe somebody here knows of an undocumented configuration setting I could possibly wrangle that would resolve the defect in my local installation of jshell? That would be awesome! Thanks in advance. _________________________________________________ [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8191640 [2] https://imgur.com/Pqvoc2G From jan.lahoda at oracle.com Fri Nov 24 17:11:11 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 24 Nov 2017 18:11:11 +0100 Subject: RFR 8190939: JShell: gives a compiler error evaluating an expression of inaccessible type In-Reply-To: <5A0DE24A.20700@oracle.com> References: <5A0CA297.7020703@oracle.com> <5A0DE24A.20700@oracle.com> Message-ID: <5A1852AF.7060205@oracle.com> Looks OK. Jan On 16.11.2017 20:08, Robert Field wrote: > > On 11/15/17 12:24, Jan Lahoda wrote: >> Hi Robert, >> >> Looking at: >> http://cr.openjdk.java.net/~rfield/8190939v0.webrev/src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java.udiff.html >> >> >> isAccessible is handling immediate recursion on types, but is not >> preventing recursion with intermediate types (as I think is noted in >> the comment). Can the recursion with intermediate types happen? >> >> Thanks, >> Jan > > Thanks Jan, > > Excess paranoia on my part. The concrete types of expressions are > trees. One cannot be nested within itself, directly or indirectly. > > I have removed the check, simplifying the code and removed the question > (moving the valid part of the comment to the method comment). > > Updated webrev: > > http://cr.openjdk.java.net/~rfield/8190939v1.webrev/ > > Changes only the isAccessible(Type) method in: > > http://cr.openjdk.java.net/~rfield/8190939v1.webrev/src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java.sdiff.html > > > -Robert > From robert.field at oracle.com Sat Nov 25 02:15:18 2017 From: robert.field at oracle.com (Robert Field) Date: Fri, 24 Nov 2017 18:15:18 -0800 Subject: RFR 8191455/8191456: StartOptionTest/ToolProviderTest.testExitCode() and ExternalEditorTest.testStatementMush() failed Message-ID: <5A18D236.1040302@oracle.com> Please review. Bugs: 8191455: jdk/jshell/StartOptionTest.java and jdk/jshell/ToolProviderTest.java failed after changeset e0f08a https://bugs.openjdk.java.net/browse/JDK-8191455 These saw failures on Windows due to line-end mismatches. Fixed by normalizing line-ends. 8191456: jdk/jshell/ExternalEditorTest.java testStatementMush(): failure https://bugs.openjdk.java.net/browse/JDK-8191456 The expected output is not seen, not reproducible locally, Disabled the specific test and filed issue to enable. This includes undoing: 8191631: Problem list jdk/jshell/StartOptionTest.java, jdk/jshell/ToolProviderTest.java and jdk/jshell/ExternalEditorTest.java temporarily https://bugs.openjdk.java.net/browse/JDK-8191631 Webrev: http://cr.openjdk.java.net/~rfield/8191455v0.webrev/ Thanks, Robert