From robert.field at oracle.com Tue Nov 1 04:16:33 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 31 Oct 2016 21:16:33 -0700 Subject: RFR 8167636: jshell tool: Edit Pad should be in its own module In-Reply-To: <580CBE51.9080701@oracle.com> References: <580C3929.5030108@oracle.com> <580C5E2C.9000706@oracle.com> <580CBE51.9080701@oracle.com> Message-ID: <58181721.6050505@oracle.com> New module layout: jdk.internal.ed -- built-in editor SPI and external editor support. In its own module so it can be used by other tools. jdk.editpad -- Edit Pad provider of built-in editor SPI both now in the jdk repo. Please review... Bugs: 8167636: jshell tool: Edit Pad should be in its own module https://bugs.openjdk.java.net/browse/JDK-8167636 8168972: Editor support: move built-in and external editor support to the jdk repo https://bugs.openjdk.java.net/browse/JDK-8168972 8168974: Editor support: include properties file in image https://bugs.openjdk.java.net/browse/JDK-8168974 8167639: jshell tool: Edit Pad has readability issues https://bugs.openjdk.java.net/browse/JDK-8167639 Webrevs: Langtools (8167636) http://cr.openjdk.java.net/~rfield/8167636v3.webrev/ jdk (8168972 & 8167639) http://cr.openjdk.java.net/~rfield/8168972v3.webrev/ top-level (8168974) http://cr.openjdk.java.net/~rfield/8168974v3.webrev/ Thanks, Robert ----------------------------------------------- Robert Field wrote: > Per comments: > BuildInEditorProvider now interface. > CountDownLatch hidden in EditPadProvider. > Plain old JFrame. > > > New webrev: > http://cr.openjdk.java.net/~rfield/8167636v2.webrev/ > > Thanks again, > Robert On 10/23/16 06:42, Robert Field wrote: > New version -- > > Both runtime-time and compile-time dependency on ActionListener (and > thus java.desktop) removed from ConsoleIOContext. > All key sequences work on jlinked image without desktop. > > Webrev: > http://cr.openjdk.java.net/~rfield/8167636v1.webrev/ > > -Robert > > On 10/22/16 23:52, Robert Field wrote: >> Note: jdk.internal.le and thus the jshell tool's ConsoleIOContext >> have a dependency on java.awt.event.ActionListener. >> The former uses reflection to quietly ignore when it isn't present -- >> at a loss of functionality (functionality we use). >> This code has a hack until I can discuss with Jan what the options are. >> Ideally jdk.internal.le can lose it's dependency; Otherwise, I will >> change ConsoleIOContext to use reflection, which will mean a loss of >> shift-tab and shortcut+* functionality when java.desktop is not in >> the image. >> >> -Robert >> >> >> On 10/22/16 21:14, Robert Field wrote: >>> Remove the dependency of the jshell tool on the java.desktop module. >>> Uses modules and ServiceLoader so that Edit Pad is optional -- that >>> is, a jlink'ed image can be produced without Edit Pad and without >>> java.desktop >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8167636 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rfield/8167636v0.webrev/ >>> >>> Thanks, >>> Robert >>> >> > From jan.lahoda at oracle.com Tue Nov 1 12:45:29 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 1 Nov 2016 13:45:29 +0100 Subject: RFR 8167636: jshell tool: Edit Pad should be in its own module In-Reply-To: <58181721.6050505@oracle.com> References: <580C3929.5030108@oracle.com> <580C5E2C.9000706@oracle.com> <580CBE51.9080701@oracle.com> <58181721.6050505@oracle.com> Message-ID: <58188E69.6000604@oracle.com> Seems fine to me. Jan On 1.11.2016 05:16, Robert Field wrote: > New module layout: > > jdk.internal.ed -- built-in editor SPI and external editor support. > In its own module so it can be used by other tools. > > jdk.editpad -- Edit Pad provider of built-in editor SPI > > both now in the jdk repo. > > Please review... > > Bugs: > > 8167636: jshell tool: Edit Pad should be in its own module > https://bugs.openjdk.java.net/browse/JDK-8167636 > > 8168972: Editor support: move built-in and external editor > support to the jdk repo > https://bugs.openjdk.java.net/browse/JDK-8168972 > > 8168974: Editor support: include properties file in image > https://bugs.openjdk.java.net/browse/JDK-8168974 > > 8167639: jshell tool: Edit Pad has readability issues > https://bugs.openjdk.java.net/browse/JDK-8167639 > > Webrevs: > > Langtools (8167636) > http://cr.openjdk.java.net/~rfield/8167636v3.webrev/ > > jdk (8168972 & 8167639) > http://cr.openjdk.java.net/~rfield/8168972v3.webrev/ > > top-level (8168974) > http://cr.openjdk.java.net/~rfield/8168974v3.webrev/ > > Thanks, > Robert > > ----------------------------------------------- > > Robert Field wrote: >> Per comments: >> BuildInEditorProvider now interface. >> CountDownLatch hidden in EditPadProvider. >> Plain old JFrame. >> >> >> New webrev: >> http://cr.openjdk.java.net/~rfield/8167636v2.webrev/ >> >> Thanks again, >> Robert > > On 10/23/16 06:42, Robert Field wrote: >> New version -- >> >> Both runtime-time and compile-time dependency on ActionListener (and >> thus java.desktop) removed from ConsoleIOContext. >> All key sequences work on jlinked image without desktop. >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8167636v1.webrev/ >> >> -Robert >> >> On 10/22/16 23:52, Robert Field wrote: >>> Note: jdk.internal.le and thus the jshell tool's ConsoleIOContext >>> have a dependency on java.awt.event.ActionListener. >>> The former uses reflection to quietly ignore when it isn't present -- >>> at a loss of functionality (functionality we use). >>> This code has a hack until I can discuss with Jan what the options are. >>> Ideally jdk.internal.le can lose it's dependency; Otherwise, I will >>> change ConsoleIOContext to use reflection, which will mean a loss of >>> shift-tab and shortcut+* functionality when java.desktop is not in >>> the image. >>> >>> -Robert >>> >>> >>> On 10/22/16 21:14, Robert Field wrote: >>>> Remove the dependency of the jshell tool on the java.desktop module. >>>> Uses modules and ServiceLoader so that Edit Pad is optional -- that >>>> is, a jlink'ed image can be produced without Edit Pad and without >>>> java.desktop >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8167636 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rfield/8167636v0.webrev/ >>>> >>>> Thanks, >>>> Robert >>>> >>> >> > From jan.lahoda at oracle.com Tue Nov 1 12:59:04 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 1 Nov 2016 13:59:04 +0100 Subject: RFR 8131019: jshell tool: access javadoc from tool In-Reply-To: <58121199.1090609@oracle.com> References: <5804F760.5050509@oracle.com> <58101982.6050006@oracle.com> <5810E947.9060403@oracle.com> <58116BBC.4090300@oracle.com> <58121199.1090609@oracle.com> Message-ID: <58189198.6070600@oracle.com> An updated webrev that tweaks the javadoc for the SourceCodeAnalysis.documentation method (no other changes): http://cr.openjdk.java.net/~jlahoda/8131019/webrev.03/ http://cr.openjdk.java.net/~jlahoda/8131019/webrev.03/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java.udiff.html How does that look? Thanks, Jan On 27.10.2016 16:39, Jan Lahoda wrote: > A slightly updated patch: > http://cr.openjdk.java.net/~jlahoda/8131019/webrev.02/ > > Changes: > -support for modularized src.zip (SourceCodeAnalysisImpl) > - handling ("alt" attribute is printed), as suggested > -handling for
,
and
> > How does this look? > > Thanks, > Jan > > On 27.10.2016 04:51, Jonathan Gibbons wrote: >> Looks OK to me. >> >> -- Jon >> >> On 10/26/2016 10:35 AM, Jan Lahoda wrote: >>> Thanks for all the comments so far. An updated webrev reflecting the >>> comments is here: >>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.01/ >>> >>> Also needs this change to the top-level repository: >>> http://cr.openjdk.java.net/~jlahoda/8131019/toplevel.01/ >>> >>> Summary of changes: >>> -the text adjustment suggested by Robert >>> -the output is paginated, and pauses after methods (if another method >>> follows) >>> -most of the comments below have been addressed (some more comments >>> inlined). >>> >>> On 26.10.2016 04:48, Jonathan Gibbons wrote: >>>> >>>> >>>> On 10/17/2016 09:08 AM, Jan Lahoda wrote: >>>>> Hello, >>>>> >>>>> This patch adds ability to show javadoc inside JShell (by showingg it >>>>> on the second invocation of the Shift- documentation). In >>>>> addition to jdk.jshell changes, there is a support in jdk.compiler, >>>>> that is expected to be reused by jjs. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8131019 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.00/ >>>>> >>>>> Any feedback is welcome! >>>>> >>>>> Thanks, >>>>> Jan >>>> >>>> The file >>>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javadocformatter.properties >>>> >>>> >>>> >>>> doesn't seem like it belongs in com/sun/tools/javac/resources. >>> >>> Moved to: >>> src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/resources/javadocformatter.properties >>> >>> >>> >>>> >>>> It would be nice to provide and use String constants for the ANSI >>>> escape >>>> sequences. >>> >>> Using constants now. >>> >>>> >>>> JavadocFormatter.java:113 -- ex.printStackTrace seems suspect, >>>> especially as there seems >>>> to be better infrastructure for handling unwanted exceptions elsewhere >>>> in JShell. >>> >>> Should not normally happen, I think, so I changed that to throw >>> InternalError. >>> >>>> >>>> JavadocFormatter.java:183 -- no distinguished handling for type >>>> parameters >>> >>> Fixed. >>> >>>> >>>> JavadocFormatter.java:240 -- is it safe to assume lower case tags at >>>> this point? If it helps, >>>> you could leverage com.sun.tools.doclint.HtmlTag >>> >>> Using HtmlTag now. >>> >>>> >>>> JavadocFormatter.java:356 -- (general comment) what about invalid HTML >>>> input. >>>> Yes, JDK javadoc comments are reasonably good these days, but that >>>> doesn't apply >>>> everywhere. >>> >>> I tried to fix the formatter so that it does not crash on broken HTML. >>> The output may not be ideal, though. >>> >>>> >>>> JavadocFormatter.java:333 -- no explicit handling for

>>> >>> Is it necessary to handle the closing tag? >>> >>>> >>>> JavadocFormatter.java:444 -- suggest moving resource file >>>> Just curious, why the CAP prefix? >>> >>> That's for "caption". >>> >>>> >>>> JavaDocFormatter.java:visitEndElement: it is common to see optional end >>>> tags omitted, like >>>> , , >>>> This could screw up the stacks. If is omitted, won't you >>>> skip >>>> printing the row? >>> >>> I've tried to fix the "tr" problem. Added tests for missing closing >>> "td" (there were existing tests for missing closing "li"). >>> >>>> >>>> JavadocFormatter.java:409 >>>> Ignoring , will mean that vertical whitespace between >>>> table cell elements >>>> may be incorporated into the table cell itself, won't it? I guess >>>> in general, it'll all be >>>> collapsed into a space character, so in general you'll be OK >>> >>> I tried to clear out the whitespaces so that these should get >>> eliminated (but they would probably not be a big deal). >>> >>>> >>>> JavadocFormatter.java >>>> No support for entities, including < > & >>> >>> Done. >>> >>>> >>>> JavadocHelper.java >>>> I haven't figured out how the {@inheritDoc} resolver is working, >>>> insofar as how are you >>>> working with the issue that you have to create a new JavacTask for >>>> each tree that you >>>> parse, which means separate distinct components like Names, >>>> Symtab, >>>> and all the other >>>> javac internal classes. In particular, when you start computing >>>> supertypes, how do >>>> you coordinate the different elements provided by the different >>>> JavacTask objects? >>> >>> Mapping from the original JavacTask to the new one is done using a >>> "handle" (the "elementSignature" will produce a textual representation >>> of an Element which is found in the newly parsed source). The >>> resulting javadoc is a plain text (with @inheritDoc resolved). >>> >>> Any feedback is welcome. >>> >>> Thanks! >>> >>> Jan >>> >>> >>>> >>>> -- Jon >> From robert.field at oracle.com Tue Nov 1 15:18:54 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 01 Nov 2016 08:18:54 -0700 Subject: RFR 8131019: jshell tool: access javadoc from tool In-Reply-To: <58189198.6070600@oracle.com> References: <5804F760.5050509@oracle.com> <58101982.6050006@oracle.com> <5810E947.9060403@oracle.com> <58116BBC.4090300@oracle.com> <58121199.1090609@oracle.com> <58189198.6070600@oracle.com> Message-ID: <5818B25E.5040602@oracle.com> New doc looks good. + * @return the javadoc, or null if not found Maybe this should be seomthing like: ... or null if not found or not requested -Robert On 11/01/16 05:59, Jan Lahoda wrote: > An updated webrev that tweaks the javadoc for the > SourceCodeAnalysis.documentation method (no other changes): > http://cr.openjdk.java.net/~jlahoda/8131019/webrev.03/ > > http://cr.openjdk.java.net/~jlahoda/8131019/webrev.03/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java.udiff.html > > > How does that look? > > Thanks, > Jan > > On 27.10.2016 16:39, Jan Lahoda wrote: >> A slightly updated patch: >> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.02/ >> >> Changes: >> -support for modularized src.zip (SourceCodeAnalysisImpl) >> - handling ("alt" attribute is printed), as suggested >> -handling for
,
and
>> >> How does this look? >> >> Thanks, >> Jan >> >> On 27.10.2016 04:51, Jonathan Gibbons wrote: >>> Looks OK to me. >>> >>> -- Jon >>> >>> On 10/26/2016 10:35 AM, Jan Lahoda wrote: >>>> Thanks for all the comments so far. An updated webrev reflecting the >>>> comments is here: >>>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.01/ >>>> >>>> Also needs this change to the top-level repository: >>>> http://cr.openjdk.java.net/~jlahoda/8131019/toplevel.01/ >>>> >>>> Summary of changes: >>>> -the text adjustment suggested by Robert >>>> -the output is paginated, and pauses after methods (if another method >>>> follows) >>>> -most of the comments below have been addressed (some more comments >>>> inlined). >>>> >>>> On 26.10.2016 04:48, Jonathan Gibbons wrote: >>>>> >>>>> >>>>> On 10/17/2016 09:08 AM, Jan Lahoda wrote: >>>>>> Hello, >>>>>> >>>>>> This patch adds ability to show javadoc inside JShell (by >>>>>> showingg it >>>>>> on the second invocation of the Shift- documentation). In >>>>>> addition to jdk.jshell changes, there is a support in jdk.compiler, >>>>>> that is expected to be reused by jjs. >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8131019 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.00/ >>>>>> >>>>>> Any feedback is welcome! >>>>>> >>>>>> Thanks, >>>>>> Jan >>>>> >>>>> The file >>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javadocformatter.properties >>>>> >>>>> >>>>> >>>>> >>>>> doesn't seem like it belongs in com/sun/tools/javac/resources. >>>> >>>> Moved to: >>>> src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/resources/javadocformatter.properties >>>> >>>> >>>> >>>> >>>>> >>>>> It would be nice to provide and use String constants for the ANSI >>>>> escape >>>>> sequences. >>>> >>>> Using constants now. >>>> >>>>> >>>>> JavadocFormatter.java:113 -- ex.printStackTrace seems suspect, >>>>> especially as there seems >>>>> to be better infrastructure for handling unwanted exceptions >>>>> elsewhere >>>>> in JShell. >>>> >>>> Should not normally happen, I think, so I changed that to throw >>>> InternalError. >>>> >>>>> >>>>> JavadocFormatter.java:183 -- no distinguished handling for type >>>>> parameters >>>> >>>> Fixed. >>>> >>>>> >>>>> JavadocFormatter.java:240 -- is it safe to assume lower case tags at >>>>> this point? If it helps, >>>>> you could leverage com.sun.tools.doclint.HtmlTag >>>> >>>> Using HtmlTag now. >>>> >>>>> >>>>> JavadocFormatter.java:356 -- (general comment) what about invalid >>>>> HTML >>>>> input. >>>>> Yes, JDK javadoc comments are reasonably good these days, but that >>>>> doesn't apply >>>>> everywhere. >>>> >>>> I tried to fix the formatter so that it does not crash on broken HTML. >>>> The output may not be ideal, though. >>>> >>>>> >>>>> JavadocFormatter.java:333 -- no explicit handling for

>>>> >>>> Is it necessary to handle the closing tag? >>>> >>>>> >>>>> JavadocFormatter.java:444 -- suggest moving resource file >>>>> Just curious, why the CAP prefix? >>>> >>>> That's for "caption". >>>> >>>>> >>>>> JavaDocFormatter.java:visitEndElement: it is common to see >>>>> optional end >>>>> tags omitted, like >>>>> , , >>>>> This could screw up the stacks. If is omitted, won't you >>>>> skip >>>>> printing the row? >>>> >>>> I've tried to fix the "tr" problem. Added tests for missing closing >>>> "td" (there were existing tests for missing closing "li"). >>>> >>>>> >>>>> JavadocFormatter.java:409 >>>>> Ignoring , will mean that vertical whitespace between >>>>> table cell elements >>>>> may be incorporated into the table cell itself, won't it? I >>>>> guess >>>>> in general, it'll all be >>>>> collapsed into a space character, so in general you'll be OK >>>> >>>> I tried to clear out the whitespaces so that these should get >>>> eliminated (but they would probably not be a big deal). >>>> >>>>> >>>>> JavadocFormatter.java >>>>> No support for entities, including < > & >>>> >>>> Done. >>>> >>>>> >>>>> JavadocHelper.java >>>>> I haven't figured out how the {@inheritDoc} resolver is working, >>>>> insofar as how are you >>>>> working with the issue that you have to create a new >>>>> JavacTask for >>>>> each tree that you >>>>> parse, which means separate distinct components like Names, >>>>> Symtab, >>>>> and all the other >>>>> javac internal classes. In particular, when you start computing >>>>> supertypes, how do >>>>> you coordinate the different elements provided by the different >>>>> JavacTask objects? >>>> >>>> Mapping from the original JavacTask to the new one is done using a >>>> "handle" (the "elementSignature" will produce a textual representation >>>> of an Element which is found in the newly parsed source). The >>>> resulting javadoc is a plain text (with @inheritDoc resolved). >>>> >>>> Any feedback is welcome. >>>> >>>> Thanks! >>>> >>>> Jan >>>> >>>> >>>>> >>>>> -- Jon >>> From jan.lahoda at oracle.com Tue Nov 1 16:44:00 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 1 Nov 2016 17:44:00 +0100 Subject: RFR 8131019: jshell tool: access javadoc from tool In-Reply-To: <5818B25E.5040602@oracle.com> References: <5804F760.5050509@oracle.com> <58101982.6050006@oracle.com> <5810E947.9060403@oracle.com> <58116BBC.4090300@oracle.com> <58121199.1090609@oracle.com> <58189198.6070600@oracle.com> <5818B25E.5040602@oracle.com> Message-ID: <5818C650.9030109@oracle.com> Sure, will do. Jan On 1.11.2016 16:18, Robert Field wrote: > New doc looks good. > > + * @return the javadoc, or null if not found > > Maybe this should be seomthing like: ... or null if not found or not > requested > > -Robert > > > On 11/01/16 05:59, Jan Lahoda wrote: >> An updated webrev that tweaks the javadoc for the >> SourceCodeAnalysis.documentation method (no other changes): >> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.03/ >> >> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.03/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java.udiff.html >> >> >> How does that look? >> >> Thanks, >> Jan >> >> On 27.10.2016 16:39, Jan Lahoda wrote: >>> A slightly updated patch: >>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.02/ >>> >>> Changes: >>> -support for modularized src.zip (SourceCodeAnalysisImpl) >>> - handling ("alt" attribute is printed), as suggested >>> -handling for
,
and
>>> >>> How does this look? >>> >>> Thanks, >>> Jan >>> >>> On 27.10.2016 04:51, Jonathan Gibbons wrote: >>>> Looks OK to me. >>>> >>>> -- Jon >>>> >>>> On 10/26/2016 10:35 AM, Jan Lahoda wrote: >>>>> Thanks for all the comments so far. An updated webrev reflecting the >>>>> comments is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.01/ >>>>> >>>>> Also needs this change to the top-level repository: >>>>> http://cr.openjdk.java.net/~jlahoda/8131019/toplevel.01/ >>>>> >>>>> Summary of changes: >>>>> -the text adjustment suggested by Robert >>>>> -the output is paginated, and pauses after methods (if another method >>>>> follows) >>>>> -most of the comments below have been addressed (some more comments >>>>> inlined). >>>>> >>>>> On 26.10.2016 04:48, Jonathan Gibbons wrote: >>>>>> >>>>>> >>>>>> On 10/17/2016 09:08 AM, Jan Lahoda wrote: >>>>>>> Hello, >>>>>>> >>>>>>> This patch adds ability to show javadoc inside JShell (by >>>>>>> showingg it >>>>>>> on the second invocation of the Shift- documentation). In >>>>>>> addition to jdk.jshell changes, there is a support in jdk.compiler, >>>>>>> that is expected to be reused by jjs. >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8131019 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8131019/webrev.00/ >>>>>>> >>>>>>> Any feedback is welcome! >>>>>>> >>>>>>> Thanks, >>>>>>> Jan >>>>>> >>>>>> The file >>>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javadocformatter.properties >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> doesn't seem like it belongs in com/sun/tools/javac/resources. >>>>> >>>>> Moved to: >>>>> src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/resources/javadocformatter.properties >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> It would be nice to provide and use String constants for the ANSI >>>>>> escape >>>>>> sequences. >>>>> >>>>> Using constants now. >>>>> >>>>>> >>>>>> JavadocFormatter.java:113 -- ex.printStackTrace seems suspect, >>>>>> especially as there seems >>>>>> to be better infrastructure for handling unwanted exceptions >>>>>> elsewhere >>>>>> in JShell. >>>>> >>>>> Should not normally happen, I think, so I changed that to throw >>>>> InternalError. >>>>> >>>>>> >>>>>> JavadocFormatter.java:183 -- no distinguished handling for type >>>>>> parameters >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> JavadocFormatter.java:240 -- is it safe to assume lower case tags at >>>>>> this point? If it helps, >>>>>> you could leverage com.sun.tools.doclint.HtmlTag >>>>> >>>>> Using HtmlTag now. >>>>> >>>>>> >>>>>> JavadocFormatter.java:356 -- (general comment) what about invalid >>>>>> HTML >>>>>> input. >>>>>> Yes, JDK javadoc comments are reasonably good these days, but that >>>>>> doesn't apply >>>>>> everywhere. >>>>> >>>>> I tried to fix the formatter so that it does not crash on broken HTML. >>>>> The output may not be ideal, though. >>>>> >>>>>> >>>>>> JavadocFormatter.java:333 -- no explicit handling for

>>>>> >>>>> Is it necessary to handle the closing tag? >>>>> >>>>>> >>>>>> JavadocFormatter.java:444 -- suggest moving resource file >>>>>> Just curious, why the CAP prefix? >>>>> >>>>> That's for "caption". >>>>> >>>>>> >>>>>> JavaDocFormatter.java:visitEndElement: it is common to see >>>>>> optional end >>>>>> tags omitted, like >>>>>> , , >>>>>> This could screw up the stacks. If is omitted, won't you >>>>>> skip >>>>>> printing the row? >>>>> >>>>> I've tried to fix the "tr" problem. Added tests for missing closing >>>>> "td" (there were existing tests for missing closing "li"). >>>>> >>>>>> >>>>>> JavadocFormatter.java:409 >>>>>> Ignoring , will mean that vertical whitespace between >>>>>> table cell elements >>>>>> may be incorporated into the table cell itself, won't it? I >>>>>> guess >>>>>> in general, it'll all be >>>>>> collapsed into a space character, so in general you'll be OK >>>>> >>>>> I tried to clear out the whitespaces so that these should get >>>>> eliminated (but they would probably not be a big deal). >>>>> >>>>>> >>>>>> JavadocFormatter.java >>>>>> No support for entities, including < > & >>>>> >>>>> Done. >>>>> >>>>>> >>>>>> JavadocHelper.java >>>>>> I haven't figured out how the {@inheritDoc} resolver is working, >>>>>> insofar as how are you >>>>>> working with the issue that you have to create a new >>>>>> JavacTask for >>>>>> each tree that you >>>>>> parse, which means separate distinct components like Names, >>>>>> Symtab, >>>>>> and all the other >>>>>> javac internal classes. In particular, when you start computing >>>>>> supertypes, how do >>>>>> you coordinate the different elements provided by the different >>>>>> JavacTask objects? >>>>> >>>>> Mapping from the original JavacTask to the new one is done using a >>>>> "handle" (the "elementSignature" will produce a textual representation >>>>> of an Element which is found in the newly parsed source). The >>>>> resulting javadoc is a plain text (with @inheritDoc resolved). >>>>> >>>>> Any feedback is welcome. >>>>> >>>>> Thanks! >>>>> >>>>> Jan >>>>> >>>>> >>>>>> >>>>>> -- Jon >>>> > From robert.field at oracle.com Wed Nov 2 02:47:37 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 01 Nov 2016 19:47:37 -0700 Subject: RFR 8129559: JShell: compilation fails if class, method or field is annotated and has modifiers Message-ID: <581953C9.5010707@oracle.com> Please review.... Bugs: 8129559: JShell: compilation fails if class, method or field is annotated and has modifiers https://bugs.openjdk.java.net/browse/JDK-8129559 8080354: JShell: Runtime visible annotations cannot be retrieved https://bugs.openjdk.java.net/browse/JDK-8080354 Webrev: http://cr.openjdk.java.net/~rfield/8129559v0.webrev/ Thanks, Robert From robert.field at oracle.com Thu Nov 3 00:33:55 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 02 Nov 2016 17:33:55 -0700 Subject: RFR 8161983: JShell API: Clean-up following 8160127 et. al. Message-ID: <581A85F3.2040500@oracle.com> Important: please read bug for context and description of the work. Bug: https://bugs.openjdk.java.net/browse/JDK-8161983 Webrev: http://cr.openjdk.java.net/~rfield/8161983v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Thu Nov 3 14:35:11 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 3 Nov 2016 15:35:11 +0100 Subject: RFR 8161969, 8166637, 8154513, 8167552: jshell tool: ... truncation, welcome, /reload help In-Reply-To: <5812C6D5.2040901@oracle.com> References: <5812C6D5.2040901@oracle.com> Message-ID: <581B4B1F.4010401@oracle.com> Seems OK to me. Jan On 28.10.2016 05:32, Robert Field wrote: > Please review the fix to these four bugs: > > Bugs: > > 8161969: jshell tool: /var value is not truncated per feedback setting > https://bugs.openjdk.java.net/browse/JDK-8161969 > > 8166637: jshell tool: confusing truncation of long result values > https://bugs.openjdk.java.net/browse/JDK-8166637 > > 8154513: JShell tool: welcome message should match feedback mode > https://bugs.openjdk.java.net/browse/JDK-8154513 > > 8167552: jshell tool: Typo in jshell command '/? /reload' description > https://bugs.openjdk.java.net/browse/JDK-8167552 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8161969v0.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Thu Nov 3 15:10:14 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 3 Nov 2016 16:10:14 +0100 Subject: RFR 8161983: JShell API: Clean-up following 8160127 et. al. In-Reply-To: <581A85F3.2040500@oracle.com> References: <581A85F3.2040500@oracle.com> Message-ID: <581B5356.4000007@oracle.com> The patch itself seems OK, but I wonder about the JDI->Jdi rename, is it a recommendation for abbreviations to have only the first letter capitalized in classnames? I was looking for precedents (JDI/Jdi, XML/Xml, HTML/Html), and the usages seem to be mixed. W.r.t. to JDI, I found only JDIPermission. Thanks, Jan On 3.11.2016 01:33, Robert Field wrote: > Important: please read bug for context and description of the work. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8161983 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8161983v0.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Thu Nov 3 15:25:07 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 3 Nov 2016 16:25:07 +0100 Subject: RFR 8129559: JShell: compilation fails if class, method or field is annotated and has modifiers In-Reply-To: <581953C9.5010707@oracle.com> References: <581953C9.5010707@oracle.com> Message-ID: <581B56D3.3090601@oracle.com> Ok, I think. I wonder if it wouldn't be easier to use javac's lexer (JavaTokenizer) to detect the comments, and/or JavacParser.modifiersOpt to detect the modifiers. BTW, should Unicode escapes be supported? Jan On 2.11.2016 03:47, Robert Field wrote: > Please review.... > > Bugs: > > 8129559: JShell: compilation fails if class, method or field is > annotated and has modifiers > https://bugs.openjdk.java.net/browse/JDK-8129559 > > 8080354: JShell: Runtime visible annotations cannot be retrieved > https://bugs.openjdk.java.net/browse/JDK-8080354 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8129559v0.webrev/ > > Thanks, > Robert > From germano.carella at gmail.com Thu Nov 3 16:03:58 2016 From: germano.carella at gmail.com (germano.carella at gmail.com) Date: Thu, 3 Nov 2016 17:03:58 +0100 Subject: New of java, some questions Message-ID: <581b5fe9.a59dc20a.4bce.f9ea@mx.google.com> Hi, I?m new of java, i?m Learning. So I decided to install java 9, ?cause it contains jshell. I seen kulla project and I?m wondering if it?s the same jshell I found in jdk 9. I?m on Windows 10. Ok, so, I started jshell and I tried some examples. I read cannot import sun packages. I can import com.sun.* but anything else. I read about java modules and tried some example on building my own jmod file. So, There is a way to try this jmod in jshell? If kulla is an other project jre independent, can you help me to understand how to install it on Windows? Sorry, but I?m very confused. Thanks, Germano Inviato da Posta per Windows 10 From robert.field at oracle.com Thu Nov 3 16:18:13 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 03 Nov 2016 09:18:13 -0700 Subject: New of java, some questions In-Reply-To: <581b5fe9.a59dc20a.4bce.f9ea@mx.google.com> References: <581b5fe9.a59dc20a.4bce.f9ea@mx.google.com> Message-ID: <581B6345.7040109@oracle.com> Hi Germano, Yes, it is the same jshell. But development moved from kulla to JDK 9, so the JDK 9 version is much newer. The sun.* packages are internal implementations, they should not be used outside the development of the JDK. No, jshell cannot be used to create modules. The jshell tool is part of the JDK not the JRE. Enjoy, Robert On 11/03/16 09:03, germano.carella at gmail.com wrote: > Hi, > I?m new of java, i?m Learning. > So I decided to install java 9, ?cause it contains jshell. > I seen kulla project and I?m wondering if it?s the same jshell I found in jdk 9. > I?m on Windows 10. > Ok, so, I started jshell and I tried some examples. > I read cannot import sun packages. > I can import com.sun.* but anything else. > I read about java modules and tried some example on building my own jmod file. > So, There is a way to try this jmod in jshell? > If kulla is an other project jre independent, can you help me to understand how to install it on Windows? > Sorry, but I?m very confused. > Thanks, > Germano > > > Inviato da Posta per Windows 10 > From robert.field at oracle.com Thu Nov 3 16:34:51 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 03 Nov 2016 09:34:51 -0700 Subject: RFR 8161983: JShell API: Clean-up following 8160127 et. al. In-Reply-To: <581B5356.4000007@oracle.com> References: <581A85F3.2040500@oracle.com> <581B5356.4000007@oracle.com> Message-ID: <581B672B.5080303@oracle.com> On 11/03/16 08:10, Jan Lahoda wrote: > The patch itself seems OK, but I wonder about the JDI->Jdi rename, is > it a recommendation for abbreviations to have only the first letter > capitalized in classnames? I was looking for precedents (JDI/Jdi, > XML/Xml, HTML/Html), and the usages seem to be mixed. W.r.t. to JDI, I > found only JDIPermission. A couple years ago we were working on a langtools style guide. It never got "finished" (which is unfortunate), but did represent consensus of opinion. I tracked the current inarnation to here: http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html I have mixed feelings about abbreviation capitalization, but the relevant section is here: http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-class-interface-and-enum-names And this makes to differentiate from constants. And standards (to the extent they exist) are important to follow. -Robert > > Thanks, > Jan > > On 3.11.2016 01:33, Robert Field wrote: >> Important: please read bug for context and description of the work. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8161983 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8161983v0.webrev/ >> >> Thanks, >> Robert >> From robert.field at oracle.com Thu Nov 3 17:11:03 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 03 Nov 2016 10:11:03 -0700 Subject: RFR 8129559: JShell: compilation fails if class, method or field is annotated and has modifiers In-Reply-To: <581B56D3.3090601@oracle.com> References: <581953C9.5010707@oracle.com> <581B56D3.3090601@oracle.com> Message-ID: <581B6FA7.702@oracle.com> On 11/03/16 08:25, Jan Lahoda wrote: > Ok, I think. I wonder if it wouldn't be easier to use javac's lexer > (JavaTokenizer) to detect the comments, and/or > JavacParser.modifiersOpt to detect the modifiers. Tokens.Comment does not seem to have start/end position in any obvious way. And, that would, of course, be a rewrite. > BTW, should Unicode escapes be supported? Yes. Perhaps that should be handled as a separate issue. -Robert > > Jan > > On 2.11.2016 03:47, Robert Field wrote: >> Please review.... >> >> Bugs: >> >> 8129559: JShell: compilation fails if class, method or field is >> annotated and has modifiers >> https://bugs.openjdk.java.net/browse/JDK-8129559 >> >> 8080354: JShell: Runtime visible annotations cannot be retrieved >> https://bugs.openjdk.java.net/browse/JDK-8080354 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8129559v0.webrev/ >> >> Thanks, >> Robert >> From germano.carella at gmail.com Fri Nov 4 12:16:01 2016 From: germano.carella at gmail.com (germano.carella at gmail.com) Date: Fri, 4 Nov 2016 13:16:01 +0100 Subject: Some questions on jshell Message-ID: <581c7bfa.04e51c0a.38fa4.5e77@mx.google.com> Hi to all, I?m Germano from Italy. I started java 9 experience and I downloaded last release (jdk-9 142) from java.net. Now, i started jshell to try some java statemente. All works correctly, so I read some sample from internet to learn java. I notice that many samples use sun.* classes, but jshell won?t import them. I am able to show sun.* classes but I cannot import anything. It is normal? There is a way to import sun.* classes or there are obsolete? An other question: I read I can create modules. I tried simple example and I created a jmod file that I copied in my own directory. Does jshell import these modules? I seen java has jmods directory, but I cannot use these jmods files. There is variable can I set to import jmods in jshell? I did not find documentation on how to use jmods in jshell. Thanks for answer, Germano Inviato da Posta per Windows 10 From robert.field at oracle.com Thu Nov 10 04:01:34 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 09 Nov 2016 20:01:34 -0800 Subject: RFR 8169519: JShell: Handle start-up failures and hangs gracefully Message-ID: <5823F11E.9010109@oracle.com> JShell: Handle start-up failures and hangs gracefully -- specifically -- Add time-outs so hangs do not lock out users and so fail-over can function. Handle failures more gracefully, including cleaning up remote process. Fail-fast for better user-experience and better failure handling. Surface failure in API. Add testing hooks. Better failure information. Bugs: 8169519: JShell: Handle start-up failures and hangs gracefully https://bugs.openjdk.java.net/browse/JDK-8169519 8166581: JShell: locks forever if -R options is wrong https://bugs.openjdk.java.net/browse/JDK-8166581 Webrev: http://cr.openjdk.java.net/~rfield/8169519v0.webrev/ Specdiff: http://cr.openjdk.java.net/~rfield/8169519v0.specdiff/overview-summary.html JShell API: http://cr.openjdk.java.net/~rfield/8169519v0.jshellAPI/ Thanks, Robert From robert.field at oracle.com Fri Nov 11 04:30:47 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 10 Nov 2016 20:30:47 -0800 Subject: JShell: Input requested -- variable creation short-cut -- import? Message-ID: <58254977.1010200@oracle.com> There are currently two shortcut options: v Convert expression to variable i Import type Where the key is either Alt-F1 or Alt-Enter. Current behavior (annotated with invisible keystrokes) -- % jshell --no-startup | Welcome to JShell -- Version 9-internal | For an introduction type: /help intro jshell> Patterni 0: Do nothing 1: import: java.util.regex.Pattern Choice: 1 Imported: java.util.regex.Pattern jshell> Pattern.compile("a.*b").matcher("acccccb")v jshell> java.util.regex.Matcher m = Pattern.compile("a.*b").matcher("acccccb") m ==> java.util.regex.Matcher[pattern=a.*b region=0,7 lastmatch=] Note that the resultant variable is created with the fully qualified type. Here is a prototype that combines these functionalities -- jshell> Pattern.compile("a.*b").matcher("acccccb")x 0: Do nothing 1: Create variable 2: import: java.util.regex.Matcher. Create variable Choice: 2 Imported: java.util.regex.Matcher jshell> Matcher m = Pattern.compile("a.*b").matcher("acccccb") m ==> java.util.regex.Matcher[pattern=a.*b region=0,7 lastmatch=] Note: both the import and the simple type name. Thoughts? This could be the default behavior of v or have a different shortcut letter -- but what? Note: there is no menu with this if there is no need for an import -- just converts to variable form. For people who care about such things, this is the bug: https://bugs.openjdk.java.net/browse/JDK-8166333 and prototype webrev: http://cr.openjdk.java.net/~rfield/8166333v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Fri Nov 11 17:49:56 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 11 Nov 2016 18:49:56 +0100 Subject: RFR JDK-8169595: jshell tool: pasting multiple lines hangs input Message-ID: <582604C4.9040107@oracle.com> Hi, There's a code in jdk.internal.le to query cursor position. This is done by writing an escape code to the output, and reading an escape code with the cursor position from the input. As the input may also contain user's input, the read text may look like "\033[72;9R". There is a regexp pattern to recognize the cursor position code, but it won't match the text if contains line endings. This patch adds DOTALL to the pattern, so it will match the user's input even if it is multi-line. Bug: https://bugs.openjdk.java.net/browse/JDK-8169595 Webrev: http://cr.openjdk.java.net/~jlahoda/8169595/webrev.00/ Any comments are welcome! Thanks, Jan From robert.field at oracle.com Fri Nov 11 18:08:16 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 11 Nov 2016 10:08:16 -0800 Subject: RFR jshell tool: shortcut var does not import its type Message-ID: <58260910.8040505@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8166333 Webrev: http://cr.openjdk.java.net/~rfield/8166333v1.webrev/ Thanks, Robert From robert.field at oracle.com Fri Nov 11 18:16:51 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 11 Nov 2016 10:16:51 -0800 Subject: RFR JDK-8169595: jshell tool: pasting multiple lines hangs input In-Reply-To: <582604C4.9040107@oracle.com> References: <582604C4.9040107@oracle.com> Message-ID: <58260B13.4070607@oracle.com> Thumbs up! -Robert On 11/11/16 09:49, Jan Lahoda wrote: > Hi, > > There's a code in jdk.internal.le to query cursor position. This is > done by writing an escape code to the output, and reading an escape > code with the cursor position from the input. As the input may also > contain user's input, the read text may look like > "\033[72;9R". There is a regexp pattern to recognize the > cursor position code, but it won't match the text if > contains line endings. > > This patch adds DOTALL to the pattern, so it will match the user's > input even if it is multi-line. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169595 > Webrev: http://cr.openjdk.java.net/~jlahoda/8169595/webrev.00/ > > Any comments are welcome! > > Thanks, > Jan From jan.lahoda at oracle.com Fri Nov 11 18:56:39 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 11 Nov 2016 19:56:39 +0100 Subject: RFR jshell tool: shortcut var does not import its type In-Reply-To: <58260910.8040505@oracle.com> References: <58260910.8040505@oracle.com> Message-ID: <58261467.3070206@oracle.com> Seems OK. Jan On 11.11.2016 19:08, Robert Field wrote: > Please review. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8166333 > > Webrev: > http://cr.openjdk.java.net/~rfield/8166333v1.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Fri Nov 11 22:59:22 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 11 Nov 2016 14:59:22 -0800 Subject: RFR 8143006: jshell tool: /edit doesn't process each line as same as inputs for jshell Message-ID: <58264D4A.7000808@oracle.com> Please review -- Bugs: jshell tool: /edit doesn't process each line as same as inputs for jshell https://bugs.openjdk.java.net/browse/JDK-8143006 JShell tests: jdk/jshell/ExternalEditorTest.java -- unexpected results EditorTestBase.testEditClass1() and .testEditMethod1() https://bugs.openjdk.java.net/browse/JDK-8163816 Webrev: http://cr.openjdk.java.net/~rfield/8143006v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Mon Nov 14 14:20:43 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 14 Nov 2016 15:20:43 +0100 Subject: RFR JDK-8169561: jshell tool: double shift-tab on variable crashes tool Message-ID: <5829C83B.5010807@oracle.com> Hello, Documentation comments handling for JShell has a few problems: -crashes on unknown HTML tags -crashes when the documentation is not found (because the "not found" message is handled as an HTML) -provides a wrong signature for variables declared in JShell itself. This webrev fixes the problems: http://cr.openjdk.java.net/~jlahoda/8169561/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8169561 Any comments are welcome, Jan From robert.field at oracle.com Mon Nov 14 19:14:26 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 14 Nov 2016 11:14:26 -0800 Subject: RFR 8169519: JShell: Handle start-up failures and hangs gracefully In-Reply-To: <5823F11E.9010109@oracle.com> References: <5823F11E.9010109@oracle.com> Message-ID: <582A0D12.5060400@oracle.com> Updated webrev: http://cr.openjdk.java.net/~rfield/8169519v1.webrev/ Change of how localhost determined (thanks, Jan). Tests not included in webrev, -Robert On 11/09/16 20:01, Robert Field wrote: > JShell: Handle start-up failures and hangs gracefully -- specifically -- > Add time-outs so hangs do not lock out users and so fail-over can > function. > Handle failures more gracefully, including cleaning up remote process. > Fail-fast for better user-experience and better failure handling. > Surface failure in API. > Add testing hooks. > Better failure information. > > Bugs: > > 8169519: JShell: Handle start-up failures and hangs gracefully > https://bugs.openjdk.java.net/browse/JDK-8169519 > > 8166581: JShell: locks forever if -R options is wrong > https://bugs.openjdk.java.net/browse/JDK-8166581 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8169519v0.webrev/ > > Specdiff: > > http://cr.openjdk.java.net/~rfield/8169519v0.specdiff/overview-summary.html > > > JShell API: > > http://cr.openjdk.java.net/~rfield/8169519v0.jshellAPI/ > > > Thanks, > Robert > From jan.lahoda at oracle.com Mon Nov 14 22:01:42 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 14 Nov 2016 23:01:42 +0100 Subject: RFR 8169519: JShell: Handle start-up failures and hangs gracefully In-Reply-To: <582A0D12.5060400@oracle.com> References: <5823F11E.9010109@oracle.com> <582A0D12.5060400@oracle.com> Message-ID: <582A3446.1050700@oracle.com> Overall, seems OK to me. Two comments: -DyingRemoteAgent should have a license header: http://cr.openjdk.java.net/~rfield/8169519v1.webrev/test/jdk/jshell/DyingRemoteAgent.java.html -the tests seem to depend on exact exception messages - is there a risk of that being unstable? (And, possibly, platform-specific?) Jan On 14.11.2016 20:14, Robert Field wrote: > Updated webrev: > > http://cr.openjdk.java.net/~rfield/8169519v1.webrev/ > > Change of how localhost determined (thanks, Jan). Tests not included in > webrev, > > -Robert > > On 11/09/16 20:01, Robert Field wrote: >> JShell: Handle start-up failures and hangs gracefully -- specifically -- >> Add time-outs so hangs do not lock out users and so fail-over can >> function. >> Handle failures more gracefully, including cleaning up remote process. >> Fail-fast for better user-experience and better failure handling. >> Surface failure in API. >> Add testing hooks. >> Better failure information. >> >> Bugs: >> >> 8169519: JShell: Handle start-up failures and hangs gracefully >> https://bugs.openjdk.java.net/browse/JDK-8169519 >> >> 8166581: JShell: locks forever if -R options is wrong >> https://bugs.openjdk.java.net/browse/JDK-8166581 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8169519v0.webrev/ >> >> Specdiff: >> >> http://cr.openjdk.java.net/~rfield/8169519v0.specdiff/overview-summary.html >> >> >> JShell API: >> >> http://cr.openjdk.java.net/~rfield/8169519v0.jshellAPI/ >> >> >> Thanks, >> Robert >> > From robert.field at oracle.com Mon Nov 14 22:09:16 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 14 Nov 2016 14:09:16 -0800 Subject: RFR 8169519: JShell: Handle start-up failures and hangs gracefully In-Reply-To: <582A3446.1050700@oracle.com> References: <5823F11E.9010109@oracle.com> <582A0D12.5060400@oracle.com> <582A3446.1050700@oracle.com> Message-ID: <582A360C.6090304@oracle.com> On 11/14/16 14:01, Jan Lahoda wrote: > Overall, seems OK to me. Two comments: > -DyingRemoteAgent should have a license header: Ooops, fixed. > http://cr.openjdk.java.net/~rfield/8169519v1.webrev/test/jdk/jshell/DyingRemoteAgent.java.html > > -the tests seem to depend on exact exception messages - is there a > risk of that being unstable? (And, possibly, platform-specific?) The tests assume that the failure has occurred and is caught in a specific way, which is testing what is fixed. It is certainly possible that timing or platform issues could cause other behaviors -- but, to some extent, that would be a failure of the code. There is nothing platform specific in the layers of message that is checked, those are all JShell layers. -Robert > > Jan > > On 14.11.2016 20:14, Robert Field wrote: >> Updated webrev: >> >> http://cr.openjdk.java.net/~rfield/8169519v1.webrev/ >> >> Change of how localhost determined (thanks, Jan). Tests not included in >> webrev, >> >> -Robert >> >> On 11/09/16 20:01, Robert Field wrote: >>> JShell: Handle start-up failures and hangs gracefully -- >>> specifically -- >>> Add time-outs so hangs do not lock out users and so fail-over can >>> function. >>> Handle failures more gracefully, including cleaning up remote process. >>> Fail-fast for better user-experience and better failure handling. >>> Surface failure in API. >>> Add testing hooks. >>> Better failure information. >>> >>> Bugs: >>> >>> 8169519: JShell: Handle start-up failures and hangs gracefully >>> https://bugs.openjdk.java.net/browse/JDK-8169519 >>> >>> 8166581: JShell: locks forever if -R options is wrong >>> https://bugs.openjdk.java.net/browse/JDK-8166581 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8169519v0.webrev/ >>> >>> Specdiff: >>> >>> http://cr.openjdk.java.net/~rfield/8169519v0.specdiff/overview-summary.html >>> >>> >>> >>> JShell API: >>> >>> http://cr.openjdk.java.net/~rfield/8169519v0.jshellAPI/ >>> >>> >>> Thanks, >>> Robert >>> >> From robert.field at oracle.com Mon Nov 14 22:16:47 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 14 Nov 2016 14:16:47 -0800 Subject: RFR JDK-8169561: jshell tool: double shift-tab on variable crashes tool In-Reply-To: <5829C83B.5010807@oracle.com> References: <5829C83B.5010807@oracle.com> Message-ID: <582A37CF.9040904@oracle.com> Thumbs up. -Robert On 11/14/16 06:20, Jan Lahoda wrote: > Hello, > > Documentation comments handling for JShell has a few problems: > -crashes on unknown HTML tags > -crashes when the documentation is not found (because the "not found" > message is handled as an HTML) > -provides a wrong signature for variables declared in JShell itself. > > This webrev fixes the problems: > http://cr.openjdk.java.net/~jlahoda/8169561/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169561 > > Any comments are welcome, > Jan From ryacobellis at luc.edu Wed Nov 16 03:33:52 2016 From: ryacobellis at luc.edu (Yacobellis, Robert) Date: Wed, 16 Nov 2016 03:33:52 +0000 Subject: possible jshell input bug (or feature?) Message-ID: In the current early access version of JDK 9 / jshell, when I type something like String s = "xxxxxxxxxxxxxxx ... xxxxxxxxxxxxxx" where there are a lot of x's, at about column 80 the cursor returns to the beginning of the line and typing continues from there, overwriting what I had typed before. If the input line length is going to be limited I would expect that characters beyond the length limit would appear on the next line, not the same line, so that my earlier typing would still be visible. Admittedly this case will probably not happen very often, but it is certainly possible for someone to type a jshell input line that is longer than 80 characters and expect that it would display properly. The input line above works (String s has the correct contents), but the input display is unexpected. I've only tried this in a Windows command window (cmd), I don't know if the same thing happens on a Mac or on Linux. Thanks, Bob Yacobellis From robert.field at oracle.com Wed Nov 16 03:40:00 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 15 Nov 2016 19:40:00 -0800 Subject: possible jshell input bug (or feature?) In-Reply-To: References: Message-ID: <582BD510.8010301@oracle.com> Thanks Bob. I do not get this behavior on Fedora KDE / Konsole. Jan? -Robert On 11/15/16 19:33, Yacobellis, Robert wrote: > In the current early access version of JDK 9 / jshell, when I type something like String s = "xxxxxxxxxxxxxxx ... xxxxxxxxxxxxxx" where there are a lot of x's, at about column 80 the cursor returns to the beginning of the line and typing continues from there, overwriting what I had typed before. If the input line length is going to be limited I would expect that characters beyond the length limit would appear on the next line, not the same line, so that my earlier typing would still be visible. > > Admittedly this case will probably not happen very often, but it is certainly possible for someone to type a jshell input line that is longer than 80 characters and expect that it would display properly. The input line above works (String s has the correct contents), but the input display is unexpected. > > I've only tried this in a Windows command window (cmd), I don't know if the same thing happens on a Mac or on Linux. > > Thanks, > Bob Yacobellis From robert.field at oracle.com Wed Nov 16 03:53:26 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 15 Nov 2016 19:53:26 -0800 Subject: RFR 8169519: JShell: Handle start-up failures and hangs gracefully In-Reply-To: <582A3446.1050700@oracle.com> References: <5823F11E.9010109@oracle.com> <582A0D12.5060400@oracle.com> <582A3446.1050700@oracle.com> Message-ID: <582BD836.8090804@oracle.com> OK, here is v2 -- addresses the first issue, dials-back the second issue. But, much more importantly, after discussions of JDI and some issues there with Alan, I've moved the JShell code to take more control and do more complete failure handling. New webrev: http://cr.openjdk.java.net/~rfield/8169519v2.webrev/ Annotated changes from v1 below -- @@@ New tests Only in ./test/jdk/jshell: FailOverExecutionControlDyingLaunchTest.java Only in ./test/jdk/jshell: FailOverExecutionControlHangingLaunchTest.java Only in ./test/jdk/jshell: FailOverExecutionControlHangingListenTest.java @@@ First choice in fail-over sequence is JShell controlled launch: --- ./src/jdk.jshell/share/classes/jdk/jshell/JShell.java Tue Nov 15 13:32:14 2016 *************** *** 118,125 **** this.extraCompilerOptions = b.extraCompilerOptions; ExecutionControl.Generator executionControlGenerator = b.executionControlGenerator==null ? failOverExecutionControlGenerator( - JdiDefaultExecutionControl.launch(), JdiDefaultExecutionControl.listen(InetAddress.getLoopbackAddress().getHostAddress()), JdiDefaultExecutionControl.listen(null) ) : b.executionControlGenerator; --- 118,125 ---- this.extraCompilerOptions = b.extraCompilerOptions; ExecutionControl.Generator executionControlGenerator = b.executionControlGenerator==null ? failOverExecutionControlGenerator( JdiDefaultExecutionControl.listen(InetAddress.getLoopbackAddress().getHostAddress()), + JdiDefaultExecutionControl.launch(), JdiDefaultExecutionControl.listen(null) ) : b.executionControlGenerator; @@@ Monitor process termination (listen case) to more quickly fail-over. New parameter to timedVirtualMachineCreation @@@ Put stopListening in a finally clause so connections don't leak diff -r /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java ./src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java 27a28 > import java.io.IOException; 43a45 > import com.sun.jdi.connect.IllegalConnectorArgumentsException; 126c128 < VirtualMachine new_vm = timedVirtualMachineCreation(() -> launcher.launch(connectorArgs)); --- > VirtualMachine new_vm = timedVirtualMachineCreation(() -> launcher.launch(connectorArgs), null); 160,161c162,163 < vm = timedVirtualMachineCreation(() -> listener.accept(connectorArgs)); < listener.stopListening(connectorArgs); --- > vm = timedVirtualMachineCreation(() -> listener.accept(connectorArgs), > () -> process.waitFor()); 167a170,175 > } finally { > try { > listener.stopListening(connectorArgs); > } catch (IOException | IllegalConnectorArgumentsException ex) { > // ignore > } 171c179,180 < VirtualMachine timedVirtualMachineCreation(Callable creator) throws Exception { --- > VirtualMachine timedVirtualMachineCreation(Callable creator, > Callable processComplete) throws Exception { 173c182 < ExecutorService executor = Executors.newSingleThreadExecutor(runnable -> { --- > ExecutorService executor = Executors.newCachedThreadPool(runnable -> { 178,179d186 < Future future = executor.submit(creator); < 181,184c188,202 < result = future.get(connectTimeout, TimeUnit.MILLISECONDS); < } catch (TimeoutException ex) { < future.cancel(true); < throw ex; --- > Future future = executor.submit(creator); > if (processComplete != null) { > executor.submit(() -> { > Integer i = processComplete.call(); > future.cancel(true); > return i; > }); > } > > try { > result = future.get(connectTimeout, TimeUnit.MILLISECONDS); > } catch (TimeoutException ex) { > future.cancel(true); > throw ex; > } @@@ Add license header diff -r /w/y/dev/langtools/test/jdk/jshell/DyingRemoteAgent.java ./test/jdk/jshell/DyingRemoteAgent.java 0a1,22 > /* > * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License version 2 only, as > * published by the Free Software Foundation. > * > * This code is distributed in the hope that it will be useful, but WITHOUT > * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > * version 2 for more details (a copy is included in the LICENSE file that > * accompanied this code). > * > * You should have received a copy of the GNU General Public License version > * 2 along with this work; if not, write to the Free Software Foundation, > * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > * > * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > * or visit www.oracle.com if you need additional information or have any > * questions. > */ @@@ Trim some over-jealous exception message matches diff -r /w/y/dev/langtools/test/jdk/jshell/JdiBadOptionListenExecutionControlTest.java ./test/jdk/jshell/JdiBadOptionListenExecutionControlTest.java 42c42 < "Launching JShell execution engine threw: Failed remote listen: java.util.concurrent.ExecutionException: com.sun.jdi.connect.TransportTimeoutException: timeout waiting for connection @ com.sun.jdi.SocketListen"; --- > "Launching JShell execution engine threw: Failed remote listen:"; diff -r /w/y/dev/langtools/test/jdk/jshell/StartOptionTest.java ./test/jdk/jshell/StartOptionTest.java 144c144 < assertTrue(s.startsWith("Launching JShell execution engine threw: Failed remote launch:"), s); --- > assertTrue(s.startsWith("Launching JShell execution engine threw: Failed remote"), s); Thanks, Robert On 11/14/16 14:01, Jan Lahoda wrote: > Overall, seems OK to me. Two comments: > -DyingRemoteAgent should have a license header: > http://cr.openjdk.java.net/~rfield/8169519v1.webrev/test/jdk/jshell/DyingRemoteAgent.java.html > > -the tests seem to depend on exact exception messages - is there a > risk of that being unstable? (And, possibly, platform-specific?) > > Jan > > On 14.11.2016 20:14, Robert Field wrote: >> Updated webrev: >> >> http://cr.openjdk.java.net/~rfield/8169519v1.webrev/ >> >> Change of how localhost determined (thanks, Jan). Tests not included in >> webrev, >> >> -Robert >> >> On 11/09/16 20:01, Robert Field wrote: >>> JShell: Handle start-up failures and hangs gracefully -- >>> specifically -- >>> Add time-outs so hangs do not lock out users and so fail-over can >>> function. >>> Handle failures more gracefully, including cleaning up remote process. >>> Fail-fast for better user-experience and better failure handling. >>> Surface failure in API. >>> Add testing hooks. >>> Better failure information. >>> >>> Bugs: >>> >>> 8169519: JShell: Handle start-up failures and hangs gracefully >>> https://bugs.openjdk.java.net/browse/JDK-8169519 >>> >>> 8166581: JShell: locks forever if -R options is wrong >>> https://bugs.openjdk.java.net/browse/JDK-8166581 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8169519v0.webrev/ >>> >>> Specdiff: >>> >>> http://cr.openjdk.java.net/~rfield/8169519v0.specdiff/overview-summary.html >>> >>> >>> >>> JShell API: >>> >>> http://cr.openjdk.java.net/~rfield/8169519v0.jshellAPI/ >>> >>> >>> Thanks, >>> Robert >>> >> From kevin.walls at oracle.com Wed Nov 16 10:52:50 2016 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 16 Nov 2016 10:52:50 +0000 Subject: Export existing Java Objects to a JShell? Message-ID: <179f8cd9-6d60-4617-43a0-ec431685fb1d@oracle.com> Hi kulla-dev, I am looking for a way to expose an existing Java Object to code running in a JShell which a Java app created. I created a JShell which runs in the same JVM as the controlling class: JShell.Builder builder = JShell.builder().executionEngine(LocalExecutionControl.create()); jshell = builder.build(); That works. Now, I want to populate a variable such that the script code can access it by name. I realise a JShell is not a ScriptEngine, but I am looking for an equivalent of "scriptEngine.put(name, value)". Any suggestions? (and apologies if I missed something obvious) Many thanks Kevin Walls From jan.lahoda at oracle.com Wed Nov 16 11:47:28 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 16 Nov 2016 12:47:28 +0100 Subject: RFR 8143006: jshell tool: /edit doesn't process each line as same as inputs for jshell In-Reply-To: <58264D4A.7000808@oracle.com> References: <58264D4A.7000808@oracle.com> Message-ID: <582C4750.7060106@oracle.com> Seems OK. Jan On 11.11.2016 23:59, Robert Field wrote: > Please review -- > > Bugs: > > jshell tool: /edit doesn't process each line as same as inputs for > jshell > https://bugs.openjdk.java.net/browse/JDK-8143006 > > JShell tests: jdk/jshell/ExternalEditorTest.java -- unexpected > results EditorTestBase.testEditClass1() and .testEditMethod1() > https://bugs.openjdk.java.net/browse/JDK-8163816 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8143006v0.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Wed Nov 16 15:59:22 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 16 Nov 2016 16:59:22 +0100 Subject: RFR 8169519: JShell: Handle start-up failures and hangs gracefully In-Reply-To: <582BD836.8090804@oracle.com> References: <5823F11E.9010109@oracle.com> <582A0D12.5060400@oracle.com> <582A3446.1050700@oracle.com> <582BD836.8090804@oracle.com> Message-ID: <582C825A.4080500@oracle.com> Seems OK. Jan On 16.11.2016 04:53, Robert Field wrote: > OK, here is v2 -- addresses the first issue, dials-back the second issue. > But, much more importantly, after discussions of JDI and some issues > there with Alan, I've moved the JShell code to take more control and do > more complete failure handling. > > New webrev: > > http://cr.openjdk.java.net/~rfield/8169519v2.webrev/ > > > Annotated changes from v1 below -- > > @@@ New tests > > Only in ./test/jdk/jshell: FailOverExecutionControlDyingLaunchTest.java > Only in ./test/jdk/jshell: FailOverExecutionControlHangingLaunchTest.java > Only in ./test/jdk/jshell: FailOverExecutionControlHangingListenTest.java > > > @@@ First choice in fail-over sequence is JShell controlled launch: > > --- ./src/jdk.jshell/share/classes/jdk/jshell/JShell.java Tue Nov > 15 13:32:14 2016 > *************** > *** 118,125 **** > this.extraCompilerOptions = b.extraCompilerOptions; > ExecutionControl.Generator executionControlGenerator = > b.executionControlGenerator==null > ? failOverExecutionControlGenerator( > - JdiDefaultExecutionControl.launch(), > JdiDefaultExecutionControl.listen(InetAddress.getLoopbackAddress().getHostAddress()), > > JdiDefaultExecutionControl.listen(null) > ) > : b.executionControlGenerator; > --- 118,125 ---- > this.extraCompilerOptions = b.extraCompilerOptions; > ExecutionControl.Generator executionControlGenerator = > b.executionControlGenerator==null > ? failOverExecutionControlGenerator( > JdiDefaultExecutionControl.listen(InetAddress.getLoopbackAddress().getHostAddress()), > > + JdiDefaultExecutionControl.launch(), > JdiDefaultExecutionControl.listen(null) > ) > : b.executionControlGenerator; > > > @@@ Monitor process termination (listen case) to more quickly > fail-over. New parameter to timedVirtualMachineCreation > > @@@ Put stopListening in a finally clause so connections don't leak > > diff -r > /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java > ./src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java > 27a28 >> import java.io.IOException; > 43a45 >> import com.sun.jdi.connect.IllegalConnectorArgumentsException; > 126c128 > < VirtualMachine new_vm = timedVirtualMachineCreation(() -> > launcher.launch(connectorArgs)); > --- >> VirtualMachine new_vm = timedVirtualMachineCreation(() -> >> launcher.launch(connectorArgs), null); > 160,161c162,163 > < vm = timedVirtualMachineCreation(() -> > listener.accept(connectorArgs)); > < listener.stopListening(connectorArgs); > --- >> vm = timedVirtualMachineCreation(() -> >> listener.accept(connectorArgs), >> () -> process.waitFor()); > 167a170,175 >> } finally { >> try { >> listener.stopListening(connectorArgs); >> } catch (IOException | IllegalConnectorArgumentsException >> ex) { >> // ignore >> } > 171c179,180 > < VirtualMachine > timedVirtualMachineCreation(Callable creator) throws > Exception { > --- >> VirtualMachine >> timedVirtualMachineCreation(Callable creator, >> Callable processComplete) throws Exception { > 173c182 > < ExecutorService executor = > Executors.newSingleThreadExecutor(runnable -> { > --- >> ExecutorService executor = >> Executors.newCachedThreadPool(runnable -> { > 178,179d186 > < Future future = executor.submit(creator); > < > 181,184c188,202 > < result = future.get(connectTimeout, TimeUnit.MILLISECONDS); > < } catch (TimeoutException ex) { > < future.cancel(true); > < throw ex; > --- >> Future future = executor.submit(creator); >> if (processComplete != null) { >> executor.submit(() -> { >> Integer i = processComplete.call(); >> future.cancel(true); >> return i; >> }); >> } >> >> try { >> result = future.get(connectTimeout, >> TimeUnit.MILLISECONDS); >> } catch (TimeoutException ex) { >> future.cancel(true); >> throw ex; >> } > > > @@@ Add license header > > diff -r /w/y/dev/langtools/test/jdk/jshell/DyingRemoteAgent.java > ./test/jdk/jshell/DyingRemoteAgent.java > 0a1,22 >> /* >> * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> * under the terms of the GNU General Public License version 2 only, as >> * published by the Free Software Foundation. >> * >> * This code is distributed in the hope that it will be useful, but >> WITHOUT >> * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> * version 2 for more details (a copy is included in the LICENSE file >> that >> * accompanied this code). >> * >> * You should have received a copy of the GNU General Public License >> version >> * 2 along with this work; if not, write to the Free Software Foundation, >> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> * >> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 >> USA >> * or visit www.oracle.com if you need additional information or have any >> * questions. >> */ > > @@@ Trim some over-jealous exception message matches > > diff -r > /w/y/dev/langtools/test/jdk/jshell/JdiBadOptionListenExecutionControlTest.java > ./test/jdk/jshell/JdiBadOptionListenExecutionControlTest.java > 42c42 > < "Launching JShell execution engine threw: Failed remote > listen: java.util.concurrent.ExecutionException: > com.sun.jdi.connect.TransportTimeoutException: timeout waiting for > connection @ com.sun.jdi.SocketListen"; > --- >> "Launching JShell execution engine threw: Failed remote >> listen:"; > diff -r /w/y/dev/langtools/test/jdk/jshell/StartOptionTest.java > ./test/jdk/jshell/StartOptionTest.java > 144c144 > < assertTrue(s.startsWith("Launching JShell execution engine > threw: Failed remote launch:"), s); > --- >> assertTrue(s.startsWith("Launching JShell execution engine >> threw: Failed remote"), s); > > > Thanks, > Robert > > > > On 11/14/16 14:01, Jan Lahoda wrote: >> Overall, seems OK to me. Two comments: >> -DyingRemoteAgent should have a license header: >> http://cr.openjdk.java.net/~rfield/8169519v1.webrev/test/jdk/jshell/DyingRemoteAgent.java.html >> >> -the tests seem to depend on exact exception messages - is there a >> risk of that being unstable? (And, possibly, platform-specific?) >> >> Jan >> >> On 14.11.2016 20:14, Robert Field wrote: >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8169519v1.webrev/ >>> >>> Change of how localhost determined (thanks, Jan). Tests not included in >>> webrev, >>> >>> -Robert >>> >>> On 11/09/16 20:01, Robert Field wrote: >>>> JShell: Handle start-up failures and hangs gracefully -- >>>> specifically -- >>>> Add time-outs so hangs do not lock out users and so fail-over can >>>> function. >>>> Handle failures more gracefully, including cleaning up remote process. >>>> Fail-fast for better user-experience and better failure handling. >>>> Surface failure in API. >>>> Add testing hooks. >>>> Better failure information. >>>> >>>> Bugs: >>>> >>>> 8169519: JShell: Handle start-up failures and hangs gracefully >>>> https://bugs.openjdk.java.net/browse/JDK-8169519 >>>> >>>> 8166581: JShell: locks forever if -R options is wrong >>>> https://bugs.openjdk.java.net/browse/JDK-8166581 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~rfield/8169519v0.webrev/ >>>> >>>> Specdiff: >>>> >>>> http://cr.openjdk.java.net/~rfield/8169519v0.specdiff/overview-summary.html >>>> >>>> >>>> >>>> JShell API: >>>> >>>> http://cr.openjdk.java.net/~rfield/8169519v0.jshellAPI/ >>>> >>>> >>>> Thanks, >>>> Robert >>>> >>> > From robert.field at oracle.com Wed Nov 16 22:35:24 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 16 Nov 2016 14:35:24 -0800 Subject: RFR (s) 8114842: JShell: SourceCodeAnalysis splits code with array initialiazer incorrectly Message-ID: <582CDF2C.1040501@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8114842 Webrev: http://cr.openjdk.java.net/~rfield/8114842v0.webrev/ Thanks, Robert From robert.field at oracle.com Thu Nov 17 20:47:35 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 17 Nov 2016 12:47:35 -0800 Subject: RFR 8153402: jshell tool: completion provider for /help Message-ID: <582E1767.1010907@oracle.com> Bugs: 8153402: jshell tool: completion provider for /help https://bugs.openjdk.java.net/browse/JDK-8153402 8169818: jshell tool: completion provider for /vars /methods /types gives -history https://bugs.openjdk.java.net/browse/JDK-8169818 Webrev: http://cr.openjdk.java.net/~rfield/8153402v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Fri Nov 18 15:59:39 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 18 Nov 2016 16:59:39 +0100 Subject: RFR 8153402: jshell tool: completion provider for /help In-Reply-To: <582E1767.1010907@oracle.com> References: <582E1767.1010907@oracle.com> Message-ID: <582F256B.5020806@oracle.com> Seems OK to me. Jan On 17.11.2016 21:47, Robert Field wrote: > Bugs: > > 8153402: jshell tool: completion provider for /help > https://bugs.openjdk.java.net/browse/JDK-8153402 > > 8169818: jshell tool: completion provider for /vars /methods /types > gives -history > https://bugs.openjdk.java.net/browse/JDK-8169818 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8153402v0.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Fri Nov 18 16:09:34 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 18 Nov 2016 17:09:34 +0100 Subject: RFR (s) 8114842: JShell: SourceCodeAnalysis splits code with array initialiazer incorrectly In-Reply-To: <582CDF2C.1040501@oracle.com> References: <582CDF2C.1040501@oracle.com> Message-ID: <582F27BE.80400@oracle.com> Seems to me the handling of commas in declarations is not quite correct. Consider for example: --- jshell> int m = 0, | Error: | reached end of file while parsing | int m = 0, | ^ jshell> int n1 = 0, n2 | Error: | reached end of file while parsing | int n1 = 0, n2 | ^ jshell> int n1 = 0, n2 = | Error: | reached end of file while parsing | int n1 = 0, n2 = | ^ --- Would something along these lines work better? http://cr.openjdk.java.net/~jlahoda/8114842/comma-in-decls.diff Jan On 16.11.2016 23:35, Robert Field wrote: > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8114842 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8114842v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Fri Nov 18 17:57:34 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 18 Nov 2016 09:57:34 -0800 Subject: RFR (s) 8114842: JShell: SourceCodeAnalysis splits code with array initialiazer incorrectly In-Reply-To: <582F27BE.80400@oracle.com> References: <582CDF2C.1040501@oracle.com> <582F27BE.80400@oracle.com> Message-ID: <582F410E.3010701@oracle.com> Strange, I don't get any of the behaviors you show (what did you see this on?) -- jshell> int m = 0, | Error: | expected | int m = 0,; | ^ jshell> int n1 = 0, n2 n1 ==> 0 n2 ==> 0 jshell> int n1 = 0, n2 = ...> 5 n1 ==> 0 n2 ==> 5 The first one though is definitely a problem. That is because XTERM is set for COMMA, I'm trying to figure out why that is set. Comma can terminate a list of values, but that would be in braces and never seen here. -Robert On 11/18/16 08:09, Jan Lahoda wrote: > Seems to me the handling of commas in declarations is not quite > correct. Consider for example: > --- > jshell> int m = 0, > | Error: > | reached end of file while parsing > | int m = 0, > | ^ > > jshell> int n1 = 0, n2 > | Error: > | reached end of file while parsing > | int n1 = 0, n2 > | ^ > > jshell> int n1 = 0, n2 = > | Error: > | reached end of file while parsing > | int n1 = 0, n2 = > | ^ > --- > > Would something along these lines work better? > http://cr.openjdk.java.net/~jlahoda/8114842/comma-in-decls.diff > > Jan > > > On 16.11.2016 23:35, Robert Field wrote: >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8114842 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8114842v0.webrev/ >> >> Thanks, >> Robert >> From jan.lahoda at oracle.com Fri Nov 18 18:37:38 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 18 Nov 2016 19:37:38 +0100 Subject: RFR (s) 8114842: JShell: SourceCodeAnalysis splits code with array initialiazer incorrectly In-Reply-To: <582F410E.3010701@oracle.com> References: <582CDF2C.1040501@oracle.com> <582F27BE.80400@oracle.com> <582F410E.3010701@oracle.com> Message-ID: <582F4A72.5040900@oracle.com> On 18.11.2016 18:57, Robert Field wrote: > Strange, I don't get any of the behaviors you show (what did you see > this on?) -- Oops, sorry, that was with some other changes already (which were motivated by the failing "int m = 0,"). > > jshell> int m = 0, > | Error: > | expected > | int m = 0,; > | ^ > > jshell> int n1 = 0, n2 > n1 ==> 0 > n2 ==> 0 > > jshell> int n1 = 0, n2 = > ...> 5 > n1 ==> 0 > n2 ==> 5 > > The first one though is definitely a problem. That is because XTERM is > set for COMMA, I'm trying to figure out why that is set. Comma can I thought it is more due to COMMA being XEXPR, so parseExpression() goes through ',', and claims the input is complete (with semi)? Jan > terminate a list of values, but that would be in braces and never seen > here. > > -Robert > > > On 11/18/16 08:09, Jan Lahoda wrote: >> Seems to me the handling of commas in declarations is not quite >> correct. Consider for example: >> --- >> jshell> int m = 0, >> | Error: >> | reached end of file while parsing >> | int m = 0, >> | ^ >> >> jshell> int n1 = 0, n2 >> | Error: >> | reached end of file while parsing >> | int n1 = 0, n2 >> | ^ >> >> jshell> int n1 = 0, n2 = >> | Error: >> | reached end of file while parsing >> | int n1 = 0, n2 = >> | ^ >> --- >> >> Would something along these lines work better? >> http://cr.openjdk.java.net/~jlahoda/8114842/comma-in-decls.diff >> >> Jan >> >> >> On 16.11.2016 23:35, Robert Field wrote: >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8114842 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8114842v0.webrev/ >>> >>> Thanks, >>> Robert >>> > From robert.field at oracle.com Fri Nov 18 23:09:43 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 18 Nov 2016 15:09:43 -0800 Subject: RFR (s) 8114842: JShell: SourceCodeAnalysis splits code with array initialiazer incorrectly In-Reply-To: <582F4A72.5040900@oracle.com> References: <582CDF2C.1040501@oracle.com> <582F27BE.80400@oracle.com> <582F410E.3010701@oracle.com> <582F4A72.5040900@oracle.com> Message-ID: <582F8A37.5060800@oracle.com> New version, fixes trailing comma problem. Fixes original problem (by code deletion!). Many new test cases. Webrev: http://cr.openjdk.java.net/~rfield/8114842v1.webrev/ Thanks, Robert On 11/18/16 10:37, Jan Lahoda wrote: > On 18.11.2016 18:57, Robert Field wrote: >> Strange, I don't get any of the behaviors you show (what did you see >> this on?) -- > > Oops, sorry, that was with some other changes already (which were > motivated by the failing "int m = 0,"). > >> >> jshell> int m = 0, >> | Error: >> | expected >> | int m = 0,; >> | ^ >> >> jshell> int n1 = 0, n2 >> n1 ==> 0 >> n2 ==> 0 >> >> jshell> int n1 = 0, n2 = >> ...> 5 >> n1 ==> 0 >> n2 ==> 5 >> >> The first one though is definitely a problem. That is because XTERM is >> set for COMMA, I'm trying to figure out why that is set. Comma can > > I thought it is more due to COMMA being XEXPR, so parseExpression() > goes through ',', and claims the input is complete (with semi)? > > Jan > >> terminate a list of values, but that would be in braces and never seen >> here. >> >> -Robert >> >> >> On 11/18/16 08:09, Jan Lahoda wrote: >>> Seems to me the handling of commas in declarations is not quite >>> correct. Consider for example: >>> --- >>> jshell> int m = 0, >>> | Error: >>> | reached end of file while parsing >>> | int m = 0, >>> | ^ >>> >>> jshell> int n1 = 0, n2 >>> | Error: >>> | reached end of file while parsing >>> | int n1 = 0, n2 >>> | ^ >>> >>> jshell> int n1 = 0, n2 = >>> | Error: >>> | reached end of file while parsing >>> | int n1 = 0, n2 = >>> | ^ >>> --- >>> >>> Would something along these lines work better? >>> http://cr.openjdk.java.net/~jlahoda/8114842/comma-in-decls.diff >>> >>> Jan >>> >>> >>> On 16.11.2016 23:35, Robert Field wrote: >>>> Bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8114842 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~rfield/8114842v0.webrev/ >>>> >>>> Thanks, >>>> Robert >>>> >> From robert.field at oracle.com Sun Nov 20 07:27:48 2016 From: robert.field at oracle.com (Robert Field) Date: Sat, 19 Nov 2016 23:27:48 -0800 Subject: RFR 8170044: jshell tool: jshell missing from javax.tools.ToolProvider Message-ID: <9E85F456-498C-477C-A38B-5CC15D9CAE20@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8170044 Webrev: http://cr.openjdk.java.net/~rfield/8170044v0.webrev/ Thanks, Robert From forax at univ-mlv.fr Mon Nov 21 09:16:50 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 21 Nov 2016 10:16:50 +0100 (CET) Subject: RFR 8170044: jshell tool: jshell missing from javax.tools.ToolProvider In-Reply-To: <9E85F456-498C-477C-A38B-5CC15D9CAE20@oracle.com> References: <9E85F456-498C-477C-A38B-5CC15D9CAE20@oracle.com> Message-ID: <1371473037.126280.1479719810374.JavaMail.zimbra@u-pem.fr> Looks goods to me ! I supposed that the interface of java.util.pref is too big so every projects are poised to re-create its own prefs when they needs another backing store (here a HashMap). regards, R?mi ----- Mail original ----- > De: "Robert Field" > ?: "Kulla" > Envoy?: Dimanche 20 Novembre 2016 08:27:48 > Objet: RFR 8170044: jshell tool: jshell missing from javax.tools.ToolProvider > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8170044 > > > Webrev: > > http://cr.openjdk.java.net/~rfield/8170044v0.webrev/ > > > Thanks, > Robert From robert.field at oracle.com Mon Nov 21 18:26:50 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 21 Nov 2016 10:26:50 -0800 Subject: RFR 8170044: jshell tool: jshell missing from javax.tools.ToolProvider In-Reply-To: <1371473037.126280.1479719810374.JavaMail.zimbra@u-pem.fr> References: <9E85F456-498C-477C-A38B-5CC15D9CAE20@oracle.com> <1371473037.126280.1479719810374.JavaMail.zimbra@u-pem.fr> Message-ID: <58333C6A.8060300@oracle.com> Thanks R?mi. Preferences is used internally (the default if no Map is provided). However, java.compiler (wherein lies javax.tools) does not depend on java.util.pref -- hence the adaption to Map. -Robert On 11/21/16 01:16, Remi Forax wrote: > Looks goods to me ! > I supposed that the interface of java.util.pref is too big so every projects are poised to re-create its own prefs when they needs another backing store (here a HashMap). > > regards, > R?mi > > ----- Mail original ----- >> De: "Robert Field" >> ?: "Kulla" >> Envoy?: Dimanche 20 Novembre 2016 08:27:48 >> Objet: RFR 8170044: jshell tool: jshell missing from javax.tools.ToolProvider >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8170044 >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8170044v0.webrev/ >> >> >> Thanks, >> Robert From jan.lahoda at oracle.com Mon Nov 21 19:37:19 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 21 Nov 2016 20:37:19 +0100 Subject: RFR (s) 8114842: JShell: SourceCodeAnalysis splits code with array initialiazer incorrectly In-Reply-To: <582F8A37.5060800@oracle.com> References: <582CDF2C.1040501@oracle.com> <582F27BE.80400@oracle.com> <582F410E.3010701@oracle.com> <582F4A72.5040900@oracle.com> <582F8A37.5060800@oracle.com> Message-ID: <58334CEF.800@oracle.com> Seems OK. Jan On 19.11.2016 00:09, Robert Field wrote: > New version, fixes trailing comma problem. Fixes original problem (by > code deletion!). > > Many new test cases. > > Webrev: > > http://cr.openjdk.java.net/~rfield/8114842v1.webrev/ > > Thanks, > Robert > > > On 11/18/16 10:37, Jan Lahoda wrote: >> On 18.11.2016 18:57, Robert Field wrote: >>> Strange, I don't get any of the behaviors you show (what did you see >>> this on?) -- >> >> Oops, sorry, that was with some other changes already (which were >> motivated by the failing "int m = 0,"). >> >>> >>> jshell> int m = 0, >>> | Error: >>> | expected >>> | int m = 0,; >>> | ^ >>> >>> jshell> int n1 = 0, n2 >>> n1 ==> 0 >>> n2 ==> 0 >>> >>> jshell> int n1 = 0, n2 = >>> ...> 5 >>> n1 ==> 0 >>> n2 ==> 5 >>> >>> The first one though is definitely a problem. That is because XTERM is >>> set for COMMA, I'm trying to figure out why that is set. Comma can >> >> I thought it is more due to COMMA being XEXPR, so parseExpression() >> goes through ',', and claims the input is complete (with semi)? >> >> Jan >> >>> terminate a list of values, but that would be in braces and never seen >>> here. >>> >>> -Robert >>> >>> >>> On 11/18/16 08:09, Jan Lahoda wrote: >>>> Seems to me the handling of commas in declarations is not quite >>>> correct. Consider for example: >>>> --- >>>> jshell> int m = 0, >>>> | Error: >>>> | reached end of file while parsing >>>> | int m = 0, >>>> | ^ >>>> >>>> jshell> int n1 = 0, n2 >>>> | Error: >>>> | reached end of file while parsing >>>> | int n1 = 0, n2 >>>> | ^ >>>> >>>> jshell> int n1 = 0, n2 = >>>> | Error: >>>> | reached end of file while parsing >>>> | int n1 = 0, n2 = >>>> | ^ >>>> --- >>>> >>>> Would something along these lines work better? >>>> http://cr.openjdk.java.net/~jlahoda/8114842/comma-in-decls.diff >>>> >>>> Jan >>>> >>>> >>>> On 16.11.2016 23:35, Robert Field wrote: >>>>> Bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8114842 >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~rfield/8114842v0.webrev/ >>>>> >>>>> Thanks, >>>>> Robert >>>>> >>> > From robert.field at oracle.com Tue Nov 22 00:41:00 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 21 Nov 2016 16:41:00 -0800 Subject: RFR 8169519: JShell: Handle start-up failures and hangs gracefully In-Reply-To: <582BD836.8090804@oracle.com> References: <5823F11E.9010109@oracle.com> <582A0D12.5060400@oracle.com> <582A3446.1050700@oracle.com> <582BD836.8090804@oracle.com> Message-ID: <5833941C.1070009@oracle.com> Per off-line review -- Generally looks okay, but ... I don't think the fields DEFAULT_TIMEOUT REMOTE_AGENT should be constants from a JLS perspective. These values are not so constant we might not want to change them in the future, but as it is they are constants from a Java perspective and thus the raw values will get constant-folded and compiled into clients. I recommend replacing these constants with static methods instead. Thanks, -Joe I rev'ed the code again -- Bugs: 8169519: JShell: Handle start-up failures and hangs gracefully https://bugs.openjdk.java.net/browse/JDK-8169519 8166581: JShell: locks forever if -R options is wrong https://bugs.openjdk.java.net/browse/JDK-8166581 Webrev: http://cr.openjdk.java.net/~rfield/8169519v3.webrev/ Specdiff: http://cr.openjdk.java.net/~rfield/8169519v3.specdiff/overview-summary.html JShell API: http://cr.openjdk.java.net/~rfield/8169519v3.jshellAPI/ The only change in this version is to the JdiDefaultExecutionControl class: http://cr.openjdk.java.net/~rfield/8169519v3.specdiff/jdk/jshell/execution/JdiDefaultExecutionControl.html http://cr.openjdk.java.net/~rfield/8169519v3.jshellAPI/jdk/jshell/execution/JdiDefaultExecutionControl.html http://cr.openjdk.java.net/~rfield/8169519v3.webrev/src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java.sdiff.html as above, changing the two constants to methods. Robert On 11/15/16 19:53, Robert Field wrote: > OK, here is v2 -- addresses the first issue, dials-back the second issue. > But, much more importantly, after discussions of JDI and some issues > there with Alan, I've moved the JShell code to take more control and > do more complete failure handling. > > New webrev: > > http://cr.openjdk.java.net/~rfield/8169519v2.webrev/ > > > Annotated changes from v1 below -- > > @@@ New tests > > Only in ./test/jdk/jshell: FailOverExecutionControlDyingLaunchTest.java > Only in ./test/jdk/jshell: FailOverExecutionControlHangingLaunchTest.java > Only in ./test/jdk/jshell: FailOverExecutionControlHangingListenTest.java > > > @@@ First choice in fail-over sequence is JShell controlled launch: > > --- ./src/jdk.jshell/share/classes/jdk/jshell/JShell.java Tue Nov 15 > 13:32:14 2016 > *************** > *** 118,125 **** > this.extraCompilerOptions = b.extraCompilerOptions; > ExecutionControl.Generator executionControlGenerator = > b.executionControlGenerator==null > ? failOverExecutionControlGenerator( > - JdiDefaultExecutionControl.launch(), > JdiDefaultExecutionControl.listen(InetAddress.getLoopbackAddress().getHostAddress()), > > JdiDefaultExecutionControl.listen(null) > ) > : b.executionControlGenerator; > --- 118,125 ---- > this.extraCompilerOptions = b.extraCompilerOptions; > ExecutionControl.Generator executionControlGenerator = > b.executionControlGenerator==null > ? failOverExecutionControlGenerator( > JdiDefaultExecutionControl.listen(InetAddress.getLoopbackAddress().getHostAddress()), > > + JdiDefaultExecutionControl.launch(), > JdiDefaultExecutionControl.listen(null) > ) > : b.executionControlGenerator; > > > @@@ Monitor process termination (listen case) to more quickly > fail-over. New parameter to timedVirtualMachineCreation > > @@@ Put stopListening in a finally clause so connections don't leak > > diff -r > /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java > ./src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java > 27a28 >> import java.io.IOException; > 43a45 >> import com.sun.jdi.connect.IllegalConnectorArgumentsException; > 126c128 > < VirtualMachine new_vm = timedVirtualMachineCreation(() > -> launcher.launch(connectorArgs)); > --- >> VirtualMachine new_vm = timedVirtualMachineCreation(() -> >> launcher.launch(connectorArgs), null); > 160,161c162,163 > < vm = timedVirtualMachineCreation(() -> > listener.accept(connectorArgs)); > < listener.stopListening(connectorArgs); > --- >> vm = timedVirtualMachineCreation(() -> >> listener.accept(connectorArgs), >> () -> process.waitFor()); > 167a170,175 >> } finally { >> try { >> listener.stopListening(connectorArgs); >> } catch (IOException | IllegalConnectorArgumentsException >> ex) { >> // ignore >> } > 171c179,180 > < VirtualMachine > timedVirtualMachineCreation(Callable creator) throws > Exception { > --- >> VirtualMachine >> timedVirtualMachineCreation(Callable creator, >> Callable processComplete) throws Exception { > 173c182 > < ExecutorService executor = > Executors.newSingleThreadExecutor(runnable -> { > --- >> ExecutorService executor = >> Executors.newCachedThreadPool(runnable -> { > 178,179d186 > < Future future = executor.submit(creator); > < > 181,184c188,202 > < result = future.get(connectTimeout, TimeUnit.MILLISECONDS); > < } catch (TimeoutException ex) { > < future.cancel(true); > < throw ex; > --- >> Future future = executor.submit(creator); >> if (processComplete != null) { >> executor.submit(() -> { >> Integer i = processComplete.call(); >> future.cancel(true); >> return i; >> }); >> } >> >> try { >> result = future.get(connectTimeout, >> TimeUnit.MILLISECONDS); >> } catch (TimeoutException ex) { >> future.cancel(true); >> throw ex; >> } > > > @@@ Add license header > > diff -r /w/y/dev/langtools/test/jdk/jshell/DyingRemoteAgent.java > ./test/jdk/jshell/DyingRemoteAgent.java > 0a1,22 >> /* >> * Copyright (c) 2016, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> * under the terms of the GNU General Public License version 2 only, as >> * published by the Free Software Foundation. >> * >> * This code is distributed in the hope that it will be useful, but >> WITHOUT >> * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> * version 2 for more details (a copy is included in the LICENSE file >> that >> * accompanied this code). >> * >> * You should have received a copy of the GNU General Public License >> version >> * 2 along with this work; if not, write to the Free Software >> Foundation, >> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> * >> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >> 94065 USA >> * or visit www.oracle.com if you need additional information or have >> any >> * questions. >> */ > > @@@ Trim some over-jealous exception message matches > > diff -r > /w/y/dev/langtools/test/jdk/jshell/JdiBadOptionListenExecutionControlTest.java > ./test/jdk/jshell/JdiBadOptionListenExecutionControlTest.java > 42c42 > < "Launching JShell execution engine threw: Failed remote > listen: java.util.concurrent.ExecutionException: > com.sun.jdi.connect.TransportTimeoutException: timeout waiting for > connection @ com.sun.jdi.SocketListen"; > --- >> "Launching JShell execution engine threw: Failed remote >> listen:"; > diff -r /w/y/dev/langtools/test/jdk/jshell/StartOptionTest.java > ./test/jdk/jshell/StartOptionTest.java > 144c144 > < assertTrue(s.startsWith("Launching JShell execution > engine threw: Failed remote launch:"), s); > --- >> assertTrue(s.startsWith("Launching JShell execution engine threw: >> Failed remote"), s); > > > Thanks, > Robert > > > > On 11/14/16 14:01, Jan Lahoda wrote: >> Overall, seems OK to me. Two comments: >> -DyingRemoteAgent should have a license header: >> http://cr.openjdk.java.net/~rfield/8169519v1.webrev/test/jdk/jshell/DyingRemoteAgent.java.html >> >> -the tests seem to depend on exact exception messages - is there a >> risk of that being unstable? (And, possibly, platform-specific?) >> >> Jan >> >> On 14.11.2016 20:14, Robert Field wrote: >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8169519v1.webrev/ >>> >>> Change of how localhost determined (thanks, Jan). Tests not >>> included in >>> webrev, >>> >>> -Robert >>> >>> On 11/09/16 20:01, Robert Field wrote: >>>> JShell: Handle start-up failures and hangs gracefully -- >>>> specifically -- >>>> Add time-outs so hangs do not lock out users and so fail-over can >>>> function. >>>> Handle failures more gracefully, including cleaning up remote process. >>>> Fail-fast for better user-experience and better failure handling. >>>> Surface failure in API. >>>> Add testing hooks. >>>> Better failure information. >>>> >>>> Bugs: >>>> >>>> 8169519: JShell: Handle start-up failures and hangs gracefully >>>> https://bugs.openjdk.java.net/browse/JDK-8169519 >>>> >>>> 8166581: JShell: locks forever if -R options is wrong >>>> https://bugs.openjdk.java.net/browse/JDK-8166581 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~rfield/8169519v0.webrev/ >>>> >>>> Specdiff: >>>> >>>> http://cr.openjdk.java.net/~rfield/8169519v0.specdiff/overview-summary.html >>>> >>>> >>>> >>>> JShell API: >>>> >>>> http://cr.openjdk.java.net/~rfield/8169519v0.jshellAPI/ >>>> >>>> >>>> Thanks, >>>> Robert >>>> >>> > From jan.lahoda at oracle.com Tue Nov 22 21:22:18 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 22 Nov 2016 22:22:18 +0100 Subject: RFR 8169519: JShell: Handle start-up failures and hangs gracefully In-Reply-To: <5833941C.1070009@oracle.com> References: <5823F11E.9010109@oracle.com> <582A0D12.5060400@oracle.com> <582A3446.1050700@oracle.com> <582BD836.8090804@oracle.com> <5833941C.1070009@oracle.com> Message-ID: <5834B70A.8030001@oracle.com> Seems OK to me. Jan On 22.11.2016 01:41, Robert Field wrote: > Per off-line review -- > > Generally looks okay, but ... I don't think the fields > > DEFAULT_TIMEOUT > REMOTE_AGENT > > should be constants from a JLS perspective. > These values are not so constant we might not want to change > them in the future, but as it is they are constants > from a Java perspective and thus the raw values will get > constant-folded and compiled into clients. I recommend > replacing these constants with static methods instead. > > Thanks, > -Joe > > I rev'ed the code again -- > > Bugs: > > 8169519: JShell: Handle start-up failures and hangs gracefully > https://bugs.openjdk.java.net/browse/JDK-8169519 > > 8166581: JShell: locks forever if -R options is wrong > https://bugs.openjdk.java.net/browse/JDK-8166581 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8169519v3.webrev/ > > Specdiff: > > http://cr.openjdk.java.net/~rfield/8169519v3.specdiff/overview-summary.html > > JShell API: > > http://cr.openjdk.java.net/~rfield/8169519v3.jshellAPI/ > > The only change in this version is to the JdiDefaultExecutionControl class: > > http://cr.openjdk.java.net/~rfield/8169519v3.specdiff/jdk/jshell/execution/JdiDefaultExecutionControl.html > > > http://cr.openjdk.java.net/~rfield/8169519v3.jshellAPI/jdk/jshell/execution/JdiDefaultExecutionControl.html > > > http://cr.openjdk.java.net/~rfield/8169519v3.webrev/src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java.sdiff.html > > > as above, changing the two constants to methods. > > Robert > > > > > On 11/15/16 19:53, Robert Field wrote: >> OK, here is v2 -- addresses the first issue, dials-back the second issue. >> But, much more importantly, after discussions of JDI and some issues >> there with Alan, I've moved the JShell code to take more control and >> do more complete failure handling. >> >> New webrev: >> >> http://cr.openjdk.java.net/~rfield/8169519v2.webrev/ >> >> >> Annotated changes from v1 below -- >> >> @@@ New tests >> >> Only in ./test/jdk/jshell: FailOverExecutionControlDyingLaunchTest.java >> Only in ./test/jdk/jshell: FailOverExecutionControlHangingLaunchTest.java >> Only in ./test/jdk/jshell: FailOverExecutionControlHangingListenTest.java >> >> >> @@@ First choice in fail-over sequence is JShell controlled launch: >> >> --- ./src/jdk.jshell/share/classes/jdk/jshell/JShell.java Tue Nov 15 >> 13:32:14 2016 >> *************** >> *** 118,125 **** >> this.extraCompilerOptions = b.extraCompilerOptions; >> ExecutionControl.Generator executionControlGenerator = >> b.executionControlGenerator==null >> ? failOverExecutionControlGenerator( >> - JdiDefaultExecutionControl.launch(), >> JdiDefaultExecutionControl.listen(InetAddress.getLoopbackAddress().getHostAddress()), >> >> JdiDefaultExecutionControl.listen(null) >> ) >> : b.executionControlGenerator; >> --- 118,125 ---- >> this.extraCompilerOptions = b.extraCompilerOptions; >> ExecutionControl.Generator executionControlGenerator = >> b.executionControlGenerator==null >> ? failOverExecutionControlGenerator( >> JdiDefaultExecutionControl.listen(InetAddress.getLoopbackAddress().getHostAddress()), >> >> + JdiDefaultExecutionControl.launch(), >> JdiDefaultExecutionControl.listen(null) >> ) >> : b.executionControlGenerator; >> >> >> @@@ Monitor process termination (listen case) to more quickly >> fail-over. New parameter to timedVirtualMachineCreation >> >> @@@ Put stopListening in a finally clause so connections don't leak >> >> diff -r >> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java >> ./src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java >> 27a28 >>> import java.io.IOException; >> 43a45 >>> import com.sun.jdi.connect.IllegalConnectorArgumentsException; >> 126c128 >> < VirtualMachine new_vm = timedVirtualMachineCreation(() >> -> launcher.launch(connectorArgs)); >> --- >>> VirtualMachine new_vm = timedVirtualMachineCreation(() -> >>> launcher.launch(connectorArgs), null); >> 160,161c162,163 >> < vm = timedVirtualMachineCreation(() -> >> listener.accept(connectorArgs)); >> < listener.stopListening(connectorArgs); >> --- >>> vm = timedVirtualMachineCreation(() -> >>> listener.accept(connectorArgs), >>> () -> process.waitFor()); >> 167a170,175 >>> } finally { >>> try { >>> listener.stopListening(connectorArgs); >>> } catch (IOException | IllegalConnectorArgumentsException >>> ex) { >>> // ignore >>> } >> 171c179,180 >> < VirtualMachine >> timedVirtualMachineCreation(Callable creator) throws >> Exception { >> --- >>> VirtualMachine >>> timedVirtualMachineCreation(Callable creator, >>> Callable processComplete) throws Exception { >> 173c182 >> < ExecutorService executor = >> Executors.newSingleThreadExecutor(runnable -> { >> --- >>> ExecutorService executor = >>> Executors.newCachedThreadPool(runnable -> { >> 178,179d186 >> < Future future = executor.submit(creator); >> < >> 181,184c188,202 >> < result = future.get(connectTimeout, TimeUnit.MILLISECONDS); >> < } catch (TimeoutException ex) { >> < future.cancel(true); >> < throw ex; >> --- >>> Future future = executor.submit(creator); >>> if (processComplete != null) { >>> executor.submit(() -> { >>> Integer i = processComplete.call(); >>> future.cancel(true); >>> return i; >>> }); >>> } >>> >>> try { >>> result = future.get(connectTimeout, >>> TimeUnit.MILLISECONDS); >>> } catch (TimeoutException ex) { >>> future.cancel(true); >>> throw ex; >>> } >> >> >> @@@ Add license header >> >> diff -r /w/y/dev/langtools/test/jdk/jshell/DyingRemoteAgent.java >> ./test/jdk/jshell/DyingRemoteAgent.java >> 0a1,22 >>> /* >>> * Copyright (c) 2016, Oracle and/or its affiliates. All rights >>> reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> * under the terms of the GNU General Public License version 2 only, as >>> * published by the Free Software Foundation. >>> * >>> * This code is distributed in the hope that it will be useful, but >>> WITHOUT >>> * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >>> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >>> * version 2 for more details (a copy is included in the LICENSE file >>> that >>> * accompanied this code). >>> * >>> * You should have received a copy of the GNU General Public License >>> version >>> * 2 along with this work; if not, write to the Free Software >>> Foundation, >>> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>> * >>> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>> 94065 USA >>> * or visit www.oracle.com if you need additional information or have >>> any >>> * questions. >>> */ >> >> @@@ Trim some over-jealous exception message matches >> >> diff -r >> /w/y/dev/langtools/test/jdk/jshell/JdiBadOptionListenExecutionControlTest.java >> ./test/jdk/jshell/JdiBadOptionListenExecutionControlTest.java >> 42c42 >> < "Launching JShell execution engine threw: Failed remote >> listen: java.util.concurrent.ExecutionException: >> com.sun.jdi.connect.TransportTimeoutException: timeout waiting for >> connection @ com.sun.jdi.SocketListen"; >> --- >>> "Launching JShell execution engine threw: Failed remote >>> listen:"; >> diff -r /w/y/dev/langtools/test/jdk/jshell/StartOptionTest.java >> ./test/jdk/jshell/StartOptionTest.java >> 144c144 >> < assertTrue(s.startsWith("Launching JShell execution >> engine threw: Failed remote launch:"), s); >> --- >>> assertTrue(s.startsWith("Launching JShell execution engine threw: >>> Failed remote"), s); >> >> >> Thanks, >> Robert >> >> >> >> On 11/14/16 14:01, Jan Lahoda wrote: >>> Overall, seems OK to me. Two comments: >>> -DyingRemoteAgent should have a license header: >>> http://cr.openjdk.java.net/~rfield/8169519v1.webrev/test/jdk/jshell/DyingRemoteAgent.java.html >>> >>> -the tests seem to depend on exact exception messages - is there a >>> risk of that being unstable? (And, possibly, platform-specific?) >>> >>> Jan >>> >>> On 14.11.2016 20:14, Robert Field wrote: >>>> Updated webrev: >>>> >>>> http://cr.openjdk.java.net/~rfield/8169519v1.webrev/ >>>> >>>> Change of how localhost determined (thanks, Jan). Tests not >>>> included in >>>> webrev, >>>> >>>> -Robert >>>> >>>> On 11/09/16 20:01, Robert Field wrote: >>>>> JShell: Handle start-up failures and hangs gracefully -- >>>>> specifically -- >>>>> Add time-outs so hangs do not lock out users and so fail-over can >>>>> function. >>>>> Handle failures more gracefully, including cleaning up remote process. >>>>> Fail-fast for better user-experience and better failure handling. >>>>> Surface failure in API. >>>>> Add testing hooks. >>>>> Better failure information. >>>>> >>>>> Bugs: >>>>> >>>>> 8169519: JShell: Handle start-up failures and hangs gracefully >>>>> https://bugs.openjdk.java.net/browse/JDK-8169519 >>>>> >>>>> 8166581: JShell: locks forever if -R options is wrong >>>>> https://bugs.openjdk.java.net/browse/JDK-8166581 >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~rfield/8169519v0.webrev/ >>>>> >>>>> Specdiff: >>>>> >>>>> http://cr.openjdk.java.net/~rfield/8169519v0.specdiff/overview-summary.html >>>>> >>>>> >>>>> >>>>> JShell API: >>>>> >>>>> http://cr.openjdk.java.net/~rfield/8169519v0.jshellAPI/ >>>>> >>>>> >>>>> Thanks, >>>>> Robert >>>>> >>>> >> > From robert.field at oracle.com Sat Nov 26 22:14:21 2016 From: robert.field at oracle.com (Robert Field) Date: Sat, 26 Nov 2016 14:14:21 -0800 Subject: RFR 8170015: JShell: /help output looks terrible on a 100 column wide terminal Message-ID: <583A093D.5070802@oracle.com> Please review... Bugs: 8170015: jshell tool: /help output looks terrible on a 100 column wide terminal https://bugs.openjdk.java.net/browse/JDK-8170015 8170368: jshell tool: post setting not properly applied, line-ends not prefixed correctly https://bugs.openjdk.java.net/browse/JDK-8170368 Webrev: http://cr.openjdk.java.net/~rfield/8170015v1.webrev/ Thanks, Robert From robert.field at oracle.com Sat Nov 26 22:19:07 2016 From: robert.field at oracle.com (Robert Field) Date: Sat, 26 Nov 2016 14:19:07 -0800 Subject: RFR 8170162: jshell tool: no mechanism to programmatically launch Message-ID: <583A0A5B.6050100@oracle.com> Goldilocks and the three launching mechanisms... She lay down in the first bed, but it was too hard. java.util.spi.ToolProvider (8169821) has a severe impedance mismatch: the use of Writers, no InputStream, and no flexibility. Then she lay in the second bed, but it was too soft. javax.tools.ToolProvider (8170044) would require significant changes that are not possible at this time, it is limited, and is old mechanism. Then she lay down in the third bed and it was just right. Goldilocks fell asleep. jdk.jshell.tool (8170162) provides a matching, clean, and configurable launching mechanism Please review... Bug: 8170162: jshell tool: no mechanism to programmatically launch https://bugs.openjdk.java.net/browse/JDK-8170162 Sub-Tasks (tiny tweaks to other repos): 8170194: jshell tool (jdk repo): launch tool from JShellToolProvider https://bugs.openjdk.java.net/browse/JDK-8170194 8170195: jshell tool (make): update javadoc generation for jdk.jshell https://bugs.openjdk.java.net/browse/JDK-8170195 Webrevs: http://cr.openjdk.java.net/~rfield/8170162v0.webrev/ http://cr.openjdk.java.net/~rfield/8170194v0.webrev/ http://cr.openjdk.java.net/~rfield/8170195v0.webrev/ API: http://cr.openjdk.java.net/~rfield/8170162v0.jshellAPI/ SpecDiff: http://cr.openjdk.java.net/~rfield/8170162v0.specdiff/overview-summary.html Thanks, Robert From robert.field at oracle.com Sun Nov 27 04:04:25 2016 From: robert.field at oracle.com (Robert Field) Date: Sat, 26 Nov 2016 20:04:25 -0800 Subject: RFR 8169828: jdk/jshell/ExternalEditorTest.java testStatementMush() fails frequently on all platform Message-ID: <583A5B49.4080102@oracle.com> Please review... Bug: https://bugs.openjdk.java.net/browse/JDK-8169828 Related bug: https://bugs.openjdk.java.net/browse/JDK-8170369 Webrev: http://cr.openjdk.java.net/~rfield/8169828v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Mon Nov 28 16:47:45 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 28 Nov 2016 17:47:45 +0100 Subject: RFR 8170015: JShell: /help output looks terrible on a 100 column wide terminal In-Reply-To: <583A093D.5070802@oracle.com> References: <583A093D.5070802@oracle.com> Message-ID: <583C5FB1.3050709@oracle.com> Overall seems ok. Nit: -the return in JShellTool.prefix appears to be indented one space too much. Jan On 26.11.2016 23:14, Robert Field wrote: > Please review... > > Bugs: > > 8170015: jshell tool: /help output looks terrible on a 100 column > wide terminal > https://bugs.openjdk.java.net/browse/JDK-8170015 > > 8170368: jshell tool: post setting not properly applied, line-ends > not prefixed correctly > https://bugs.openjdk.java.net/browse/JDK-8170368 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8170015v1.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Mon Nov 28 16:47:49 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 28 Nov 2016 17:47:49 +0100 Subject: RFR 8169828: jdk/jshell/ExternalEditorTest.java testStatementMush() fails frequently on all platform In-Reply-To: <583A5B49.4080102@oracle.com> References: <583A5B49.4080102@oracle.com> Message-ID: <583C5FB5.5030208@oracle.com> Seems OK. Jan On 27.11.2016 05:04, Robert Field wrote: > Please review... > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8169828 > > Related bug: > > https://bugs.openjdk.java.net/browse/JDK-8170369 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8169828v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Mon Nov 28 22:49:52 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 28 Nov 2016 14:49:52 -0800 Subject: RFR (s) 8167185: JShell API: Exported elements referring to inaccessible types in jdk.jshell Message-ID: <583CB490.1050307@oracle.com> Please review.... Bugs: 8167185: JShell API: Exported elements referring to inaccessible types in jdk.jshell https://bugs.openjdk.java.net/browse/JDK-8167185 Sub-Task: 8170406: JShell (jdk): remove exports exclusion from -Xlint for jdk.jshell https://bugs.openjdk.java.net/browse/JDK-8170406 Webrevs: http://cr.openjdk.java.net/~rfield/8167185v0.webrev/ http://cr.openjdk.java.net/~rfield/8170406v0.webrev/ Thanks, Robert From germano.carella at gmail.com Fri Nov 4 06:18:40 2016 From: germano.carella at gmail.com (germano.carella at gmail.com) Date: Fri, 04 Nov 2016 06:18:40 -0000 Subject: Jshell questions Message-ID: <581c283c.913fc20a.fd955.fd9b@mx.google.com> Hi to all, I?m Germano from Italy. I?m new of this list and java in general. Perhaps these question are been asked, but I?m new and I don?t know differences between java 9 an java 8, so let me ask again. 1) I installed jdk-9 142 for Windows and I started using jshell. I notice that jshell shows me sun.* classes but it won?t let me import them in any way. This is normal? I read more java samples that use sun classes but I can?t try them. 2) In java 9 there are jmods files, I read, that I can use. There is a way to use jmods with jshell? I can?t find documentation on how to make it easy; can you provide me some example? Thanks for the moment! Germano Inviato da Posta per Windows 10