From bitterfoxc at gmail.com Thu Sep 1 02:12:10 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Thu, 1 Sep 2016 11:12:10 +0900 Subject: RFR 8164825: jshell tool: Completion for subcommand In-Reply-To: <57C424D3.4080309@oracle.com> References: <57C424D3.4080309@oracle.com> Message-ID: Hi Jan, Thank you for the review. I've pushed. http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d87cef2896aa Sorry for late pushing, Robert. Regards, shinyafox(Shinya Yoshida) 2016-08-29 21:04 GMT+09:00 Jan Lahoda : > Hi Shinya, > > Seems good to me. > > Jan > > > On 27.8.2016 06:46, ShinyaYoshida wrote: > >> Hi all, >> Could you review this? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164825 >> >> Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8164825/webrev.00/ >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> From robert.field at oracle.com Thu Sep 1 03:46:02 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 31 Aug 2016 20:46:02 -0700 Subject: RFR 8164825: jshell tool: Completion for subcommand In-Reply-To: References: <57C424D3.4080309@oracle.com> Message-ID: <57C7A47A.7020001@oracle.com> Thanks for the fix, shinyafox! -Robert On 08/31/16 19:12, ShinyaYoshida wrote: > Hi Jan, > Thank you for the review. I've pushed. > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d87cef2896aa > > Sorry for late pushing, Robert. > > Regards, > shinyafox(Shinya Yoshida) > > 2016-08-29 21:04 GMT+09:00 Jan Lahoda : > >> Hi Shinya, >> >> Seems good to me. >> >> Jan >> >> >> On 27.8.2016 06:46, ShinyaYoshida wrote: >> >>> Hi all, >>> Could you review this? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164825 >>> >>> Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8164825/webrev.00/ >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> From robert.field at oracle.com Thu Sep 1 07:11:56 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 01 Sep 2016 00:11:56 -0700 Subject: 8165211: JShell: Fix completion analysis problems Message-ID: <57C7D4BC.4070202@oracle.com> Please review.... Bugs: JShell: Fix completion analysis problems https://bugs.openjdk.java.net/browse/JDK-8165211 Which includes these two sub-tasks (previously separate bugs): JShell: incorrect completion analysis for class literals https://bugs.openjdk.java.net/browse/JDK-8130454 JShell: Completion detection: "new" constructor reference considered incomplete https://bugs.openjdk.java.net/browse/JDK-8080071 Webrev: http://cr.openjdk.java.net/~rfield/8165211v0.webrev/ Thanks, Robert From bitterfoxc at gmail.com Thu Sep 1 12:36:41 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Thu, 1 Sep 2016 21:36:41 +0900 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] Message-ID: Hi all, I've implemented this feature to JShell API and Tool with full completion: Bugs: https://bugs.openjdk.java.net/browse/JDK-8154714 jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.jdk/ langtools: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.langtools/ This is missing the train of Java 9.0 but it could catch the train of Java 9.1 or later. I want to get your comments for this. jshell> /set add-exports jdk.jconsole sun.tools.jconsole jshell> import sun.tools.jconsole.* jshell> LocalVirtualMachine.getAllVirtualMachines().forEach((k, v) -> System.out.println(k + ":" + v)) 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool 10826:jdk.jshell.execution.RemoteExecutionControl 35548 28447:org.netbeans.Main --cachedir /home/bitter_fox/.cache/netbeans/8.0.1 --userdir /home/bitter_fox/.netbeans/8.0.1 --branding nb Currently, there is no testing, so it will be required to add test. Regards, shinyafox(Shinya Yoshida) From jan.lahoda at oracle.com Thu Sep 1 14:45:45 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 1 Sep 2016 16:45:45 +0200 Subject: RFR JDK-8164952: JShell tests: jdk/jshell/CompletionSuggestionTest.testUncompletedDeclaration(): failure Message-ID: <57C83F19.7070806@oracle.com> Hello, Bug: https://bugs.openjdk.java.net/browse/JDK-8164952 Webrev: http://cr.openjdk.java.net/~jlahoda/8164952/webrev.00/ The problem is that another test (ClassPathTest) creates directory "class_path_test", which is then picked up by the testUncompletedDeclaration test as a package. The proposed solution is to simply use "claz" as a prefix instead of "cla", to ensure the output is always "clazz" only. Any feedback on this? Thanks, Jan From robert.field at oracle.com Thu Sep 1 17:15:10 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 01 Sep 2016 10:15:10 -0700 Subject: RFR 8165211: JShell: Fix completion analysis problems Message-ID: <57C8621E.4070301@oracle.com> Please review.... Bugs: JShell: Fix completion analysis problems https://bugs.openjdk.java.net/browse/JDK-8165211 Which includes these two sub-tasks (previously separate bugs): JShell: incorrect completion analysis for class literals https://bugs.openjdk.java.net/browse/JDK-8130454 JShell: Completion detection: "new" constructor reference considered incomplete https://bugs.openjdk.java.net/browse/JDK-8080071 Webrev: http://cr.openjdk.java.net/~rfield/8165211v0.webrev/ Thanks, Robert From robert.field at oracle.com Thu Sep 1 17:16:29 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 01 Sep 2016 10:16:29 -0700 Subject: RFR JDK-8164952: JShell tests: jdk/jshell/CompletionSuggestionTest.testUncompletedDeclaration(): failure In-Reply-To: <57C83F19.7070806@oracle.com> References: <57C83F19.7070806@oracle.com> Message-ID: <57C8626D.2040009@oracle.com> Thumbs up! On 09/01/16 07:45, Jan Lahoda wrote: > Hello, > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8164952 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8164952/webrev.00/ > > The problem is that another test (ClassPathTest) creates directory > "class_path_test", which is then picked up by the > testUncompletedDeclaration test as a package. The proposed solution is > to simply use "claz" as a prefix instead of "cla", to ensure the > output is always "clazz" only. > > Any feedback on this? > > Thanks, > Jan From robert.field at oracle.com Thu Sep 1 17:25:27 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 01 Sep 2016 10:25:27 -0700 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: References: Message-ID: <57C86487.5010703@oracle.com> On 09/01/16 05:36, ShinyaYoshida wrote: > Hi all, > I've implemented this feature to JShell API and Tool with full completion: > Bugs: https://bugs.openjdk.java.net/browse/JDK-8154714 > > jdk: > http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.jdk/ > > langtools: > http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.langtools/ > > I'll look at this today. > This is missing the train of Java 9.0 but it could catch the train of > Java 9.1 or later. > I want to get your comments for this. I've assigned this to you. I think it is important to get this in for 9. So, if you think it can be ready soon we can make it happen. > > jshell> /set add-exports jdk.jconsole sun.tools.jconsole We don't currently have any hyphenated sub-commands. What do people think of just having it be "exports"? > > jshell> import sun.tools.jconsole.* > > jshell> LocalVirtualMachine.getAllVirtualMachines().forEach((k, v) -> > System.out.println(k + ":" + v)) > 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool > 10826:jdk.jshell.execution.RemoteExecutionControl 35548 > 28447:org.netbeans.Main --cachedir > /home/bitter_fox/.cache/netbeans/8.0.1 --userdir > /home/bitter_fox/.netbeans/8.0.1 --branding nb > > Currently, there is no testing, so it will be required to add test. Of course. > > Regards, > shinyafox(Shinya Yoshida) Thanks, Robert From jan.lahoda at oracle.com Thu Sep 1 19:27:07 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 1 Sep 2016 21:27:07 +0200 Subject: RFR 8165211: JShell: Fix completion analysis problems In-Reply-To: <57C8621E.4070301@oracle.com> References: <57C8621E.4070301@oracle.com> Message-ID: <57C8810B.8000404@oracle.com> Seems OK. Jan On 1.9.2016 19:15, Robert Field wrote: > Please review.... > > Bugs: > > JShell: Fix completion analysis problems > https://bugs.openjdk.java.net/browse/JDK-8165211 > > Which includes these two sub-tasks (previously separate bugs): > > JShell: incorrect completion analysis for class literals > https://bugs.openjdk.java.net/browse/JDK-8130454 > > JShell: Completion detection: "new" constructor reference > considered incomplete > https://bugs.openjdk.java.net/browse/JDK-8080071 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8165211v0.webrev/ > > Thanks, > Robert > From bitterfoxc at gmail.com Thu Sep 1 21:56:29 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Fri, 2 Sep 2016 06:56:29 +0900 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: <57C86487.5010703@oracle.com> References: <57C86487.5010703@oracle.com> Message-ID: 2016-09-02 2:25 GMT+09:00 Robert Field : > > On 09/01/16 05:36, ShinyaYoshida wrote: > >> Hi all, >> I've implemented this feature to JShell API and Tool with full completion: >> Bugs: https://bugs.openjdk.java.net/browse/JDK-8154714 >> >> jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.jdk/ < >> http://cr.openjdk.java.net/%7Eshinyafox/kulla/8154714/webrev.00.jdk/> >> langtools: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev. >> 00.langtools/ > Eshinyafox/kulla/8154714/webrev.00.langtools/> >> >> > I'll look at this today. > > This is missing the train of Java 9.0 but it could catch the train of Java >> 9.1 or later. >> I want to get your comments for this. >> > > I've assigned this to you. I think it is important to get this in for 9. > So, if you think it can be ready soon we can make it happen. Hi Robert, Thank you?? Probably I can prepare the first RFR in 2 or 3 days. I wonder if you could work on the documentation of the API and the tool instead? > >> jshell> /set add-exports jdk.jconsole sun.tools.jconsole >> > > We don't currently have any hyphenated sub-commands. What do people think > of just having it be "exports"? Absolutely!! It seems to me that it's reasonable. Questions: - Subcommand of /set is reasonable? Similar command, /classpath, to make users available to use new packages is not a subcommand of /set. - Should we need retain feature to this? Regards, shinyafox(Shinya Yoshida) > > > >> jshell> import sun.tools.jconsole.* >> >> jshell> LocalVirtualMachine.getAllVirtualMachines().forEach((k, v) -> >> System.out.println(k + ":" + v)) >> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >> 10826:jdk.jshell.execution.RemoteExecutionControl 35548 >> 28447:org.netbeans.Main --cachedir /home/bitter_fox/.cache/netbeans/8.0.1 >> --userdir /home/bitter_fox/.netbeans/8.0.1 --branding nb >> >> Currently, there is no testing, so it will be required to add test. >> > > Of course. > > >> Regards, >> shinyafox(Shinya Yoshida) >> > > Thanks, > Robert > > From robert.field at oracle.com Fri Sep 2 02:38:20 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 01 Sep 2016 19:38:20 -0700 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: References: Message-ID: <57C8E61C.1040907@oracle.com> Thanks shiyafox! This is a significant piece of code! As to your questions -- > I wonder if you could work on the documentation of the API and the tool instead? Yes, I will do API and tool docs. > Subcommand of /set is reasonable? Similar command, /classpath, to make users available to use new packages is not a subcommand of /set. Yes, I think /set exports is best. And, yes, /classpath is inconsistent, it should be /set classpath, that can be a separate task, unless you want to roll that in. > Should we need retain feature to this? All /set have a /retain counterpart -- we should maintain that As to the code review: Looks good to me, just minor questions/issues -- JShellTool.java: * As discussed /set add-exports => /set exports * Nit: a comment got moved out of place line 1194(old) JShell.java: * EXT_CMD_AVAILABLE_MODULES and EXT_CMD_AVAILABLE_PACKAGES, these should be referenced via RemoteCodes.java rather than be coped. * Which leads me to another question: why is addExports a command and these two are extensions. It seems fine, just curious. I notice that extensions are a lot less code -- ;-) TaskFactory.java: * Question: the "/" separator between module and package is that platform independent? DefaultLoaderDelegate.java: * Jan, can you look at this code? -Robert On 09/01/16 05:36, ShinyaYoshida wrote: > Hi all, > I've implemented this feature to JShell API and Tool with full completion: > Bugs: https://bugs.openjdk.java.net/browse/JDK-8154714 > > jdk: > http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.jdk/ > > langtools: > http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.langtools/ > > > This is missing the train of Java 9.0 but it could catch the train of > Java 9.1 or later. > I want to get your comments for this. > > jshell> /set add-exports jdk.jconsole sun.tools.jconsole > > jshell> import sun.tools.jconsole.* > > jshell> LocalVirtualMachine.getAllVirtualMachines().forEach((k, v) -> > System.out.println(k + ":" + v)) > 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool > 10826:jdk.jshell.execution.RemoteExecutionControl 35548 > 28447:org.netbeans.Main --cachedir > /home/bitter_fox/.cache/netbeans/8.0.1 --userdir > /home/bitter_fox/.netbeans/8.0.1 --branding nb > > Currently, there is no testing, so it will be required to add test. > > Regards, > shinyafox(Shinya Yoshida) From bitterfoxc at gmail.com Sat Sep 3 09:15:12 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Sat, 3 Sep 2016 18:15:12 +0900 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: <57C8E61C.1040907@oracle.com> References: <57C8E61C.1040907@oracle.com> Message-ID: Hi Robert, Thank you for reviewing. I'll update my patch later. 2016-09-02 11:38 GMT+09:00 Robert Field : > Thanks shiyafox! This is a significant piece of code! > > As to your questions -- > > > I wonder if you could work on the documentation of the API and the tool > instead? > > Yes, I will do API and tool docs. Thank you! > Subcommand of /set is reasonable? Similar command, /classpath, to make > users available to use new packages is not a subcommand of /set. > > Yes, I think /set exports is best. And, yes, /classpath is inconsistent, > it should be /set classpath, that can be a separate task, unless you want > to roll that in. I see, I've created the issue to move /classpath to /set classpath: https://bugs.openjdk.java.net/browse/JDK-8165405 > > Should we need retain feature to this? > > All /set have a /retain counterpart -- we should maintain that > Ok, I'll add /retain exports. I've also create the issue for retaining classpath: https://bugs.openjdk.java.net/browse/JDK-8165406 > As to the code review: Looks good to me, just minor questions/issues -- > > JShellTool.java: > > * As discussed /set add-exports => /set exports > > * Nit: a comment got moved out of place line 1194(old) > > JShell.java: > > * EXT_CMD_AVAILABLE_MODULES and EXT_CMD_AVAILABLE_PACKAGES, these should > be referenced via RemoteCodes.java rather than be coped. > Absolutely! I'd like to move these into RemoteCodes but it is package-private class and cannot be referred from JShell. Can I make RemoteCodes public and move it to another module-private package like jdk.jshell.execution.code? > * Which leads me to another question: why is addExports a command and > these two are extensions. It seems fine, just curious. I notice that > extensions are a lot less code -- ;-) Exporting module and package is similar to adding classpath to platform, so I made the addExports a command like setClasspath. And it should be added as API because it is very basic feature. > TaskFactory.java: > > * Question: the "/" separator between module and package is that platform > independent? > It seems to me that "{module}/{path}" format for --add-exports option of javac is platform independent. Regards, shinyafox(Shinya Yoshida) > DefaultLoaderDelegate.java: > > * Jan, can you look at this code? > > > -Robert > > > On 09/01/16 05:36, ShinyaYoshida wrote: > >> Hi all, >> I've implemented this feature to JShell API and Tool with full completion: >> Bugs: https://bugs.openjdk.java.net/browse/JDK-8154714 >> >> jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.jdk/ < >> http://cr.openjdk.java.net/%7Eshinyafox/kulla/8154714/webrev.00.jdk/> >> langtools: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev. >> 00.langtools/ > Eshinyafox/kulla/8154714/webrev.00.langtools/> >> >> This is missing the train of Java 9.0 but it could catch the train of >> Java 9.1 or later. >> I want to get your comments for this. >> >> jshell> /set add-exports jdk.jconsole sun.tools.jconsole >> >> jshell> import sun.tools.jconsole.* >> >> jshell> LocalVirtualMachine.getAllVirtualMachines().forEach((k, v) -> >> System.out.println(k + ":" + v)) >> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >> 10826:jdk.jshell.execution.RemoteExecutionControl 35548 >> 28447:org.netbeans.Main --cachedir /home/bitter_fox/.cache/netbeans/8.0.1 >> --userdir /home/bitter_fox/.netbeans/8.0.1 --branding nb >> >> Currently, there is no testing, so it will be required to add test. >> >> Regards, >> shinyafox(Shinya Yoshida) >> > > From bitterfoxc at gmail.com Sat Sep 3 12:07:15 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Sat, 3 Sep 2016 21:07:15 +0900 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: References: <57C8E61C.1040907@oracle.com> Message-ID: Hi all, I've updated my patch, new webrev is here: webrev.01.langtools: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.01.langtools/ webrev.01.jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.01.jdk/ (Same as previous) In this version, - rename /set add-exports to /set exports - add /retain exports - add tests - move EXT_CMD_XXX into RemoteCodes - make RemoteCodes public and move it into jdk.jshell.execution.code which is module-private Regards, shinyafox(Shinya Yoshida) 2016-09-03 18:15 GMT+09:00 ShinyaYoshida : > Hi Robert, > Thank you for reviewing. > I'll update my patch later. > > 2016-09-02 11:38 GMT+09:00 Robert Field : > >> Thanks shiyafox! This is a significant piece of code! >> >> As to your questions -- >> >> > I wonder if you could work on the documentation of the API and the >> tool instead? >> >> Yes, I will do API and tool docs. > > Thank you! > > > Subcommand of /set is reasonable? Similar command, /classpath, to make >> users available to use new packages is not a subcommand of /set. >> >> Yes, I think /set exports is best. And, yes, /classpath is inconsistent, >> it should be /set classpath, that can be a separate task, unless you want >> to roll that in. > > I see, I've created the issue to move /classpath to /set classpath: > https://bugs.openjdk.java.net/browse/JDK-8165405 > > >> > Should we need retain feature to this? >> >> All /set have a /retain counterpart -- we should maintain that >> > Ok, I'll add /retain exports. > I've also create the issue for retaining classpath: > https://bugs.openjdk.java.net/browse/JDK-8165406 > > >> As to the code review: Looks good to me, just minor questions/issues -- >> >> JShellTool.java: >> >> * As discussed /set add-exports => /set exports >> >> * Nit: a comment got moved out of place line 1194(old) >> >> JShell.java: >> >> * EXT_CMD_AVAILABLE_MODULES and EXT_CMD_AVAILABLE_PACKAGES, these should >> be referenced via RemoteCodes.java rather than be coped. >> > Absolutely! I'd like to move these into RemoteCodes but it is > package-private class and cannot be referred from JShell. > Can I make RemoteCodes public and move it to another module-private > package like jdk.jshell.execution.code? > > >> * Which leads me to another question: why is addExports a command and >> these two are extensions. It seems fine, just curious. I notice that >> extensions are a lot less code -- ;-) > > Exporting module and package is similar to adding classpath to platform, > so I made the addExports a command like setClasspath. > And it should be added as API because it is very basic feature. > > >> TaskFactory.java: >> >> * Question: the "/" separator between module and package is that platform >> independent? >> > It seems to me that "{module}/{path}" format for --add-exports option of > javac is platform independent. > > Regards, > shinyafox(Shinya Yoshida) > > >> DefaultLoaderDelegate.java: >> >> * Jan, can you look at this code? >> >> >> -Robert >> >> >> On 09/01/16 05:36, ShinyaYoshida wrote: >> >>> Hi all, >>> I've implemented this feature to JShell API and Tool with full >>> completion: >>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8154714 >>> >>> jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.jdk/ >>> >>> langtools: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>> 0.langtools/ >> Eshinyafox/kulla/8154714/webrev.00.langtools/> >>> >>> This is missing the train of Java 9.0 but it could catch the train of >>> Java 9.1 or later. >>> I want to get your comments for this. >>> >>> jshell> /set add-exports jdk.jconsole sun.tools.jconsole >>> >>> jshell> import sun.tools.jconsole.* >>> >>> jshell> LocalVirtualMachine.getAllVirtualMachines().forEach((k, v) -> >>> System.out.println(k + ":" + v)) >>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>> 10826:jdk.jshell.execution.RemoteExecutionControl 35548 >>> 28447:org.netbeans.Main --cachedir /home/bitter_fox/.cache/netbeans/8.0.1 >>> --userdir /home/bitter_fox/.netbeans/8.0.1 --branding nb >>> >>> Currently, there is no testing, so it will be required to add test. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >> >> > From bitterfoxc at gmail.com Mon Sep 5 13:49:39 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Mon, 5 Sep 2016 22:49:39 +0900 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: <57CD09FE.70908@oracle.com> References: <57C8E61C.1040907@oracle.com> <57CD09FE.70908@oracle.com> Message-ID: Hi Robert, Thank you for the review. I totally agree with you. I also think that availableModules and availablePackages(module) are worthless excepting for the command completion feature. I'd like to avoid adding these APIs which have not been speculated and revised because if API is once added, it is too difficult to remove than adding. So currently, I'll remove the completion feature for /set or /retain exports and make the issue to JBS to add completion feature for them in future. I'll update the webrev. So please review it again later. When the silently evaluation feature is added, I'd like to work for the completion feature again. Thank you, shinyafox(Shinya Yoshida) 2016-09-05 15:00 GMT+09:00 Robert Field : > > On 09/03/16 05:07, ShinyaYoshida wrote: > > Hi all, > I've updated my patch, new webrev is here: > webrev.01.langtools: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/ > webrev.01.langtools/ > webrev.01.jdk: http://cr.openjdk.java.net/~shinyafox/ > kulla/8154714/webrev.01.jdk/ (Same as previous) > > In this version, > - rename /set add-exports to /set exports > > > OK > > - add /retain exports > > > The /retain implementation looks good. > > - add tests > > > Well tested > > - move EXT_CMD_XXX into RemoteCodes > - make RemoteCodes public and move it into jdk.jshell.execution.code which > is module-private > > > So, here, in addition to addExports, there are two more methods added to > the API availableModules() and availablePackage(String module). > I see how in rare cases they could be useful. And the rare case that > causes them to be present is for command completion in the tool. > What are the options: > > (1) Add them to the API. If it is in the API then it is a first-class > form of functionality and should be treated as such in execution support > (as a command) > (2) Not support them and not support command completion for /set > exports. Command completion is not supported in much more common cases. > Then we could support command completion in the future (see (3)). > (3) What these commands do is simply execute an expression on the remote > side. But we already have a mechanism to execute expressions on the remote > side: Snippets. > That leaves a problem: we wouldn't want these Snippets to be seen > by the user, but we have a solution for that the tool uses the idGenerator. > Another problem is that, by default and with no current way around > the default, expressions generate temp-variables. My intention was to make > this configurable -- see Eval.shouldGenTempVar(...). > > One goal I've been using in the design of the API is to keep it as small > and simple as possible. This improves maintainability, but much more > importantly makes the API easier to learn and use. > So, for something to warrant inclusion it should be generally useful and > have no other way of being achieved -- neither is true of these two > queries. > > My suggestion, particularly in light of how late in the release this is, > would be (2). Thoughts? > > -Robert > > > > > > > Regards, > shinyafox(Shinya Yoshida) > > 2016-09-03 18:15 GMT+09:00 ShinyaYoshida : > >> Hi Robert, >> Thank you for reviewing. >> I'll update my patch later. >> >> 2016-09-02 11:38 GMT+09:00 Robert Field : >> >>> Thanks shiyafox! This is a significant piece of code! >>> >>> As to your questions -- >>> >>> > I wonder if you could work on the documentation of the API and the >>> tool instead? >>> >>> Yes, I will do API and tool docs. >> >> Thank you! >> >> > Subcommand of /set is reasonable? Similar command, /classpath, to make >>> users available to use new packages is not a subcommand of /set. >>> >>> Yes, I think /set exports is best. And, yes, /classpath is >>> inconsistent, it should be /set classpath, that can be a separate task, >>> unless you want to roll that in. >> >> I see, I've created the issue to move /classpath to /set classpath: >> https://bugs.openjdk.java.net/browse/JDK-8165405 >> >> >>> > Should we need retain feature to this? >>> >>> All /set have a /retain counterpart -- we should maintain that >>> >> Ok, I'll add /retain exports. >> I've also create the issue for retaining classpath: >> https://bugs.openjdk.java.net/browse/JDK-8165406 >> >> >>> As to the code review: Looks good to me, just minor questions/issues -- >>> >>> JShellTool.java: >>> >>> * As discussed /set add-exports => /set exports >>> >>> * Nit: a comment got moved out of place line 1194(old) >>> >>> JShell.java: >>> >>> * EXT_CMD_AVAILABLE_MODULES and EXT_CMD_AVAILABLE_PACKAGES, these should >>> be referenced via RemoteCodes.java rather than be coped. >>> >> Absolutely! I'd like to move these into RemoteCodes but it is >> package-private class and cannot be referred from JShell. >> Can I make RemoteCodes public and move it to another module-private >> package like jdk.jshell.execution.code? >> >> >>> * Which leads me to another question: why is addExports a command and >>> these two are extensions. It seems fine, just curious. I notice that >>> extensions are a lot less code -- ;-) >> >> Exporting module and package is similar to adding classpath to platform, >> so I made the addExports a command like setClasspath. >> And it should be added as API because it is very basic feature. >> >> >>> TaskFactory.java: >>> >>> * Question: the "/" separator between module and package is that >>> platform independent? >>> >> It seems to me that "{module}/{path}" format for --add-exports option of >> javac is platform independent. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >>> DefaultLoaderDelegate.java: >>> >>> * Jan, can you look at this code? >>> >>> >>> -Robert >>> >>> >>> On 09/01/16 05:36, ShinyaYoshida wrote: >>> >>>> Hi all, >>>> I've implemented this feature to JShell API and Tool with full >>>> completion: >>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8154714 >>>> >>>> jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.jdk/ >>>> >>>> langtools: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>> 0.langtools/ >>> Eshinyafox/kulla/8154714/webrev.00.langtools/> >>>> >>>> This is missing the train of Java 9.0 but it could catch the train of >>>> Java 9.1 or later. >>>> I want to get your comments for this. >>>> >>>> jshell> /set add-exports jdk.jconsole sun.tools.jconsole >>>> >>>> jshell> import sun.tools.jconsole.* >>>> >>>> jshell> LocalVirtualMachine.getAllVirtualMachines().forEach((k, v) -> >>>> System.out.println(k + ":" + v)) >>>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>>> 10826:jdk.jshell.execution.RemoteExecutionControl 35548 >>>> 28447:org.netbeans.Main --cachedir /home/bitter_fox/.cache/netbeans/8.0.1 >>>> --userdir /home/bitter_fox/.netbeans/8.0.1 --branding nb >>>> >>>> Currently, there is no testing, so it will be required to add test. >>>> >>>> Regards, >>>> shinyafox(Shinya Yoshida) >>>> >>> >>> >> > > From bitterfoxc at gmail.com Mon Sep 5 15:02:27 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Tue, 6 Sep 2016 00:02:27 +0900 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: References: <57C8E61C.1040907@oracle.com> <57CD09FE.70908@oracle.com> Message-ID: Hi, I've update webrev of langtools: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.02.langtools/ I added an issue for the completion feature. https://bugs.openjdk.java.net/browse/JDK-8165445 Regards, shinyafox(Shinya Yoshida) 2016-09-05 22:49 GMT+09:00 ShinyaYoshida : > Hi Robert, > Thank you for the review. > > I totally agree with you. > I also think that availableModules and availablePackages(module) are > worthless excepting for the command completion feature. > I'd like to avoid adding these APIs which have not been speculated and > revised because if API is once added, it is too difficult to remove than > adding. > > So currently, I'll remove the completion feature for /set or /retain > exports and make the issue to JBS to add completion feature for them in > future. > > I'll update the webrev. So please review it again later. > When the silently evaluation feature is added, I'd like to work for the > completion feature again. > > Thank you, > shinyafox(Shinya Yoshida) > > > 2016-09-05 15:00 GMT+09:00 Robert Field : > >> >> On 09/03/16 05:07, ShinyaYoshida wrote: >> >> Hi all, >> I've updated my patch, new webrev is here: >> webrev.01.langtools: http://cr.openjdk.java.net/~shinyafox/ >> kulla/8154714/webrev.01.langtools/ >> webrev.01.jdk: http://cr.openjdk.java.net/~shinyafox/kulla/ >> 8154714/webrev.01.jdk/ (Same as previous) >> >> In this version, >> - rename /set add-exports to /set exports >> >> >> OK >> >> - add /retain exports >> >> >> The /retain implementation looks good. >> >> - add tests >> >> >> Well tested >> >> - move EXT_CMD_XXX into RemoteCodes >> - make RemoteCodes public and move it into jdk.jshell.execution.code >> which is module-private >> >> >> So, here, in addition to addExports, there are two more methods added to >> the API availableModules() and availablePackage(String module). >> I see how in rare cases they could be useful. And the rare case that >> causes them to be present is for command completion in the tool. >> What are the options: >> >> (1) Add them to the API. If it is in the API then it is a first-class >> form of functionality and should be treated as such in execution support >> (as a command) >> (2) Not support them and not support command completion for /set >> exports. Command completion is not supported in much more common cases. >> Then we could support command completion in the future (see (3)). >> (3) What these commands do is simply execute an expression on the >> remote side. But we already have a mechanism to execute expressions on the >> remote side: Snippets. >> That leaves a problem: we wouldn't want these Snippets to be seen >> by the user, but we have a solution for that the tool uses the idGenerator. >> Another problem is that, by default and with no current way >> around the default, expressions generate temp-variables. My intention was >> to make this configurable -- see Eval.shouldGenTempVar(...). >> >> One goal I've been using in the design of the API is to keep it as small >> and simple as possible. This improves maintainability, but much more >> importantly makes the API easier to learn and use. >> So, for something to warrant inclusion it should be generally useful and >> have no other way of being achieved -- neither is true of these two >> queries. >> >> My suggestion, particularly in light of how late in the release this is, >> would be (2). Thoughts? >> >> -Robert >> >> >> >> >> >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2016-09-03 18:15 GMT+09:00 ShinyaYoshida : >> >>> Hi Robert, >>> Thank you for reviewing. >>> I'll update my patch later. >>> >>> 2016-09-02 11:38 GMT+09:00 Robert Field : >>> >>>> Thanks shiyafox! This is a significant piece of code! >>>> >>>> As to your questions -- >>>> >>>> > I wonder if you could work on the documentation of the API and the >>>> tool instead? >>>> >>>> Yes, I will do API and tool docs. >>> >>> Thank you! >>> >>> > Subcommand of /set is reasonable? Similar command, /classpath, to make >>>> users available to use new packages is not a subcommand of /set. >>>> >>>> Yes, I think /set exports is best. And, yes, /classpath is >>>> inconsistent, it should be /set classpath, that can be a separate task, >>>> unless you want to roll that in. >>> >>> I see, I've created the issue to move /classpath to /set classpath: >>> https://bugs.openjdk.java.net/browse/JDK-8165405 >>> >>> >>>> > Should we need retain feature to this? >>>> >>>> All /set have a /retain counterpart -- we should maintain that >>>> >>> Ok, I'll add /retain exports. >>> I've also create the issue for retaining classpath: >>> https://bugs.openjdk.java.net/browse/JDK-8165406 >>> >>> >>>> As to the code review: Looks good to me, just minor questions/issues -- >>>> >>>> JShellTool.java: >>>> >>>> * As discussed /set add-exports => /set exports >>>> >>>> * Nit: a comment got moved out of place line 1194(old) >>>> >>>> JShell.java: >>>> >>>> * EXT_CMD_AVAILABLE_MODULES and EXT_CMD_AVAILABLE_PACKAGES, these >>>> should be referenced via RemoteCodes.java rather than be coped. >>>> >>> Absolutely! I'd like to move these into RemoteCodes but it is >>> package-private class and cannot be referred from JShell. >>> Can I make RemoteCodes public and move it to another module-private >>> package like jdk.jshell.execution.code? >>> >>> >>>> * Which leads me to another question: why is addExports a command and >>>> these two are extensions. It seems fine, just curious. I notice that >>>> extensions are a lot less code -- ;-) >>> >>> Exporting module and package is similar to adding classpath to platform, >>> so I made the addExports a command like setClasspath. >>> And it should be added as API because it is very basic feature. >>> >>> >>>> TaskFactory.java: >>>> >>>> * Question: the "/" separator between module and package is that >>>> platform independent? >>>> >>> It seems to me that "{module}/{path}" format for --add-exports option of >>> javac is platform independent. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> >>>> DefaultLoaderDelegate.java: >>>> >>>> * Jan, can you look at this code? >>>> >>>> >>>> -Robert >>>> >>>> >>>> On 09/01/16 05:36, ShinyaYoshida wrote: >>>> >>>>> Hi all, >>>>> I've implemented this feature to JShell API and Tool with full >>>>> completion: >>>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8154714 >>>>> >>>>> jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>> 0.jdk/ >>>> v.00.jdk/> >>>>> langtools: http://cr.openjdk.java.net/~sh >>>>> inyafox/kulla/8154714/webrev.00.langtools/ < >>>>> http://cr.openjdk.java.net/%7Eshinyafox/kulla/8154714/webre >>>>> v.00.langtools/> >>>>> >>>>> This is missing the train of Java 9.0 but it could catch the train of >>>>> Java 9.1 or later. >>>>> I want to get your comments for this. >>>>> >>>>> jshell> /set add-exports jdk.jconsole sun.tools.jconsole >>>>> >>>>> jshell> import sun.tools.jconsole.* >>>>> >>>>> jshell> LocalVirtualMachine.getAllVirtualMachines().forEach((k, v) -> >>>>> System.out.println(k + ":" + v)) >>>>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>>>> 10826:jdk.jshell.execution.RemoteExecutionControl 35548 >>>>> 28447:org.netbeans.Main --cachedir /home/bitter_fox/.cache/netbeans/8.0.1 >>>>> --userdir /home/bitter_fox/.netbeans/8.0.1 --branding nb >>>>> >>>>> Currently, there is no testing, so it will be required to add test. >>>>> >>>>> Regards, >>>>> shinyafox(Shinya Yoshida) >>>>> >>>> >>>> >>> >> >> > From robert.field at oracle.com Mon Sep 5 18:10:09 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 05 Sep 2016 11:10:09 -0700 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: References: <57C8E61C.1040907@oracle.com> <57CD09FE.70908@oracle.com> Message-ID: <156fb8b0be8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Great! It would be great if you copy your code and the discussion into the issue so we don't lose context. Thanks! Robert On September 5, 2016 6:49:43 AM ShinyaYoshida wrote: > Hi Robert, > Thank you for the review. > > I totally agree with you. > I also think that availableModules and availablePackages(module) are > worthless excepting for the command completion feature. > I'd like to avoid adding these APIs which have not been speculated and > revised because if API is once added, it is too difficult to remove than > adding. > > So currently, I'll remove the completion feature for /set or /retain > exports and make the issue to JBS to add completion feature for them in > future. > > I'll update the webrev. So please review it again later. > When the silently evaluation feature is added, I'd like to work for the > completion feature again. > > Thank you, > shinyafox(Shinya Yoshida) > > > 2016-09-05 15:00 GMT+09:00 Robert Field : > >> >> On 09/03/16 05:07, ShinyaYoshida wrote: >> >> Hi all, >> I've updated my patch, new webrev is here: >> webrev.01.langtools: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/ >> webrev.01.langtools/ >> webrev.01.jdk: http://cr.openjdk.java.net/~shinyafox/ >> kulla/8154714/webrev.01.jdk/ (Same as previous) >> >> In this version, >> - rename /set add-exports to /set exports >> >> >> OK >> >> - add /retain exports >> >> >> The /retain implementation looks good. >> >> - add tests >> >> >> Well tested >> >> - move EXT_CMD_XXX into RemoteCodes >> - make RemoteCodes public and move it into jdk.jshell.execution.code which >> is module-private >> >> >> So, here, in addition to addExports, there are two more methods added to >> the API availableModules() and availablePackage(String module). >> I see how in rare cases they could be useful. And the rare case that >> causes them to be present is for command completion in the tool. >> What are the options: >> >> (1) Add them to the API. If it is in the API then it is a first-class >> form of functionality and should be treated as such in execution support >> (as a command) >> (2) Not support them and not support command completion for /set >> exports. Command completion is not supported in much more common cases. >> Then we could support command completion in the future (see (3)). >> (3) What these commands do is simply execute an expression on the remote >> side. But we already have a mechanism to execute expressions on the remote >> side: Snippets. >> That leaves a problem: we wouldn't want these Snippets to be seen >> by the user, but we have a solution for that the tool uses the idGenerator. >> Another problem is that, by default and with no current way around >> the default, expressions generate temp-variables. My intention was to make >> this configurable -- see Eval.shouldGenTempVar(...). >> >> One goal I've been using in the design of the API is to keep it as small >> and simple as possible. This improves maintainability, but much more >> importantly makes the API easier to learn and use. >> So, for something to warrant inclusion it should be generally useful and >> have no other way of being achieved -- neither is true of these two >> queries. >> >> My suggestion, particularly in light of how late in the release this is, >> would be (2). Thoughts? >> >> -Robert >> >> >> >> >> >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2016-09-03 18:15 GMT+09:00 ShinyaYoshida : >> >>> Hi Robert, >>> Thank you for reviewing. >>> I'll update my patch later. >>> >>> 2016-09-02 11:38 GMT+09:00 Robert Field : >>> >>>> Thanks shiyafox! This is a significant piece of code! >>>> >>>> As to your questions -- >>>> >>>> > I wonder if you could work on the documentation of the API and the >>>> tool instead? >>>> >>>> Yes, I will do API and tool docs. >>> >>> Thank you! >>> >>> > Subcommand of /set is reasonable? Similar command, /classpath, to make >>>> users available to use new packages is not a subcommand of /set. >>>> >>>> Yes, I think /set exports is best. And, yes, /classpath is >>>> inconsistent, it should be /set classpath, that can be a separate task, >>>> unless you want to roll that in. >>> >>> I see, I've created the issue to move /classpath to /set classpath: >>> https://bugs.openjdk.java.net/browse/JDK-8165405 >>> >>> >>>> > Should we need retain feature to this? >>>> >>>> All /set have a /retain counterpart -- we should maintain that >>>> >>> Ok, I'll add /retain exports. >>> I've also create the issue for retaining classpath: >>> https://bugs.openjdk.java.net/browse/JDK-8165406 >>> >>> >>>> As to the code review: Looks good to me, just minor questions/issues -- >>>> >>>> JShellTool.java: >>>> >>>> * As discussed /set add-exports => /set exports >>>> >>>> * Nit: a comment got moved out of place line 1194(old) >>>> >>>> JShell.java: >>>> >>>> * EXT_CMD_AVAILABLE_MODULES and EXT_CMD_AVAILABLE_PACKAGES, these should >>>> be referenced via RemoteCodes.java rather than be coped. >>>> >>> Absolutely! I'd like to move these into RemoteCodes but it is >>> package-private class and cannot be referred from JShell. >>> Can I make RemoteCodes public and move it to another module-private >>> package like jdk.jshell.execution.code? >>> >>> >>>> * Which leads me to another question: why is addExports a command and >>>> these two are extensions. It seems fine, just curious. I notice that >>>> extensions are a lot less code -- ;-) >>> >>> Exporting module and package is similar to adding classpath to platform, >>> so I made the addExports a command like setClasspath. >>> And it should be added as API because it is very basic feature. >>> >>> >>>> TaskFactory.java: >>>> >>>> * Question: the "/" separator between module and package is that >>>> platform independent? >>>> >>> It seems to me that "{module}/{path}" format for --add-exports option of >>> javac is platform independent. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> >>>> DefaultLoaderDelegate.java: >>>> >>>> * Jan, can you look at this code? >>>> >>>> >>>> -Robert >>>> >>>> >>>> On 09/01/16 05:36, ShinyaYoshida wrote: >>>> >>>>> Hi all, >>>>> I've implemented this feature to JShell API and Tool with full >>>>> completion: >>>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8154714 >>>>> >>>>> jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.jdk/ >>>>> >>>>> langtools: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>> 0.langtools/ >>>> Eshinyafox/kulla/8154714/webrev.00.langtools/> >>>>> >>>>> This is missing the train of Java 9.0 but it could catch the train of >>>>> Java 9.1 or later. >>>>> I want to get your comments for this. >>>>> >>>>> jshell> /set add-exports jdk.jconsole sun.tools.jconsole >>>>> >>>>> jshell> import sun.tools.jconsole.* >>>>> >>>>> jshell> LocalVirtualMachine.getAllVirtualMachines().forEach((k, v) -> >>>>> System.out.println(k + ":" + v)) >>>>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>>>> 10826:jdk.jshell.execution.RemoteExecutionControl 35548 >>>>> 28447:org.netbeans.Main --cachedir /home/bitter_fox/.cache/netbeans/8.0.1 >>>>> --userdir /home/bitter_fox/.netbeans/8.0.1 --branding nb >>>>> >>>>> Currently, there is no testing, so it will be required to add test. >>>>> >>>>> Regards, >>>>> shinyafox(Shinya Yoshida) >>>>> >>>> >>>> >>> >> >> From robert.field at oracle.com Tue Sep 6 06:11:05 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 05 Sep 2016 23:11:05 -0700 Subject: RFR (s) 8080352: jshell tool: Error message for using "package" should be more descriptive than "Failed" Message-ID: <57CE5DF9.3090005@oracle.com> "package xyz;" is illegal in JShell but was not being processed correctly because the JavacParser processing of package was left in. Code deletion! Bug: https://bugs.openjdk.java.net/browse/JDK-8080352 Webrev: http://cr.openjdk.java.net/~rfield/8080352v0.webrev/ Thanks, Robert From bitterfoxc at gmail.com Wed Sep 7 13:10:02 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Wed, 7 Sep 2016 22:10:02 +0900 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: <57CDE39A.3020100@oracle.com> References: <57C8E61C.1040907@oracle.com> <57CD09FE.70908@oracle.com> <57CDE39A.3020100@oracle.com> Message-ID: Hi Robert, Thank you for your helping. I've update webrev according to your comments. If I'm missing your meaning, I'm sorry. Please point it. http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.03.langtools/ Now, - JShell#addExports will throw BadArgumentException when module or package is wrong, which is check exception. - JShellTool checks that exception. - ExecutionControl#addExports throws InternalException when something is wrong. Regards, shinyafox(Shinya Yoshida) 2016-09-06 6:28 GMT+09:00 Robert Field : > Code looks good. Needs docs I promised (see below). > > As to completion issue you created, I see you already added discussion and > tests. I added your completion code. > > Below is my suggested doc... > > src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties > -- > > /set exports \n\t\ > Allow access to some of the unexported types of a module\n\n\ > > > /retain exports \n\t\ > Allow access to some of the unexported types of a module\n\n\ > > > help.set.exports=\ > Set a package to add to those exported to snippets.\n\ > \n\t\ > /set exports \n\ > \n\ > Where is the module from which to export .\n\ > Where is the package to export to snippets.\n > > > help.retain.exports=\ > Retain a package to add to those exported to snippets.\n\ > \n\t\ > /retain exports \n\ > \n\ > Where is the module from which to export .\n\ > Where is the package to export to snippets.\n > > [I notice that 'snippet' is used in doc without being defined. If, while > you are it, you change the help for /list to define it:] > > help.list =\ > Show the source of snippets, prefaced with the snippet id (a snippet is a > chunk of code that the jshell tool evaluates -- the code you enter at the > prompt is a snippet).\n\ > ... > > src/jdk.jshell/share/classes/jdk/jshell/JShell.java -- > > > /** > * Add a package to those exported to snippets. > * @param module The module from which to export > * @param pack The package to export > * @throws NullPointerException if arguments are null. > * @throws IllegalStateException if this {@code JShell} instance is > closed. > * @throws XYZ if .... > */ > > OK, actually this code should change. Like addToClasspath above it, it > should return void. It looks like under normal operation it can fail -- > the failure should be reported with an exception. > What are the failure modes? IllegalArgumentException would be likely > choice at the JShell API layer. But then the exception needs to be > propagated there. > Since none of the existing exceptions is a match, this means a new > ExecutionControlException. Maybe something general, like > BadUserArgumentException. > Note: I've also added IllegalStateException -- this can be thrown when you > get EngineTerminationException. > Also, typo, the second "module cannot be null" should be "package cannot > be null" > > src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteCodes.java -- > > The comment you have is fine. Just remove PLEASE REVISE THE COMMENT > > src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl.java -- > > /** > * Add a package to those exported to snippets. > * @param module The module from which to export > * @param pack The package to export > * @throws EngineTerminationException the execution engine has > terminated > * @throws .... > * @throws InternalException an internal problem occurred > */ > > Plus add the bad argument exception. > Whatever it is, should be added to extensionCommand() exceptions. > > Robert > > > > On 09/05/16 08:02, ShinyaYoshida wrote: > > Hi, > I've update webrev of langtools: > http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.02.langtools/ > > I added an issue for the completion feature. > https://bugs.openjdk.java.net/browse/JDK-8165445 > > Regards, > shinyafox(Shinya Yoshida) > > 2016-09-05 22:49 GMT+09:00 ShinyaYoshida : > >> Hi Robert, >> Thank you for the review. >> >> I totally agree with you. >> I also think that availableModules and availablePackages(module) are >> worthless excepting for the command completion feature. >> I'd like to avoid adding these APIs which have not been speculated and >> revised because if API is once added, it is too difficult to remove than >> adding. >> >> So currently, I'll remove the completion feature for /set or /retain >> exports and make the issue to JBS to add completion feature for them in >> future. >> >> I'll update the webrev. So please review it again later. >> When the silently evaluation feature is added, I'd like to work for the >> completion feature again. >> >> Thank you, >> shinyafox(Shinya Yoshida) >> >> >> 2016-09-05 15:00 GMT+09:00 Robert Field : >> >>> >>> On 09/03/16 05:07, ShinyaYoshida wrote: >>> >>> Hi all, >>> I've updated my patch, new webrev is here: >>> webrev.01.langtools: http://cr.openjdk.java.net/~shinyafox/k >>> ulla/8154714/webrev.01.langtools/ >>> webrev.01.jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8 >>> 154714/webrev.01.jdk/ (Same as previous) >>> >>> In this version, >>> - rename /set add-exports to /set exports >>> >>> >>> OK >>> >>> - add /retain exports >>> >>> >>> The /retain implementation looks good. >>> >>> - add tests >>> >>> >>> Well tested >>> >>> - move EXT_CMD_XXX into RemoteCodes >>> - make RemoteCodes public and move it into jdk.jshell.execution.code >>> which is module-private >>> >>> >>> So, here, in addition to addExports, there are two more methods added to >>> the API availableModules() and availablePackage(String module). >>> I see how in rare cases they could be useful. And the rare case that >>> causes them to be present is for command completion in the tool. >>> What are the options: >>> >>> (1) Add them to the API. If it is in the API then it is a first-class >>> form of functionality and should be treated as such in execution support >>> (as a command) >>> (2) Not support them and not support command completion for /set >>> exports. Command completion is not supported in much more common cases. >>> Then we could support command completion in the future (see (3)). >>> (3) What these commands do is simply execute an expression on the >>> remote side. But we already have a mechanism to execute expressions on the >>> remote side: Snippets. >>> That leaves a problem: we wouldn't want these Snippets to be >>> seen by the user, but we have a solution for that the tool uses the >>> idGenerator. >>> Another problem is that, by default and with no current way >>> around the default, expressions generate temp-variables. My intention was >>> to make this configurable -- see Eval.shouldGenTempVar(...). >>> >>> One goal I've been using in the design of the API is to keep it as small >>> and simple as possible. This improves maintainability, but much more >>> importantly makes the API easier to learn and use. >>> So, for something to warrant inclusion it should be generally useful and >>> have no other way of being achieved -- neither is true of these two >>> queries. >>> >>> My suggestion, particularly in light of how late in the release this is, >>> would be (2). Thoughts? >>> >>> -Robert >>> >>> >>> >>> >>> >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> 2016-09-03 18:15 GMT+09:00 ShinyaYoshida : >>> >>>> Hi Robert, >>>> Thank you for reviewing. >>>> I'll update my patch later. >>>> >>>> 2016-09-02 11:38 GMT+09:00 Robert Field : >>>> >>>>> Thanks shiyafox! This is a significant piece of code! >>>>> >>>>> As to your questions -- >>>>> >>>>> > I wonder if you could work on the documentation of the API and the >>>>> tool instead? >>>>> >>>>> Yes, I will do API and tool docs. >>>> >>>> Thank you! >>>> >>>> > Subcommand of /set is reasonable? Similar command, /classpath, to >>>>> make users available to use new packages is not a subcommand of /set. >>>>> >>>>> Yes, I think /set exports is best. And, yes, /classpath is >>>>> inconsistent, it should be /set classpath, that can be a separate task, >>>>> unless you want to roll that in. >>>> >>>> I see, I've created the issue to move /classpath to /set classpath: >>>> https://bugs.openjdk.java.net/browse/JDK-8165405 >>>> >>>> >>>>> > Should we need retain feature to this? >>>>> >>>>> All /set have a /retain counterpart -- we should maintain that >>>>> >>>> Ok, I'll add /retain exports. >>>> I've also create the issue for retaining classpath: >>>> https://bugs.openjdk.java.net/browse/JDK-8165406 >>>> >>>> >>>>> As to the code review: Looks good to me, just minor questions/issues -- >>>>> >>>>> JShellTool.java: >>>>> >>>>> * As discussed /set add-exports => /set exports >>>>> >>>>> * Nit: a comment got moved out of place line 1194(old) >>>>> >>>>> JShell.java: >>>>> >>>>> * EXT_CMD_AVAILABLE_MODULES and EXT_CMD_AVAILABLE_PACKAGES, these >>>>> should be referenced via RemoteCodes.java rather than be coped. >>>>> >>>> Absolutely! I'd like to move these into RemoteCodes but it is >>>> package-private class and cannot be referred from JShell. >>>> Can I make RemoteCodes public and move it to another module-private >>>> package like jdk.jshell.execution.code? >>>> >>>> >>>>> * Which leads me to another question: why is addExports a command and >>>>> these two are extensions. It seems fine, just curious. I notice that >>>>> extensions are a lot less code -- ;-) >>>> >>>> Exporting module and package is similar to adding classpath to >>>> platform, so I made the addExports a command like setClasspath. >>>> And it should be added as API because it is very basic feature. >>>> >>>> >>>>> TaskFactory.java: >>>>> >>>>> * Question: the "/" separator between module and package is that >>>>> platform independent? >>>>> >>>> It seems to me that "{module}/{path}" format for --add-exports option >>>> of javac is platform independent. >>>> >>>> Regards, >>>> shinyafox(Shinya Yoshida) >>>> >>>> >>>>> DefaultLoaderDelegate.java: >>>>> >>>>> * Jan, can you look at this code? >>>>> >>>>> >>>>> -Robert >>>>> >>>>> >>>>> On 09/01/16 05:36, ShinyaYoshida wrote: >>>>> >>>>>> Hi all, >>>>>> I've implemented this feature to JShell API and Tool with full >>>>>> completion: >>>>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8154714 >>>>>> >>>>>> jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>> 0.jdk/ >>>>> v.00.jdk/> >>>>>> langtools: http://cr.openjdk.java.net/~sh >>>>>> inyafox/kulla/8154714/webrev.00.langtools/ < >>>>>> http://cr.openjdk.java.net/%7Eshinyafox/kulla/8154714/webre >>>>>> v.00.langtools/> >>>>>> >>>>>> This is missing the train of Java 9.0 but it could catch the train of >>>>>> Java 9.1 or later. >>>>>> I want to get your comments for this. >>>>>> >>>>>> jshell> /set add-exports jdk.jconsole sun.tools.jconsole >>>>>> >>>>>> jshell> import sun.tools.jconsole.* >>>>>> >>>>>> jshell> LocalVirtualMachine.getAllVirtualMachines().forEach((k, v) >>>>>> -> System.out.println(k + ":" + v)) >>>>>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>>>>> 10826:jdk.jshell.execution.RemoteExecutionControl 35548 >>>>>> 28447:org.netbeans.Main --cachedir /home/bitter_fox/.cache/netbeans/8.0.1 >>>>>> --userdir /home/bitter_fox/.netbeans/8.0.1 --branding nb >>>>>> >>>>>> Currently, there is no testing, so it will be required to add test. >>>>>> >>>>>> Regards, >>>>>> shinyafox(Shinya Yoshida) >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From jan.lahoda at oracle.com Wed Sep 7 17:44:37 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 7 Sep 2016 19:44:37 +0200 Subject: RFR JDK-8131025: JShell: crash on tab-complete reference to bad class file Message-ID: <57D05205.9040503@oracle.com> Hello, Bug: https://bugs.openjdk.java.net/browse/JDK-8131025 Webrev: http://cr.openjdk.java.net/~jlahoda/8131025/webrev.00/ Basically, a workaround to an underlying complex issue. See: https://bugs.openjdk.java.net/browse/JDK-8024687 Thanks, Jan From robert.field at oracle.com Wed Sep 7 18:06:09 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 07 Sep 2016 11:06:09 -0700 Subject: RFR JDK-8131025: JShell: crash on tab-complete reference to bad class file In-Reply-To: <57D05205.9040503@oracle.com> References: <57D05205.9040503@oracle.com> Message-ID: <57D05711.40002@oracle.com> Thumbs up! -Robert On 09/07/16 10:44, Jan Lahoda wrote: > Hello, > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8131025 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8131025/webrev.00/ > > Basically, a workaround to an underlying complex issue. See: > https://bugs.openjdk.java.net/browse/JDK-8024687 > > Thanks, > Jan From jan.lahoda at oracle.com Wed Sep 7 18:12:21 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 7 Sep 2016 20:12:21 +0200 Subject: RFR (s) 8080352: jshell tool: Error message for using "package" should be more descriptive than "Failed" In-Reply-To: <57CE5DF9.3090005@oracle.com> References: <57CE5DF9.3090005@oracle.com> Message-ID: <57D05885.1000503@oracle.com> Seems OK to me. Jan On 6.9.2016 08:11, Robert Field wrote: > "package xyz;" is illegal in JShell but was not being processed > correctly because the JavacParser processing of package was left in. > Code deletion! > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8080352 > > Webrev: > http://cr.openjdk.java.net/~rfield/8080352v0.webrev/ > > Thanks, > Robert > From bitterfoxc at gmail.com Thu Sep 8 14:14:44 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Thu, 8 Sep 2016 23:14:44 +0900 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: <57D069C0.8030009@oracle.com> References: <57C8E61C.1040907@oracle.com> <57CD09FE.70908@oracle.com> <57CDE39A.3020100@oracle.com> <57D069C0.8030009@oracle.com> Message-ID: Hi Robert, Thank you for your pointing out. I've understood. Here is new webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.04.langtools/ In this version, - ExecutionControl#addExports throws BadArgumentException which is extends ExecutionControlException if module or package are not found. - JShell#addExports throws IllegalArgumentException when BadArgumentException is occured I've notice that /classpath and addToClasspath says nothing when it doesn't exist. I think it should be reported, so I've created a issue: https://bugs.openjdk.java.net/browse/JDK-8165650 What do you think? Please review me again! Thank you, shinyafox(Shinya Yoshida) 2016-09-08 4:25 GMT+09:00 Robert Field : > Thanks for the update. > > l10n.properties -- > > Oops, typo: the help.set.exports entry got pasted again instead of > help.retain.exports > > Sorry I was unclear about the exceptions... > > On the execution side -- > > ExecutionControl.InternalException is only for unexpected failures. > > In this case you are dealing an expected exception that occurs when the > user gives the wrong input. None of the existing ExecutionControlException > subclasses are good candidates, so a new ExecutionControlException subclass > is needed. I was suggesting "BadArgumentException" for this exception. > None of ExecutionControlException subclasses are seen at the JShell level > -- this should be the case for this new one as well. > > I don't what kind of exceptions are thrown by moduleAccess.addExportsToAllUnnamed(target, > pack), but that message text or some other appropriate descriptive message > text needs to be placed in the BadArgumentException message so it can be > seen all the way up (including the JShellTool). > > > On the JShell class -- > > Incorrect arguments on JShell API methods generate the Java standard > java.lang.IllegalArgumentException (see, for example, drop() or status() > ) -- so, this is also the appropriate exception for JShell.addExports(). > Thus, JShell.addExports() catchs the BadArgumentException, turning it into > an IllegalArgumentException. > > Thanks, > Robert > > > On 09/07/16 06:10, ShinyaYoshida wrote: > > Hi Robert, > Thank you for your helping. > > I've update webrev according to your comments. > If I'm missing your meaning, I'm sorry. Please point it. > http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.03.langtools/ > > Now, > - JShell#addExports will throw BadArgumentException when module or package > is wrong, which is check exception. > - JShellTool checks that exception. > - ExecutionControl#addExports throws InternalException when something is > wrong. > > Regards, > shinyafox(Shinya Yoshida) > > > 2016-09-06 6:28 GMT+09:00 Robert Field : > >> Code looks good. Needs docs I promised (see below). >> >> As to completion issue you created, I see you already added discussion >> and tests. I added your completion code. >> >> Below is my suggested doc... >> >> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties >> -- >> >> /set exports \n\t\ >> Allow access to some of the unexported types of a module\n\n\ >> >> >> /retain exports \n\t\ >> Allow access to some of the unexported types of a module\n\n\ >> >> >> help.set.exports=\ >> Set a package to add to those exported to snippets.\n\ >> \n\t\ >> /set exports \n\ >> \n\ >> Where is the module from which to export .\n\ >> Where is the package to export to snippets.\n >> >> >> help.retain.exports=\ >> Retain a package to add to those exported to snippets.\n\ >> \n\t\ >> /retain exports \n\ >> \n\ >> Where is the module from which to export .\n\ >> Where is the package to export to snippets.\n >> >> [I notice that 'snippet' is used in doc without being defined. If, while >> you are it, you change the help for /list to define it:] >> >> help.list =\ >> Show the source of snippets, prefaced with the snippet id (a snippet is a >> chunk of code that the jshell tool evaluates -- the code you enter at the >> prompt is a snippet).\n\ >> ... >> >> src/jdk.jshell/share/classes/jdk/jshell/JShell.java -- >> >> >> /** >> * Add a package to those exported to snippets. >> * @param module The module from which to export >> * @param pack The package to export >> * @throws NullPointerException if arguments are null. >> * @throws IllegalStateException if this {@code JShell} instance is >> closed. >> * @throws XYZ if .... >> */ >> >> OK, actually this code should change. Like addToClasspath above it, it >> should return void. It looks like under normal operation it can fail -- >> the failure should be reported with an exception. >> What are the failure modes? IllegalArgumentException would be likely >> choice at the JShell API layer. But then the exception needs to be >> propagated there. >> Since none of the existing exceptions is a match, this means a new >> ExecutionControlException. Maybe something general, like >> BadUserArgumentException. >> Note: I've also added IllegalStateException -- this can be thrown when >> you get EngineTerminationException. >> Also, typo, the second "module cannot be null" should be "package cannot >> be null" >> >> src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteCodes.java -- >> >> The comment you have is fine. Just remove PLEASE REVISE THE COMMENT >> >> src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl.java -- >> >> /** >> * Add a package to those exported to snippets. >> * @param module The module from which to export >> * @param pack The package to export >> * @throws EngineTerminationException the execution engine has >> terminated >> * @throws .... >> * @throws InternalException an internal problem occurred >> */ >> >> Plus add the bad argument exception. >> Whatever it is, should be added to extensionCommand() exceptions. >> >> Robert >> >> >> >> On 09/05/16 08:02, ShinyaYoshida wrote: >> >> Hi, >> I've update webrev of langtools: >> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.02.langtools/ >> >> I added an issue for the completion feature. >> https://bugs.openjdk.java.net/browse/JDK-8165445 >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2016-09-05 22:49 GMT+09:00 ShinyaYoshida : >> >>> Hi Robert, >>> Thank you for the review. >>> >>> I totally agree with you. >>> I also think that availableModules and availablePackages(module) are >>> worthless excepting for the command completion feature. >>> I'd like to avoid adding these APIs which have not been speculated and >>> revised because if API is once added, it is too difficult to remove than >>> adding. >>> >>> So currently, I'll remove the completion feature for /set or /retain >>> exports and make the issue to JBS to add completion feature for them in >>> future. >>> >>> I'll update the webrev. So please review it again later. >>> When the silently evaluation feature is added, I'd like to work for the >>> completion feature again. >>> >>> Thank you, >>> shinyafox(Shinya Yoshida) >>> >>> >>> 2016-09-05 15:00 GMT+09:00 Robert Field : >>> >>>> >>>> On 09/03/16 05:07, ShinyaYoshida wrote: >>>> >>>> Hi all, >>>> I've updated my patch, new webrev is here: >>>> webrev.01.langtools: http://cr.openjdk.java.net/~shinyafox/k >>>> ulla/8154714/webrev.01.langtools/ >>>> webrev.01.jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8 >>>> 154714/webrev.01.jdk/ (Same as previous) >>>> >>>> In this version, >>>> - rename /set add-exports to /set exports >>>> >>>> >>>> OK >>>> >>>> - add /retain exports >>>> >>>> >>>> The /retain implementation looks good. >>>> >>>> - add tests >>>> >>>> >>>> Well tested >>>> >>>> - move EXT_CMD_XXX into RemoteCodes >>>> - make RemoteCodes public and move it into jdk.jshell.execution.code >>>> which is module-private >>>> >>>> >>>> So, here, in addition to addExports, there are two more methods added >>>> to the API availableModules() and availablePackage(String module). >>>> I see how in rare cases they could be useful. And the rare case that >>>> causes them to be present is for command completion in the tool. >>>> What are the options: >>>> >>>> (1) Add them to the API. If it is in the API then it is a >>>> first-class form of functionality and should be treated as such in >>>> execution support (as a command) >>>> (2) Not support them and not support command completion for /set >>>> exports. Command completion is not supported in much more common cases. >>>> Then we could support command completion in the future (see (3)). >>>> (3) What these commands do is simply execute an expression on the >>>> remote side. But we already have a mechanism to execute expressions on the >>>> remote side: Snippets. >>>> That leaves a problem: we wouldn't want these Snippets to be >>>> seen by the user, but we have a solution for that the tool uses the >>>> idGenerator. >>>> Another problem is that, by default and with no current way >>>> around the default, expressions generate temp-variables. My intention was >>>> to make this configurable -- see Eval.shouldGenTempVar(...). >>>> >>>> One goal I've been using in the design of the API is to keep it as >>>> small and simple as possible. This improves maintainability, but much more >>>> importantly makes the API easier to learn and use. >>>> So, for something to warrant inclusion it should be generally useful >>>> and have no other way of being achieved -- neither is true of these two >>>> queries. >>>> >>>> My suggestion, particularly in light of how late in the release this >>>> is, would be (2). Thoughts? >>>> >>>> -Robert >>>> >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> shinyafox(Shinya Yoshida) >>>> >>>> 2016-09-03 18:15 GMT+09:00 ShinyaYoshida : >>>> >>>>> Hi Robert, >>>>> Thank you for reviewing. >>>>> I'll update my patch later. >>>>> >>>>> 2016-09-02 11:38 GMT+09:00 Robert Field : >>>>> >>>>>> Thanks shiyafox! This is a significant piece of code! >>>>>> >>>>>> As to your questions -- >>>>>> >>>>>> > I wonder if you could work on the documentation of the API and the >>>>>> tool instead? >>>>>> >>>>>> Yes, I will do API and tool docs. >>>>> >>>>> Thank you! >>>>> >>>>> > Subcommand of /set is reasonable? Similar command, /classpath, to >>>>>> make users available to use new packages is not a subcommand of /set. >>>>>> >>>>>> Yes, I think /set exports is best. And, yes, /classpath is >>>>>> inconsistent, it should be /set classpath, that can be a separate task, >>>>>> unless you want to roll that in. >>>>> >>>>> I see, I've created the issue to move /classpath to /set classpath: >>>>> https://bugs.openjdk.java.net/browse/JDK-8165405 >>>>> >>>>> >>>>>> > Should we need retain feature to this? >>>>>> >>>>>> All /set have a /retain counterpart -- we should maintain that >>>>>> >>>>> Ok, I'll add /retain exports. >>>>> I've also create the issue for retaining classpath: >>>>> https://bugs.openjdk.java.net/browse/JDK-8165406 >>>>> >>>>> >>>>>> As to the code review: Looks good to me, just minor questions/issues >>>>>> -- >>>>>> >>>>>> JShellTool.java: >>>>>> >>>>>> * As discussed /set add-exports => /set exports >>>>>> >>>>>> * Nit: a comment got moved out of place line 1194(old) >>>>>> >>>>>> JShell.java: >>>>>> >>>>>> * EXT_CMD_AVAILABLE_MODULES and EXT_CMD_AVAILABLE_PACKAGES, these >>>>>> should be referenced via RemoteCodes.java rather than be coped. >>>>>> >>>>> Absolutely! I'd like to move these into RemoteCodes but it is >>>>> package-private class and cannot be referred from JShell. >>>>> Can I make RemoteCodes public and move it to another module-private >>>>> package like jdk.jshell.execution.code? >>>>> >>>>> >>>>>> * Which leads me to another question: why is addExports a command and >>>>>> these two are extensions. It seems fine, just curious. I notice that >>>>>> extensions are a lot less code -- ;-) >>>>> >>>>> Exporting module and package is similar to adding classpath to >>>>> platform, so I made the addExports a command like setClasspath. >>>>> And it should be added as API because it is very basic feature. >>>>> >>>>> >>>>>> TaskFactory.java: >>>>>> >>>>>> * Question: the "/" separator between module and package is that >>>>>> platform independent? >>>>>> >>>>> It seems to me that "{module}/{path}" format for --add-exports option >>>>> of javac is platform independent. >>>>> >>>>> Regards, >>>>> shinyafox(Shinya Yoshida) >>>>> >>>>> >>>>>> DefaultLoaderDelegate.java: >>>>>> >>>>>> * Jan, can you look at this code? >>>>>> >>>>>> >>>>>> -Robert >>>>>> >>>>>> >>>>>> On 09/01/16 05:36, ShinyaYoshida wrote: >>>>>> >>>>>>> Hi all, >>>>>>> I've implemented this feature to JShell API and Tool with full >>>>>>> completion: >>>>>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8154714 >>>>>>> >>>>>>> jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>> 0.jdk/ >>>>>> v.00.jdk/> >>>>>>> langtools: http://cr.openjdk.java.net/~sh >>>>>>> inyafox/kulla/8154714/webrev.00.langtools/ < >>>>>>> http://cr.openjdk.java.net/%7Eshinyafox/kulla/8154714/webre >>>>>>> v.00.langtools/> >>>>>>> >>>>>>> This is missing the train of Java 9.0 but it could catch the train >>>>>>> of Java 9.1 or later. >>>>>>> I want to get your comments for this. >>>>>>> >>>>>>> jshell> /set add-exports jdk.jconsole sun.tools.jconsole >>>>>>> >>>>>>> jshell> import sun.tools.jconsole.* >>>>>>> >>>>>>> jshell> LocalVirtualMachine.getAllVirtualMachines().forEach((k, v) >>>>>>> -> System.out.println(k + ":" + v)) >>>>>>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>>>>>> 10826:jdk.jshell.execution.RemoteExecutionControl 35548 >>>>>>> 28447:org.netbeans.Main --cachedir /home/bitter_fox/.cache/netbeans/8.0.1 >>>>>>> --userdir /home/bitter_fox/.netbeans/8.0.1 --branding nb >>>>>>> >>>>>>> Currently, there is no testing, so it will be required to add test. >>>>>>> >>>>>>> Regards, >>>>>>> shinyafox(Shinya Yoshida) >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > > From robert.field at oracle.com Fri Sep 9 19:51:41 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 09 Sep 2016 12:51:41 -0700 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: <57D3035B.706@oracle.com> References: <57C8E61C.1040907@oracle.com> <57CD09FE.70908@oracle.com> <57CDE39A.3020100@oracle.com> <57D069C0.8030009@oracle.com> <57D3035B.706@oracle.com> Message-ID: <57D312CD.1070406@oracle.com> FYI: JShell javadoc with this change: http://cr.openjdk.java.net/~rfield/8154714v4.jshellAPI/ Generated specification difference: http://cr.openjdk.java.net/~rfield/8154714v4.specdiff/overview-summary.html -Robert From bitterfoxc at gmail.com Sun Sep 11 00:35:38 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Sun, 11 Sep 2016 09:35:38 +0900 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: <57D3035B.706@oracle.com> References: <57C8E61C.1040907@oracle.com> <57CD09FE.70908@oracle.com> <57CDE39A.3020100@oracle.com> <57D069C0.8030009@oracle.com> <57D3035B.706@oracle.com> Message-ID: Hi Robert, Thank you. I'll reply inline 2016-09-10 3:45 GMT+09:00 Robert Field : > Jan, I've been involved enough that I'd like you to take an independent > look. > > Looks great! I've provided a comment below and a suggestion on exception > parameters -- you can change these without another review from me. > I've asked Jan to take a look and because it is an API change, I'll send > it to Joe to take a look now. I'll let you know when I get a thumbs up > from him, then you can push. > > As for addToClasspath, a classpath (as specified with the CLASSPATH > environment variable or -classpath option) for the java or javac commands > can have non-existent paths on it without error -- seems we should be > consistent with that. I could see the tool warning about non-existent > paths. Seems though that it should throw IllegalStateException if the > JShell instance is closed. > I see. I've update the issue to produce warning by /classpath command. > > JShell.java -- > > 485,488: I don't think we want to expose the internal exception, all it > would usually show would be the forwarding mechanism. But we do want the > message. So, I'd pass ex.getMessage() instead -- see line 663 for an > example. > > Comment for ExecutionControl.BadArgumentException: > > /** > * An exception indicating that an invalid argument was provided. > */ > > I've updated my previous webrev! I've changed StreamingExecutionControl#addToClasspath, #setClasspath to convert BadArgumentException to InternalException and changed comments. Regards, shinyafox(Shinya Yoshida) > > -Robert > > > > On 09/08/16 07:14, ShinyaYoshida wrote: > > Hi Robert, > Thank you for your pointing out. > I've understood. > > Here is new webrev: > http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.04.langtools/ > > In this version, > - ExecutionControl#addExports throws BadArgumentException which is extends > ExecutionControlException if module or package are not found. > - JShell#addExports throws IllegalArgumentException when > BadArgumentException is occured > > I've notice that /classpath and addToClasspath says nothing when it > doesn't exist. > I think it should be reported, so I've created a issue: > https://bugs.openjdk.java.net/browse/JDK-8165650 > > What do you think? > > Please review me again! > > Thank you, > shinyafox(Shinya Yoshida) > > > 2016-09-08 4:25 GMT+09:00 Robert Field : > >> Thanks for the update. >> >> l10n.properties -- >> >> Oops, typo: the help.set.exports entry got pasted again instead of >> help.retain.exports >> >> Sorry I was unclear about the exceptions... >> >> On the execution side -- >> >> ExecutionControl.InternalException is only for unexpected failures. >> >> In this case you are dealing an expected exception that occurs when the >> user gives the wrong input. None of the existing ExecutionControlException >> subclasses are good candidates, so a new ExecutionControlException subclass >> is needed. I was suggesting "BadArgumentException" for this exception. >> None of ExecutionControlException subclasses are seen at the JShell level >> -- this should be the case for this new one as well. >> >> I don't what kind of exceptions are thrown by >> moduleAccess.addExportsToAllUnnamed(target, pack), but that message text >> or some other appropriate descriptive message text needs to be placed in >> the BadArgumentException message so it can be seen all the way up >> (including the JShellTool). >> >> >> On the JShell class -- >> >> Incorrect arguments on JShell API methods generate the Java standard >> java.lang.IllegalArgumentException (see, for example, drop() or status() >> ) -- so, this is also the appropriate exception for JShell.addExports(). >> Thus, JShell.addExports() catchs the BadArgumentException, turning it into >> an IllegalArgumentException. >> >> Thanks, >> Robert >> >> >> On 09/07/16 06:10, ShinyaYoshida wrote: >> >> Hi Robert, >> Thank you for your helping. >> >> I've update webrev according to your comments. >> If I'm missing your meaning, I'm sorry. Please point it. >> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.03.langtools/ >> >> Now, >> - JShell#addExports will throw BadArgumentException when module or >> package is wrong, which is check exception. >> - JShellTool checks that exception. >> - ExecutionControl#addExports throws InternalException when something is >> wrong. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >> 2016-09-06 6:28 GMT+09:00 Robert Field : >> >>> Code looks good. Needs docs I promised (see below). >>> >>> As to completion issue you created, I see you already added discussion >>> and tests. I added your completion code. >>> >>> Below is my suggested doc... >>> >>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties >>> -- >>> >>> /set exports \n\t\ >>> Allow access to some of the unexported types of a module\n\n\ >>> >>> >>> /retain exports \n\t\ >>> Allow access to some of the unexported types of a module\n\n\ >>> >>> >>> help.set.exports=\ >>> Set a package to add to those exported to snippets.\n\ >>> \n\t\ >>> /set exports \n\ >>> \n\ >>> Where is the module from which to export .\n\ >>> Where is the package to export to snippets.\n >>> >>> >>> help.retain.exports=\ >>> Retain a package to add to those exported to snippets.\n\ >>> \n\t\ >>> /retain exports \n\ >>> \n\ >>> Where is the module from which to export .\n\ >>> Where is the package to export to snippets.\n >>> >>> [I notice that 'snippet' is used in doc without being defined. If, while >>> you are it, you change the help for /list to define it:] >>> >>> help.list =\ >>> Show the source of snippets, prefaced with the snippet id (a snippet is >>> a chunk of code that the jshell tool evaluates -- the code you enter at the >>> prompt is a snippet).\n\ >>> ... >>> >>> src/jdk.jshell/share/classes/jdk/jshell/JShell.java -- >>> >>> >>> /** >>> * Add a package to those exported to snippets. >>> * @param module The module from which to export >>> * @param pack The package to export >>> * @throws NullPointerException if arguments are null. >>> * @throws IllegalStateException if this {@code JShell} instance is >>> closed. >>> * @throws XYZ if .... >>> */ >>> >>> OK, actually this code should change. Like addToClasspath above it, it >>> should return void. It looks like under normal operation it can fail -- >>> the failure should be reported with an exception. >>> What are the failure modes? IllegalArgumentException would be likely >>> choice at the JShell API layer. But then the exception needs to be >>> propagated there. >>> Since none of the existing exceptions is a match, this means a new >>> ExecutionControlException. Maybe something general, like >>> BadUserArgumentException. >>> Note: I've also added IllegalStateException -- this can be thrown when >>> you get EngineTerminationException. >>> Also, typo, the second "module cannot be null" should be "package cannot >>> be null" >>> >>> src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteCodes.java -- >>> >>> The comment you have is fine. Just remove PLEASE REVISE THE COMMENT >>> >>> src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl.java -- >>> >>> /** >>> * Add a package to those exported to snippets. >>> * @param module The module from which to export >>> * @param pack The package to export >>> * @throws EngineTerminationException the execution engine has >>> terminated >>> * @throws .... >>> * @throws InternalException an internal problem occurred >>> */ >>> >>> Plus add the bad argument exception. >>> Whatever it is, should be added to extensionCommand() exceptions. >>> >>> Robert >>> >>> >>> >>> On 09/05/16 08:02, ShinyaYoshida wrote: >>> >>> Hi, >>> I've update webrev of langtools: >>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.02.langtools/ >>> >>> I added an issue for the completion feature. >>> https://bugs.openjdk.java.net/browse/JDK-8165445 >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> 2016-09-05 22:49 GMT+09:00 ShinyaYoshida : >>> >>>> Hi Robert, >>>> Thank you for the review. >>>> >>>> I totally agree with you. >>>> I also think that availableModules and availablePackages(module) are >>>> worthless excepting for the command completion feature. >>>> I'd like to avoid adding these APIs which have not been speculated and >>>> revised because if API is once added, it is too difficult to remove than >>>> adding. >>>> >>>> So currently, I'll remove the completion feature for /set or /retain >>>> exports and make the issue to JBS to add completion feature for them in >>>> future. >>>> >>>> I'll update the webrev. So please review it again later. >>>> When the silently evaluation feature is added, I'd like to work for the >>>> completion feature again. >>>> >>>> Thank you, >>>> shinyafox(Shinya Yoshida) >>>> >>>> >>>> 2016-09-05 15:00 GMT+09:00 Robert Field : >>>> >>>>> >>>>> On 09/03/16 05:07, ShinyaYoshida wrote: >>>>> >>>>> Hi all, >>>>> I've updated my patch, new webrev is here: >>>>> webrev.01.langtools: http://cr.openjdk.java.net/~shinyafox/k >>>>> ulla/8154714/webrev.01.langtools/ >>>>> webrev.01.jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8 >>>>> 154714/webrev.01.jdk/ (Same as previous) >>>>> >>>>> In this version, >>>>> - rename /set add-exports to /set exports >>>>> >>>>> >>>>> OK >>>>> >>>>> - add /retain exports >>>>> >>>>> >>>>> The /retain implementation looks good. >>>>> >>>>> - add tests >>>>> >>>>> >>>>> Well tested >>>>> >>>>> - move EXT_CMD_XXX into RemoteCodes >>>>> - make RemoteCodes public and move it into jdk.jshell.execution.code >>>>> which is module-private >>>>> >>>>> >>>>> So, here, in addition to addExports, there are two more methods added >>>>> to the API availableModules() and availablePackage(String module). >>>>> I see how in rare cases they could be useful. And the rare case that >>>>> causes them to be present is for command completion in the tool. >>>>> What are the options: >>>>> >>>>> (1) Add them to the API. If it is in the API then it is a >>>>> first-class form of functionality and should be treated as such in >>>>> execution support (as a command) >>>>> (2) Not support them and not support command completion for /set >>>>> exports. Command completion is not supported in much more common cases. >>>>> Then we could support command completion in the future (see (3)). >>>>> (3) What these commands do is simply execute an expression on the >>>>> remote side. But we already have a mechanism to execute expressions on the >>>>> remote side: Snippets. >>>>> That leaves a problem: we wouldn't want these Snippets to be >>>>> seen by the user, but we have a solution for that the tool uses the >>>>> idGenerator. >>>>> Another problem is that, by default and with no current way >>>>> around the default, expressions generate temp-variables. My intention was >>>>> to make this configurable -- see Eval.shouldGenTempVar(...). >>>>> >>>>> One goal I've been using in the design of the API is to keep it as >>>>> small and simple as possible. This improves maintainability, but much more >>>>> importantly makes the API easier to learn and use. >>>>> So, for something to warrant inclusion it should be generally useful >>>>> and have no other way of being achieved -- neither is true of these two >>>>> queries. >>>>> >>>>> My suggestion, particularly in light of how late in the release this >>>>> is, would be (2). Thoughts? >>>>> >>>>> -Robert >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> shinyafox(Shinya Yoshida) >>>>> >>>>> 2016-09-03 18:15 GMT+09:00 ShinyaYoshida : >>>>> >>>>>> Hi Robert, >>>>>> Thank you for reviewing. >>>>>> I'll update my patch later. >>>>>> >>>>>> 2016-09-02 11:38 GMT+09:00 Robert Field : >>>>>> >>>>>>> Thanks shiyafox! This is a significant piece of code! >>>>>>> >>>>>>> As to your questions -- >>>>>>> >>>>>>> > I wonder if you could work on the documentation of the API and >>>>>>> the tool instead? >>>>>>> >>>>>>> Yes, I will do API and tool docs. >>>>>> >>>>>> Thank you! >>>>>> >>>>>> > Subcommand of /set is reasonable? Similar command, /classpath, to >>>>>>> make users available to use new packages is not a subcommand of /set. >>>>>>> >>>>>>> Yes, I think /set exports is best. And, yes, /classpath is >>>>>>> inconsistent, it should be /set classpath, that can be a separate task, >>>>>>> unless you want to roll that in. >>>>>> >>>>>> I see, I've created the issue to move /classpath to /set classpath: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8165405 >>>>>> >>>>>> >>>>>>> > Should we need retain feature to this? >>>>>>> >>>>>>> All /set have a /retain counterpart -- we should maintain that >>>>>>> >>>>>> Ok, I'll add /retain exports. >>>>>> I've also create the issue for retaining classpath: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8165406 >>>>>> >>>>>> >>>>>>> As to the code review: Looks good to me, just minor questions/issues >>>>>>> -- >>>>>>> >>>>>>> JShellTool.java: >>>>>>> >>>>>>> * As discussed /set add-exports => /set exports >>>>>>> >>>>>>> * Nit: a comment got moved out of place line 1194(old) >>>>>>> >>>>>>> JShell.java: >>>>>>> >>>>>>> * EXT_CMD_AVAILABLE_MODULES and EXT_CMD_AVAILABLE_PACKAGES, these >>>>>>> should be referenced via RemoteCodes.java rather than be coped. >>>>>>> >>>>>> Absolutely! I'd like to move these into RemoteCodes but it is >>>>>> package-private class and cannot be referred from JShell. >>>>>> Can I make RemoteCodes public and move it to another module-private >>>>>> package like jdk.jshell.execution.code? >>>>>> >>>>>> >>>>>>> * Which leads me to another question: why is addExports a command >>>>>>> and these two are extensions. It seems fine, just curious. I notice that >>>>>>> extensions are a lot less code -- ;-) >>>>>> >>>>>> Exporting module and package is similar to adding classpath to >>>>>> platform, so I made the addExports a command like setClasspath. >>>>>> And it should be added as API because it is very basic feature. >>>>>> >>>>>> >>>>>>> TaskFactory.java: >>>>>>> >>>>>>> * Question: the "/" separator between module and package is that >>>>>>> platform independent? >>>>>>> >>>>>> It seems to me that "{module}/{path}" format for --add-exports option >>>>>> of javac is platform independent. >>>>>> >>>>>> Regards, >>>>>> shinyafox(Shinya Yoshida) >>>>>> >>>>>> >>>>>>> DefaultLoaderDelegate.java: >>>>>>> >>>>>>> * Jan, can you look at this code? >>>>>>> >>>>>>> >>>>>>> -Robert >>>>>>> >>>>>>> >>>>>>> On 09/01/16 05:36, ShinyaYoshida wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> I've implemented this feature to JShell API and Tool with full >>>>>>>> completion: >>>>>>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8154714 >>>>>>>> >>>>>>>> jdk: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>> 0.jdk/ >>>>>>> v.00.jdk/> >>>>>>>> langtools: http://cr.openjdk.java.net/~sh >>>>>>>> inyafox/kulla/8154714/webrev.00.langtools/ < >>>>>>>> http://cr.openjdk.java.net/%7Eshinyafox/kulla/8154714/webre >>>>>>>> v.00.langtools/> >>>>>>>> >>>>>>>> This is missing the train of Java 9.0 but it could catch the train >>>>>>>> of Java 9.1 or later. >>>>>>>> I want to get your comments for this. >>>>>>>> >>>>>>>> jshell> /set add-exports jdk.jconsole sun.tools.jconsole >>>>>>>> >>>>>>>> jshell> import sun.tools.jconsole.* >>>>>>>> >>>>>>>> jshell> LocalVirtualMachine.getAllVirtualMachines().forEach((k, v) >>>>>>>> -> System.out.println(k + ":" + v)) >>>>>>>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>>>>>>> 10826:jdk.jshell.execution.RemoteExecutionControl 35548 >>>>>>>> 28447:org.netbeans.Main --cachedir /home/bitter_fox/.cache/netbeans/8.0.1 >>>>>>>> --userdir /home/bitter_fox/.netbeans/8.0.1 --branding nb >>>>>>>> >>>>>>>> Currently, there is no testing, so it will be required to add test. >>>>>>>> >>>>>>>> Regards, >>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > From bitterfoxc at gmail.com Tue Sep 13 00:55:37 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Tue, 13 Sep 2016 09:55:37 +0900 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: <57D74A77.5000905@oracle.com> References: <57C8E61C.1040907@oracle.com> <57CD09FE.70908@oracle.com> <57CDE39A.3020100@oracle.com> <57D069C0.8030009@oracle.com> <57D33CE9.9060305@oracle.com> <57D5BBEC.8060506@oracle.com> <57D6CA3F.4050309@oracle.com> <57D6DE8F.4070405@oracle.com> <57D6EEB1.4050506@oracle.com> <57D7189F.2070901@oracle.com> <57D71A2C.9030501@oracle.com> <57D74A77.5000905@oracle.com> Message-ID: Hi Jan and all, I've confirmed your snippet. Certainly it have a security problem and it should be avoided. I'll update my patch to add a new command-line option -C which give the option to compiler. In addition to, I'd like to add a new command-line option --add-exports / which is a short-circuit for "-J--add-exports /=ALL-UNNAMED -C--add-exports /=ALL-UNNAMED." java and javac are also have --add-exports option, so it seems to me that it is reasonable for jshell to have --add-exports option. What do you think about this? Kind Regards, shinyafox(Shinya Yoshida) 2016-09-13 9:38 GMT+09:00 Robert Field : > If our approach to security is "do nothing a user could not do with their > own use of javac/java" (which we have yet to have validated) then if the > SharedSecrets use in JShell requires the change to the module.info.java in > java.base to add jdk.jshell, then that would be a violation. > > If this changeset gave access only to snippets executing via the JShell > API maybe that would be OK. But it, as your exploit verifies, could easily > be used by anyone to change module boundaries. > > Maybe there would be a hack that would allow only proper JShell use, but I > don't see what that would be, and that sounds dangerous and unappealing. > > Command-line option only would match the original request and other > tools. The implementation would closely match the implementation of '-R', > being on the command-line of JShellTool and the API in JShell.Builder. > Alas, this is mostly a rewrite, only some code in TaskFactory, > ToolBasicTest, and maybe KullaTesting would be reusable. > > Bummer! > > But thanks for catching this Jan! > > -Robert > > > > On 09/12/16 14:12, Jan Lahoda wrote: > >> (Basically, the use of SharedSecrets in jdk.jshell seems highly >> suspicious to me.) >> >> Jan >> >> On 12.9.2016 23:05, Jan Lahoda wrote: >> >>> On 12.9.2016 20:06, Robert Field wrote: >>> >>>> The jshell tool is built on the JShell API. Command-line options, like >>>> -R, pass to the remote process via the JShell API. -R would allow >>>> --patch-module or --add-exports. Having addExports functionality >>>> >>> >>> I am not much worried about --add-exports added using -R, that seems OK >>> to me. This only affects a newly spawned JVM, and the API client could >>> spawn it even without JShell, so not a problem IMO. >>> >>> What I am worried about is that using the most recent proposed patch >>> (lwebrev.04.langtools), one can use the DirectExecutionControl to change >>> module boundaries in the _currently running VM_. Please see the attached >>> class to see what I mean - I didn't even have to create JShell as such, >>> simply using DirectExecutionControl was enough. It probably does not >>> even need some special privileges to achieve the result. >>> >>> Jan >>> >>> anywhere is jshell means having it in the JShell API. >>>> >>>> I believe this cycles us, to some degree, back to the security >>>> discussion. What is our level of concern about a launched process >>>> running pure JDK code? >>>> >>>> -Robert >>>> >>>> On 09/12/16 09:57, Jan Lahoda wrote: >>>> >>>>> [adding Jon] >>>>> >>>>> On 12.9.2016 17:31, Robert Field wrote: >>>>> >>>>>> Both javac and java have a --add-exports option, so it isn't opening >>>>>> anything that isn't already open. >>>>>> I don't see how command-line options are any different that API in >>>>>> terms >>>>>> of exposure. >>>>>> >>>>> >>>>> I think there's a huge difference between command line and an API, in >>>>> at least two aspects: >>>>> a) the person that controls the command line, has a lot of power in >>>>> any case (they could do -Xbootclasspath/p: in 8 or --patch-module now >>>>> to get around the boundaries). API users are much more restricted in >>>>> what they can do. >>>>> b) affecting the command line options is generally very hard - imagine >>>>> library maintainers - how can they affect the command line setting? >>>>> The only thing they can do is to write some documentation, but they >>>>> cannot directly affect the command line. But they can call an API (and >>>>> they can call it even reflectively). >>>>> >>>>> I believe it is generally undesirable to create APIs that allow to >>>>> create holes in module boundaries. If you think that's something >>>>> JShell needs, I think we need to take that to the Jigsaw team. >>>>> >>>>> Jan >>>>> >>>>> >>>>>> -Robert >>>>>> >>>>>> >>>>>> On 09/11/16 13:17, Jan Lahoda wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I apologize for not following this sooner. >>>>>>> >>>>>>> Looking at this, it seems to me the change would effectively allow to >>>>>>> overcome the module boundary limitations using JShell - I don't think >>>>>>> that's something that would be acceptable. We could take this to the >>>>>>> Jigsaw team, but I don't think they would be happy about this. >>>>>>> >>>>>>> I wonder what exactly is the usecase here. Would it be sufficient if >>>>>>> the jshell tool as such would allow command line options to break >>>>>>> through the boundaries? We already have -R, which should allow to >>>>>>> make >>>>>>> holes to the boundaries when running the snippets, so maybe we just >>>>>>> need to add something for compile-time? >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>> On 11.9.2016 02:12, ShinyaYoshida wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> Please apply this webrev: >>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.jdk/ >>>>>>>> >>>>>>>> >>>>>>>> Changing module-info is needed. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>> >>>>>>>> 2016-09-10 7:51 GMT+09:00 Robert Field >>>>>>> >: >>>>>>>> >>>>>>>> [audience reduced] >>>>>>>> >>>>>>>> BTW shinyafox, >>>>>>>> >>>>>>>> Building "make images" with this patch and the latest jdk9/dev >>>>>>>> bits >>>>>>>> fails. Probably need to change module set-up -- >>>>>>>> >>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/ >>>>>>>> execution/DirectExecutionControl.java:33: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> error: package jdk.internal.misc does not exist >>>>>>>> import jdk.internal.misc.JavaLangReflectModuleAccess; >>>>>>>> ^ >>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/ >>>>>>>> execution/DirectExecutionControl.java:34: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> error: package jdk.internal.misc does not exist >>>>>>>> import jdk.internal.misc.SharedSecrets; >>>>>>>> ^ >>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/ >>>>>>>> execution/DirectExecutionControl.java:155: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> error: cannot find symbol >>>>>>>> JavaLangReflectModuleAccess moduleAccess = >>>>>>>> SharedSecrets.getJavaLangReflectModuleAccess(); >>>>>>>> ^ >>>>>>>> symbol: class JavaLangReflectModuleAccess >>>>>>>> location: class DirectExecutionControl >>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/ >>>>>>>> execution/DirectExecutionControl.java:155: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> error: cannot find symbol >>>>>>>> JavaLangReflectModuleAccess moduleAccess = >>>>>>>> SharedSecrets.getJavaLangReflectModuleAccess(); >>>>>>>> ^ >>>>>>>> symbol: variable SharedSecrets >>>>>>>> location: class DirectExecutionControl >>>>>>>> 4 errors >>>>>>>> >>>>>>>> -Robert >>>>>>>> >>>>>>>> >>>>>>>> On 09/08/16 07:14, ShinyaYoshida wrote: >>>>>>>> >>>>>>>>> Hi Robert, >>>>>>>>> Thank you for your pointing out. >>>>>>>>> I've understood. >>>>>>>>> >>>>>>>>> Here is new webrev: >>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev. >>>>>>>>> 04.langtools/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> v.04.langtools/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> In this version, >>>>>>>>> - ExecutionControl#addExports throws BadArgumentException >>>>>>>>> which is >>>>>>>>> extends ExecutionControlException if module or package are not >>>>>>>>> found. >>>>>>>>> - JShell#addExports throws IllegalArgumentException when >>>>>>>>> BadArgumentException is occured >>>>>>>>> >>>>>>>>> I've notice that /classpath and addToClasspath says nothing >>>>>>>>> when >>>>>>>>> it doesn't exist. >>>>>>>>> I think it should be reported, so I've created a issue: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165650 >>>>>>>>> >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Please review me again! >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>> >>>>>>>>> >>>>>>>>> 2016-09-08 4:25 GMT+09:00 Robert Field < >>>>>>>>> robert.field at oracle.com >>>>>>>>> >: >>>>>>>>> >>>>>>>>> Thanks for the update. >>>>>>>>> >>>>>>>>> l10n.properties -- >>>>>>>>> >>>>>>>>> Oops, typo: the help.set.exports entry got pasted again >>>>>>>>> instead of help.retain.exports >>>>>>>>> >>>>>>>>> Sorry I was unclear about the exceptions... >>>>>>>>> >>>>>>>>> On the execution side -- >>>>>>>>> >>>>>>>>> ExecutionControl.InternalException is only for unexpected >>>>>>>>> failures. >>>>>>>>> >>>>>>>>> In this case you are dealing an expected exception that >>>>>>>>> occurs >>>>>>>>> when the user gives the wrong input. None of the existing >>>>>>>>> ExecutionControlException subclasses are good candidates, >>>>>>>>> so a >>>>>>>>> new ExecutionControlException subclass is needed. I was >>>>>>>>> suggesting "BadArgumentException" for this exception. >>>>>>>>> None of >>>>>>>>> ExecutionControlException subclasses are seen at the JShell >>>>>>>>> level -- this should be the case for this new one as well. >>>>>>>>> >>>>>>>>> I don't what kind of exceptions are thrown by >>>>>>>>> moduleAccess.addExportsToAllUnnamed(target, pack), but >>>>>>>>> that >>>>>>>>> message text or some other appropriate descriptive message >>>>>>>>> text needs to be placed in the BadArgumentException >>>>>>>>> message so >>>>>>>>> it can be seen all the way up (including the JShellTool). >>>>>>>>> >>>>>>>>> >>>>>>>>> On the JShell class -- >>>>>>>>> >>>>>>>>> Incorrect arguments on JShell API methods generate the Java >>>>>>>>> standard java.lang.IllegalArgumentException (see, for >>>>>>>>> example, >>>>>>>>> drop() or status() ) -- so, this is also the appropriate >>>>>>>>> exception for JShell.addExports(). Thus, >>>>>>>>> JShell.addExports() >>>>>>>>> catchs the BadArgumentException, turning it into an >>>>>>>>> IllegalArgumentException. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Robert >>>>>>>>> >>>>>>>>> >>>>>>>>> On 09/07/16 06:10, ShinyaYoshida wrote: >>>>>>>>> >>>>>>>>>> Hi Robert, >>>>>>>>>> Thank you for your helping. >>>>>>>>>> >>>>>>>>>> I've update webrev according to your comments. >>>>>>>>>> If I'm missing your meaning, I'm sorry. Please point it. >>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev. >>>>>>>>>> 03.langtools/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> v.03.langtools/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Now, >>>>>>>>>> - JShell#addExports will throw BadArgumentException when >>>>>>>>>> module or package is wrong, which is check exception. >>>>>>>>>> - JShellTool checks that exception. >>>>>>>>>> - ExecutionControl#addExports throws InternalException >>>>>>>>>> when >>>>>>>>>> something is wrong. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-09-06 6:28 GMT+09:00 Robert Field >>>>>>>>>> >>>>>>>>> >>: >>>>>>>>>> >>>>>>>>>> Code looks good. Needs docs I promised (see below). >>>>>>>>>> >>>>>>>>>> As to completion issue you created, I see you already >>>>>>>>>> added discussion and tests. I added your completion >>>>>>>>>> code. >>>>>>>>>> >>>>>>>>>> Below is my suggested doc... >>>>>>>>>> >>>>>>>>>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> /set exports \n\t\ >>>>>>>>>> Allow access to some of the unexported types of a >>>>>>>>>> module\n\n\ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /retain exports \n\t\ >>>>>>>>>> Allow access to some of the unexported types of a >>>>>>>>>> module\n\n\ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> help.set.exports=\ >>>>>>>>>> Set a package to add to those exported to snippets.\n\ >>>>>>>>>> \n\t\ >>>>>>>>>> /set exports \n\ >>>>>>>>>> \n\ >>>>>>>>>> Where is the module from which to export >>>>>>>>>> .\n\ >>>>>>>>>> Where is the package to export to >>>>>>>>>> snippets.\n >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> help.retain.exports=\ >>>>>>>>>> Retain a package to add to those exported to >>>>>>>>>> snippets.\n\ >>>>>>>>>> \n\t\ >>>>>>>>>> /retain exports \n\ >>>>>>>>>> \n\ >>>>>>>>>> Where is the module from which to export >>>>>>>>>> .\n\ >>>>>>>>>> Where is the package to export to >>>>>>>>>> snippets.\n >>>>>>>>>> >>>>>>>>>> [I notice that 'snippet' is used in doc without being >>>>>>>>>> defined. If, while you are it, you change the help for >>>>>>>>>> /list to define it:] >>>>>>>>>> >>>>>>>>>> help.list =\ >>>>>>>>>> Show the source of snippets, prefaced with the >>>>>>>>>> snippet id >>>>>>>>>> (a snippet is a chunk of code that the jshell tool >>>>>>>>>> evaluates -- the code you enter at the prompt is a >>>>>>>>>> snippet).\n\ >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/JShell.java -- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /** >>>>>>>>>> * Add a package to those exported to snippets. >>>>>>>>>> * @param module The module from which to export >>>>>>>>>> * @param pack The package to export >>>>>>>>>> * @throws NullPointerException if arguments are >>>>>>>>>> null. >>>>>>>>>> * @throws IllegalStateException if this {@code >>>>>>>>>> JShell} instance is closed. >>>>>>>>>> * @throws XYZ if .... >>>>>>>>>> */ >>>>>>>>>> >>>>>>>>>> OK, actually this code should change. Like >>>>>>>>>> addToClasspath above it, it should return void. It >>>>>>>>>> looks >>>>>>>>>> like under normal operation it can fail -- the failure >>>>>>>>>> should be reported with an exception. >>>>>>>>>> What are the failure modes? IllegalArgumentException >>>>>>>>>> would be likely choice at the JShell API layer. But >>>>>>>>>> then >>>>>>>>>> the exception needs to be propagated there. >>>>>>>>>> Since none of the existing exceptions is a match, this >>>>>>>>>> means a new ExecutionControlException. Maybe something >>>>>>>>>> general, like BadUserArgumentException. >>>>>>>>>> Note: I've also added IllegalStateException -- this >>>>>>>>>> can >>>>>>>>>> be thrown when you get EngineTerminationException. >>>>>>>>>> Also, typo, the second "module cannot be null" >>>>>>>>>> should be >>>>>>>>>> "package cannot be null" >>>>>>>>>> >>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteCodes.java >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> The comment you have is fine. Just remove PLEASE >>>>>>>>>> REVISE >>>>>>>>>> THE COMMENT >>>>>>>>>> >>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl.java >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> /** >>>>>>>>>> * Add a package to those exported to snippets. >>>>>>>>>> * @param module The module from which to export >>>>>>>>>> * @param pack The package to export >>>>>>>>>> * @throws EngineTerminationException the >>>>>>>>>> execution >>>>>>>>>> engine has terminated >>>>>>>>>> * @throws .... >>>>>>>>>> * @throws InternalException an internal problem >>>>>>>>>> occurred >>>>>>>>>> */ >>>>>>>>>> >>>>>>>>>> Plus add the bad argument exception. >>>>>>>>>> Whatever it is, should be added to extensionCommand() >>>>>>>>>> exceptions. >>>>>>>>>> >>>>>>>>>> Robert >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 09/05/16 08:02, ShinyaYoshida wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> I've update webrev of langtools: >>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev. >>>>>>>>>>> 02.langtools/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> v.02.langtools/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I added an issue for the completion feature. >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165445 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>> >>>>>>>>>>> 2016-09-05 22:49 GMT+09:00 ShinyaYoshida >>>>>>>>>>> > >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>> Hi Robert, >>>>>>>>>>> Thank you for the review. >>>>>>>>>>> >>>>>>>>>>> I totally agree with you. >>>>>>>>>>> I also think that availableModules and >>>>>>>>>>> availablePackages(module) are worthless excepting >>>>>>>>>>> for the command completion feature. >>>>>>>>>>> I'd like to avoid adding these APIs which have >>>>>>>>>>> not >>>>>>>>>>> been speculated and revised because if API is >>>>>>>>>>> once >>>>>>>>>>> added, it is too difficult to remove than adding. >>>>>>>>>>> >>>>>>>>>>> So currently, I'll remove the completion feature >>>>>>>>>>> for >>>>>>>>>>> /set or /retain exports and make the issue to >>>>>>>>>>> JBS to >>>>>>>>>>> add completion feature for them in future. >>>>>>>>>>> >>>>>>>>>>> I'll update the webrev. So please review it again >>>>>>>>>>> later. >>>>>>>>>>> When the silently evaluation feature is added, >>>>>>>>>>> I'd >>>>>>>>>>> like to work for the completion feature again. >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2016-09-05 15:00 GMT+09:00 Robert Field >>>>>>>>>>> >>>>>>>>>> >: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 09/03/16 05:07, ShinyaYoshida wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> I've updated my patch, new webrev is here: >>>>>>>>>>>> webrev.01.langtools: >>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev. >>>>>>>>>>>> 01.langtools/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> v.01.langtools/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> webrev.01.jdk: >>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev. >>>>>>>>>>>> 01.jdk/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> v.01.jdk/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (Same as previous) >>>>>>>>>>>> >>>>>>>>>>>> In this version, >>>>>>>>>>>> - rename /set add-exports to /set exports >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> OK >>>>>>>>>>> >>>>>>>>>>> - add /retain exports >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The /retain implementation looks good. >>>>>>>>>>> >>>>>>>>>>> - add tests >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Well tested >>>>>>>>>>> >>>>>>>>>>> - move EXT_CMD_XXX into RemoteCodes >>>>>>>>>>>> - make RemoteCodes public and move it into >>>>>>>>>>>> jdk.jshell.execution.code which is >>>>>>>>>>>> module-private >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So, here, in addition to addExports, there >>>>>>>>>>> are >>>>>>>>>>> two more methods added to the API >>>>>>>>>>> availableModules() and >>>>>>>>>>> availablePackage(String >>>>>>>>>>> module). >>>>>>>>>>> I see how in rare cases they could be useful. >>>>>>>>>>> And the rare case that causes them to be >>>>>>>>>>> present >>>>>>>>>>> is for command completion in the tool. >>>>>>>>>>> What are the options: >>>>>>>>>>> >>>>>>>>>>> (1) Add them to the API. If it is in the >>>>>>>>>>> API >>>>>>>>>>> then it is a first-class form of >>>>>>>>>>> functionality >>>>>>>>>>> and should be treated as such in execution >>>>>>>>>>> support (as a command) >>>>>>>>>>> (2) Not support them and not support >>>>>>>>>>> command >>>>>>>>>>> completion for /set exports. Command >>>>>>>>>>> completion >>>>>>>>>>> is not supported in much more common cases. >>>>>>>>>>> Then we could support command completion in >>>>>>>>>>> the >>>>>>>>>>> future (see (3)). >>>>>>>>>>> (3) What these commands do is simply >>>>>>>>>>> execute >>>>>>>>>>> an expression on the remote side. But we >>>>>>>>>>> already have a mechanism to execute >>>>>>>>>>> expressions >>>>>>>>>>> on the remote side: Snippets. >>>>>>>>>>> That leaves a problem: we wouldn't >>>>>>>>>>> want >>>>>>>>>>> these Snippets to be seen by the user, but we >>>>>>>>>>> have a solution for that the tool uses the >>>>>>>>>>> idGenerator. >>>>>>>>>>> Another problem is that, by default >>>>>>>>>>> and >>>>>>>>>>> with no current way around the default, >>>>>>>>>>> expressions generate temp-variables. My >>>>>>>>>>> intention was to make this configurable -- >>>>>>>>>>> see >>>>>>>>>>> Eval.shouldGenTempVar(...). >>>>>>>>>>> >>>>>>>>>>> One goal I've been using in the design of the >>>>>>>>>>> API is to keep it as small and simple as >>>>>>>>>>> possible. This improves maintainability, but >>>>>>>>>>> much more importantly makes the API easier to >>>>>>>>>>> learn and use. >>>>>>>>>>> So, for something to warrant inclusion it >>>>>>>>>>> should >>>>>>>>>>> be generally useful and have no other way of >>>>>>>>>>> being achieved -- neither is true of these >>>>>>>>>>> two >>>>>>>>>>> queries. >>>>>>>>>>> >>>>>>>>>>> My suggestion, particularly in light of how >>>>>>>>>>> late >>>>>>>>>>> in the release this is, would be (2). >>>>>>>>>>> Thoughts? >>>>>>>>>>> >>>>>>>>>>> -Robert >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>> >>>>>>>>>>>> 2016-09-03 18:15 GMT+09:00 ShinyaYoshida >>>>>>>>>>>> >>>>>>>>>>> >: >>>>>>>>>>>> >>>>>>>>>>>> Hi Robert, >>>>>>>>>>>> Thank you for reviewing. >>>>>>>>>>>> I'll update my patch later. >>>>>>>>>>>> >>>>>>>>>>>> 2016-09-02 11:38 GMT+09:00 Robert Field >>>>>>>>>>>> >>>>>>>>>>> >: >>>>>>>>>>>> >>>>>>>>>>>> Thanks shiyafox! This is a >>>>>>>>>>>> significant >>>>>>>>>>>> piece of code! >>>>>>>>>>>> >>>>>>>>>>>> As to your questions -- >>>>>>>>>>>> >>>>>>>>>>>> > I wonder if you could work on the >>>>>>>>>>>> documentation of the API and the >>>>>>>>>>>> tool >>>>>>>>>>>> instead? >>>>>>>>>>>> >>>>>>>>>>>> Yes, I will do API and tool docs. >>>>>>>>>>>> >>>>>>>>>>>> Thank you! >>>>>>>>>>>> >>>>>>>>>>>> > Subcommand of /set is reasonable? >>>>>>>>>>>> Similar command, /classpath, to make >>>>>>>>>>>> users available to use new >>>>>>>>>>>> packages is >>>>>>>>>>>> not a subcommand of /set. >>>>>>>>>>>> >>>>>>>>>>>> Yes, I think /set exports is best. >>>>>>>>>>>> And, yes, /classpath is >>>>>>>>>>>> inconsistent, >>>>>>>>>>>> it should be /set classpath, that >>>>>>>>>>>> can >>>>>>>>>>>> be a separate task, unless you >>>>>>>>>>>> want to >>>>>>>>>>>> roll that in. >>>>>>>>>>>> >>>>>>>>>>>> I see, I've created the issue to move >>>>>>>>>>>> /classpath to /set classpath: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165405 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > Should we need retain feature to >>>>>>>>>>>> this? >>>>>>>>>>>> >>>>>>>>>>>> All /set have a /retain >>>>>>>>>>>> counterpart -- >>>>>>>>>>>> we should maintain that >>>>>>>>>>>> >>>>>>>>>>>> Ok, I'll add /retain exports. >>>>>>>>>>>> I've also create the issue for retaining >>>>>>>>>>>> classpath: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165406 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As to the code review: Looks good to >>>>>>>>>>>> me, just minor questions/issues -- >>>>>>>>>>>> >>>>>>>>>>>> JShellTool.java: >>>>>>>>>>>> >>>>>>>>>>>> * As discussed /set add-exports => >>>>>>>>>>>> /set >>>>>>>>>>>> exports >>>>>>>>>>>> >>>>>>>>>>>> * Nit: a comment got moved out of >>>>>>>>>>>> place >>>>>>>>>>>> line 1194(old) >>>>>>>>>>>> >>>>>>>>>>>> JShell.java: >>>>>>>>>>>> >>>>>>>>>>>> * EXT_CMD_AVAILABLE_MODULES and >>>>>>>>>>>> EXT_CMD_AVAILABLE_PACKAGES, these >>>>>>>>>>>> should be referenced via >>>>>>>>>>>> RemoteCodes.java rather than be >>>>>>>>>>>> coped. >>>>>>>>>>>> >>>>>>>>>>>> Absolutely! I'd like to move these into >>>>>>>>>>>> RemoteCodes but it is package-private >>>>>>>>>>>> class >>>>>>>>>>>> and cannot be referred from JShell. >>>>>>>>>>>> Can I make RemoteCodes public and move >>>>>>>>>>>> it >>>>>>>>>>>> to another module-private package like >>>>>>>>>>>> jdk.jshell.execution.code? >>>>>>>>>>>> >>>>>>>>>>>> * Which leads me to another >>>>>>>>>>>> question: >>>>>>>>>>>> why is addExports a command and >>>>>>>>>>>> these >>>>>>>>>>>> two are extensions. It seems fine, >>>>>>>>>>>> just >>>>>>>>>>>> curious. I notice that extensions >>>>>>>>>>>> are a >>>>>>>>>>>> lot less code -- ;-) >>>>>>>>>>>> >>>>>>>>>>>> Exporting module and package is >>>>>>>>>>>> similar to >>>>>>>>>>>> adding classpath to platform, so I made >>>>>>>>>>>> the >>>>>>>>>>>> addExports a command like setClasspath. >>>>>>>>>>>> And it should be added as API because >>>>>>>>>>>> it is >>>>>>>>>>>> very basic feature. >>>>>>>>>>>> >>>>>>>>>>>> TaskFactory.java: >>>>>>>>>>>> >>>>>>>>>>>> * Question: the "/" separator >>>>>>>>>>>> between >>>>>>>>>>>> module and package is that platform >>>>>>>>>>>> independent? >>>>>>>>>>>> >>>>>>>>>>>> It seems to me that "{module}/{path}" >>>>>>>>>>>> format for --add-exports option of >>>>>>>>>>>> javac is >>>>>>>>>>>> platform independent. >>>>>>>>>>>> Regards, >>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> DefaultLoaderDelegate.java: >>>>>>>>>>>> >>>>>>>>>>>> * Jan, can you look at this code? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -Robert >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 09/01/16 05:36, ShinyaYoshida >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> I've implemented this feature to >>>>>>>>>>>> JShell API and Tool with full >>>>>>>>>>>> completion: >>>>>>>>>>>> Bugs: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8154714 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> jdk: >>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev. >>>>>>>>>>>> 00.jdk/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> v.00.jdk/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> v.00.jdk/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> v.00.jdk/>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> langtools: >>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev. >>>>>>>>>>>> 00.langtools/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> v.00.langtools/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> v.00.langtools/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> v.00.langtools/>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This is missing the train of >>>>>>>>>>>> Java >>>>>>>>>>>> 9.0 but it could catch the >>>>>>>>>>>> train of >>>>>>>>>>>> Java 9.1 or later. >>>>>>>>>>>> I want to get your comments for >>>>>>>>>>>> this. >>>>>>>>>>>> >>>>>>>>>>>> jshell> /set add-exports >>>>>>>>>>>> jdk.jconsole sun.tools.jconsole >>>>>>>>>>>> >>>>>>>>>>>> jshell> import >>>>>>>>>>>> sun.tools.jconsole.* >>>>>>>>>>>> >>>>>>>>>>>> jshell> >>>>>>>>>>>> LocalVirtualMachine.getAllVirtualMachines().forEach((k, >>>>>>>>>>>> v) -> System.out.println(k + ":" >>>>>>>>>>>> + v)) >>>>>>>>>>>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>>>>>>>>>>> 10826:jdk.jshell.execution.RemoteExecutionControl >>>>>>>>>>>> 35548 >>>>>>>>>>>> 28447:org.netbeans.Main --cachedir >>>>>>>>>>>> /home/bitter_fox/.cache/netbeans/8.0.1 >>>>>>>>>>>> --userdir >>>>>>>>>>>> /home/bitter_fox/.netbeans/8.0.1 >>>>>>>>>>>> --branding nb >>>>>>>>>>>> >>>>>>>>>>>> Currently, there is no >>>>>>>>>>>> testing, so >>>>>>>>>>>> it will be required to add test. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> > From jan.lahoda at oracle.com Fri Sep 16 09:23:57 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 16 Sep 2016 11:23:57 +0200 Subject: RFR 8166051: [jline] Cannot parse .inputrc with \r Message-ID: <57DBBA2D.9050705@oracle.com> Please review a change to how .inputrc is read. Currently, it uses BufferedReader.readLine(), which interprets '\r' as a line separator, and so the '\r' character cannot be used in the macros. The proposed change is to use System.getProperty("line.separator") and "\n" as line separators. Bug: https://bugs.openjdk.java.net/browse/JDK-8166051 Webrev: http://cr.openjdk.java.net/~jlahoda/8166051/webrev.00/ Thanks! Jan From robert.field at oracle.com Fri Sep 16 16:26:36 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 16 Sep 2016 09:26:36 -0700 Subject: RFR 8166051: [jline] Cannot parse .inputrc with \r In-Reply-To: <57DBBA2D.9050705@oracle.com> References: <57DBBA2D.9050705@oracle.com> Message-ID: <57DC1D3C.9070500@oracle.com> BufferedReader provides platform independent behavior. Which is appropriate here because configuration files get copied between platforms with different line-end standards. The proposed replacement exchanges this for a platform dependent strategy. While it would address this one obscure failure, my concern is that it will create new, possibly more common, problems. specifically where a file where \r\n is used -- injecting \r into the results. Not sure what the right choice is. A compromise might be to accept \n or \r\n on all platforms, and \r alone only on platforms that accept that as a line end. I am concerned with forking jline, esp. if it not a clear fix. Can we address this at a higher level? More tolerant error handling? -Robert On 09/16/16 02:23, Jan Lahoda wrote: > Please review a change to how .inputrc is read. Currently, it uses > BufferedReader.readLine(), which interprets '\r' as a line separator, > and so the '\r' character cannot be used in the macros. The proposed > change is to use System.getProperty("line.separator") and "\n" as line > separators. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8166051 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8166051/webrev.00/ > > Thanks! > > Jan From jonathan.gibbons at oracle.com Fri Sep 16 18:31:53 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 16 Sep 2016 11:31:53 -0700 Subject: RFR 8166051: [jline] Cannot parse .inputrc with \r In-Reply-To: <57DC1D3C.9070500@oracle.com> References: <57DBBA2D.9050705@oracle.com> <57DC1D3C.9070500@oracle.com> Message-ID: <57DC3A99.8020904@oracle.com> Perhaps your .inputrc reader should support an escape mechanism for handling problematic characters. -- Jon On 09/16/2016 09:26 AM, Robert Field wrote: > BufferedReader provides platform independent behavior. Which is > appropriate here because configuration files get copied between > platforms with different line-end standards. > The proposed replacement exchanges this for a platform dependent > strategy. > While it would address this one obscure failure, my concern is that it > will create new, possibly more common, problems. specifically where a > file where \r\n is used -- injecting \r into the results. > Not sure what the right choice is. > A compromise might be to accept \n or \r\n on all platforms, and \r > alone only on platforms that accept that as a line end. > I am concerned with forking jline, esp. if it not a clear fix. > Can we address this at a higher level? More tolerant error handling? > > -Robert > > > On 09/16/16 02:23, Jan Lahoda wrote: >> Please review a change to how .inputrc is read. Currently, it uses >> BufferedReader.readLine(), which interprets '\r' as a line separator, >> and so the '\r' character cannot be used in the macros. The proposed >> change is to use System.getProperty("line.separator") and "\n" as >> line separators. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8166051 >> >> Webrev: >> http://cr.openjdk.java.net/~jlahoda/8166051/webrev.00/ >> >> Thanks! >> >> Jan > From robert.field at oracle.com Fri Sep 16 19:08:45 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 16 Sep 2016 12:08:45 -0700 Subject: RFR 8166051: [jline] Cannot parse .inputrc with \r In-Reply-To: <57DC3A99.8020904@oracle.com> References: <57DBBA2D.9050705@oracle.com> <57DC1D3C.9070500@oracle.com> <57DC3A99.8020904@oracle.com> Message-ID: <57DC433D.9090302@oracle.com> On 09/16/16 11:31, Jonathan Gibbons wrote: > Perhaps your .inputrc reader should support an escape mechanism for > handling problematic characters. .inputrc is a standard not under our control: https://www.gnu.org/software/bash/manual/html_node/Readline-Init-File.html Though! That gives a hint on how we should handle this: figure out what bash does. -Robert > > -- Jon > > On 09/16/2016 09:26 AM, Robert Field wrote: >> BufferedReader provides platform independent behavior. Which is >> appropriate here because configuration files get copied between >> platforms with different line-end standards. >> The proposed replacement exchanges this for a platform dependent >> strategy. >> While it would address this one obscure failure, my concern is that >> it will create new, possibly more common, problems. specifically >> where a file where \r\n is used -- injecting \r into the results. >> Not sure what the right choice is. >> A compromise might be to accept \n or \r\n on all platforms, and \r >> alone only on platforms that accept that as a line end. >> I am concerned with forking jline, esp. if it not a clear fix. >> Can we address this at a higher level? More tolerant error handling? >> >> -Robert >> >> >> On 09/16/16 02:23, Jan Lahoda wrote: >>> Please review a change to how .inputrc is read. Currently, it uses >>> BufferedReader.readLine(), which interprets '\r' as a line >>> separator, and so the '\r' character cannot be used in the macros. >>> The proposed change is to use System.getProperty("line.separator") >>> and "\n" as line separators. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8166051 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~jlahoda/8166051/webrev.00/ >>> >>> Thanks! >>> >>> Jan >> > From jan.lahoda at oracle.com Fri Sep 16 19:10:20 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 16 Sep 2016 21:10:20 +0200 Subject: RFR 8166051: [jline] Cannot parse .inputrc with \r In-Reply-To: <57DC1D3C.9070500@oracle.com> References: <57DBBA2D.9050705@oracle.com> <57DC1D3C.9070500@oracle.com> Message-ID: <57DC439C.90201@oracle.com> On 16.9.2016 18:26, Robert Field wrote: > BufferedReader provides platform independent behavior. Which is Yes. > appropriate here because configuration files get copied between Not sure if (BufferedReader-based) platform-independent behavior is appropriate for reading inputrc - that file is originally for use of the native readline. The native readline appears to use '\n' on my Linux and either '\n' or \'r\n' on my Windows. Neither appears to interpret standalone '\r'. Which is similar to the proposed patch. But I admit the jline behavior still differs from the native behavior, as jline trim()s the line it read; and native does not appear to produce warnings for absent closing ". > platforms with different line-end standards. > The proposed replacement exchanges this for a platform dependent strategy. > While it would address this one obscure failure, my concern is that it > will create new, possibly more common, problems. specifically where a > file where \r\n is used -- injecting \r into the results. > Not sure what the right choice is. > A compromise might be to accept \n or \r\n on all platforms, and \r > alone only on platforms that accept that as a line end. > I am concerned with forking jline, esp. if it not a clear fix. So, maybe we should treat this is an upstream bug, reporting it to jline and wait until it is properly fixed there? > Can we address this at a higher level? More tolerant error handling? Without changing jline, I think we could completely suppress all warnings from jline. With a change to jline, we could suppress this specific warning. But, I am not sure either of these is a proper fix - we/jline is still not interpreting the file correctly. So we would be just masking out the problem. Jan > > -Robert > > > On 09/16/16 02:23, Jan Lahoda wrote: >> Please review a change to how .inputrc is read. Currently, it uses >> BufferedReader.readLine(), which interprets '\r' as a line separator, >> and so the '\r' character cannot be used in the macros. The proposed >> change is to use System.getProperty("line.separator") and "\n" as line >> separators. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8166051 >> >> Webrev: >> http://cr.openjdk.java.net/~jlahoda/8166051/webrev.00/ >> >> Thanks! >> >> Jan > From robert.field at oracle.com Fri Sep 16 19:35:28 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 16 Sep 2016 12:35:28 -0700 Subject: RFR 8166051: [jline] Cannot parse .inputrc with \r In-Reply-To: <57DC433D.9090302@oracle.com> References: <57DBBA2D.9050705@oracle.com> <57DC1D3C.9070500@oracle.com> <57DC3A99.8020904@oracle.com> <57DC433D.9090302@oracle.com> Message-ID: <57DC4980.8040104@oracle.com> The code that typically reads this file is in the Readline library, specifically bind.c -- this is what it does: while (line < end) { /* Find the end of this line. */ for (i = 0; line + i != end && line[i] != '\n'; i++); #if defined (__CYGWIN__) /* ``Be liberal in what you accept.'' */ if (line[i] == '\n' && line[i-1] == '\r') line[i - 1] = '\0'; #endif /* Mark end of line. */ line[i] = '\0'; /* Skip leading whitespace. */ while (*line && whitespace (*line)) { line++; i--; } /* If the line is not a comment, then parse it. */ if (*line && *line != '#') rl_parse_and_bind (line); /* Move to the next line. */ line += i + 1; current_readline_init_lineno++; } I think we should mimic this behavior. Specifically, this means accepting \n and \r\n but not treating stand-alone \r as a special character. I think this should be handled the same across platform. As Jan points out, this also treats whitespace differently than jline. Specifically it trims the start but not end of the line. Note: they read the whole file and then just operate on the string. It is a small file. Rather than subclassing BufferedReader, that given the flexibility the exactly match their logic. And I think we should contribute this back to jline. -Robert On 09/16/16 12:08, Robert Field wrote: > > On 09/16/16 11:31, Jonathan Gibbons wrote: >> Perhaps your .inputrc reader should support an escape mechanism for >> handling problematic characters. > > .inputrc is a standard not under our control: > > https://www.gnu.org/software/bash/manual/html_node/Readline-Init-File.html > > > Though! That gives a hint on how we should handle this: figure out > what bash does. > > -Robert > > >> >> -- Jon >> >> On 09/16/2016 09:26 AM, Robert Field wrote: >>> BufferedReader provides platform independent behavior. Which is >>> appropriate here because configuration files get copied between >>> platforms with different line-end standards. >>> The proposed replacement exchanges this for a platform dependent >>> strategy. >>> While it would address this one obscure failure, my concern is that >>> it will create new, possibly more common, problems. specifically >>> where a file where \r\n is used -- injecting \r into the results. >>> Not sure what the right choice is. >>> A compromise might be to accept \n or \r\n on all platforms, and \r >>> alone only on platforms that accept that as a line end. >>> I am concerned with forking jline, esp. if it not a clear fix. >>> Can we address this at a higher level? More tolerant error handling? >>> >>> -Robert >>> >>> >>> On 09/16/16 02:23, Jan Lahoda wrote: >>>> Please review a change to how .inputrc is read. Currently, it uses >>>> BufferedReader.readLine(), which interprets '\r' as a line >>>> separator, and so the '\r' character cannot be used in the macros. >>>> The proposed change is to use System.getProperty("line.separator") >>>> and "\n" as line separators. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8166051 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8166051/webrev.00/ >>>> >>>> Thanks! >>>> >>>> Jan >>> >> > From jonathan.gibbons at oracle.com Fri Sep 16 20:41:47 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 16 Sep 2016 13:41:47 -0700 Subject: RFR 8166051: [jline] Cannot parse .inputrc with \r In-Reply-To: <57DC433D.9090302@oracle.com> References: <57DBBA2D.9050705@oracle.com> <57DC1D3C.9070500@oracle.com> <57DC3A99.8020904@oracle.com> <57DC433D.9090302@oracle.com> Message-ID: <1f7a9bb7-791f-1d58-8f60-035c334f8423@oracle.com> While the overall syntax of the file may be publicly defined, surely you are at liberty to define how you interpret the characters in the values found in .inputrc. In other words, follow the standards for whitespace and line breaks, but if you find the character sequence THIS-IS-A-RETURN then you can replace it with (char)0x0d -- Jon On 9/16/16 12:08 PM, Robert Field wrote: > > On 09/16/16 11:31, Jonathan Gibbons wrote: >> Perhaps your .inputrc reader should support an escape mechanism for >> handling problematic characters. > > .inputrc is a standard not under our control: > > https://www.gnu.org/software/bash/manual/html_node/Readline-Init-File.html > > > Though! That gives a hint on how we should handle this: figure out > what bash does. > > -Robert > > >> >> -- Jon >> >> On 09/16/2016 09:26 AM, Robert Field wrote: >>> BufferedReader provides platform independent behavior. Which is >>> appropriate here because configuration files get copied between >>> platforms with different line-end standards. >>> The proposed replacement exchanges this for a platform dependent >>> strategy. >>> While it would address this one obscure failure, my concern is that >>> it will create new, possibly more common, problems. specifically >>> where a file where \r\n is used -- injecting \r into the results. >>> Not sure what the right choice is. >>> A compromise might be to accept \n or \r\n on all platforms, and \r >>> alone only on platforms that accept that as a line end. >>> I am concerned with forking jline, esp. if it not a clear fix. >>> Can we address this at a higher level? More tolerant error handling? >>> >>> -Robert >>> >>> >>> On 09/16/16 02:23, Jan Lahoda wrote: >>>> Please review a change to how .inputrc is read. Currently, it uses >>>> BufferedReader.readLine(), which interprets '\r' as a line >>>> separator, and so the '\r' character cannot be used in the macros. >>>> The proposed change is to use System.getProperty("line.separator") >>>> and "\n" as line separators. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8166051 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8166051/webrev.00/ >>>> >>>> Thanks! >>>> >>>> Jan >>> >> > From robert.field at oracle.com Thu Sep 22 01:16:58 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 21 Sep 2016 18:16:58 -0700 Subject: JShell: representation of array values Message-ID: <57E3310A.7050504@oracle.com> JavaOne demos made it clear we need a friendlier representation of array values. Current -- jshell> new String[] { "hi", "low", null } $2 ==> [Ljava.lang.String;@ae45eb6 jshell> new char[] { 'a', 34, 77 } $3 ==> [C at 27efef64 I'm proposing this -- jshell> new int[4] $1 ==> int[4] { 0, 0, 0, 0 } jshell> new int[0] $2 ==> int[0] { } jshell> new String[] { "hi", "low", null } $3 ==> String[3] { "hi", "low", null } jshell> new char[] { 'a', 34, 77 } $4 ==> char[3] { 'a', '"', 'M' } jshell> new int[][] { new int[] {44, 55}, new int[] {88,99}} $5 ==> int[][2] { int[2] { 44, 55 }, int[2] { 88, 99 } } jshell> new Object[] { "howdy", new int[] { 33, 44, 55 }, new String[] { "up", "down" }} $6 ==> Object[3] { "howdy", int[3] { 33, 44, 55 }, String[2] { "up", "down" } } jshell> new int[100000] $7 ==> int[100000] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ... jshell> Comments??? Thanks, Robert From robert.field at oracle.com Thu Sep 22 02:08:37 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 21 Sep 2016 19:08:37 -0700 Subject: RFR 8166400: JShell: friendlier representation of array values Message-ID: <57E33D25.3020406@oracle.com> Please review -- Bug: https://bugs.openjdk.java.net/browse/JDK-8166400 Webrev: http://cr.openjdk.java.net/~rfield/8166400v0.webrev/ Robert From cay at horstmann.com Thu Sep 22 03:16:26 2016 From: cay at horstmann.com (Cay Horstmann) Date: Wed, 21 Sep 2016 20:16:26 -0700 Subject: JShell: representation of array values In-Reply-To: <57E3310A.7050504@oracle.com> References: <57E3310A.7050504@oracle.com> Message-ID: <2ccb51bd-5dd4-1285-6767-17b8052b5fcd@horstmann.com> Hah, that's what I said last Java One :-) Yes, you definitely want to do this. I've used jshell extensively for presentations the last year, and it was always a distraction to have to add Arrays.toString. I think there is some value of seeing the actual toString output in addition to the useful output when feedback is verbose. Some variation of $2 ==> String[3] { "hi", "low", null } ([Ljava.lang.String;@ae45eb6) Cheers, Cay Le 09/21/2016 ? 06:16 PM, Robert Field a ?crit : > JavaOne demos made it clear we need a friendlier representation of array > values. > > Current -- > > jshell> new String[] { "hi", "low", null } > $2 ==> [Ljava.lang.String;@ae45eb6 > > jshell> new char[] { 'a', 34, 77 } > $3 ==> [C at 27efef64 > > I'm proposing this -- > > jshell> new int[4] > $1 ==> int[4] { 0, 0, 0, 0 } > > jshell> new int[0] > $2 ==> int[0] { } > > jshell> new String[] { "hi", "low", null } > $3 ==> String[3] { "hi", "low", null } > > jshell> new char[] { 'a', 34, 77 } > $4 ==> char[3] { 'a', '"', 'M' } > > jshell> new int[][] { new int[] {44, 55}, new int[] {88,99}} > $5 ==> int[][2] { int[2] { 44, 55 }, int[2] { 88, 99 } } > > jshell> new Object[] { "howdy", new int[] { 33, 44, 55 }, new String[] { > "up", "down" }} > $6 ==> Object[3] { "howdy", int[3] { 33, 44, 55 }, String[2] { "up", > "down" } } > > jshell> new int[100000] > $7 ==> int[100000] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ... > > jshell> > > > Comments??? > > Thanks, > Robert > -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From sundararajan.athijegannathan at oracle.com Thu Sep 22 05:03:20 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 22 Sep 2016 10:33:20 +0530 Subject: RFR 8166400: JShell: friendlier representation of array values In-Reply-To: <57E33D25.3020406@oracle.com> References: <57E33D25.3020406@oracle.com> Message-ID: <0ed3684a-9320-bd4e-7609-5ff3082e7d81@oracle.com> Can reflection be used to avoid that switch case (Array.getLength, Array.get())? Or perhaps java.util.Arrays.toString overloads may be used (slightly different output "[]" instead of "{}")? -Sundar On 9/22/2016 7:38 AM, Robert Field wrote: > Please review -- > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8166400 > > Webrev: > http://cr.openjdk.java.net/~rfield/8166400v0.webrev/ > > Robert > From forax at univ-mlv.fr Thu Sep 22 05:40:47 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 22 Sep 2016 05:40:47 +0000 Subject: JShell: representation of array values In-Reply-To: <57E3310A.7050504@oracle.com> References: <57E3310A.7050504@oracle.com> Message-ID: <7B9A2197-2CFB-4C3D-9404-D4269DA4F081@univ-mlv.fr> Yes ! R?mi On September 22, 2016 3:16:58 AM GMT+02:00, Robert Field wrote: >JavaOne demos made it clear we need a friendlier representation of >array >values. > >Current -- > >jshell> new String[] { "hi", "low", null } >$2 ==> [Ljava.lang.String;@ae45eb6 > >jshell> new char[] { 'a', 34, 77 } >$3 ==> [C at 27efef64 > >I'm proposing this -- > >jshell> new int[4] >$1 ==> int[4] { 0, 0, 0, 0 } > >jshell> new int[0] >$2 ==> int[0] { } > >jshell> new String[] { "hi", "low", null } >$3 ==> String[3] { "hi", "low", null } > >jshell> new char[] { 'a', 34, 77 } >$4 ==> char[3] { 'a', '"', 'M' } > >jshell> new int[][] { new int[] {44, 55}, new int[] {88,99}} >$5 ==> int[][2] { int[2] { 44, 55 }, int[2] { 88, 99 } } > >jshell> new Object[] { "howdy", new int[] { 33, 44, 55 }, new String[] >{ >"up", "down" }} >$6 ==> Object[3] { "howdy", int[3] { 33, 44, 55 }, String[2] { "up", >"down" } } > >jshell> new int[100000] >$7 ==> int[100000] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > >0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ... > >jshell> > > >Comments??? > >Thanks, >Robert -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From robert.field at oracle.com Thu Sep 22 05:46:14 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 21 Sep 2016 22:46:14 -0700 Subject: RFR 8166400: JShell: friendlier representation of array values In-Reply-To: <0ed3684a-9320-bd4e-7609-5ff3082e7d81@oracle.com> References: <57E33D25.3020406@oracle.com> <0ed3684a-9320-bd4e-7609-5ff3082e7d81@oracle.com> Message-ID: <57E37026.8080100@oracle.com> Arrays can't be used because that is based on compile-time type. Array can be used. I was resistant to using reflection. But that sure reduces the code. Here is the new webrev: http://cr.openjdk.java.net/~rfield/8166400v1.webrev/ (Test is unchanged). -Robert P.S. The representation is getting positive reviews On 09/21/16 22:03, Sundararajan Athijegannathan wrote: > Can reflection be used to avoid that switch case (Array.getLength, > Array.get())? Or perhaps java.util.Arrays.toString overloads may be used > (slightly different output "[]" instead of "{}")? > > -Sundar > > > On 9/22/2016 7:38 AM, Robert Field wrote: >> Please review -- >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8166400 >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8166400v0.webrev/ >> >> Robert >> From sundararajan.athijegannathan at oracle.com Thu Sep 22 05:52:31 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 22 Sep 2016 11:22:31 +0530 Subject: RFR 8166400: JShell: friendlier representation of array values In-Reply-To: <57E37026.8080100@oracle.com> References: <57E33D25.3020406@oracle.com> <0ed3684a-9320-bd4e-7609-5ff3082e7d81@oracle.com> <57E37026.8080100@oracle.com> Message-ID: <571247e2-b3be-27e6-a37e-363a60e5e0c2@oracle.com> +1 -Sundar On 9/22/2016 11:16 AM, Robert Field wrote: > Arrays can't be used because that is based on compile-time type. > > Array can be used. I was resistant to using reflection. But that > sure reduces the code. Here is the new webrev: > > http://cr.openjdk.java.net/~rfield/8166400v1.webrev/ > > (Test is unchanged). > > -Robert > > P.S. The representation is getting positive reviews > > > On 09/21/16 22:03, Sundararajan Athijegannathan wrote: >> Can reflection be used to avoid that switch case (Array.getLength, >> Array.get())? Or perhaps java.util.Arrays.toString overloads may be used >> (slightly different output "[]" instead of "{}")? >> >> -Sundar >> >> >> On 9/22/2016 7:38 AM, Robert Field wrote: >>> Please review -- >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8166400 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rfield/8166400v0.webrev/ >>> >>> Robert >>> > From robert.field at oracle.com Thu Sep 22 05:53:47 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 21 Sep 2016 22:53:47 -0700 Subject: RFR 8166400: JShell: friendlier representation of array values In-Reply-To: <571247e2-b3be-27e6-a37e-363a60e5e0c2@oracle.com> References: <57E33D25.3020406@oracle.com> <0ed3684a-9320-bd4e-7609-5ff3082e7d81@oracle.com> <57E37026.8080100@oracle.com> <571247e2-b3be-27e6-a37e-363a60e5e0c2@oracle.com> Message-ID: <57E371EB.2060105@oracle.com> Thanks Sundar! -Robert On 09/21/16 22:52, Sundararajan Athijegannathan wrote: > +1 > > -Sundar > > > On 9/22/2016 11:16 AM, Robert Field wrote: >> Arrays can't be used because that is based on compile-time type. >> >> Array can be used. I was resistant to using reflection. But that >> sure reduces the code. Here is the new webrev: >> >> http://cr.openjdk.java.net/~rfield/8166400v1.webrev/ >> >> (Test is unchanged). >> >> -Robert >> >> P.S. The representation is getting positive reviews >> >> >> On 09/21/16 22:03, Sundararajan Athijegannathan wrote: >>> Can reflection be used to avoid that switch case (Array.getLength, >>> Array.get())? Or perhaps java.util.Arrays.toString overloads may be used >>> (slightly different output "[]" instead of "{}")? >>> >>> -Sundar >>> >>> >>> On 9/22/2016 7:38 AM, Robert Field wrote: >>>> Please review -- >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8166400 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rfield/8166400v0.webrev/ >>>> >>>> Robert >>>> From benjamin.john.evans at gmail.com Thu Sep 22 06:07:18 2016 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 22 Sep 2016 11:37:18 +0530 Subject: JShell: representation of array values In-Reply-To: <57E3310A.7050504@oracle.com> References: <57E3310A.7050504@oracle.com> Message-ID: Hi Robert, Some feedback from my wife, who's currently writing some introductory material for absolute beginners in Java (& programming as a whole) - she uses jshell as the very first thing that learners meet and had this to say: > seeing a visual representation of the array like that would be a great help! > (Right now you have to use iterations to see what's in the array, and that's brining in logic far earlier than I'd like) > I really liked in earlier versions where it returned a type as well as a result - helps learners get to grips with java as typed language. > (Also makes it easier for kids who are used to calculators to understand why 4/3 returns 1, not 1.333334!) If the usage of jshell for beginners is a big aim of the project (something like Swift Playgrounds), Anna & I would be happy to help review features & provide more feedback with that audience in mind. Thanks, Ben On Thu, Sep 22, 2016 at 6:46 AM, Robert Field wrote: > JavaOne demos made it clear we need a friendlier representation of array > values. > > Current -- > > jshell> new String[] { "hi", "low", null } > $2 ==> [Ljava.lang.String;@ae45eb6 > > jshell> new char[] { 'a', 34, 77 } > $3 ==> [C at 27efef64 > > I'm proposing this -- > > jshell> new int[4] > $1 ==> int[4] { 0, 0, 0, 0 } > > jshell> new int[0] > $2 ==> int[0] { } > > jshell> new String[] { "hi", "low", null } > $3 ==> String[3] { "hi", "low", null } > > jshell> new char[] { 'a', 34, 77 } > $4 ==> char[3] { 'a', '"', 'M' } > > jshell> new int[][] { new int[] {44, 55}, new int[] {88,99}} > $5 ==> int[][2] { int[2] { 44, 55 }, int[2] { 88, 99 } } > > jshell> new Object[] { "howdy", new int[] { 33, 44, 55 }, new String[] { > "up", "down" }} > $6 ==> Object[3] { "howdy", int[3] { 33, 44, 55 }, String[2] { "up", "down" > } } > > jshell> new int[100000] > $7 ==> int[100000] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ... > > jshell> > > > Comments??? > > Thanks, > Robert > From jan.lahoda at oracle.com Thu Sep 22 06:30:18 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 22 Sep 2016 08:30:18 +0200 Subject: RFR 8166400: JShell: friendlier representation of array values In-Reply-To: <571247e2-b3be-27e6-a37e-363a60e5e0c2@oracle.com> References: <57E33D25.3020406@oracle.com> <0ed3684a-9320-bd4e-7609-5ff3082e7d81@oracle.com> <57E37026.8080100@oracle.com> <571247e2-b3be-27e6-a37e-363a60e5e0c2@oracle.com> Message-ID: <57E37A7A.8020300@oracle.com> Seems OK to me too. Array.get/length seems definitely better to me than the switch. Jan On 22.9.2016 07:52, Sundararajan Athijegannathan wrote: > +1 > > -Sundar > > > On 9/22/2016 11:16 AM, Robert Field wrote: >> Arrays can't be used because that is based on compile-time type. >> >> Array can be used. I was resistant to using reflection. But that >> sure reduces the code. Here is the new webrev: >> >> http://cr.openjdk.java.net/~rfield/8166400v1.webrev/ >> >> (Test is unchanged). >> >> -Robert >> >> P.S. The representation is getting positive reviews >> >> >> On 09/21/16 22:03, Sundararajan Athijegannathan wrote: >>> Can reflection be used to avoid that switch case (Array.getLength, >>> Array.get())? Or perhaps java.util.Arrays.toString overloads may be used >>> (slightly different output "[]" instead of "{}")? >>> >>> -Sundar >>> >>> >>> On 9/22/2016 7:38 AM, Robert Field wrote: >>>> Please review -- >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8166400 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rfield/8166400v0.webrev/ >>>> >>>> Robert >>>> >> > From robert.field at oracle.com Thu Sep 22 06:48:49 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 21 Sep 2016 23:48:49 -0700 Subject: JShell: representation of array values In-Reply-To: References: <57E3310A.7050504@oracle.com> Message-ID: <57E37ED1.6000906@oracle.com> Thanks Cay, Michael, Remi, Anna, and Ben for the feedback! Just pushed it! Anna: responding under separate thread. Robert On 09/21/16 23:07, Ben Evans wrote: > Hi Robert, > > Some feedback from my wife, who's currently writing some introductory > material for absolute beginners in Java (& programming as a whole) - > she uses jshell as the very first thing that learners meet and had > this to say: > >> seeing a visual representation of the array like that would be a great help! >> (Right now you have to use iterations to see what's in the array, and that's brining in logic far earlier than I'd like) >> I really liked in earlier versions where it returned a type as well as a result - helps learners get to grips with java as typed language. >> (Also makes it easier for kids who are used to calculators to understand why 4/3 returns 1, not 1.333334!) > If the usage of jshell for beginners is a big aim of the project > (something like Swift Playgrounds), Anna & I would be happy to help > review features & provide more feedback with that audience in mind. > > Thanks, > > Ben > > > On Thu, Sep 22, 2016 at 6:46 AM, Robert Field wrote: >> JavaOne demos made it clear we need a friendlier representation of array >> values. >> >> Current -- >> >> jshell> new String[] { "hi", "low", null } >> $2 ==> [Ljava.lang.String;@ae45eb6 >> >> jshell> new char[] { 'a', 34, 77 } >> $3 ==> [C at 27efef64 >> >> I'm proposing this -- >> >> jshell> new int[4] >> $1 ==> int[4] { 0, 0, 0, 0 } >> >> jshell> new int[0] >> $2 ==> int[0] { } >> >> jshell> new String[] { "hi", "low", null } >> $3 ==> String[3] { "hi", "low", null } >> >> jshell> new char[] { 'a', 34, 77 } >> $4 ==> char[3] { 'a', '"', 'M' } >> >> jshell> new int[][] { new int[] {44, 55}, new int[] {88,99}} >> $5 ==> int[][2] { int[2] { 44, 55 }, int[2] { 88, 99 } } >> >> jshell> new Object[] { "howdy", new int[] { 33, 44, 55 }, new String[] { >> "up", "down" }} >> $6 ==> Object[3] { "howdy", int[3] { 33, 44, 55 }, String[2] { "up", "down" >> } } >> >> jshell> new int[100000] >> $7 ==> int[100000] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ... >> >> jshell> >> >> >> Comments??? >> >> Thanks, >> Robert >> From robert.field at oracle.com Thu Sep 22 07:22:56 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 22 Sep 2016 00:22:56 -0700 Subject: JShell & Newbies Message-ID: <57E386D0.4000402@oracle.com> On 09/21/16 23:07, Ben Evans wrote: > Some feedback from my wife, who's currently writing some introductory > material for absolute beginners in Java (& programming as a whole) - > she uses jshell as the very first thing that learners meet and had > this to say: Excellent! Yes, please, Anna & Ben. When we launched the JShell project we identified three main audiences: (1) People learning Java (including learning to program for the first time using Java) (2) Learning a new API or language feature (3) Prototyping And it appears this is also significant: (4) Testing While we have had some feedback from educators, I think other uses have held heavier sway. I'm particularly interested in making it work well for raw beginners. > >> >I really liked in earlier versions where it returned a type as well as a result - helps learners get to grips with java as typed language. >> >(Also makes it easier for kids who are used to calculators to understand why 4/3 returns 1, not 1.333334!) The feedback I got was that users of other REPLs would "laugh at JShell" if it stayed as verbose as it was. So, we tried to hit a middle ground of being expressive but concise. The good news is (to do that) we made the jshell tool extremely configurable. First level of configuration is that you can set the feedback mode. Either with a command: /set feedback verbose or with a command-line switch: jshell -v The "verbose" predefined mode will show the type. (you can also go the other direction: concise or silent) The second level of configuration is what enables the first. You can, at fine detail, configure what feedback you get. See the /set commands: /help /set, /help /set mode, /help /set format, , /help /set feedback Weird place to find it (until you think about it), but you can see the configuration that creates the default modes here: langtools/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources -- startup.feedback = ... > If the usage of jshell for beginners is a big aim of the project > (something like Swift Playgrounds), Anna & I would be happy to help > review features & provide more feedback with that audience in mind. Absolutely!! Thanks, Robert From benjamin.john.evans at gmail.com Thu Sep 22 07:37:46 2016 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 22 Sep 2016 13:07:46 +0530 Subject: JShell & Newbies In-Reply-To: <57E386D0.4000402@oracle.com> References: <57E386D0.4000402@oracle.com> Message-ID: +Anna On Thu, Sep 22, 2016 at 12:52 PM, Robert Field wrote: > > On 09/21/16 23:07, Ben Evans wrote: >> >> Some feedback from my wife, who's currently writing some introductory >> material for absolute beginners in Java (& programming as a whole) - >> she uses jshell as the very first thing that learners meet and had >> this to say: > > > Excellent! Yes, please, Anna & Ben. > > When we launched the JShell project we identified three main audiences: > > (1) People learning Java (including learning to program for the first time > using Java) > > (2) Learning a new API or language feature > > (3) Prototyping > > And it appears this is also significant: > > (4) Testing > > While we have had some feedback from educators, I think other uses have held > heavier sway. > > I'm particularly interested in making it work well for raw beginners. > >>> >I really liked in earlier versions where it returned a type as well as a >>> > result - helps learners get to grips with java as typed language. >>> >(Also makes it easier for kids who are used to calculators to understand >>> > why 4/3 returns 1, not 1.333334!) > > > The feedback I got was that users of other REPLs would "laugh at JShell" if > it stayed as verbose as it was. > > So, we tried to hit a middle ground of being expressive but concise. > > The good news is (to do that) we made the jshell tool extremely > configurable. > > First level of configuration is that you can set the feedback mode. Either > with a command: > > /set feedback verbose > > or with a command-line switch: > > jshell -v > > The "verbose" predefined mode will show the type. > > (you can also go the other direction: concise or silent) > > The second level of configuration is what enables the first. You can, at > fine detail, configure what feedback you get. See the /set commands: /help > /set, /help /set mode, /help /set format, , /help /set feedback > > Weird place to find it (until you think about it), but you can see the > configuration that creates the default modes here: > > langtools/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources -- > startup.feedback = ... > >> If the usage of jshell for beginners is a big aim of the project >> (something like Swift Playgrounds), Anna & I would be happy to help >> review features & provide more feedback with that audience in mind. > > > Absolutely!! > > Thanks, > Robert > From anna at curvedspaces.co.uk Thu Sep 22 07:47:59 2016 From: anna at curvedspaces.co.uk (Anna Evans) Date: Thu, 22 Sep 2016 13:17:59 +0530 Subject: JShell & Newbies In-Reply-To: References: <57E386D0.4000402@oracle.com> Message-ID: Hi Robert, That's incredibly useful, thank you! I'll have a play with those settings... (I can see why established users would find it overly verbose, but to learners it's such a major element to grasp that I think having that reinforcement is incredibly important, so it's great to know it can be an option.) Already I can say it's a wonderful teaching tool ? so much better for total beginners than even the friendliest IDE could ever be! I'm starting with the absolute basics and working up from there, so shall let you know any additional feedback that arises. Kind regards Anna > > +Anna > > On Thu, Sep 22, 2016 at 12:52 PM, Robert Field > wrote: > > > > On 09/21/16 23:07, Ben Evans wrote: > >> > >> Some feedback from my wife, who's currently writing some introductory > >> material for absolute beginners in Java (& programming as a whole) - > >> she uses jshell as the very first thing that learners meet and had > >> this to say: > > > > > > Excellent! Yes, please, Anna & Ben. > > > > When we launched the JShell project we identified three main audiences: > > > > (1) People learning Java (including learning to program for the first > time > > using Java) > > > > (2) Learning a new API or language feature > > > > (3) Prototyping > > > > And it appears this is also significant: > > > > (4) Testing > > > > While we have had some feedback from educators, I think other uses have > held > > heavier sway. > > > > I'm particularly interested in making it work well for raw beginners. > > > >>> >I really liked in earlier versions where it returned a type as well > as a > >>> > result - helps learners get to grips with java as typed language. > >>> >(Also makes it easier for kids who are used to calculators to > understand > >>> > why 4/3 returns 1, not 1.333334!) > > > > > > The feedback I got was that users of other REPLs would "laugh at JShell" > if > > it stayed as verbose as it was. > > > > So, we tried to hit a middle ground of being expressive but concise. > > > > The good news is (to do that) we made the jshell tool extremely > > configurable. > > > > First level of configuration is that you can set the feedback mode. > Either > > with a command: > > > > /set feedback verbose > > > > or with a command-line switch: > > > > jshell -v > > > > The "verbose" predefined mode will show the type. > > > > (you can also go the other direction: concise or silent) > > > > The second level of configuration is what enables the first. You can, at > > fine detail, configure what feedback you get. See the /set commands: > /help > > /set, /help /set mode, /help /set format, , /help /set feedback > > > > Weird place to find it (until you think about it), but you can see the > > configuration that creates the default modes here: > > > > langtools/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources > -- > > startup.feedback = ... > > > >> If the usage of jshell for beginners is a big aim of the project > >> (something like Swift Playgrounds), Anna & I would be happy to help > >> review features & provide more feedback with that audience in mind. > > > > > > Absolutely!! > > > > Thanks, > > Robert > > > > -- Anna Evans e: anna at curvedspaces.co.uk m: +44 (0) 7872 006 297 From michael.mueller at mueller-bruehl.de Thu Sep 22 17:09:19 2016 From: michael.mueller at mueller-bruehl.de (=?UTF-8?Q?Michael_M=c3=bcller?=) Date: Thu, 22 Sep 2016 19:09:19 +0200 Subject: JShell: representation of array values In-Reply-To: <57E3310A.7050504@oracle.com> References: <57E3310A.7050504@oracle.com> Message-ID: Hi Robert, Beside my quick "Great" some additional thoughts: For large arrays this kind of output will extremely divide the inputs. Sometimes I like to keep all of my input together. For mitigation, /list can be used. I propose an additional output window, e.g. /output window opens a second window. All output is redirected to that window /output self resets the output channel to the shell's own window. The extra output window might be the same like the editor (which is used as default for /edit), but readonly. This allows the user to mark and copy parts of the output. Herzliche Gr??e - Best Regards, Michael M?ller Br?hl, Germany blog.mueller-bruehl.de it-rezension.de @muellermi Read my books "Web Development with Java and JSF": https://leanpub.com/jsf "Java Lambdas und (parallel) Streams" Deutsche Ausgabe: https://leanpub.com/lambdas-de "Java Lambdas and (parallel) Streams" English edition: https://leanpub.com/lambdas On 09/22/2016 03:16 AM, Robert Field wrote: > JavaOne demos made it clear we need a friendlier representation of > array values. > > Current -- > > jshell> new String[] { "hi", "low", null } > $2 ==> [Ljava.lang.String;@ae45eb6 > > jshell> new char[] { 'a', 34, 77 } > $3 ==> [C at 27efef64 > > I'm proposing this -- > > jshell> new int[4] > $1 ==> int[4] { 0, 0, 0, 0 } > > jshell> new int[0] > $2 ==> int[0] { } > > jshell> new String[] { "hi", "low", null } > $3 ==> String[3] { "hi", "low", null } > > jshell> new char[] { 'a', 34, 77 } > $4 ==> char[3] { 'a', '"', 'M' } > > jshell> new int[][] { new int[] {44, 55}, new int[] {88,99}} > $5 ==> int[][2] { int[2] { 44, 55 }, int[2] { 88, 99 } } > > jshell> new Object[] { "howdy", new int[] { 33, 44, 55 }, new String[] > { "up", "down" }} > $6 ==> Object[3] { "howdy", int[3] { 33, 44, 55 }, String[2] { "up", > "down" } } > > jshell> new int[100000] > $7 ==> int[100000] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ... > > jshell> > > > Comments??? > > Thanks, > Robert > > From john.r.rose at oracle.com Thu Sep 22 17:37:18 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 22 Sep 2016 10:37:18 -0700 Subject: JShell: representation of array values In-Reply-To: <57E3310A.7050504@oracle.com> References: <57E3310A.7050504@oracle.com> Message-ID: <74883988-E12D-41C2-AF83-2DE3A98ECFDE@oracle.com> On Sep 21, 2016, at 6:16 PM, Robert Field wrote: > > Comments??? Another +1 from me. Some comments from my inner Common Lisper: There should be a close brace after the "?" of an overlong array. This will allow syntax sensitive editors (emacs!) to block the thing correctly. The cutoff length of the overlong array should be a configurable number. You might consider a configurable cutoff for printed nesting level. These ideas from from this section of the CL manual: http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node193.html#LEVELLENGTHTABLE There is also an option called *print-array* which gates whether arrays should be expanded at all. This is relevant to Java, which also distinguishes Arrays.toString from Object.toString. ? John From jonathan.gibbons at oracle.com Thu Sep 22 17:42:36 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 22 Sep 2016 10:42:36 -0700 Subject: JShell: representation of array values In-Reply-To: <74883988-E12D-41C2-AF83-2DE3A98ECFDE@oracle.com> References: <57E3310A.7050504@oracle.com> <74883988-E12D-41C2-AF83-2DE3A98ECFDE@oracle.com> Message-ID: <796e2acd-5da4-85a5-a188-f2935ea62300@oracle.com> In the long array case, I'd suggest to hide the middle, not the end of the array. Show the first "few" entries and the last "few" entries in the array, for some value of "few". -- Jon On 9/22/16 10:37 AM, John Rose wrote: > On Sep 21, 2016, at 6:16 PM, Robert Field wrote: >> Comments??? > Another +1 from me. Some comments from my inner Common Lisper: > > There should be a close brace after the "?" of an overlong array. > This will allow syntax sensitive editors (emacs!) to block the thing correctly. > > The cutoff length of the overlong array should be a configurable number. > > You might consider a configurable cutoff for printed nesting level. > > These ideas from from this section of the CL manual: > > http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node193.html#LEVELLENGTHTABLE > > There is also an option called *print-array* which gates whether arrays should be expanded at all. > This is relevant to Java, which also distinguishes Arrays.toString from Object.toString. > > ? John From bitterfoxc at gmail.com Thu Sep 22 19:51:08 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Thu, 22 Sep 2016 12:51:08 -0700 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: <57D8289B.5030403@oracle.com> References: <57C8E61C.1040907@oracle.com> <57CD09FE.70908@oracle.com> <57CDE39A.3020100@oracle.com> <57D069C0.8030009@oracle.com> <57D33CE9.9060305@oracle.com> <57D5BBEC.8060506@oracle.com> <57D6CA3F.4050309@oracle.com> <57D6DE8F.4070405@oracle.com> <57D6EEB1.4050506@oracle.com> <57D7189F.2070901@oracle.com> <57D71A2C.9030501@oracle.com> <57D74A77.5000905@oracle.com> <57D8289B.5030403@oracle.com> Message-ID: Hi Robert and Jan, I've updated the webrev to add -C option and --add-exports option(as a non-standard option): http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.10.langtools/ Could you review and give me a comment? Another issue is found until implementing: https://bugs.openjdk.java.net/browse/JDK-8166581 Could you confirm and address this? Regards, shinyafox(Shinya Yoshida)@JavaOne 20016 2016-09-13 9:26 GMT-07:00 Robert Field : > > On 09/12/16 17:55, ShinyaYoshida wrote: > > Hi Jan and all, > I've confirmed your snippet. > Certainly it have a security problem and it should be avoided. > > I'll update my patch to add a new command-line option -C which give the > option to compiler. > > In addition to, I'd like to add a new command-line option --add-exports > / which is a short-circuit for "-J--add-exports > /=ALL-UNNAMED -C--add-exports > /=ALL-UNNAMED." > java and javac are also have --add-exports option, so it seems to me that > it is reasonable for jshell to have --add-exports option. > What do you think about this? > > Kind Regards, > shinyafox(Shinya Yoshida) > > > OK, great. > > I started to write that I didn't think you needed or wanted a -C > flag. But on further thought, that allows all kinds of flexibility that we > may not want to provide item by item -- for example: > --processor-module-path, --module-source-path, .... > There is a question: which compiles should these flags get applied to, but > it seems they would just be ignored where not needed, so probably all of > them. > > I notice --add-exports is on the -X help for both java and javac -- it is > non-standard. Seems wrong for it to be a non-standard option for those two > and a standard option for jshell. > > I think it is a question for Jigsaw people as to what module options: > > * should be directly jshell command-line options > * should be non-standard -X command-line options (if jshell has -X options) > * obscure enough that users should use -R and -C > > -Robert > > > > > > 2016-09-13 9:38 GMT+09:00 Robert Field : > >> If our approach to security is "do nothing a user could not do with their >> own use of javac/java" (which we have yet to have validated) then if the >> SharedSecrets use in JShell requires the change to the module.info.java in >> java.base to add jdk.jshell, then that would be a violation. >> >> If this changeset gave access only to snippets executing via the JShell >> API maybe that would be OK. But it, as your exploit verifies, could easily >> be used by anyone to change module boundaries. >> >> Maybe there would be a hack that would allow only proper JShell use, but >> I don't see what that would be, and that sounds dangerous and unappealing. >> >> Command-line option only would match the original request and other >> tools. The implementation would closely match the implementation of '-R', >> being on the command-line of JShellTool and the API in JShell.Builder. >> Alas, this is mostly a rewrite, only some code in TaskFactory, >> ToolBasicTest, and maybe KullaTesting would be reusable. >> >> Bummer! >> >> But thanks for catching this Jan! >> >> -Robert >> >> >> >> On 09/12/16 14:12, Jan Lahoda wrote: >> >>> (Basically, the use of SharedSecrets in jdk.jshell seems highly >>> suspicious to me.) >>> >>> Jan >>> >>> On 12.9.2016 23:05, Jan Lahoda wrote: >>> >>>> On 12.9.2016 20:06, Robert Field wrote: >>>> >>>>> The jshell tool is built on the JShell API. Command-line options, like >>>>> -R, pass to the remote process via the JShell API. -R would allow >>>>> --patch-module or --add-exports. Having addExports functionality >>>>> >>>> >>>> I am not much worried about --add-exports added using -R, that seems OK >>>> to me. This only affects a newly spawned JVM, and the API client could >>>> spawn it even without JShell, so not a problem IMO. >>>> >>>> What I am worried about is that using the most recent proposed patch >>>> (lwebrev.04.langtools), one can use the DirectExecutionControl to change >>>> module boundaries in the _currently running VM_. Please see the attached >>>> class to see what I mean - I didn't even have to create JShell as such, >>>> simply using DirectExecutionControl was enough. It probably does not >>>> even need some special privileges to achieve the result. >>>> >>>> Jan >>>> >>>> anywhere is jshell means having it in the JShell API. >>>>> >>>>> I believe this cycles us, to some degree, back to the security >>>>> discussion. What is our level of concern about a launched process >>>>> running pure JDK code? >>>>> >>>>> -Robert >>>>> >>>>> On 09/12/16 09:57, Jan Lahoda wrote: >>>>> >>>>>> [adding Jon] >>>>>> >>>>>> On 12.9.2016 17:31, Robert Field wrote: >>>>>> >>>>>>> Both javac and java have a --add-exports option, so it isn't opening >>>>>>> anything that isn't already open. >>>>>>> I don't see how command-line options are any different that API in >>>>>>> terms >>>>>>> of exposure. >>>>>>> >>>>>> >>>>>> I think there's a huge difference between command line and an API, in >>>>>> at least two aspects: >>>>>> a) the person that controls the command line, has a lot of power in >>>>>> any case (they could do -Xbootclasspath/p: in 8 or --patch-module now >>>>>> to get around the boundaries). API users are much more restricted in >>>>>> what they can do. >>>>>> b) affecting the command line options is generally very hard - imagine >>>>>> library maintainers - how can they affect the command line setting? >>>>>> The only thing they can do is to write some documentation, but they >>>>>> cannot directly affect the command line. But they can call an API (and >>>>>> they can call it even reflectively). >>>>>> >>>>>> I believe it is generally undesirable to create APIs that allow to >>>>>> create holes in module boundaries. If you think that's something >>>>>> JShell needs, I think we need to take that to the Jigsaw team. >>>>>> >>>>>> Jan >>>>>> >>>>>> >>>>>>> -Robert >>>>>>> >>>>>>> >>>>>>> On 09/11/16 13:17, Jan Lahoda wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I apologize for not following this sooner. >>>>>>>> >>>>>>>> Looking at this, it seems to me the change would effectively allow >>>>>>>> to >>>>>>>> overcome the module boundary limitations using JShell - I don't >>>>>>>> think >>>>>>>> that's something that would be acceptable. We could take this to the >>>>>>>> Jigsaw team, but I don't think they would be happy about this. >>>>>>>> >>>>>>>> I wonder what exactly is the usecase here. Would it be sufficient if >>>>>>>> the jshell tool as such would allow command line options to break >>>>>>>> through the boundaries? We already have -R, which should allow to >>>>>>>> make >>>>>>>> holes to the boundaries when running the snippets, so maybe we just >>>>>>>> need to add something for compile-time? >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>>> On 11.9.2016 02:12, ShinyaYoshida wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> Please apply this webrev: >>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.jdk/ >>>>>>>>> >>>>>>>> 00.jdk/> >>>>>>>>> Changing module-info is needed. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>> >>>>>>>>> 2016-09-10 7:51 GMT+09:00 Robert Field >>>>>>>> >: >>>>>>>>> >>>>>>>>> [audience reduced] >>>>>>>>> >>>>>>>>> BTW shinyafox, >>>>>>>>> >>>>>>>>> Building "make images" with this patch and the latest jdk9/dev >>>>>>>>> bits >>>>>>>>> fails. Probably need to change module set-up -- >>>>>>>>> >>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>> xecution/DirectExecutionControl.java:33: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> error: package jdk.internal.misc does not exist >>>>>>>>> import jdk.internal.misc.JavaLangReflectModuleAccess; >>>>>>>>> ^ >>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>> xecution/DirectExecutionControl.java:34: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> error: package jdk.internal.misc does not exist >>>>>>>>> import jdk.internal.misc.SharedSecrets; >>>>>>>>> ^ >>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>> xecution/DirectExecutionControl.java:155: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> error: cannot find symbol >>>>>>>>> JavaLangReflectModuleAccess moduleAccess = >>>>>>>>> SharedSecrets.getJavaLangReflectModuleAccess(); >>>>>>>>> ^ >>>>>>>>> symbol: class JavaLangReflectModuleAccess >>>>>>>>> location: class DirectExecutionControl >>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>> xecution/DirectExecutionControl.java:155: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> error: cannot find symbol >>>>>>>>> JavaLangReflectModuleAccess moduleAccess = >>>>>>>>> SharedSecrets.getJavaLangReflectModuleAccess(); >>>>>>>>> ^ >>>>>>>>> symbol: variable SharedSecrets >>>>>>>>> location: class DirectExecutionControl >>>>>>>>> 4 errors >>>>>>>>> >>>>>>>>> -Robert >>>>>>>>> >>>>>>>>> >>>>>>>>> On 09/08/16 07:14, ShinyaYoshida wrote: >>>>>>>>> >>>>>>>>>> Hi Robert, >>>>>>>>>> Thank you for your pointing out. >>>>>>>>>> I've understood. >>>>>>>>>> >>>>>>>>>> Here is new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>> 4.langtools/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> v.04.langtools/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In this version, >>>>>>>>>> - ExecutionControl#addExports throws BadArgumentException >>>>>>>>>> which is >>>>>>>>>> extends ExecutionControlException if module or package are not >>>>>>>>>> found. >>>>>>>>>> - JShell#addExports throws IllegalArgumentException when >>>>>>>>>> BadArgumentException is occured >>>>>>>>>> >>>>>>>>>> I've notice that /classpath and addToClasspath says nothing >>>>>>>>>> when >>>>>>>>>> it doesn't exist. >>>>>>>>>> I think it should be reported, so I've created a issue: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165650 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What do you think? >>>>>>>>>> >>>>>>>>>> Please review me again! >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-09-08 4:25 GMT+09:00 Robert Field < >>>>>>>>>> robert.field at oracle.com >>>>>>>>>> >: >>>>>>>>>> >>>>>>>>>> Thanks for the update. >>>>>>>>>> >>>>>>>>>> l10n.properties -- >>>>>>>>>> >>>>>>>>>> Oops, typo: the help.set.exports entry got pasted again >>>>>>>>>> instead of help.retain.exports >>>>>>>>>> >>>>>>>>>> Sorry I was unclear about the exceptions... >>>>>>>>>> >>>>>>>>>> On the execution side -- >>>>>>>>>> >>>>>>>>>> ExecutionControl.InternalException is only for unexpected >>>>>>>>>> failures. >>>>>>>>>> >>>>>>>>>> In this case you are dealing an expected exception that >>>>>>>>>> occurs >>>>>>>>>> when the user gives the wrong input. None of the existing >>>>>>>>>> ExecutionControlException subclasses are good candidates, >>>>>>>>>> so a >>>>>>>>>> new ExecutionControlException subclass is needed. I was >>>>>>>>>> suggesting "BadArgumentException" for this exception. >>>>>>>>>> None of >>>>>>>>>> ExecutionControlException subclasses are seen at the >>>>>>>>>> JShell >>>>>>>>>> level -- this should be the case for this new one as well. >>>>>>>>>> >>>>>>>>>> I don't what kind of exceptions are thrown by >>>>>>>>>> moduleAccess.addExportsToAllUnnamed(target, pack), but >>>>>>>>>> that >>>>>>>>>> message text or some other appropriate descriptive message >>>>>>>>>> text needs to be placed in the BadArgumentException >>>>>>>>>> message so >>>>>>>>>> it can be seen all the way up (including the JShellTool). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On the JShell class -- >>>>>>>>>> >>>>>>>>>> Incorrect arguments on JShell API methods generate the >>>>>>>>>> Java >>>>>>>>>> standard java.lang.IllegalArgumentException (see, for >>>>>>>>>> example, >>>>>>>>>> drop() or status() ) -- so, this is also the appropriate >>>>>>>>>> exception for JShell.addExports(). Thus, >>>>>>>>>> JShell.addExports() >>>>>>>>>> catchs the BadArgumentException, turning it into an >>>>>>>>>> IllegalArgumentException. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Robert >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 09/07/16 06:10, ShinyaYoshida wrote: >>>>>>>>>> >>>>>>>>>>> Hi Robert, >>>>>>>>>>> Thank you for your helping. >>>>>>>>>>> >>>>>>>>>>> I've update webrev according to your comments. >>>>>>>>>>> If I'm missing your meaning, I'm sorry. Please point it. >>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>> 3.langtools/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> v.03.langtools/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Now, >>>>>>>>>>> - JShell#addExports will throw BadArgumentException when >>>>>>>>>>> module or package is wrong, which is check exception. >>>>>>>>>>> - JShellTool checks that exception. >>>>>>>>>>> - ExecutionControl#addExports throws InternalException >>>>>>>>>>> when >>>>>>>>>>> something is wrong. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2016-09-06 6:28 GMT+09:00 Robert Field >>>>>>>>>>> >>>>>>>>>> >>: >>>>>>>>>>> >>>>>>>>>>> Code looks good. Needs docs I promised (see below). >>>>>>>>>>> >>>>>>>>>>> As to completion issue you created, I see you already >>>>>>>>>>> added discussion and tests. I added your completion >>>>>>>>>>> code. >>>>>>>>>>> >>>>>>>>>>> Below is my suggested doc... >>>>>>>>>>> >>>>>>>>>>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> /set exports \n\t\ >>>>>>>>>>> Allow access to some of the unexported types of >>>>>>>>>>> a >>>>>>>>>>> module\n\n\ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /retain exports \n\t\ >>>>>>>>>>> Allow access to some of the unexported types of >>>>>>>>>>> a >>>>>>>>>>> module\n\n\ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> help.set.exports=\ >>>>>>>>>>> Set a package to add to those exported to >>>>>>>>>>> snippets.\n\ >>>>>>>>>>> \n\t\ >>>>>>>>>>> /set exports \n\ >>>>>>>>>>> \n\ >>>>>>>>>>> Where is the module from which to export >>>>>>>>>>> .\n\ >>>>>>>>>>> Where is the package to export to >>>>>>>>>>> snippets.\n >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> help.retain.exports=\ >>>>>>>>>>> Retain a package to add to those exported to >>>>>>>>>>> snippets.\n\ >>>>>>>>>>> \n\t\ >>>>>>>>>>> /retain exports \n\ >>>>>>>>>>> \n\ >>>>>>>>>>> Where is the module from which to export >>>>>>>>>>> .\n\ >>>>>>>>>>> Where is the package to export to >>>>>>>>>>> snippets.\n >>>>>>>>>>> >>>>>>>>>>> [I notice that 'snippet' is used in doc without being >>>>>>>>>>> defined. If, while you are it, you change the help >>>>>>>>>>> for >>>>>>>>>>> /list to define it:] >>>>>>>>>>> >>>>>>>>>>> help.list =\ >>>>>>>>>>> Show the source of snippets, prefaced with the >>>>>>>>>>> snippet id >>>>>>>>>>> (a snippet is a chunk of code that the jshell tool >>>>>>>>>>> evaluates -- the code you enter at the prompt is a >>>>>>>>>>> snippet).\n\ >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/JShell.java -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /** >>>>>>>>>>> * Add a package to those exported to snippets. >>>>>>>>>>> * @param module The module from which to export >>>>>>>>>>> * @param pack The package to export >>>>>>>>>>> * @throws NullPointerException if arguments are >>>>>>>>>>> null. >>>>>>>>>>> * @throws IllegalStateException if this {@code >>>>>>>>>>> JShell} instance is closed. >>>>>>>>>>> * @throws XYZ if .... >>>>>>>>>>> */ >>>>>>>>>>> >>>>>>>>>>> OK, actually this code should change. Like >>>>>>>>>>> addToClasspath above it, it should return void. It >>>>>>>>>>> looks >>>>>>>>>>> like under normal operation it can fail -- the >>>>>>>>>>> failure >>>>>>>>>>> should be reported with an exception. >>>>>>>>>>> What are the failure modes? IllegalArgumentException >>>>>>>>>>> would be likely choice at the JShell API layer. But >>>>>>>>>>> then >>>>>>>>>>> the exception needs to be propagated there. >>>>>>>>>>> Since none of the existing exceptions is a match, >>>>>>>>>>> this >>>>>>>>>>> means a new ExecutionControlException. Maybe >>>>>>>>>>> something >>>>>>>>>>> general, like BadUserArgumentException. >>>>>>>>>>> Note: I've also added IllegalStateException -- this >>>>>>>>>>> can >>>>>>>>>>> be thrown when you get EngineTerminationException. >>>>>>>>>>> Also, typo, the second "module cannot be null" >>>>>>>>>>> should be >>>>>>>>>>> "package cannot be null" >>>>>>>>>>> >>>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteCodes.java >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> The comment you have is fine. Just remove PLEASE >>>>>>>>>>> REVISE >>>>>>>>>>> THE COMMENT >>>>>>>>>>> >>>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl >>>>>>>>>>> .java >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> /** >>>>>>>>>>> * Add a package to those exported to snippets. >>>>>>>>>>> * @param module The module from which to export >>>>>>>>>>> * @param pack The package to export >>>>>>>>>>> * @throws EngineTerminationException the >>>>>>>>>>> execution >>>>>>>>>>> engine has terminated >>>>>>>>>>> * @throws .... >>>>>>>>>>> * @throws InternalException an internal problem >>>>>>>>>>> occurred >>>>>>>>>>> */ >>>>>>>>>>> >>>>>>>>>>> Plus add the bad argument exception. >>>>>>>>>>> Whatever it is, should be added to extensionCommand() >>>>>>>>>>> exceptions. >>>>>>>>>>> >>>>>>>>>>> Robert >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 09/05/16 08:02, ShinyaYoshida wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> I've update webrev of langtools: >>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>> 2.langtools/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> v.02.langtools/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I added an issue for the completion feature. >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165445 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>> >>>>>>>>>>>> 2016-09-05 22:49 GMT+09:00 ShinyaYoshida >>>>>>>>>>>> >>>>>>>>>>> >>: >>>>>>>>>>>> >>>>>>>>>>>> Hi Robert, >>>>>>>>>>>> Thank you for the review. >>>>>>>>>>>> >>>>>>>>>>>> I totally agree with you. >>>>>>>>>>>> I also think that availableModules and >>>>>>>>>>>> availablePackages(module) are worthless >>>>>>>>>>>> excepting >>>>>>>>>>>> for the command completion feature. >>>>>>>>>>>> I'd like to avoid adding these APIs which have >>>>>>>>>>>> not >>>>>>>>>>>> been speculated and revised because if API is >>>>>>>>>>>> once >>>>>>>>>>>> added, it is too difficult to remove than >>>>>>>>>>>> adding. >>>>>>>>>>>> >>>>>>>>>>>> So currently, I'll remove the completion feature >>>>>>>>>>>> for >>>>>>>>>>>> /set or /retain exports and make the issue to >>>>>>>>>>>> JBS to >>>>>>>>>>>> add completion feature for them in future. >>>>>>>>>>>> >>>>>>>>>>>> I'll update the webrev. So please review it >>>>>>>>>>>> again >>>>>>>>>>>> later. >>>>>>>>>>>> When the silently evaluation feature is added, >>>>>>>>>>>> I'd >>>>>>>>>>>> like to work for the completion feature again. >>>>>>>>>>>> >>>>>>>>>>>> Thank you, >>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2016-09-05 15:00 GMT+09:00 Robert Field >>>>>>>>>>>> >>>>>>>>>>> >: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 09/03/16 05:07, ShinyaYoshida wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> I've updated my patch, new webrev is here: >>>>>>>>>>>>> webrev.01.langtools: >>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>> 1.langtools/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> v.01.langtools/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> webrev.01.jdk: >>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>> 1.jdk/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> v.01.jdk/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (Same as previous) >>>>>>>>>>>>> >>>>>>>>>>>>> In this version, >>>>>>>>>>>>> - rename /set add-exports to /set exports >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> OK >>>>>>>>>>>> >>>>>>>>>>>> - add /retain exports >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The /retain implementation looks good. >>>>>>>>>>>> >>>>>>>>>>>> - add tests >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Well tested >>>>>>>>>>>> >>>>>>>>>>>> - move EXT_CMD_XXX into RemoteCodes >>>>>>>>>>>>> - make RemoteCodes public and move it into >>>>>>>>>>>>> jdk.jshell.execution.code which is >>>>>>>>>>>>> module-private >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> So, here, in addition to addExports, there >>>>>>>>>>>> are >>>>>>>>>>>> two more methods added to the API >>>>>>>>>>>> availableModules() and >>>>>>>>>>>> availablePackage(String >>>>>>>>>>>> module). >>>>>>>>>>>> I see how in rare cases they could be >>>>>>>>>>>> useful. >>>>>>>>>>>> And the rare case that causes them to be >>>>>>>>>>>> present >>>>>>>>>>>> is for command completion in the tool. >>>>>>>>>>>> What are the options: >>>>>>>>>>>> >>>>>>>>>>>> (1) Add them to the API. If it is in the >>>>>>>>>>>> API >>>>>>>>>>>> then it is a first-class form of >>>>>>>>>>>> functionality >>>>>>>>>>>> and should be treated as such in execution >>>>>>>>>>>> support (as a command) >>>>>>>>>>>> (2) Not support them and not support >>>>>>>>>>>> command >>>>>>>>>>>> completion for /set exports. Command >>>>>>>>>>>> completion >>>>>>>>>>>> is not supported in much more common cases. >>>>>>>>>>>> Then we could support command completion in >>>>>>>>>>>> the >>>>>>>>>>>> future (see (3)). >>>>>>>>>>>> (3) What these commands do is simply >>>>>>>>>>>> execute >>>>>>>>>>>> an expression on the remote side. But we >>>>>>>>>>>> already have a mechanism to execute >>>>>>>>>>>> expressions >>>>>>>>>>>> on the remote side: Snippets. >>>>>>>>>>>> That leaves a problem: we wouldn't >>>>>>>>>>>> want >>>>>>>>>>>> these Snippets to be seen by the user, but >>>>>>>>>>>> we >>>>>>>>>>>> have a solution for that the tool uses the >>>>>>>>>>>> idGenerator. >>>>>>>>>>>> Another problem is that, by default >>>>>>>>>>>> and >>>>>>>>>>>> with no current way around the default, >>>>>>>>>>>> expressions generate temp-variables. My >>>>>>>>>>>> intention was to make this configurable -- >>>>>>>>>>>> see >>>>>>>>>>>> Eval.shouldGenTempVar(...). >>>>>>>>>>>> >>>>>>>>>>>> One goal I've been using in the design of >>>>>>>>>>>> the >>>>>>>>>>>> API is to keep it as small and simple as >>>>>>>>>>>> possible. This improves maintainability, but >>>>>>>>>>>> much more importantly makes the API easier >>>>>>>>>>>> to >>>>>>>>>>>> learn and use. >>>>>>>>>>>> So, for something to warrant inclusion it >>>>>>>>>>>> should >>>>>>>>>>>> be generally useful and have no other way of >>>>>>>>>>>> being achieved -- neither is true of these >>>>>>>>>>>> two >>>>>>>>>>>> queries. >>>>>>>>>>>> >>>>>>>>>>>> My suggestion, particularly in light of how >>>>>>>>>>>> late >>>>>>>>>>>> in the release this is, would be (2). >>>>>>>>>>>> Thoughts? >>>>>>>>>>>> >>>>>>>>>>>> -Robert >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>> >>>>>>>>>>>>> 2016-09-03 18:15 GMT+09:00 ShinyaYoshida >>>>>>>>>>>>> >>>>>>>>>>>> >: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>> Thank you for reviewing. >>>>>>>>>>>>> I'll update my patch later. >>>>>>>>>>>>> >>>>>>>>>>>>> 2016-09-02 11:38 GMT+09:00 Robert Field >>>>>>>>>>>>> >>>>>>>>>>>> >: >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks shiyafox! This is a >>>>>>>>>>>>> significant >>>>>>>>>>>>> piece of code! >>>>>>>>>>>>> >>>>>>>>>>>>> As to your questions -- >>>>>>>>>>>>> >>>>>>>>>>>>> > I wonder if you could work on the >>>>>>>>>>>>> documentation of the API and the >>>>>>>>>>>>> tool >>>>>>>>>>>>> instead? >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, I will do API and tool docs. >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you! >>>>>>>>>>>>> >>>>>>>>>>>>> > Subcommand of /set is reasonable? >>>>>>>>>>>>> Similar command, /classpath, to >>>>>>>>>>>>> make >>>>>>>>>>>>> users available to use new >>>>>>>>>>>>> packages is >>>>>>>>>>>>> not a subcommand of /set. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, I think /set exports is best. >>>>>>>>>>>>> And, yes, /classpath is >>>>>>>>>>>>> inconsistent, >>>>>>>>>>>>> it should be /set classpath, that >>>>>>>>>>>>> can >>>>>>>>>>>>> be a separate task, unless you >>>>>>>>>>>>> want to >>>>>>>>>>>>> roll that in. >>>>>>>>>>>>> >>>>>>>>>>>>> I see, I've created the issue to move >>>>>>>>>>>>> /classpath to /set classpath: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165405 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > Should we need retain feature to >>>>>>>>>>>>> this? >>>>>>>>>>>>> >>>>>>>>>>>>> All /set have a /retain >>>>>>>>>>>>> counterpart -- >>>>>>>>>>>>> we should maintain that >>>>>>>>>>>>> >>>>>>>>>>>>> Ok, I'll add /retain exports. >>>>>>>>>>>>> I've also create the issue for >>>>>>>>>>>>> retaining >>>>>>>>>>>>> classpath: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165406 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> As to the code review: Looks good >>>>>>>>>>>>> to >>>>>>>>>>>>> me, just minor questions/issues -- >>>>>>>>>>>>> >>>>>>>>>>>>> JShellTool.java: >>>>>>>>>>>>> >>>>>>>>>>>>> * As discussed /set add-exports => >>>>>>>>>>>>> /set >>>>>>>>>>>>> exports >>>>>>>>>>>>> >>>>>>>>>>>>> * Nit: a comment got moved out of >>>>>>>>>>>>> place >>>>>>>>>>>>> line 1194(old) >>>>>>>>>>>>> >>>>>>>>>>>>> JShell.java: >>>>>>>>>>>>> >>>>>>>>>>>>> * EXT_CMD_AVAILABLE_MODULES and >>>>>>>>>>>>> EXT_CMD_AVAILABLE_PACKAGES, these >>>>>>>>>>>>> should be referenced via >>>>>>>>>>>>> RemoteCodes.java rather than be >>>>>>>>>>>>> coped. >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely! I'd like to move these into >>>>>>>>>>>>> RemoteCodes but it is package-private >>>>>>>>>>>>> class >>>>>>>>>>>>> and cannot be referred from JShell. >>>>>>>>>>>>> Can I make RemoteCodes public and move >>>>>>>>>>>>> it >>>>>>>>>>>>> to another module-private package like >>>>>>>>>>>>> jdk.jshell.execution.code? >>>>>>>>>>>>> >>>>>>>>>>>>> * Which leads me to another >>>>>>>>>>>>> question: >>>>>>>>>>>>> why is addExports a command and >>>>>>>>>>>>> these >>>>>>>>>>>>> two are extensions. It seems fine, >>>>>>>>>>>>> just >>>>>>>>>>>>> curious. I notice that extensions >>>>>>>>>>>>> are a >>>>>>>>>>>>> lot less code -- ;-) >>>>>>>>>>>>> >>>>>>>>>>>>> Exporting module and package is >>>>>>>>>>>>> similar to >>>>>>>>>>>>> adding classpath to platform, so I made >>>>>>>>>>>>> the >>>>>>>>>>>>> addExports a command like setClasspath. >>>>>>>>>>>>> And it should be added as API because >>>>>>>>>>>>> it is >>>>>>>>>>>>> very basic feature. >>>>>>>>>>>>> >>>>>>>>>>>>> TaskFactory.java: >>>>>>>>>>>>> >>>>>>>>>>>>> * Question: the "/" separator >>>>>>>>>>>>> between >>>>>>>>>>>>> module and package is that platform >>>>>>>>>>>>> independent? >>>>>>>>>>>>> >>>>>>>>>>>>> It seems to me that "{module}/{path}" >>>>>>>>>>>>> format for --add-exports option of >>>>>>>>>>>>> javac is >>>>>>>>>>>>> platform independent. >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> DefaultLoaderDelegate.java: >>>>>>>>>>>>> >>>>>>>>>>>>> * Jan, can you look at this code? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -Robert >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 09/01/16 05:36, ShinyaYoshida >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> I've implemented this feature >>>>>>>>>>>>> to >>>>>>>>>>>>> JShell API and Tool with full >>>>>>>>>>>>> completion: >>>>>>>>>>>>> Bugs: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8154714 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> jdk: >>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>> 0.jdk/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> v.00.jdk/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> v.00.jdk/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> v.00.jdk/>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> langtools: >>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>> 0.langtools/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> v.00.langtools/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> v.00.langtools/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> v.00.langtools/>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This is missing the train of >>>>>>>>>>>>> Java >>>>>>>>>>>>> 9.0 but it could catch the >>>>>>>>>>>>> train of >>>>>>>>>>>>> Java 9.1 or later. >>>>>>>>>>>>> I want to get your comments for >>>>>>>>>>>>> this. >>>>>>>>>>>>> >>>>>>>>>>>>> jshell> /set add-exports >>>>>>>>>>>>> jdk.jconsole sun.tools.jconsole >>>>>>>>>>>>> >>>>>>>>>>>>> jshell> import >>>>>>>>>>>>> sun.tools.jconsole.* >>>>>>>>>>>>> >>>>>>>>>>>>> jshell> >>>>>>>>>>>>> LocalVirtualMachine.getAllVirtualMachines().forEach((k, >>>>>>>>>>>>> v) -> System.out.println(k + >>>>>>>>>>>>> ":" >>>>>>>>>>>>> + v)) >>>>>>>>>>>>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>>>>>>>>>>>> 10826:jdk.jshell.execution.RemoteExecutionControl >>>>>>>>>>>>> 35548 >>>>>>>>>>>>> 28447:org.netbeans.Main --cachedir >>>>>>>>>>>>> /home/bitter_fox/.cache/netbeans/8.0.1 >>>>>>>>>>>>> --userdir >>>>>>>>>>>>> /home/bitter_fox/.netbeans/8.0.1 >>>>>>>>>>>>> --branding nb >>>>>>>>>>>>> >>>>>>>>>>>>> Currently, there is no >>>>>>>>>>>>> testing, so >>>>>>>>>>>>> it will be required to add >>>>>>>>>>>>> test. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >> > > From robert.field at oracle.com Thu Sep 22 23:47:14 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 22 Sep 2016 16:47:14 -0700 Subject: JShell: result truncation In-Reply-To: <796e2acd-5da4-85a5-a188-f2935ea62300@oracle.com> References: <57E3310A.7050504@oracle.com> <74883988-E12D-41C2-AF83-2DE3A98ECFDE@oracle.com> <796e2acd-5da4-85a5-a188-f2935ea62300@oracle.com> Message-ID: <57E46D82.3020802@oracle.com> [Was: Re: JShell: representation of array values] John, Jon, Thanks for the comments. Some context is needed. This is the JShell stack (a prettier, more detailed view attached): jshell tool -- JShell API -- JShell core implementation -- JShell SPI -- JShell execution engine Returned execution values, through both interfaces, and thus in the core implementation and tool are Strings. The execution engine is charged with translating returned values into a String representation. This is where the work to provide a better representation of arrays was done. No truncation is done (for any kind of value) at the execution engine level. Truncation is done only in the tool. And it is configurable. See /help output below. I don't want to push configurable truncation through all those layers. So, we are stuck with truncation being stupid (not in terms of context) in terms of the kind of value it is truncating. Truncation is operating on Strings for which it knows nothing of their structure or content. They might be a long String, List, or ... That said, it better for whatever the truncated thing is to have a bit of terminal context. A String: "abcdefg ... xyz" A List: [1, 2, 3, 4, ... 999] An array: boolean[233] { false, false, false, false, f ... se } So, there could be a length of termination context argument. -Robert jshell> /help /set truncation | Set the max length a displayed value. | | /set truncation ... | | Where is the name of a previously defined feedback mode -- see '/help /set mode'. | Where is an unsigned integer representing a maximum length. | Where is only needed if you wish to fine-tune value truncation length | by context, is the context in which the truncation is applied. | The structure of selector is a hyphen separated list of selector kind lists. | A selector kind list is a comma separated list of values of one selector kind. | A selector matches if each selector kind list matches; A selector kind list | matches if one of the values matches. | | Below are the relevant selector kinds for truncation. | | The case selector kind describes the kind of snippet. The values are: | vardecl -- variable declaration without init | varinit -- variable declaration with init | expression -- expression -- note: {name}==scratch-variable-name | varvalue -- variable value expression | assignment -- assign variable | The action selector kind describes what happened to the snippet. The values are: | added -- snippet has been added | modified -- an existing snippet has been modified | replaced -- an existing snippet has been replaced with a new snippet | Examples: | /set trunc mymode 80 | /set truncation mymode 45 expression | /set truncation mymode 0 vardecl-modified,replaced | | Note that subsequent selectors for a field may overwrite some or all of previous used selectors -- last one wins On 09/22/16 10:42, Jonathan Gibbons wrote: > In the long array case, I'd suggest to hide the middle, not the end of > the array. Show the first "few" entries and the last "few" entries in > the array, for some value of "few". > > -- Jon > > > On 9/22/16 10:37 AM, John Rose wrote: >> On Sep 21, 2016, at 6:16 PM, Robert Field >> wrote: >>> Comments??? >> Another +1 from me. Some comments from my inner Common Lisper: >> >> There should be a close brace after the "?" of an overlong array. >> This will allow syntax sensitive editors (emacs!) to block the thing >> correctly. >> >> The cutoff length of the overlong array should be a configurable number. >> >> You might consider a configurable cutoff for printed nesting level. >> >> These ideas from from this section of the CL manual: >> >> http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node193.html#LEVELLENGTHTABLE >> >> >> There is also an option called *print-array* which gates whether >> arrays should be expanded at all. >> This is relevant to Java, which also distinguishes Arrays.toString >> from Object.toString. >> >> ? John > From john.r.rose at oracle.com Fri Sep 23 00:00:21 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 22 Sep 2016 17:00:21 -0700 Subject: JShell: result truncation In-Reply-To: <57E46D82.3020802@oracle.com> References: <57E3310A.7050504@oracle.com> <74883988-E12D-41C2-AF83-2DE3A98ECFDE@oracle.com> <796e2acd-5da4-85a5-a188-f2935ea62300@oracle.com> <57E46D82.3020802@oracle.com> Message-ID: On Sep 22, 2016, at 4:47 PM, Robert Field wrote: > > I don't want to push configurable truncation through all those layers. So, we are stuck with truncation being stupid (not in terms of context) in terms of the kind of value it is truncating. > Truncation is operating on Strings for which it knows nothing of their structure or content. > They might be a long String, List, or ... > > That said, it better for whatever the truncated thing is to have a bit of terminal context. Yes, that seems fine to me. ? John From jonathan.gibbons at oracle.com Fri Sep 23 00:18:59 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 22 Sep 2016 17:18:59 -0700 Subject: JShell: result truncation In-Reply-To: <57E46D82.3020802@oracle.com> References: <57E3310A.7050504@oracle.com> <74883988-E12D-41C2-AF83-2DE3A98ECFDE@oracle.com> <796e2acd-5da4-85a5-a188-f2935ea62300@oracle.com> <57E46D82.3020802@oracle.com> Message-ID: <57E474F3.8050203@oracle.com> Robert, Thanks for the update. Making the truncation only work on strings seems reasonable. But (given we're dealing with strings) it might still be nice to see if there is some whitespace or punctuation near the truncation point. Or would that be "too clever for its own good"? In a very separate context, jtreg uses the algorithm of a max string length, and then in the case of a long string, it shows 2/3 of that amount from the beginning of the string, and the remaining 1/3 of that amount from the end of the string. -- Jon On 09/22/2016 04:47 PM, Robert Field wrote: > [Was: Re: JShell: representation of array values] > > John, Jon, > > Thanks for the comments. Some context is needed. This is the JShell > stack (a prettier, more detailed view attached): > > jshell tool > -- JShell API -- > JShell core implementation > -- JShell SPI -- > JShell execution engine > > Returned execution values, through both interfaces, and thus in the > core implementation and tool are Strings. > The execution engine is charged with translating returned values into > a String representation. This is where the work to provide a better > representation of arrays was done. > No truncation is done (for any kind of value) at the execution engine > level. > > Truncation is done only in the tool. And it is configurable. See > /help output below. > > I don't want to push configurable truncation through all those > layers. So, we are stuck with truncation being stupid (not in terms > of context) in terms of the kind of value it is truncating. > Truncation is operating on Strings for which it knows nothing of their > structure or content. > They might be a long String, List, or ... > > That said, it better for whatever the truncated thing is to have a bit > of terminal context. > > A String: > > "abcdefg ... xyz" > > A List: > > [1, 2, 3, 4, ... 999] > > An array: > > boolean[233] { false, false, false, false, f ... se } > > So, there could be a length of termination context argument. > > -Robert > > > jshell> /help /set truncation > | Set the max length a displayed value. > | > | /set truncation ... > | > | Where is the name of a previously defined feedback mode -- > see '/help /set mode'. > | Where is an unsigned integer representing a maximum length. > | Where is only needed if you wish to fine-tune value > truncation length > | by context, is the context in which the truncation is > applied. > | The structure of selector is a hyphen separated list of selector > kind lists. > | A selector kind list is a comma separated list of values of one > selector kind. > | A selector matches if each selector kind list matches; A selector > kind list > | matches if one of the values matches. > | > | Below are the relevant selector kinds for truncation. > | > | The case selector kind describes the kind of snippet. The values are: > | vardecl -- variable declaration without init > | varinit -- variable declaration with init > | expression -- expression -- note: {name}==scratch-variable-name > | varvalue -- variable value expression > | assignment -- assign variable > | The action selector kind describes what happened to the > snippet. The values are: > | added -- snippet has been added > | modified -- an existing snippet has been modified > | replaced -- an existing snippet has been replaced with a new > snippet > | Examples: > | /set trunc mymode 80 > | /set truncation mymode 45 expression > | /set truncation mymode 0 vardecl-modified,replaced > | > | Note that subsequent selectors for a field may overwrite some or > all of previous used selectors -- last one wins > > > > On 09/22/16 10:42, Jonathan Gibbons wrote: >> In the long array case, I'd suggest to hide the middle, not the end >> of the array. Show the first "few" entries and the last "few" >> entries in the array, for some value of "few". >> >> -- Jon >> >> >> On 9/22/16 10:37 AM, John Rose wrote: >>> On Sep 21, 2016, at 6:16 PM, Robert Field >>> wrote: >>>> Comments??? >>> Another +1 from me. Some comments from my inner Common Lisper: >>> >>> There should be a close brace after the "?" of an overlong array. >>> This will allow syntax sensitive editors (emacs!) to block the thing >>> correctly. >>> >>> The cutoff length of the overlong array should be a configurable >>> number. >>> >>> You might consider a configurable cutoff for printed nesting level. >>> >>> These ideas from from this section of the CL manual: >>> >>> http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node193.html#LEVELLENGTHTABLE >>> >>> >>> There is also an option called *print-array* which gates whether >>> arrays should be expanded at all. >>> This is relevant to Java, which also distinguishes Arrays.toString >>> from Object.toString. >>> >>> ? John >> > From robert.field at oracle.com Fri Sep 23 20:18:31 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 23 Sep 2016 13:18:31 -0700 Subject: RFR (xs) 8166589: jshell tool: typo: remove out of place text in /help /set truncation Message-ID: <57E58E17.8000902@oracle.com> Please review -- Bug: https://bugs.openjdk.java.net/browse/JDK-8166589 Webrev: http://cr.openjdk.java.net/~rfield/8166589v0.webrev/ Thanks, Robert From robert.field at oracle.com Fri Sep 23 20:26:35 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 23 Sep 2016 13:26:35 -0700 Subject: JShell: result truncation In-Reply-To: <57E474F3.8050203@oracle.com> References: <57E3310A.7050504@oracle.com> <74883988-E12D-41C2-AF83-2DE3A98ECFDE@oracle.com> <796e2acd-5da4-85a5-a188-f2935ea62300@oracle.com> <57E46D82.3020802@oracle.com> <57E474F3.8050203@oracle.com> Message-ID: <57E58FFB.5050803@oracle.com> On 09/22/16 17:18, Jonathan Gibbons wrote: > Robert, > > Thanks for the update. Making the truncation only work on strings > seems reasonable. But (given we're dealing with strings) it might > still be nice to see if there is some whitespace or punctuation near > the truncation point. Or would that be "too clever for its own good"? Probably ;-) > > In a very separate context, jtreg uses the algorithm of a max string > length, and then in the case of a long string, it shows 2/3 of that > amount from the beginning of the string, and the remaining 1/3 of that > amount from the end of the string. I've created: https://bugs.openjdk.java.net/browse/JDK-8166637 Thanks, Robert > > -- Jon > > > On 09/22/2016 04:47 PM, Robert Field wrote: >> [Was: Re: JShell: representation of array values] >> >> John, Jon, >> >> Thanks for the comments. Some context is needed. This is the JShell >> stack (a prettier, more detailed view attached): >> >> jshell tool >> -- JShell API -- >> JShell core implementation >> -- JShell SPI -- >> JShell execution engine >> >> Returned execution values, through both interfaces, and thus in the >> core implementation and tool are Strings. >> The execution engine is charged with translating returned values into >> a String representation. This is where the work to provide a better >> representation of arrays was done. >> No truncation is done (for any kind of value) at the execution engine >> level. >> >> Truncation is done only in the tool. And it is configurable. See >> /help output below. >> >> I don't want to push configurable truncation through all those >> layers. So, we are stuck with truncation being stupid (not in terms >> of context) in terms of the kind of value it is truncating. >> Truncation is operating on Strings for which it knows nothing of >> their structure or content. >> They might be a long String, List, or ... >> >> That said, it better for whatever the truncated thing is to have a >> bit of terminal context. >> >> A String: >> >> "abcdefg ... xyz" >> >> A List: >> >> [1, 2, 3, 4, ... 999] >> >> An array: >> >> boolean[233] { false, false, false, false, f ... se } >> >> So, there could be a length of termination context argument. >> >> -Robert >> >> >> jshell> /help /set truncation >> | Set the max length a displayed value. >> | >> | /set truncation ... >> | >> | Where is the name of a previously defined feedback mode -- >> see '/help /set mode'. >> | Where is an unsigned integer representing a maximum length. >> | Where is only needed if you wish to fine-tune value >> truncation length >> | by context, is the context in which the truncation is >> applied. >> | The structure of selector is a hyphen separated list of selector >> kind lists. >> | A selector kind list is a comma separated list of values of one >> selector kind. >> | A selector matches if each selector kind list matches; A selector >> kind list >> | matches if one of the values matches. >> | >> | Below are the relevant selector kinds for truncation. >> | >> | The case selector kind describes the kind of snippet. The values >> are: >> | vardecl -- variable declaration without init >> | varinit -- variable declaration with init >> | expression -- expression -- note: {name}==scratch-variable-name >> | varvalue -- variable value expression >> | assignment -- assign variable >> | The action selector kind describes what happened to the >> snippet. The values are: >> | added -- snippet has been added >> | modified -- an existing snippet has been modified >> | replaced -- an existing snippet has been replaced with a new >> snippet >> | Examples: >> | /set trunc mymode 80 >> | /set truncation mymode 45 expression >> | /set truncation mymode 0 vardecl-modified,replaced >> | >> | Note that subsequent selectors for a field may overwrite some or >> all of previous used selectors -- last one wins >> >> >> >> On 09/22/16 10:42, Jonathan Gibbons wrote: >>> In the long array case, I'd suggest to hide the middle, not the end >>> of the array. Show the first "few" entries and the last "few" >>> entries in the array, for some value of "few". >>> >>> -- Jon >>> >>> >>> On 9/22/16 10:37 AM, John Rose wrote: >>>> On Sep 21, 2016, at 6:16 PM, Robert Field >>>> wrote: >>>>> Comments??? >>>> Another +1 from me. Some comments from my inner Common Lisper: >>>> >>>> There should be a close brace after the "?" of an overlong array. >>>> This will allow syntax sensitive editors (emacs!) to block the >>>> thing correctly. >>>> >>>> The cutoff length of the overlong array should be a configurable >>>> number. >>>> >>>> You might consider a configurable cutoff for printed nesting level. >>>> >>>> These ideas from from this section of the CL manual: >>>> >>>> http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node193.html#LEVELLENGTHTABLE >>>> >>>> >>>> There is also an option called *print-array* which gates whether >>>> arrays should be expanded at all. >>>> This is relevant to Java, which also distinguishes Arrays.toString >>>> from Object.toString. >>>> >>>> ? John >>> >> > From jan.lahoda at oracle.com Fri Sep 23 20:31:50 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 23 Sep 2016 22:31:50 +0200 Subject: RFR (xs) 8166589: jshell tool: typo: remove out of place text in /help /set truncation In-Reply-To: <57E58E17.8000902@oracle.com> References: <57E58E17.8000902@oracle.com> Message-ID: <57E59136.3000405@oracle.com> Seems OK. Jan On 23.9.2016 22:18, Robert Field wrote: > Please review -- > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8166589 > > Webrev: > http://cr.openjdk.java.net/~rfield/8166589v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Fri Sep 23 22:43:30 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 23 Sep 2016 15:43:30 -0700 Subject: RFR 8165405: jshell tool: /classpath should be /set classpath Message-ID: <57E5B012.9070602@oracle.com> Please review -- Bugs: https://bugs.openjdk.java.net/browse/JDK-8165405 jshell tool: /classpath should be /set classpath https://bugs.openjdk.java.net/browse/JDK-8165406 jshell tool: /retain classpath Webrev: http://cr.openjdk.java.net/~rfield/8165405v0.webrev/ -Robert From bitterfoxc at gmail.com Sat Sep 24 06:49:48 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Fri, 23 Sep 2016 23:49:48 -0700 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: <57E4D485.80500@oracle.com> References: <57CD09FE.70908@oracle.com> <57CDE39A.3020100@oracle.com> <57D069C0.8030009@oracle.com> <57D33CE9.9060305@oracle.com> <57D5BBEC.8060506@oracle.com> <57D6CA3F.4050309@oracle.com> <57D6DE8F.4070405@oracle.com> <57D6EEB1.4050506@oracle.com> <57D7189F.2070901@oracle.com> <57D71A2C.9030501@oracle.com> <57D74A77.5000905@oracle.com> <57D8289B.5030403@oracle.com> <57E4D485.80500@oracle.com> Message-ID: Hi Robert, 2016-09-23 0:06 GMT-07:00 Robert Field : > > On 09/22/16 12:51, ShinyaYoshida wrote: > > Hi Robert and Jan, > I've updated the webrev to add -C option and --add-exports option(as a > non-standard option): > http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.10.langtools/ > > Could you review and give me a comment? > > > Wow! This is so much simpler an approach! > > A couple little things and this is good... > > In JShellTool, should --add-exports have .withRequiredArg() rather than > .withOptionalArg()? > Yeah! That's what I want to use!! I've fixed > > I think > > 645 if (options.has("X")) { > 646 printUsageX(); > 647 } > > Should be up below "help", and, like "help", should abort by returning > null. > Absolutely yes!! New version is here: http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.11.langtools/ Regards, shinyafox(ShinyaYoshida) > > Your comment looks fine. > > Test and resource file look good. > > Thanks, > Robert > > > > > Another issue is found until implementing: > https://bugs.openjdk.java.net/browse/JDK-8166581 > > Could you confirm and address this? > > Regards, > shinyafox(Shinya Yoshida)@JavaOne 20016 > > 2016-09-13 9:26 GMT-07:00 Robert Field : > >> >> On 09/12/16 17:55, ShinyaYoshida wrote: >> >> Hi Jan and all, >> I've confirmed your snippet. >> Certainly it have a security problem and it should be avoided. >> >> I'll update my patch to add a new command-line option -C which give the >> option to compiler. >> >> In addition to, I'd like to add a new command-line option --add-exports >> / which is a short-circuit for "-J--add-exports >> /=ALL-UNNAMED -C--add-exports >> /=ALL-UNNAMED." >> java and javac are also have --add-exports option, so it seems to me that >> it is reasonable for jshell to have --add-exports option. >> What do you think about this? >> >> Kind Regards, >> shinyafox(Shinya Yoshida) >> >> >> OK, great. >> >> I started to write that I didn't think you needed or wanted a -C >> flag. But on further thought, that allows all kinds of flexibility that we >> may not want to provide item by item -- for example: >> --processor-module-path, --module-source-path, .... >> There is a question: which compiles should these flags get applied to, >> but it seems they would just be ignored where not needed, so probably all >> of them. >> >> I notice --add-exports is on the -X help for both java and javac -- it is >> non-standard. Seems wrong for it to be a non-standard option for those two >> and a standard option for jshell. >> >> I think it is a question for Jigsaw people as to what module options: >> >> * should be directly jshell command-line options >> * should be non-standard -X command-line options (if jshell has -X >> options) >> * obscure enough that users should use -R and -C >> >> -Robert >> >> >> >> >> >> 2016-09-13 9:38 GMT+09:00 Robert Field : >> >>> If our approach to security is "do nothing a user could not do with >>> their own use of javac/java" (which we have yet to have validated) then if >>> the SharedSecrets use in JShell requires the change to the module.info.java >>> in java.base to add jdk.jshell, then that would be a violation. >>> >>> If this changeset gave access only to snippets executing via the JShell >>> API maybe that would be OK. But it, as your exploit verifies, could easily >>> be used by anyone to change module boundaries. >>> >>> Maybe there would be a hack that would allow only proper JShell use, but >>> I don't see what that would be, and that sounds dangerous and unappealing. >>> >>> Command-line option only would match the original request and other >>> tools. The implementation would closely match the implementation of '-R', >>> being on the command-line of JShellTool and the API in JShell.Builder. >>> Alas, this is mostly a rewrite, only some code in TaskFactory, >>> ToolBasicTest, and maybe KullaTesting would be reusable. >>> >>> Bummer! >>> >>> But thanks for catching this Jan! >>> >>> -Robert >>> >>> >>> >>> On 09/12/16 14:12, Jan Lahoda wrote: >>> >>>> (Basically, the use of SharedSecrets in jdk.jshell seems highly >>>> suspicious to me.) >>>> >>>> Jan >>>> >>>> On 12.9.2016 23:05, Jan Lahoda wrote: >>>> >>>>> On 12.9.2016 20:06, Robert Field wrote: >>>>> >>>>>> The jshell tool is built on the JShell API. Command-line options, >>>>>> like >>>>>> -R, pass to the remote process via the JShell API. -R would allow >>>>>> --patch-module or --add-exports. Having addExports functionality >>>>>> >>>>> >>>>> I am not much worried about --add-exports added using -R, that seems OK >>>>> to me. This only affects a newly spawned JVM, and the API client could >>>>> spawn it even without JShell, so not a problem IMO. >>>>> >>>>> What I am worried about is that using the most recent proposed patch >>>>> (lwebrev.04.langtools), one can use the DirectExecutionControl to >>>>> change >>>>> module boundaries in the _currently running VM_. Please see the >>>>> attached >>>>> class to see what I mean - I didn't even have to create JShell as such, >>>>> simply using DirectExecutionControl was enough. It probably does not >>>>> even need some special privileges to achieve the result. >>>>> >>>>> Jan >>>>> >>>>> anywhere is jshell means having it in the JShell API. >>>>>> >>>>>> I believe this cycles us, to some degree, back to the security >>>>>> discussion. What is our level of concern about a launched process >>>>>> running pure JDK code? >>>>>> >>>>>> -Robert >>>>>> >>>>>> On 09/12/16 09:57, Jan Lahoda wrote: >>>>>> >>>>>>> [adding Jon] >>>>>>> >>>>>>> On 12.9.2016 17:31, Robert Field wrote: >>>>>>> >>>>>>>> Both javac and java have a --add-exports option, so it isn't opening >>>>>>>> anything that isn't already open. >>>>>>>> I don't see how command-line options are any different that API in >>>>>>>> terms >>>>>>>> of exposure. >>>>>>>> >>>>>>> >>>>>>> I think there's a huge difference between command line and an API, in >>>>>>> at least two aspects: >>>>>>> a) the person that controls the command line, has a lot of power in >>>>>>> any case (they could do -Xbootclasspath/p: in 8 or --patch-module now >>>>>>> to get around the boundaries). API users are much more restricted in >>>>>>> what they can do. >>>>>>> b) affecting the command line options is generally very hard - >>>>>>> imagine >>>>>>> library maintainers - how can they affect the command line setting? >>>>>>> The only thing they can do is to write some documentation, but they >>>>>>> cannot directly affect the command line. But they can call an API >>>>>>> (and >>>>>>> they can call it even reflectively). >>>>>>> >>>>>>> I believe it is generally undesirable to create APIs that allow to >>>>>>> create holes in module boundaries. If you think that's something >>>>>>> JShell needs, I think we need to take that to the Jigsaw team. >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>> >>>>>>>> -Robert >>>>>>>> >>>>>>>> >>>>>>>> On 09/11/16 13:17, Jan Lahoda wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I apologize for not following this sooner. >>>>>>>>> >>>>>>>>> Looking at this, it seems to me the change would effectively allow >>>>>>>>> to >>>>>>>>> overcome the module boundary limitations using JShell - I don't >>>>>>>>> think >>>>>>>>> that's something that would be acceptable. We could take this to >>>>>>>>> the >>>>>>>>> Jigsaw team, but I don't think they would be happy about this. >>>>>>>>> >>>>>>>>> I wonder what exactly is the usecase here. Would it be sufficient >>>>>>>>> if >>>>>>>>> the jshell tool as such would allow command line options to break >>>>>>>>> through the boundaries? We already have -R, which should allow to >>>>>>>>> make >>>>>>>>> holes to the boundaries when running the snippets, so maybe we just >>>>>>>>> need to add something for compile-time? >>>>>>>>> >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> On 11.9.2016 02:12, ShinyaYoshida wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> Please apply this webrev: >>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>> 0.jdk/ >>>>>>>>>> >>>>>>>>> 00.jdk/> >>>>>>>>>> Changing module-info is needed. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>> >>>>>>>>>> 2016-09-10 7:51 GMT+09:00 Robert Field >>>>>>>>> >: >>>>>>>>>> >>>>>>>>>> [audience reduced] >>>>>>>>>> >>>>>>>>>> BTW shinyafox, >>>>>>>>>> >>>>>>>>>> Building "make images" with this patch and the latest jdk9/dev >>>>>>>>>> bits >>>>>>>>>> fails. Probably need to change module set-up -- >>>>>>>>>> >>>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>>> xecution/DirectExecutionControl.java:33: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> error: package jdk.internal.misc does not exist >>>>>>>>>> import jdk.internal.misc.JavaLangReflectModuleAccess; >>>>>>>>>> ^ >>>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>>> xecution/DirectExecutionControl.java:34: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> error: package jdk.internal.misc does not exist >>>>>>>>>> import jdk.internal.misc.SharedSecrets; >>>>>>>>>> ^ >>>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>>> xecution/DirectExecutionControl.java:155: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> error: cannot find symbol >>>>>>>>>> JavaLangReflectModuleAccess moduleAccess = >>>>>>>>>> SharedSecrets.getJavaLangReflectModuleAccess(); >>>>>>>>>> ^ >>>>>>>>>> symbol: class JavaLangReflectModuleAccess >>>>>>>>>> location: class DirectExecutionControl >>>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>>> xecution/DirectExecutionControl.java:155: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> error: cannot find symbol >>>>>>>>>> JavaLangReflectModuleAccess moduleAccess = >>>>>>>>>> SharedSecrets.getJavaLangReflectModuleAccess(); >>>>>>>>>> ^ >>>>>>>>>> symbol: variable SharedSecrets >>>>>>>>>> location: class DirectExecutionControl >>>>>>>>>> 4 errors >>>>>>>>>> >>>>>>>>>> -Robert >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 09/08/16 07:14, ShinyaYoshida wrote: >>>>>>>>>> >>>>>>>>>>> Hi Robert, >>>>>>>>>>> Thank you for your pointing out. >>>>>>>>>>> I've understood. >>>>>>>>>>> >>>>>>>>>>> Here is new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>> 4.langtools/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> v.04.langtools/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In this version, >>>>>>>>>>> - ExecutionControl#addExports throws BadArgumentException >>>>>>>>>>> which is >>>>>>>>>>> extends ExecutionControlException if module or package are >>>>>>>>>>> not >>>>>>>>>>> found. >>>>>>>>>>> - JShell#addExports throws IllegalArgumentException when >>>>>>>>>>> BadArgumentException is occured >>>>>>>>>>> >>>>>>>>>>> I've notice that /classpath and addToClasspath says nothing >>>>>>>>>>> when >>>>>>>>>>> it doesn't exist. >>>>>>>>>>> I think it should be reported, so I've created a issue: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165650 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> Please review me again! >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2016-09-08 4:25 GMT+09:00 Robert Field < >>>>>>>>>>> robert.field at oracle.com >>>>>>>>>>> >: >>>>>>>>>>> >>>>>>>>>>> Thanks for the update. >>>>>>>>>>> >>>>>>>>>>> l10n.properties -- >>>>>>>>>>> >>>>>>>>>>> Oops, typo: the help.set.exports entry got pasted again >>>>>>>>>>> instead of help.retain.exports >>>>>>>>>>> >>>>>>>>>>> Sorry I was unclear about the exceptions... >>>>>>>>>>> >>>>>>>>>>> On the execution side -- >>>>>>>>>>> >>>>>>>>>>> ExecutionControl.InternalException is only for >>>>>>>>>>> unexpected >>>>>>>>>>> failures. >>>>>>>>>>> >>>>>>>>>>> In this case you are dealing an expected exception that >>>>>>>>>>> occurs >>>>>>>>>>> when the user gives the wrong input. None of the >>>>>>>>>>> existing >>>>>>>>>>> ExecutionControlException subclasses are good candidates, >>>>>>>>>>> so a >>>>>>>>>>> new ExecutionControlException subclass is needed. I was >>>>>>>>>>> suggesting "BadArgumentException" for this exception. >>>>>>>>>>> None of >>>>>>>>>>> ExecutionControlException subclasses are seen at the >>>>>>>>>>> JShell >>>>>>>>>>> level -- this should be the case for this new one as >>>>>>>>>>> well. >>>>>>>>>>> >>>>>>>>>>> I don't what kind of exceptions are thrown by >>>>>>>>>>> moduleAccess.addExportsToAllUnnamed(target, pack), but >>>>>>>>>>> that >>>>>>>>>>> message text or some other appropriate descriptive >>>>>>>>>>> message >>>>>>>>>>> text needs to be placed in the BadArgumentException >>>>>>>>>>> message so >>>>>>>>>>> it can be seen all the way up (including the JShellTool). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On the JShell class -- >>>>>>>>>>> >>>>>>>>>>> Incorrect arguments on JShell API methods generate the >>>>>>>>>>> Java >>>>>>>>>>> standard java.lang.IllegalArgumentException (see, for >>>>>>>>>>> example, >>>>>>>>>>> drop() or status() ) -- so, this is also the appropriate >>>>>>>>>>> exception for JShell.addExports(). Thus, >>>>>>>>>>> JShell.addExports() >>>>>>>>>>> catchs the BadArgumentException, turning it into an >>>>>>>>>>> IllegalArgumentException. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Robert >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 09/07/16 06:10, ShinyaYoshida wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Robert, >>>>>>>>>>>> Thank you for your helping. >>>>>>>>>>>> >>>>>>>>>>>> I've update webrev according to your comments. >>>>>>>>>>>> If I'm missing your meaning, I'm sorry. Please point it. >>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>> 3.langtools/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> v.03.langtools/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Now, >>>>>>>>>>>> - JShell#addExports will throw BadArgumentException when >>>>>>>>>>>> module or package is wrong, which is check exception. >>>>>>>>>>>> - JShellTool checks that exception. >>>>>>>>>>>> - ExecutionControl#addExports throws InternalException >>>>>>>>>>>> when >>>>>>>>>>>> something is wrong. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2016-09-06 6:28 GMT+09:00 Robert Field >>>>>>>>>>>> >>>>>>>>>>> m>>: >>>>>>>>>>>> >>>>>>>>>>>> Code looks good. Needs docs I promised (see below). >>>>>>>>>>>> >>>>>>>>>>>> As to completion issue you created, I see you >>>>>>>>>>>> already >>>>>>>>>>>> added discussion and tests. I added your completion >>>>>>>>>>>> code. >>>>>>>>>>>> >>>>>>>>>>>> Below is my suggested doc... >>>>>>>>>>>> >>>>>>>>>>>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> /set exports \n\t\ >>>>>>>>>>>> Allow access to some of the unexported types >>>>>>>>>>>> of a >>>>>>>>>>>> module\n\n\ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> /retain exports \n\t\ >>>>>>>>>>>> Allow access to some of the unexported types >>>>>>>>>>>> of a >>>>>>>>>>>> module\n\n\ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> help.set.exports=\ >>>>>>>>>>>> Set a package to add to those exported to >>>>>>>>>>>> snippets.\n\ >>>>>>>>>>>> \n\t\ >>>>>>>>>>>> /set exports \n\ >>>>>>>>>>>> \n\ >>>>>>>>>>>> Where is the module from which to export >>>>>>>>>>>> .\n\ >>>>>>>>>>>> Where is the package to export to >>>>>>>>>>>> snippets.\n >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> help.retain.exports=\ >>>>>>>>>>>> Retain a package to add to those exported to >>>>>>>>>>>> snippets.\n\ >>>>>>>>>>>> \n\t\ >>>>>>>>>>>> /retain exports \n\ >>>>>>>>>>>> \n\ >>>>>>>>>>>> Where is the module from which to export >>>>>>>>>>>> .\n\ >>>>>>>>>>>> Where is the package to export to >>>>>>>>>>>> snippets.\n >>>>>>>>>>>> >>>>>>>>>>>> [I notice that 'snippet' is used in doc without >>>>>>>>>>>> being >>>>>>>>>>>> defined. If, while you are it, you change the help >>>>>>>>>>>> for >>>>>>>>>>>> /list to define it:] >>>>>>>>>>>> >>>>>>>>>>>> help.list =\ >>>>>>>>>>>> Show the source of snippets, prefaced with the >>>>>>>>>>>> snippet id >>>>>>>>>>>> (a snippet is a chunk of code that the jshell tool >>>>>>>>>>>> evaluates -- the code you enter at the prompt is a >>>>>>>>>>>> snippet).\n\ >>>>>>>>>>>> ... >>>>>>>>>>>> >>>>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/JShell.java -- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> /** >>>>>>>>>>>> * Add a package to those exported to snippets. >>>>>>>>>>>> * @param module The module from which to export >>>>>>>>>>>> * @param pack The package to export >>>>>>>>>>>> * @throws NullPointerException if arguments are >>>>>>>>>>>> null. >>>>>>>>>>>> * @throws IllegalStateException if this {@code >>>>>>>>>>>> JShell} instance is closed. >>>>>>>>>>>> * @throws XYZ if .... >>>>>>>>>>>> */ >>>>>>>>>>>> >>>>>>>>>>>> OK, actually this code should change. Like >>>>>>>>>>>> addToClasspath above it, it should return void. It >>>>>>>>>>>> looks >>>>>>>>>>>> like under normal operation it can fail -- the >>>>>>>>>>>> failure >>>>>>>>>>>> should be reported with an exception. >>>>>>>>>>>> What are the failure modes? IllegalArgumentException >>>>>>>>>>>> would be likely choice at the JShell API layer. But >>>>>>>>>>>> then >>>>>>>>>>>> the exception needs to be propagated there. >>>>>>>>>>>> Since none of the existing exceptions is a match, >>>>>>>>>>>> this >>>>>>>>>>>> means a new ExecutionControlException. Maybe >>>>>>>>>>>> something >>>>>>>>>>>> general, like BadUserArgumentException. >>>>>>>>>>>> Note: I've also added IllegalStateException -- this >>>>>>>>>>>> can >>>>>>>>>>>> be thrown when you get EngineTerminationException. >>>>>>>>>>>> Also, typo, the second "module cannot be null" >>>>>>>>>>>> should be >>>>>>>>>>>> "package cannot be null" >>>>>>>>>>>> >>>>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteCodes.java >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> The comment you have is fine. Just remove PLEASE >>>>>>>>>>>> REVISE >>>>>>>>>>>> THE COMMENT >>>>>>>>>>>> >>>>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl >>>>>>>>>>>> .java >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> /** >>>>>>>>>>>> * Add a package to those exported to snippets. >>>>>>>>>>>> * @param module The module from which to export >>>>>>>>>>>> * @param pack The package to export >>>>>>>>>>>> * @throws EngineTerminationException the >>>>>>>>>>>> execution >>>>>>>>>>>> engine has terminated >>>>>>>>>>>> * @throws .... >>>>>>>>>>>> * @throws InternalException an internal problem >>>>>>>>>>>> occurred >>>>>>>>>>>> */ >>>>>>>>>>>> >>>>>>>>>>>> Plus add the bad argument exception. >>>>>>>>>>>> Whatever it is, should be added to >>>>>>>>>>>> extensionCommand() >>>>>>>>>>>> exceptions. >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 09/05/16 08:02, ShinyaYoshida wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> I've update webrev of langtools: >>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>> 2.langtools/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> v.02.langtools/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I added an issue for the completion feature. >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165445 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>> >>>>>>>>>>>>> 2016-09-05 22:49 GMT+09:00 ShinyaYoshida >>>>>>>>>>>>> >>>>>>>>>>>> >>: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>> Thank you for the review. >>>>>>>>>>>>> >>>>>>>>>>>>> I totally agree with you. >>>>>>>>>>>>> I also think that availableModules and >>>>>>>>>>>>> availablePackages(module) are worthless >>>>>>>>>>>>> excepting >>>>>>>>>>>>> for the command completion feature. >>>>>>>>>>>>> I'd like to avoid adding these APIs which have >>>>>>>>>>>>> not >>>>>>>>>>>>> been speculated and revised because if API is >>>>>>>>>>>>> once >>>>>>>>>>>>> added, it is too difficult to remove than >>>>>>>>>>>>> adding. >>>>>>>>>>>>> >>>>>>>>>>>>> So currently, I'll remove the completion >>>>>>>>>>>>> feature >>>>>>>>>>>>> for >>>>>>>>>>>>> /set or /retain exports and make the issue to >>>>>>>>>>>>> JBS to >>>>>>>>>>>>> add completion feature for them in future. >>>>>>>>>>>>> >>>>>>>>>>>>> I'll update the webrev. So please review it >>>>>>>>>>>>> again >>>>>>>>>>>>> later. >>>>>>>>>>>>> When the silently evaluation feature is added, >>>>>>>>>>>>> I'd >>>>>>>>>>>>> like to work for the completion feature again. >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you, >>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2016-09-05 15:00 GMT+09:00 Robert Field >>>>>>>>>>>>> >>>>>>>>>>>> >: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 09/03/16 05:07, ShinyaYoshida wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> I've updated my patch, new webrev is here: >>>>>>>>>>>>>> webrev.01.langtools: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>>> 1.langtools/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> v.01.langtools/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> webrev.01.jdk: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>>> 1.jdk/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> v.01.jdk/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> (Same as previous) >>>>>>>>>>>>>> >>>>>>>>>>>>>> In this version, >>>>>>>>>>>>>> - rename /set add-exports to /set exports >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> OK >>>>>>>>>>>>> >>>>>>>>>>>>> - add /retain exports >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The /retain implementation looks good. >>>>>>>>>>>>> >>>>>>>>>>>>> - add tests >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Well tested >>>>>>>>>>>>> >>>>>>>>>>>>> - move EXT_CMD_XXX into RemoteCodes >>>>>>>>>>>>>> - make RemoteCodes public and move it into >>>>>>>>>>>>>> jdk.jshell.execution.code which is >>>>>>>>>>>>>> module-private >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> So, here, in addition to addExports, there >>>>>>>>>>>>> are >>>>>>>>>>>>> two more methods added to the API >>>>>>>>>>>>> availableModules() and >>>>>>>>>>>>> availablePackage(String >>>>>>>>>>>>> module). >>>>>>>>>>>>> I see how in rare cases they could be >>>>>>>>>>>>> useful. >>>>>>>>>>>>> And the rare case that causes them to be >>>>>>>>>>>>> present >>>>>>>>>>>>> is for command completion in the tool. >>>>>>>>>>>>> What are the options: >>>>>>>>>>>>> >>>>>>>>>>>>> (1) Add them to the API. If it is in the >>>>>>>>>>>>> API >>>>>>>>>>>>> then it is a first-class form of >>>>>>>>>>>>> functionality >>>>>>>>>>>>> and should be treated as such in execution >>>>>>>>>>>>> support (as a command) >>>>>>>>>>>>> (2) Not support them and not support >>>>>>>>>>>>> command >>>>>>>>>>>>> completion for /set exports. Command >>>>>>>>>>>>> completion >>>>>>>>>>>>> is not supported in much more common cases. >>>>>>>>>>>>> Then we could support command completion in >>>>>>>>>>>>> the >>>>>>>>>>>>> future (see (3)). >>>>>>>>>>>>> (3) What these commands do is simply >>>>>>>>>>>>> execute >>>>>>>>>>>>> an expression on the remote side. But we >>>>>>>>>>>>> already have a mechanism to execute >>>>>>>>>>>>> expressions >>>>>>>>>>>>> on the remote side: Snippets. >>>>>>>>>>>>> That leaves a problem: we wouldn't >>>>>>>>>>>>> want >>>>>>>>>>>>> these Snippets to be seen by the user, but >>>>>>>>>>>>> we >>>>>>>>>>>>> have a solution for that the tool uses the >>>>>>>>>>>>> idGenerator. >>>>>>>>>>>>> Another problem is that, by default >>>>>>>>>>>>> and >>>>>>>>>>>>> with no current way around the default, >>>>>>>>>>>>> expressions generate temp-variables. My >>>>>>>>>>>>> intention was to make this configurable -- >>>>>>>>>>>>> see >>>>>>>>>>>>> Eval.shouldGenTempVar(...). >>>>>>>>>>>>> >>>>>>>>>>>>> One goal I've been using in the design of >>>>>>>>>>>>> the >>>>>>>>>>>>> API is to keep it as small and simple as >>>>>>>>>>>>> possible. This improves maintainability, >>>>>>>>>>>>> but >>>>>>>>>>>>> much more importantly makes the API easier >>>>>>>>>>>>> to >>>>>>>>>>>>> learn and use. >>>>>>>>>>>>> So, for something to warrant inclusion it >>>>>>>>>>>>> should >>>>>>>>>>>>> be generally useful and have no other way >>>>>>>>>>>>> of >>>>>>>>>>>>> being achieved -- neither is true of these >>>>>>>>>>>>> two >>>>>>>>>>>>> queries. >>>>>>>>>>>>> >>>>>>>>>>>>> My suggestion, particularly in light of how >>>>>>>>>>>>> late >>>>>>>>>>>>> in the release this is, would be (2). >>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>> >>>>>>>>>>>>> -Robert >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2016-09-03 18:15 GMT+09:00 ShinyaYoshida >>>>>>>>>>>>>> >>>>>>>>>>>>> >: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>> Thank you for reviewing. >>>>>>>>>>>>>> I'll update my patch later. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2016-09-02 11:38 GMT+09:00 Robert >>>>>>>>>>>>>> Field >>>>>>>>>>>>>> >>>>>>>>>>>>> >: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks shiyafox! This is a >>>>>>>>>>>>>> significant >>>>>>>>>>>>>> piece of code! >>>>>>>>>>>>>> >>>>>>>>>>>>>> As to your questions -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> > I wonder if you could work on >>>>>>>>>>>>>> the >>>>>>>>>>>>>> documentation of the API and the >>>>>>>>>>>>>> tool >>>>>>>>>>>>>> instead? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, I will do API and tool docs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you! >>>>>>>>>>>>>> >>>>>>>>>>>>>> > Subcommand of /set is >>>>>>>>>>>>>> reasonable? >>>>>>>>>>>>>> Similar command, /classpath, to >>>>>>>>>>>>>> make >>>>>>>>>>>>>> users available to use new >>>>>>>>>>>>>> packages is >>>>>>>>>>>>>> not a subcommand of /set. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, I think /set exports is best. >>>>>>>>>>>>>> And, yes, /classpath is >>>>>>>>>>>>>> inconsistent, >>>>>>>>>>>>>> it should be /set classpath, that >>>>>>>>>>>>>> can >>>>>>>>>>>>>> be a separate task, unless you >>>>>>>>>>>>>> want to >>>>>>>>>>>>>> roll that in. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I see, I've created the issue to move >>>>>>>>>>>>>> /classpath to /set classpath: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165405 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > Should we need retain feature to >>>>>>>>>>>>>> this? >>>>>>>>>>>>>> >>>>>>>>>>>>>> All /set have a /retain >>>>>>>>>>>>>> counterpart -- >>>>>>>>>>>>>> we should maintain that >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ok, I'll add /retain exports. >>>>>>>>>>>>>> I've also create the issue for >>>>>>>>>>>>>> retaining >>>>>>>>>>>>>> classpath: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165406 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> As to the code review: Looks good >>>>>>>>>>>>>> to >>>>>>>>>>>>>> me, just minor questions/issues -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> JShellTool.java: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * As discussed /set add-exports => >>>>>>>>>>>>>> /set >>>>>>>>>>>>>> exports >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Nit: a comment got moved out of >>>>>>>>>>>>>> place >>>>>>>>>>>>>> line 1194(old) >>>>>>>>>>>>>> >>>>>>>>>>>>>> JShell.java: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * EXT_CMD_AVAILABLE_MODULES and >>>>>>>>>>>>>> EXT_CMD_AVAILABLE_PACKAGES, these >>>>>>>>>>>>>> should be referenced via >>>>>>>>>>>>>> RemoteCodes.java rather than be >>>>>>>>>>>>>> coped. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Absolutely! I'd like to move these >>>>>>>>>>>>>> into >>>>>>>>>>>>>> RemoteCodes but it is package-private >>>>>>>>>>>>>> class >>>>>>>>>>>>>> and cannot be referred from JShell. >>>>>>>>>>>>>> Can I make RemoteCodes public and >>>>>>>>>>>>>> move it >>>>>>>>>>>>>> to another module-private package like >>>>>>>>>>>>>> jdk.jshell.execution.code? >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Which leads me to another >>>>>>>>>>>>>> question: >>>>>>>>>>>>>> why is addExports a command and >>>>>>>>>>>>>> these >>>>>>>>>>>>>> two are extensions. It seems fine, >>>>>>>>>>>>>> just >>>>>>>>>>>>>> curious. I notice that extensions >>>>>>>>>>>>>> are a >>>>>>>>>>>>>> lot less code -- ;-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Exporting module and package is >>>>>>>>>>>>>> similar to >>>>>>>>>>>>>> adding classpath to platform, so I >>>>>>>>>>>>>> made >>>>>>>>>>>>>> the >>>>>>>>>>>>>> addExports a command like >>>>>>>>>>>>>> setClasspath. >>>>>>>>>>>>>> And it should be added as API because >>>>>>>>>>>>>> it is >>>>>>>>>>>>>> very basic feature. >>>>>>>>>>>>>> >>>>>>>>>>>>>> TaskFactory.java: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Question: the "/" separator >>>>>>>>>>>>>> between >>>>>>>>>>>>>> module and package is that >>>>>>>>>>>>>> platform >>>>>>>>>>>>>> independent? >>>>>>>>>>>>>> >>>>>>>>>>>>>> It seems to me that "{module}/{path}" >>>>>>>>>>>>>> format for --add-exports option of >>>>>>>>>>>>>> javac is >>>>>>>>>>>>>> platform independent. >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> DefaultLoaderDelegate.java: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Jan, can you look at this code? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 09/01/16 05:36, ShinyaYoshida >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> I've implemented this feature >>>>>>>>>>>>>> to >>>>>>>>>>>>>> JShell API and Tool with full >>>>>>>>>>>>>> completion: >>>>>>>>>>>>>> Bugs: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8154714 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> jdk: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>>> 0.jdk/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> v.00.jdk/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> v.00.jdk/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> v.00.jdk/>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> langtools: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>>> 0.langtools/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> v.00.langtools/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> v.00.langtools/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> v.00.langtools/>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is missing the train of >>>>>>>>>>>>>> Java >>>>>>>>>>>>>> 9.0 but it could catch the >>>>>>>>>>>>>> train of >>>>>>>>>>>>>> Java 9.1 or later. >>>>>>>>>>>>>> I want to get your comments >>>>>>>>>>>>>> for >>>>>>>>>>>>>> this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> jshell> /set add-exports >>>>>>>>>>>>>> jdk.jconsole >>>>>>>>>>>>>> sun.tools.jconsole >>>>>>>>>>>>>> >>>>>>>>>>>>>> jshell> import >>>>>>>>>>>>>> sun.tools.jconsole.* >>>>>>>>>>>>>> >>>>>>>>>>>>>> jshell> >>>>>>>>>>>>>> LocalVirtualMachine.getAllVirtualMachines().forEach((k, >>>>>>>>>>>>>> v) -> System.out.println(k + >>>>>>>>>>>>>> ":" >>>>>>>>>>>>>> + v)) >>>>>>>>>>>>>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>>>>>>>>>>>>> 10826:jdk.jshell.execution.RemoteExecutionControl >>>>>>>>>>>>>> 35548 >>>>>>>>>>>>>> 28447:org.netbeans.Main --cachedir >>>>>>>>>>>>>> /home/bitter_fox/.cache/netbeans/8.0.1 >>>>>>>>>>>>>> --userdir >>>>>>>>>>>>>> /home/bitter_fox/.netbeans/8.0.1 >>>>>>>>>>>>>> --branding nb >>>>>>>>>>>>>> >>>>>>>>>>>>>> Currently, there is no >>>>>>>>>>>>>> testing, so >>>>>>>>>>>>>> it will be required to add >>>>>>>>>>>>>> test. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>> >> >> > > From weijun.wang at oracle.com Sat Sep 24 08:28:02 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 24 Sep 2016 16:28:02 +0800 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: References: <57CD09FE.70908@oracle.com> <57CDE39A.3020100@oracle.com> <57D069C0.8030009@oracle.com> <57D33CE9.9060305@oracle.com> <57D5BBEC.8060506@oracle.com> <57D6CA3F.4050309@oracle.com> <57D6DE8F.4070405@oracle.com> <57D6EEB1.4050506@oracle.com> <57D7189F.2070901@oracle.com> <57D71A2C.9030501@oracle.com> <57D74A77.5000905@oracle.com> <57D8289B.5030403@oracle.com> <57E4D485.80500@oracle.com> Message-ID: Hi Shinya This is not a code review, as I know nothing about jshell codes. Just want to ask: Do I have to add --add-exports on the command line? Is it possible to implement this as a command so I can add new exports on-demand while running the tool? Thanks Max From michael.mueller at mueller-bruehl.de Sat Sep 24 09:20:03 2016 From: michael.mueller at mueller-bruehl.de (=?UTF-8?Q?Michael_M=c3=bcller?=) Date: Sat, 24 Sep 2016 11:20:03 +0200 Subject: RFR 8165405: jshell tool: /classpath should be /set classpath In-Reply-To: <57E5B012.9070602@oracle.com> References: <57E5B012.9070602@oracle.com> Message-ID: <43c51a35-ca71-d5b9-cf59-bd1c0ce7871e@mueller-bruehl.de> What happens when using this /set classpath path/x.jar /set classpath path/y.jar are bot jars added to the classpath? or does the second set overwrite the classpath? maybe it might be better this way /set classpath overwrites an existing one /add classpath adds a new path /retain classpath removes a path ? Herzliche Gr??e - Best Regards, Michael M?ller Br?hl, Germany blog.mueller-bruehl.de it-rezension.de @muellermi Read my books "Web Development with Java and JSF": https://leanpub.com/jsf "Java Lambdas und (parallel) Streams" Deutsche Ausgabe: https://leanpub.com/lambdas-de "Java Lambdas and (parallel) Streams" English edition: https://leanpub.com/lambdas On 09/24/2016 12:43 AM, Robert Field wrote: > Please review -- > > Bugs: > > https://bugs.openjdk.java.net/browse/JDK-8165405 > jshell tool: /classpath should be /set classpath > > https://bugs.openjdk.java.net/browse/JDK-8165406 > jshell tool: /retain classpath > > Webrev: > > http://cr.openjdk.java.net/~rfield/8165405v0.webrev/ > > -Robert > > From robert.field at oracle.com Sat Sep 24 14:01:19 2016 From: robert.field at oracle.com (Robert Field) Date: Sat, 24 Sep 2016 07:01:19 -0700 Subject: RFR 8166655: JShell: Process running JShell should not be blocked from exit by non-daemon data-transfer threads Message-ID: <57E6872F.3040704@oracle.com> Please review -- Bug: JShell: Process running JShell should not be blocked from exit by non-daemon data-transfer threads https://bugs.openjdk.java.net/browse/JDK-8166655 Parent bug: JShell tests: jdk/jshell tests fail intermittently while cleaning up threads after test https://bugs.openjdk.java.net/browse/JDK-8163250 Related bug: JShell: JDIConnection leaks the input transfer thread on close https://bugs.openjdk.java.net/browse/JDK-8158069 Webrev: http://cr.openjdk.java.net/~rfield/8166655v0.webrev/ Thanks, Robert From robert.field at oracle.com Sat Sep 24 14:08:25 2016 From: robert.field at oracle.com (Robert Field) Date: Sat, 24 Sep 2016 07:08:25 -0700 Subject: RFR 8165405: jshell tool: /classpath should be /set classpath In-Reply-To: <43c51a35-ca71-d5b9-cf59-bd1c0ce7871e@mueller-bruehl.de> References: <57E5B012.9070602@oracle.com> <43c51a35-ca71-d5b9-cf59-bd1c0ce7871e@mueller-bruehl.de> Message-ID: <57E688D9.8080503@oracle.com> It would be nice to be able to replace, rather than append to the end of the classpath. That is: https://bugs.openjdk.java.net/browse/JDK-8129539 But there are no paths to a dynamic solution. You get that by restarting the JShell state. -Robert On 09/24/16 02:20, Michael M?ller wrote: > What happens when using this > > > /set classpath path/x.jar > > /set classpath path/y.jar > > > are bot jars added to the classpath? or does the second set overwrite > the classpath? > > maybe it might be better this way > > /set classpath overwrites an existing one > > /add classpath adds a new path > > /retain classpath removes a path > > ? > > > > > Herzliche Gr??e - Best Regards, > > Michael M?ller > Br?hl, Germany > blog.mueller-bruehl.de > it-rezension.de > @muellermi > > > Read my books > "Web Development with Java and JSF": https://leanpub.com/jsf > "Java Lambdas und (parallel) Streams" Deutsche Ausgabe: > https://leanpub.com/lambdas-de > "Java Lambdas and (parallel) Streams" English edition: > https://leanpub.com/lambdas > > On 09/24/2016 12:43 AM, Robert Field wrote: >> Please review -- >> >> Bugs: >> >> https://bugs.openjdk.java.net/browse/JDK-8165405 >> jshell tool: /classpath should be /set classpath >> >> https://bugs.openjdk.java.net/browse/JDK-8165406 >> jshell tool: /retain classpath >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8165405v0.webrev/ >> >> -Robert >> >> > From bitterfoxc at gmail.com Sat Sep 24 15:15:23 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Sat, 24 Sep 2016 08:15:23 -0700 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: References: <57CD09FE.70908@oracle.com> <57CDE39A.3020100@oracle.com> <57D069C0.8030009@oracle.com> <57D33CE9.9060305@oracle.com> <57D5BBEC.8060506@oracle.com> <57D6CA3F.4050309@oracle.com> <57D6DE8F.4070405@oracle.com> <57D6EEB1.4050506@oracle.com> <57D7189F.2070901@oracle.com> <57D71A2C.9030501@oracle.com> <57D74A77.5000905@oracle.com> <57D8289B.5030403@oracle.com> <57E4D485.80500@oracle.com> Message-ID: Hi Wang, Thank you for the comment. Previously, we've tried and implemented add-exports feature as a command. But Jan found out the security problem on it. And it seems to me that command-like option is enough to do this currently. Actually when developer speculates around boundary of modules using jshell, add-exports command is useful. If we can solve the security issue on the implementation and get the agreement of Jigsaw team, it can be added in future release...? Regards, shinyafox(Shinya Yoshida) 2016-09-24 1:28 GMT-07:00 Wang Weijun : > Hi Shinya > > This is not a code review, as I know nothing about jshell codes. > > Just want to ask: Do I have to add --add-exports on the command line? Is > it possible to implement this as a command so I can add new exports > on-demand while running the tool? > > Thanks > Max > > From nbj at nine.dk Thu Sep 22 21:00:53 2016 From: nbj at nine.dk (=?utf-8?Q?Nikolaj_Brinch_J=C3=B8rgensen?=) Date: Thu, 22 Sep 2016 14:00:53 -0700 Subject: Javadoc support Message-ID: <0F294512-1C33-4384-95AA-0C36293E934B@nine.dk> Hi, Just viewed Venkats REPL presentation on JavaOne 2016. One really useful feature that in my opinion is missing, is support for Javadoc, where that could be presented as man pages or something else. It would be very valuable to have handy. Thanks, Nikolaj Brinch J?rgensen Associate Partner Nine A/S Kongens Nytorv 3-5, 1. sal 1050 K?benhavn K Email brinch at nine.dk Mobil +45 31 79 59 99 CVR 30714024 www.nine.dk From ecki at zusammenkunft.net Sun Sep 25 20:14:54 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 25 Sep 2016 22:14:54 +0200 Subject: jshell Stacktraces without Jigsaw modules Message-ID: <20160925221454.00005bea.ecki@zusammenkunft.net> Hello, in the Jigsaw JDK a StackTrace Element contains the module/version as source information. This is however not printed in jshell's stack printing. Is this considered? jshell> InputStream is = new FileInputStream("bla"); | java.io.FileNotFoundException thrown: bla (Das System kann die angegebene Datei nicht finden) | at FileInputStream.open0 (Native Method) | at FileInputStream.open (FileInputStream.java:195) | at FileInputStream. (FileInputStream.java:138) | at FileInputStream. (FileInputStream.java:93) | at (#10:1) jshell> try { InputStream is = new FileInputStream("bla"); } catch(Exception e) { e.printStackTrace(); } java.io.FileNotFoundException: bla (Das System kann die angegebene Datei nicht finden) at java.io.FileInputStream.open0(java.base at 9-ea/Native Method) at java.io.FileInputStream.open(java.base at 9-ea/FileInputStream.java:195) at java.io.FileInputStream.(java.base at 9-ea/FileInputStream.java:138) at java.io.FileInputStream.(java.base at 9-ea/FileInputStream.java:93) at REPL.$JShell$18.do_it$($JShell$18.java:9) ... From jan.lahoda at oracle.com Mon Sep 26 13:39:54 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 26 Sep 2016 15:39:54 +0200 Subject: Javadoc support In-Reply-To: <0F294512-1C33-4384-95AA-0C36293E934B@nine.dk> References: <0F294512-1C33-4384-95AA-0C36293E934B@nine.dk> Message-ID: <57E9252A.5050102@oracle.com> Hi Nikolaj, I am currently looking at adding javadoc to the method headers shown by Shift-tab. Jan On 22.9.2016 23:00, Nikolaj Brinch J?rgensen wrote: > Hi, > > Just viewed Venkats REPL presentation on JavaOne 2016. > One really useful feature that in my opinion is missing, is support for Javadoc, where that could be presented as man pages or something else. It would be very valuable to have handy. > > Thanks, > > > > Nikolaj Brinch J?rgensen > Associate Partner > > Nine A/S > Kongens Nytorv 3-5, 1. sal > 1050 K?benhavn K > > Email brinch at nine.dk > Mobil +45 31 79 59 99 > > CVR 30714024 > www.nine.dk > From forax at univ-mlv.fr Mon Sep 26 13:42:00 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 26 Sep 2016 15:42:00 +0200 (CEST) Subject: Javadoc support In-Reply-To: <57E9252A.5050102@oracle.com> References: <0F294512-1C33-4384-95AA-0C36293E934B@nine.dk> <57E9252A.5050102@oracle.com> Message-ID: <1654576562.340971.1474897320859.JavaMail.zimbra@u-pem.fr> Hi Jan, thanks for doing this, it seems to be the number 1 request from newbees. R?mi ----- Mail original ----- > De: "Jan Lahoda" > ?: "Nikolaj Brinch J?rgensen" , kulla-dev at openjdk.java.net > Envoy?: Lundi 26 Septembre 2016 15:39:54 > Objet: Re: Javadoc support > Hi Nikolaj, > > I am currently looking at adding javadoc to the method headers shown by > Shift-tab. > > Jan > > On 22.9.2016 23:00, Nikolaj Brinch J?rgensen wrote: >> Hi, >> >> Just viewed Venkats REPL presentation on JavaOne 2016. >> One really useful feature that in my opinion is missing, is support for Javadoc, >> where that could be presented as man pages or something else. It would be very >> valuable to have handy. >> >> Thanks, >> >> >> >> Nikolaj Brinch J?rgensen >> Associate Partner >> >> Nine A/S >> Kongens Nytorv 3-5, 1. sal >> 1050 K?benhavn K >> >> Email brinch at nine.dk >> Mobil +45 31 79 59 99 >> >> CVR 30714024 >> www.nine.dk From robert.field at oracle.com Mon Sep 26 17:20:25 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 26 Sep 2016 10:20:25 -0700 Subject: jshell Stacktraces without Jigsaw modules In-Reply-To: <20160925221454.00005bea.ecki@zusammenkunft.net> References: <20160925221454.00005bea.ecki@zusammenkunft.net> Message-ID: <57E958D9.1040304@oracle.com> Good point. I've created: https://bugs.openjdk.java.net/browse/JDK-8166726 Thanks, Robert On 09/25/16 13:14, Bernd Eckenfels wrote: > in the Jigsaw JDK a StackTrace Element contains the module/version as > source information. This is however not printed in jshell's stack > printing. Is this considered? > > > jshell> InputStream is = new FileInputStream("bla"); > | java.io.FileNotFoundException thrown: bla (Das System kann die angegebene Datei nicht finden) > | at FileInputStream.open0 (Native Method) > | at FileInputStream.open (FileInputStream.java:195) > | at FileInputStream. (FileInputStream.java:138) > | at FileInputStream. (FileInputStream.java:93) > | at (#10:1) > > jshell> try { InputStream is = new FileInputStream("bla"); } catch(Exception e) { e.printStackTrace(); } > java.io.FileNotFoundException: bla (Das System kann die angegebene Datei nicht finden) > at java.io.FileInputStream.open0(java.base at 9-ea/Native Method) > at java.io.FileInputStream.open(java.base at 9-ea/FileInputStream.java:195) > at java.io.FileInputStream.(java.base at 9-ea/FileInputStream.java:138) > at java.io.FileInputStream.(java.base at 9-ea/FileInputStream.java:93) > at REPL.$JShell$18.do_it$($JShell$18.java:9) > ... From jan.lahoda at oracle.com Mon Sep 26 19:07:16 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 26 Sep 2016 21:07:16 +0200 Subject: RFR 8166655: JShell: Process running JShell should not be blocked from exit by non-daemon data-transfer threads In-Reply-To: <57E6872F.3040704@oracle.com> References: <57E6872F.3040704@oracle.com> Message-ID: <57E971E4.70705@oracle.com> Seems OK. Jan On 24.9.2016 16:01, Robert Field wrote: > Please review -- > > Bug: > > JShell: Process running JShell should not be blocked from exit by > non-daemon data-transfer threads > https://bugs.openjdk.java.net/browse/JDK-8166655 > > Parent bug: > > JShell tests: jdk/jshell tests fail intermittently while cleaning > up threads after test > https://bugs.openjdk.java.net/browse/JDK-8163250 > > Related bug: > > JShell: JDIConnection leaks the input transfer thread on close > https://bugs.openjdk.java.net/browse/JDK-8158069 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8166655v0.webrev/ > > Thanks, > Robert > From bitterfoxc at gmail.com Mon Sep 26 19:51:38 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Mon, 26 Sep 2016 12:51:38 -0700 Subject: RFR 8145263: JShell API: Change the format of SourceCodeAnalysis#documentation In-Reply-To: <57E979DC.2060007@oracle.com> References: <566ED116.3080502@oracle.com> <56707E7E.4020704@oracle.com> <57E979DC.2060007@oracle.com> Message-ID: Hi Robert, Never mind! And I'm also sorry for having left this. I'll try updating webrev to current code base until 1/Oct. BTW, currently a lot of things in jshell are configurable, could signature of documentation also be configurable in future(JDK10 or 9.1 or ...)? Thank you, shinyafox(Shinya Yoshida) 2016-09-26 12:41 GMT-07:00 Robert Field : > In reviewing outstanding issues, we discovered this RFR which was left > hanging. > > Our sincere apologies for dropping the ball on this. > > We are juggling a lot, if we miss something like this in the future, > please let us know. > > I have made some changes in the issue, please note them. I know there > have been some underlying changes as well (parameter names from source). > > If you would be willing to update this RFR we will review promptly. > > Thank you and sorry, > Robert > > > On 12/15/15 17:07, ShinyaYoshida wrote: > > Hi Jan and Robert, > Thank you. > > I've filed: > https://bugs.openjdk.java.net/browse/JDK-8145473 > > Ok, I put the type parameters for the constructor before the > traditional(current) form: > http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.01/ > > Please review it again. > > Regards, > shinyafox(Shinya Yoshida) > > > 2015-12-16 5:56 GMT+09:00 Jan Lahoda : > >> Hi Shinya, >> >> On 14.12.2015 15:40, ShinyaYoshida wrote: >> >>> Hi Jan, >>> Thank you for your review. >>> >>> 2015-12-14 23:24 GMT+09:00 Jan Lahoda >> >: >>> >>> Hi Shinya, >>> >>> Generally, looks good, thanks for looking at this! Two comments: >>> -for parameter names, I was hoping we could get them from the >>> sources (if/when available), but we are not doing that now, and >>> hiding synthetic parameter names makes sense to me. So this is OK, >>> and if we at some point start to parse parameter names from the >>> sources, we can tweak the code to do the right thing. >>> >>> I think that there should be the issue for the parameter names. >>> Do you have the issue for that? >>> >> >> No issue for this yet. >> >> If not, should I create it? >>> >> >> Sure, thanks. >> >> >>> >>> -not sure if marking constructors with ".new" >>> ("type-name.new()") will be clear - do you think the >>> traditional form ("type-name()") is unclear? >>> >>> >>> When I consider the constructor with the generics like following, I >>> notice that the traditional(current) form is difficult to represent it. >>> class C { C(U u) {} } >>> So I choose that format which is like the constructor reference. >>> >> >> I think generic constructors (i.e. constructors that themselves have type >> parameters) are very uncommon, so I wouldn't optimize for those. Having the >> format nice for usual constructors is more important, I think, even if the >> format for these uncommon constructors would be uglier. >> >> Thanks, >> Jan >> >> >> >>> Another possible representation is "new >>> type-name()" which is similar to the invocation of >>> the constructor with generics. >>> >>> What do you think? >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> >>> Thanks, >>> Jan >>> >>> >>> On 13.12.2015 07:33, ShinyaYoshida wrote: >>> >>> Hi Jan and Robert, >>> I'd like to propose changing the format of >>> SourceCodeAnalysis#documentation. >>> >>> The detail of the change is on the issue 8145263: >>> https://bugs.openjdk.java.net/browse/JDK-8145263 >>> Please see it. >>> >>> You can see the more example in the test of my patch. >>> >>> Patch is here: >>> http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.00/ >>> >>> Please consider my proposal and review the patch. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> >>> > > From bitterfoxc at gmail.com Mon Sep 26 20:20:45 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Mon, 26 Sep 2016 13:20:45 -0700 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: <57E9569B.1090904@oracle.com> References: <57CDE39A.3020100@oracle.com> <57D069C0.8030009@oracle.com> <57D33CE9.9060305@oracle.com> <57D5BBEC.8060506@oracle.com> <57D6CA3F.4050309@oracle.com> <57D6DE8F.4070405@oracle.com> <57D6EEB1.4050506@oracle.com> <57D7189F.2070901@oracle.com> <57D71A2C.9030501@oracle.com> <57D74A77.5000905@oracle.com> <57D8289B.5030403@oracle.com> <57E4D485.80500@oracle.com> <57E9569B.1090904@oracle.com> Message-ID: Hi Robert, Thank you for asking for the internal review. I've updated and replaced the previous webrev! http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.11.langtools/ Regards, shinyafox(Shinya Yoshida) 2016-09-26 10:10 GMT-07:00 Robert Field : > That's great! > > I've submitted this to internal review of the new command-line options. > We should get that in less than a week. > > One nit, I've noticed that --help doesn't list the new -X option. > Borrowing from "java -help" this should be: > > -X Print help on non-standard options > > > Thanks! > > -Robert > > > > On 09/23/16 23:49, ShinyaYoshida wrote: > > Hi Robert, > > > 2016-09-23 0:06 GMT-07:00 Robert Field : > >> >> On 09/22/16 12:51, ShinyaYoshida wrote: >> >> Hi Robert and Jan, >> I've updated the webrev to add -C option and --add-exports option(as a >> non-standard option): >> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.10.langtools/ >> >> Could you review and give me a comment? >> >> >> Wow! This is so much simpler an approach! >> >> A couple little things and this is good... >> >> In JShellTool, should --add-exports have .withRequiredArg() rather than >> .withOptionalArg()? >> > Yeah! That's what I want to use!! > I've fixed > > >> >> I think >> >> 645 if (options.has("X")) { >> 646 printUsageX(); >> 647 } >> >> Should be up below "help", and, like "help", should abort by returning >> null. >> > Absolutely yes!! > > New version is here: > http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.11.langtools/ > > Regards, > shinyafox(ShinyaYoshida) > > >> >> Your comment looks fine. >> >> Test and resource file look good. >> >> Thanks, >> Robert >> >> >> >> >> Another issue is found until implementing: >> https://bugs.openjdk.java.net/browse/JDK-8166581 >> >> Could you confirm and address this? >> >> Regards, >> shinyafox(Shinya Yoshida)@JavaOne 20016 >> >> 2016-09-13 9:26 GMT-07:00 Robert Field : >> >>> >>> On 09/12/16 17:55, ShinyaYoshida wrote: >>> >>> Hi Jan and all, >>> I've confirmed your snippet. >>> Certainly it have a security problem and it should be avoided. >>> >>> I'll update my patch to add a new command-line option -C which give the >>> option to compiler. >>> >>> In addition to, I'd like to add a new command-line option --add-exports >>> / which is a short-circuit for "-J--add-exports >>> /=ALL-UNNAMED -C--add-exports >>> /=ALL-UNNAMED." >>> java and javac are also have --add-exports option, so it seems to me >>> that it is reasonable for jshell to have --add-exports option. >>> What do you think about this? >>> >>> Kind Regards, >>> shinyafox(Shinya Yoshida) >>> >>> >>> OK, great. >>> >>> I started to write that I didn't think you needed or wanted a -C >>> flag. But on further thought, that allows all kinds of flexibility that we >>> may not want to provide item by item -- for example: >>> --processor-module-path, --module-source-path, .... >>> There is a question: which compiles should these flags get applied to, >>> but it seems they would just be ignored where not needed, so probably all >>> of them. >>> >>> I notice --add-exports is on the -X help for both java and javac -- it >>> is non-standard. Seems wrong for it to be a non-standard option for those >>> two and a standard option for jshell. >>> >>> I think it is a question for Jigsaw people as to what module options: >>> >>> * should be directly jshell command-line options >>> * should be non-standard -X command-line options (if jshell has -X >>> options) >>> * obscure enough that users should use -R and -C >>> >>> -Robert >>> >>> >>> >>> >>> >>> 2016-09-13 9:38 GMT+09:00 Robert Field : >>> >>>> If our approach to security is "do nothing a user could not do with >>>> their own use of javac/java" (which we have yet to have validated) then if >>>> the SharedSecrets use in JShell requires the change to the module.info.java >>>> in java.base to add jdk.jshell, then that would be a violation. >>>> >>>> If this changeset gave access only to snippets executing via the JShell >>>> API maybe that would be OK. But it, as your exploit verifies, could easily >>>> be used by anyone to change module boundaries. >>>> >>>> Maybe there would be a hack that would allow only proper JShell use, >>>> but I don't see what that would be, and that sounds dangerous and >>>> unappealing. >>>> >>>> Command-line option only would match the original request and other >>>> tools. The implementation would closely match the implementation of '-R', >>>> being on the command-line of JShellTool and the API in JShell.Builder. >>>> Alas, this is mostly a rewrite, only some code in TaskFactory, >>>> ToolBasicTest, and maybe KullaTesting would be reusable. >>>> >>>> Bummer! >>>> >>>> But thanks for catching this Jan! >>>> >>>> -Robert >>>> >>>> >>>> >>>> On 09/12/16 14:12, Jan Lahoda wrote: >>>> >>>>> (Basically, the use of SharedSecrets in jdk.jshell seems highly >>>>> suspicious to me.) >>>>> >>>>> Jan >>>>> >>>>> On 12.9.2016 23:05, Jan Lahoda wrote: >>>>> >>>>>> On 12.9.2016 20:06, Robert Field wrote: >>>>>> >>>>>>> The jshell tool is built on the JShell API. Command-line options, >>>>>>> like >>>>>>> -R, pass to the remote process via the JShell API. -R would allow >>>>>>> --patch-module or --add-exports. Having addExports functionality >>>>>>> >>>>>> >>>>>> I am not much worried about --add-exports added using -R, that seems >>>>>> OK >>>>>> to me. This only affects a newly spawned JVM, and the API client could >>>>>> spawn it even without JShell, so not a problem IMO. >>>>>> >>>>>> What I am worried about is that using the most recent proposed patch >>>>>> (lwebrev.04.langtools), one can use the DirectExecutionControl to >>>>>> change >>>>>> module boundaries in the _currently running VM_. Please see the >>>>>> attached >>>>>> class to see what I mean - I didn't even have to create JShell as >>>>>> such, >>>>>> simply using DirectExecutionControl was enough. It probably does not >>>>>> even need some special privileges to achieve the result. >>>>>> >>>>>> Jan >>>>>> >>>>>> anywhere is jshell means having it in the JShell API. >>>>>>> >>>>>>> I believe this cycles us, to some degree, back to the security >>>>>>> discussion. What is our level of concern about a launched process >>>>>>> running pure JDK code? >>>>>>> >>>>>>> -Robert >>>>>>> >>>>>>> On 09/12/16 09:57, Jan Lahoda wrote: >>>>>>> >>>>>>>> [adding Jon] >>>>>>>> >>>>>>>> On 12.9.2016 17:31, Robert Field wrote: >>>>>>>> >>>>>>>>> Both javac and java have a --add-exports option, so it isn't >>>>>>>>> opening >>>>>>>>> anything that isn't already open. >>>>>>>>> I don't see how command-line options are any different that API in >>>>>>>>> terms >>>>>>>>> of exposure. >>>>>>>>> >>>>>>>> >>>>>>>> I think there's a huge difference between command line and an API, >>>>>>>> in >>>>>>>> at least two aspects: >>>>>>>> a) the person that controls the command line, has a lot of power in >>>>>>>> any case (they could do -Xbootclasspath/p: in 8 or --patch-module >>>>>>>> now >>>>>>>> to get around the boundaries). API users are much more restricted in >>>>>>>> what they can do. >>>>>>>> b) affecting the command line options is generally very hard - >>>>>>>> imagine >>>>>>>> library maintainers - how can they affect the command line setting? >>>>>>>> The only thing they can do is to write some documentation, but they >>>>>>>> cannot directly affect the command line. But they can call an API >>>>>>>> (and >>>>>>>> they can call it even reflectively). >>>>>>>> >>>>>>>> I believe it is generally undesirable to create APIs that allow to >>>>>>>> create holes in module boundaries. If you think that's something >>>>>>>> JShell needs, I think we need to take that to the Jigsaw team. >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>>> >>>>>>>>> -Robert >>>>>>>>> >>>>>>>>> >>>>>>>>> On 09/11/16 13:17, Jan Lahoda wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I apologize for not following this sooner. >>>>>>>>>> >>>>>>>>>> Looking at this, it seems to me the change would effectively >>>>>>>>>> allow to >>>>>>>>>> overcome the module boundary limitations using JShell - I don't >>>>>>>>>> think >>>>>>>>>> that's something that would be acceptable. We could take this to >>>>>>>>>> the >>>>>>>>>> Jigsaw team, but I don't think they would be happy about this. >>>>>>>>>> >>>>>>>>>> I wonder what exactly is the usecase here. Would it be sufficient >>>>>>>>>> if >>>>>>>>>> the jshell tool as such would allow command line options to break >>>>>>>>>> through the boundaries? We already have -R, which should allow to >>>>>>>>>> make >>>>>>>>>> holes to the boundaries when running the snippets, so maybe we >>>>>>>>>> just >>>>>>>>>> need to add something for compile-time? >>>>>>>>>> >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>>> On 11.9.2016 02:12, ShinyaYoshida wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> Please apply this webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>> 0.jdk/ >>>>>>>>>>> >>>>>>>>>> 00.jdk/> >>>>>>>>>>> Changing module-info is needed. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>> >>>>>>>>>>> 2016-09-10 7:51 GMT+09:00 Robert Field >>>>>>>>>> >: >>>>>>>>>>> >>>>>>>>>>> [audience reduced] >>>>>>>>>>> >>>>>>>>>>> BTW shinyafox, >>>>>>>>>>> >>>>>>>>>>> Building "make images" with this patch and the latest >>>>>>>>>>> jdk9/dev >>>>>>>>>>> bits >>>>>>>>>>> fails. Probably need to change module set-up -- >>>>>>>>>>> >>>>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>>>> xecution/DirectExecutionControl.java:33: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> error: package jdk.internal.misc does not exist >>>>>>>>>>> import jdk.internal.misc.JavaLangReflectModuleAccess; >>>>>>>>>>> ^ >>>>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>>>> xecution/DirectExecutionControl.java:34: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> error: package jdk.internal.misc does not exist >>>>>>>>>>> import jdk.internal.misc.SharedSecrets; >>>>>>>>>>> ^ >>>>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>>>> xecution/DirectExecutionControl.java:155: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> error: cannot find symbol >>>>>>>>>>> JavaLangReflectModuleAccess moduleAccess = >>>>>>>>>>> SharedSecrets.getJavaLangReflectModuleAccess(); >>>>>>>>>>> ^ >>>>>>>>>>> symbol: class JavaLangReflectModuleAccess >>>>>>>>>>> location: class DirectExecutionControl >>>>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>>>> xecution/DirectExecutionControl.java:155: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> error: cannot find symbol >>>>>>>>>>> JavaLangReflectModuleAccess moduleAccess = >>>>>>>>>>> SharedSecrets.getJavaLangReflectModuleAccess(); >>>>>>>>>>> ^ >>>>>>>>>>> symbol: variable SharedSecrets >>>>>>>>>>> location: class DirectExecutionControl >>>>>>>>>>> 4 errors >>>>>>>>>>> >>>>>>>>>>> -Robert >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 09/08/16 07:14, ShinyaYoshida wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Robert, >>>>>>>>>>>> Thank you for your pointing out. >>>>>>>>>>>> I've understood. >>>>>>>>>>>> >>>>>>>>>>>> Here is new webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>> 4.langtools/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> v.04.langtools/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> In this version, >>>>>>>>>>>> - ExecutionControl#addExports throws BadArgumentException >>>>>>>>>>>> which is >>>>>>>>>>>> extends ExecutionControlException if module or package are >>>>>>>>>>>> not >>>>>>>>>>>> found. >>>>>>>>>>>> - JShell#addExports throws IllegalArgumentException when >>>>>>>>>>>> BadArgumentException is occured >>>>>>>>>>>> >>>>>>>>>>>> I've notice that /classpath and addToClasspath says nothing >>>>>>>>>>>> when >>>>>>>>>>>> it doesn't exist. >>>>>>>>>>>> I think it should be reported, so I've created a issue: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165650 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> What do you think? >>>>>>>>>>>> >>>>>>>>>>>> Please review me again! >>>>>>>>>>>> >>>>>>>>>>>> Thank you, >>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2016-09-08 4:25 GMT+09:00 Robert Field < >>>>>>>>>>>> robert.field at oracle.com >>>>>>>>>>>> >: >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the update. >>>>>>>>>>>> >>>>>>>>>>>> l10n.properties -- >>>>>>>>>>>> >>>>>>>>>>>> Oops, typo: the help.set.exports entry got pasted again >>>>>>>>>>>> instead of help.retain.exports >>>>>>>>>>>> >>>>>>>>>>>> Sorry I was unclear about the exceptions... >>>>>>>>>>>> >>>>>>>>>>>> On the execution side -- >>>>>>>>>>>> >>>>>>>>>>>> ExecutionControl.InternalException is only for >>>>>>>>>>>> unexpected >>>>>>>>>>>> failures. >>>>>>>>>>>> >>>>>>>>>>>> In this case you are dealing an expected exception that >>>>>>>>>>>> occurs >>>>>>>>>>>> when the user gives the wrong input. None of the >>>>>>>>>>>> existing >>>>>>>>>>>> ExecutionControlException subclasses are good >>>>>>>>>>>> candidates, >>>>>>>>>>>> so a >>>>>>>>>>>> new ExecutionControlException subclass is needed. I was >>>>>>>>>>>> suggesting "BadArgumentException" for this exception. >>>>>>>>>>>> None of >>>>>>>>>>>> ExecutionControlException subclasses are seen at the >>>>>>>>>>>> JShell >>>>>>>>>>>> level -- this should be the case for this new one as >>>>>>>>>>>> well. >>>>>>>>>>>> >>>>>>>>>>>> I don't what kind of exceptions are thrown by >>>>>>>>>>>> moduleAccess.addExportsToAllUnnamed(target, pack), but >>>>>>>>>>>> that >>>>>>>>>>>> message text or some other appropriate descriptive >>>>>>>>>>>> message >>>>>>>>>>>> text needs to be placed in the BadArgumentException >>>>>>>>>>>> message so >>>>>>>>>>>> it can be seen all the way up (including the >>>>>>>>>>>> JShellTool). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On the JShell class -- >>>>>>>>>>>> >>>>>>>>>>>> Incorrect arguments on JShell API methods generate the >>>>>>>>>>>> Java >>>>>>>>>>>> standard java.lang.IllegalArgumentException (see, for >>>>>>>>>>>> example, >>>>>>>>>>>> drop() or status() ) -- so, this is also the appropriate >>>>>>>>>>>> exception for JShell.addExports(). Thus, >>>>>>>>>>>> JShell.addExports() >>>>>>>>>>>> catchs the BadArgumentException, turning it into an >>>>>>>>>>>> IllegalArgumentException. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 09/07/16 06:10, ShinyaYoshida wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>> Thank you for your helping. >>>>>>>>>>>>> >>>>>>>>>>>>> I've update webrev according to your comments. >>>>>>>>>>>>> If I'm missing your meaning, I'm sorry. Please point >>>>>>>>>>>>> it. >>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>> 3.langtools/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> v.03.langtools/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Now, >>>>>>>>>>>>> - JShell#addExports will throw BadArgumentException >>>>>>>>>>>>> when >>>>>>>>>>>>> module or package is wrong, which is check exception. >>>>>>>>>>>>> - JShellTool checks that exception. >>>>>>>>>>>>> - ExecutionControl#addExports throws InternalException >>>>>>>>>>>>> when >>>>>>>>>>>>> something is wrong. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2016-09-06 6:28 GMT+09:00 Robert Field >>>>>>>>>>>>> >>>>>>>>>>>> robert.field at oracle.com>>: >>>>>>>>>>>>> >>>>>>>>>>>>> Code looks good. Needs docs I promised (see >>>>>>>>>>>>> below). >>>>>>>>>>>>> >>>>>>>>>>>>> As to completion issue you created, I see you >>>>>>>>>>>>> already >>>>>>>>>>>>> added discussion and tests. I added your >>>>>>>>>>>>> completion >>>>>>>>>>>>> code. >>>>>>>>>>>>> >>>>>>>>>>>>> Below is my suggested doc... >>>>>>>>>>>>> >>>>>>>>>>>>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> /set exports \n\t\ >>>>>>>>>>>>> Allow access to some of the unexported types >>>>>>>>>>>>> of a >>>>>>>>>>>>> module\n\n\ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> /retain exports \n\t\ >>>>>>>>>>>>> Allow access to some of the unexported types >>>>>>>>>>>>> of a >>>>>>>>>>>>> module\n\n\ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> help.set.exports=\ >>>>>>>>>>>>> Set a package to add to those exported to >>>>>>>>>>>>> snippets.\n\ >>>>>>>>>>>>> \n\t\ >>>>>>>>>>>>> /set exports \n\ >>>>>>>>>>>>> \n\ >>>>>>>>>>>>> Where is the module from which to export >>>>>>>>>>>>> .\n\ >>>>>>>>>>>>> Where is the package to export to >>>>>>>>>>>>> snippets.\n >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> help.retain.exports=\ >>>>>>>>>>>>> Retain a package to add to those exported to >>>>>>>>>>>>> snippets.\n\ >>>>>>>>>>>>> \n\t\ >>>>>>>>>>>>> /retain exports \n\ >>>>>>>>>>>>> \n\ >>>>>>>>>>>>> Where is the module from which to export >>>>>>>>>>>>> .\n\ >>>>>>>>>>>>> Where is the package to export to >>>>>>>>>>>>> snippets.\n >>>>>>>>>>>>> >>>>>>>>>>>>> [I notice that 'snippet' is used in doc without >>>>>>>>>>>>> being >>>>>>>>>>>>> defined. If, while you are it, you change the help >>>>>>>>>>>>> for >>>>>>>>>>>>> /list to define it:] >>>>>>>>>>>>> >>>>>>>>>>>>> help.list =\ >>>>>>>>>>>>> Show the source of snippets, prefaced with the >>>>>>>>>>>>> snippet id >>>>>>>>>>>>> (a snippet is a chunk of code that the jshell tool >>>>>>>>>>>>> evaluates -- the code you enter at the prompt is a >>>>>>>>>>>>> snippet).\n\ >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/JShell.java -- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> /** >>>>>>>>>>>>> * Add a package to those exported to snippets. >>>>>>>>>>>>> * @param module The module from which to >>>>>>>>>>>>> export >>>>>>>>>>>>> * @param pack The package to export >>>>>>>>>>>>> * @throws NullPointerException if arguments >>>>>>>>>>>>> are >>>>>>>>>>>>> null. >>>>>>>>>>>>> * @throws IllegalStateException if this {@code >>>>>>>>>>>>> JShell} instance is closed. >>>>>>>>>>>>> * @throws XYZ if .... >>>>>>>>>>>>> */ >>>>>>>>>>>>> >>>>>>>>>>>>> OK, actually this code should change. Like >>>>>>>>>>>>> addToClasspath above it, it should return void. It >>>>>>>>>>>>> looks >>>>>>>>>>>>> like under normal operation it can fail -- the >>>>>>>>>>>>> failure >>>>>>>>>>>>> should be reported with an exception. >>>>>>>>>>>>> What are the failure modes? >>>>>>>>>>>>> IllegalArgumentException >>>>>>>>>>>>> would be likely choice at the JShell API layer. But >>>>>>>>>>>>> then >>>>>>>>>>>>> the exception needs to be propagated there. >>>>>>>>>>>>> Since none of the existing exceptions is a match, >>>>>>>>>>>>> this >>>>>>>>>>>>> means a new ExecutionControlException. Maybe >>>>>>>>>>>>> something >>>>>>>>>>>>> general, like BadUserArgumentException. >>>>>>>>>>>>> Note: I've also added IllegalStateException -- >>>>>>>>>>>>> this can >>>>>>>>>>>>> be thrown when you get EngineTerminationException. >>>>>>>>>>>>> Also, typo, the second "module cannot be null" >>>>>>>>>>>>> should be >>>>>>>>>>>>> "package cannot be null" >>>>>>>>>>>>> >>>>>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteCodes.java >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> The comment you have is fine. Just remove PLEASE >>>>>>>>>>>>> REVISE >>>>>>>>>>>>> THE COMMENT >>>>>>>>>>>>> >>>>>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl >>>>>>>>>>>>> .java >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> /** >>>>>>>>>>>>> * Add a package to those exported to snippets. >>>>>>>>>>>>> * @param module The module from which to >>>>>>>>>>>>> export >>>>>>>>>>>>> * @param pack The package to export >>>>>>>>>>>>> * @throws EngineTerminationException the >>>>>>>>>>>>> execution >>>>>>>>>>>>> engine has terminated >>>>>>>>>>>>> * @throws .... >>>>>>>>>>>>> * @throws InternalException an internal >>>>>>>>>>>>> problem >>>>>>>>>>>>> occurred >>>>>>>>>>>>> */ >>>>>>>>>>>>> >>>>>>>>>>>>> Plus add the bad argument exception. >>>>>>>>>>>>> Whatever it is, should be added to >>>>>>>>>>>>> extensionCommand() >>>>>>>>>>>>> exceptions. >>>>>>>>>>>>> >>>>>>>>>>>>> Robert >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 09/05/16 08:02, ShinyaYoshida wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> I've update webrev of langtools: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>>> 2.langtools/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> v.02.langtools/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I added an issue for the completion feature. >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165445 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2016-09-05 22:49 GMT+09:00 ShinyaYoshida >>>>>>>>>>>>>> >>>>>>>>>>>>> bitterfoxc at gmail.com>>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>> Thank you for the review. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I totally agree with you. >>>>>>>>>>>>>> I also think that availableModules and >>>>>>>>>>>>>> availablePackages(module) are worthless >>>>>>>>>>>>>> excepting >>>>>>>>>>>>>> for the command completion feature. >>>>>>>>>>>>>> I'd like to avoid adding these APIs which >>>>>>>>>>>>>> have not >>>>>>>>>>>>>> been speculated and revised because if API is >>>>>>>>>>>>>> once >>>>>>>>>>>>>> added, it is too difficult to remove than >>>>>>>>>>>>>> adding. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So currently, I'll remove the completion >>>>>>>>>>>>>> feature >>>>>>>>>>>>>> for >>>>>>>>>>>>>> /set or /retain exports and make the issue to >>>>>>>>>>>>>> JBS to >>>>>>>>>>>>>> add completion feature for them in future. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll update the webrev. So please review it >>>>>>>>>>>>>> again >>>>>>>>>>>>>> later. >>>>>>>>>>>>>> When the silently evaluation feature is >>>>>>>>>>>>>> added, I'd >>>>>>>>>>>>>> like to work for the completion feature again. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2016-09-05 15:00 GMT+09:00 Robert Field >>>>>>>>>>>>>> >>>>>>>>>>>>> >: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 09/03/16 05:07, ShinyaYoshida wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> I've updated my patch, new webrev is >>>>>>>>>>>>>>> here: >>>>>>>>>>>>>>> webrev.01.langtools: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>>>> 1.langtools/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> v.01.langtools/> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> webrev.01.jdk: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>>>> 1.jdk/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> v.01.jdk/> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (Same as previous) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In this version, >>>>>>>>>>>>>>> - rename /set add-exports to /set exports >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> OK >>>>>>>>>>>>>> >>>>>>>>>>>>>> - add /retain exports >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The /retain implementation looks good. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - add tests >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Well tested >>>>>>>>>>>>>> >>>>>>>>>>>>>> - move EXT_CMD_XXX into RemoteCodes >>>>>>>>>>>>>>> - make RemoteCodes public and move it >>>>>>>>>>>>>>> into >>>>>>>>>>>>>>> jdk.jshell.execution.code which is >>>>>>>>>>>>>>> module-private >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, here, in addition to addExports, >>>>>>>>>>>>>> there are >>>>>>>>>>>>>> two more methods added to the API >>>>>>>>>>>>>> availableModules() and >>>>>>>>>>>>>> availablePackage(String >>>>>>>>>>>>>> module). >>>>>>>>>>>>>> I see how in rare cases they could be >>>>>>>>>>>>>> useful. >>>>>>>>>>>>>> And the rare case that causes them to be >>>>>>>>>>>>>> present >>>>>>>>>>>>>> is for command completion in the tool. >>>>>>>>>>>>>> What are the options: >>>>>>>>>>>>>> >>>>>>>>>>>>>> (1) Add them to the API. If it is in the >>>>>>>>>>>>>> API >>>>>>>>>>>>>> then it is a first-class form of >>>>>>>>>>>>>> functionality >>>>>>>>>>>>>> and should be treated as such in execution >>>>>>>>>>>>>> support (as a command) >>>>>>>>>>>>>> (2) Not support them and not support >>>>>>>>>>>>>> command >>>>>>>>>>>>>> completion for /set exports. Command >>>>>>>>>>>>>> completion >>>>>>>>>>>>>> is not supported in much more common >>>>>>>>>>>>>> cases. >>>>>>>>>>>>>> Then we could support command completion >>>>>>>>>>>>>> in >>>>>>>>>>>>>> the >>>>>>>>>>>>>> future (see (3)). >>>>>>>>>>>>>> (3) What these commands do is simply >>>>>>>>>>>>>> execute >>>>>>>>>>>>>> an expression on the remote side. But we >>>>>>>>>>>>>> already have a mechanism to execute >>>>>>>>>>>>>> expressions >>>>>>>>>>>>>> on the remote side: Snippets. >>>>>>>>>>>>>> That leaves a problem: we wouldn't >>>>>>>>>>>>>> want >>>>>>>>>>>>>> these Snippets to be seen by the user, >>>>>>>>>>>>>> but we >>>>>>>>>>>>>> have a solution for that the tool uses the >>>>>>>>>>>>>> idGenerator. >>>>>>>>>>>>>> Another problem is that, by >>>>>>>>>>>>>> default >>>>>>>>>>>>>> and >>>>>>>>>>>>>> with no current way around the default, >>>>>>>>>>>>>> expressions generate temp-variables. My >>>>>>>>>>>>>> intention was to make this configurable >>>>>>>>>>>>>> -- see >>>>>>>>>>>>>> Eval.shouldGenTempVar(...). >>>>>>>>>>>>>> >>>>>>>>>>>>>> One goal I've been using in the design of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> API is to keep it as small and simple as >>>>>>>>>>>>>> possible. This improves maintainability, >>>>>>>>>>>>>> but >>>>>>>>>>>>>> much more importantly makes the API >>>>>>>>>>>>>> easier to >>>>>>>>>>>>>> learn and use. >>>>>>>>>>>>>> So, for something to warrant inclusion it >>>>>>>>>>>>>> should >>>>>>>>>>>>>> be generally useful and have no other way >>>>>>>>>>>>>> of >>>>>>>>>>>>>> being achieved -- neither is true of >>>>>>>>>>>>>> these two >>>>>>>>>>>>>> queries. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My suggestion, particularly in light of >>>>>>>>>>>>>> how >>>>>>>>>>>>>> late >>>>>>>>>>>>>> in the release this is, would be (2). >>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2016-09-03 18:15 GMT+09:00 ShinyaYoshida >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>>> Thank you for reviewing. >>>>>>>>>>>>>>> I'll update my patch later. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2016-09-02 11:38 GMT+09:00 Robert >>>>>>>>>>>>>>> Field >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks shiyafox! This is a >>>>>>>>>>>>>>> significant >>>>>>>>>>>>>>> piece of code! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As to your questions -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > I wonder if you could work on >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> documentation of the API and the >>>>>>>>>>>>>>> tool >>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, I will do API and tool docs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > Subcommand of /set is >>>>>>>>>>>>>>> reasonable? >>>>>>>>>>>>>>> Similar command, /classpath, to >>>>>>>>>>>>>>> make >>>>>>>>>>>>>>> users available to use new >>>>>>>>>>>>>>> packages is >>>>>>>>>>>>>>> not a subcommand of /set. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, I think /set exports is >>>>>>>>>>>>>>> best. >>>>>>>>>>>>>>> And, yes, /classpath is >>>>>>>>>>>>>>> inconsistent, >>>>>>>>>>>>>>> it should be /set classpath, >>>>>>>>>>>>>>> that can >>>>>>>>>>>>>>> be a separate task, unless you >>>>>>>>>>>>>>> want to >>>>>>>>>>>>>>> roll that in. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I see, I've created the issue to move >>>>>>>>>>>>>>> /classpath to /set classpath: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165405 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > Should we need retain feature >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> this? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> All /set have a /retain >>>>>>>>>>>>>>> counterpart -- >>>>>>>>>>>>>>> we should maintain that >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ok, I'll add /retain exports. >>>>>>>>>>>>>>> I've also create the issue for >>>>>>>>>>>>>>> retaining >>>>>>>>>>>>>>> classpath: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165406 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As to the code review: Looks >>>>>>>>>>>>>>> good to >>>>>>>>>>>>>>> me, just minor questions/issues >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> JShellTool.java: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * As discussed /set add-exports >>>>>>>>>>>>>>> => >>>>>>>>>>>>>>> /set >>>>>>>>>>>>>>> exports >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * Nit: a comment got moved out of >>>>>>>>>>>>>>> place >>>>>>>>>>>>>>> line 1194(old) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> JShell.java: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * EXT_CMD_AVAILABLE_MODULES and >>>>>>>>>>>>>>> EXT_CMD_AVAILABLE_PACKAGES, these >>>>>>>>>>>>>>> should be referenced via >>>>>>>>>>>>>>> RemoteCodes.java rather than be >>>>>>>>>>>>>>> coped. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Absolutely! I'd like to move these >>>>>>>>>>>>>>> into >>>>>>>>>>>>>>> RemoteCodes but it is package-private >>>>>>>>>>>>>>> class >>>>>>>>>>>>>>> and cannot be referred from JShell. >>>>>>>>>>>>>>> Can I make RemoteCodes public and >>>>>>>>>>>>>>> move it >>>>>>>>>>>>>>> to another module-private package >>>>>>>>>>>>>>> like >>>>>>>>>>>>>>> jdk.jshell.execution.code? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * Which leads me to another >>>>>>>>>>>>>>> question: >>>>>>>>>>>>>>> why is addExports a command and >>>>>>>>>>>>>>> these >>>>>>>>>>>>>>> two are extensions. It seems >>>>>>>>>>>>>>> fine, >>>>>>>>>>>>>>> just >>>>>>>>>>>>>>> curious. I notice that extensions >>>>>>>>>>>>>>> are a >>>>>>>>>>>>>>> lot less code -- ;-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Exporting module and package is >>>>>>>>>>>>>>> similar to >>>>>>>>>>>>>>> adding classpath to platform, so I >>>>>>>>>>>>>>> made >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> addExports a command like >>>>>>>>>>>>>>> setClasspath. >>>>>>>>>>>>>>> And it should be added as API because >>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>> very basic feature. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TaskFactory.java: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * Question: the "/" separator >>>>>>>>>>>>>>> between >>>>>>>>>>>>>>> module and package is that >>>>>>>>>>>>>>> platform >>>>>>>>>>>>>>> independent? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It seems to me that "{module}/{path}" >>>>>>>>>>>>>>> format for --add-exports option of >>>>>>>>>>>>>>> javac is >>>>>>>>>>>>>>> platform independent. >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> DefaultLoaderDelegate.java: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * Jan, can you look at this code? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Robert >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 09/01/16 05:36, ShinyaYoshida >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> I've implemented this >>>>>>>>>>>>>>> feature to >>>>>>>>>>>>>>> JShell API and Tool with full >>>>>>>>>>>>>>> completion: >>>>>>>>>>>>>>> Bugs: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8154714 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> jdk: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>>>> 0.jdk/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> v.00.jdk/> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> v.00.jdk/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> v.00.jdk/>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> langtools: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>>>> 0.langtools/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> v.00.langtools/> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> v.00.langtools/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> v.00.langtools/>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is missing the train of >>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>> 9.0 but it could catch the >>>>>>>>>>>>>>> train of >>>>>>>>>>>>>>> Java 9.1 or later. >>>>>>>>>>>>>>> I want to get your comments >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> jshell> /set add-exports >>>>>>>>>>>>>>> jdk.jconsole >>>>>>>>>>>>>>> sun.tools.jconsole >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> jshell> import >>>>>>>>>>>>>>> sun.tools.jconsole.* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> jshell> >>>>>>>>>>>>>>> LocalVirtualMachine.getAllVirtualMachines().forEach((k, >>>>>>>>>>>>>>> v) -> System.out.println(k + >>>>>>>>>>>>>>> ":" >>>>>>>>>>>>>>> + v)) >>>>>>>>>>>>>>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>>>>>>>>>>>>>> 10826:jdk.jshell.execution.RemoteExecutionControl >>>>>>>>>>>>>>> 35548 >>>>>>>>>>>>>>> 28447:org.netbeans.Main --cachedir >>>>>>>>>>>>>>> /home/bitter_fox/.cache/netbeans/8.0.1 >>>>>>>>>>>>>>> --userdir >>>>>>>>>>>>>>> /home/bitter_fox/.netbeans/8.0.1 >>>>>>>>>>>>>>> --branding nb >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Currently, there is no >>>>>>>>>>>>>>> testing, so >>>>>>>>>>>>>>> it will be required to add >>>>>>>>>>>>>>> test. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>> >>> >> >> > > From jan.lahoda at oracle.com Mon Sep 26 20:29:10 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 26 Sep 2016 22:29:10 +0200 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: References: <57CDE39A.3020100@oracle.com> <57D069C0.8030009@oracle.com> <57D33CE9.9060305@oracle.com> <57D5BBEC.8060506@oracle.com> <57D6CA3F.4050309@oracle.com> <57D6DE8F.4070405@oracle.com> <57D6EEB1.4050506@oracle.com> <57D7189F.2070901@oracle.com> <57D71A2C.9030501@oracle.com> <57D74A77.5000905@oracle.com> <57D8289B.5030403@oracle.com> <57E4D485.80500@oracle.com> <57E9569B.1090904@oracle.com> Message-ID: <57E98516.6090309@oracle.com> Seems OK to me. Jan On 26.9.2016 22:20, ShinyaYoshida wrote: > Hi Robert, > Thank you for asking for the internal review. > > I've updated and replaced the previous webrev! > http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.11.langtools/ > > Regards, > shinyafox(Shinya Yoshida) > > 2016-09-26 10:10 GMT-07:00 Robert Field >: > > That's great! > > I've submitted this to internal review of the new command-line > options. We should get that in less than a week. > > One nit, I've noticed that --help doesn't list the new -X option. > Borrowing from "java -help" this should be: > > -X Print help on non-standard options > > > Thanks! > > -Robert > > > > On 09/23/16 23:49, ShinyaYoshida wrote: >> Hi Robert, >> >> >> 2016-09-23 0:06 GMT-07:00 Robert Field > >: >> >> >> On 09/22/16 12:51, ShinyaYoshida wrote: >>> Hi Robert and Jan, >>> I've updated the webrev to add -C option and --add-exports >>> option(as a non-standard option): >>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.10.langtools/ >>> >>> >>> Could you review and give me a comment? >> >> Wow! This is so much simpler an approach! >> >> A couple little things and this is good... >> >> In JShellTool, should --add-exports have .withRequiredArg() >> rather than .withOptionalArg()? >> >> Yeah! That's what I want to use!! >> I've fixed >> >> >> I think >> >> 645 if (options.has("X")) { >> 646 printUsageX(); >> 647 } >> >> Should be up below "help", and, like "help", should abort by >> returning null. >> >> Absolutely yes!! >> >> New version is here: >> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.11.langtools/ >> >> >> Regards, >> shinyafox(ShinyaYoshida) >> >> >> Your comment looks fine. >> >> Test and resource file look good. >> >> Thanks, >> Robert >> >> >> >>> >>> Another issue is found until implementing: >>> https://bugs.openjdk.java.net/browse/JDK-8166581 >>> >>> >>> Could you confirm and address this? >>> >>> Regards, >>> shinyafox(Shinya Yoshida)@JavaOne 20016 >>> >>> 2016-09-13 9:26 GMT-07:00 Robert Field >>> >: >>> >>> >>> On 09/12/16 17:55, ShinyaYoshida wrote: >>>> Hi Jan and all, >>>> I've confirmed your snippet. >>>> Certainly it have a security problem and it should be >>>> avoided. >>>> >>>> I'll update my patch to add a new command-line option -C >>>> which give the option to compiler. >>>> >>>> In addition to, I'd like to add a new command-line >>>> option --add-exports / which is a >>>> short-circuit for "-J--add-exports >>>> /=ALL-UNNAMED -C--add-exports >>>> /=ALL-UNNAMED." >>>> java and javac are also have --add-exports option, so it >>>> seems to me that it is reasonable for jshell to have >>>> --add-exports option. >>>> What do you think about this? >>>> >>>> Kind Regards, >>>> shinyafox(Shinya Yoshida) >>> >>> OK, great. >>> >>> I started to write that I didn't think you needed or >>> wanted a -C flag. But on further thought, that >>> allows all kinds of flexibility that we may not want to >>> provide item by item -- for example: >>> --processor-module-path, --module-source-path, .... >>> There is a question: which compiles should these flags >>> get applied to, but it seems they would just be ignored >>> where not needed, so probably all of them. >>> >>> I notice --add-exports is on the -X help for both java >>> and javac -- it is non-standard. Seems wrong for it to >>> be a non-standard option for those two and a standard >>> option for jshell. >>> >>> I think it is a question for Jigsaw people as to what >>> module options: >>> >>> * should be directly jshell command-line options >>> * should be non-standard -X command-line options (if >>> jshell has -X options) >>> * obscure enough that users should use -R and -C >>> >>> -Robert >>> >>> >>> >>>> >>>> >>>> 2016-09-13 9:38 GMT+09:00 Robert Field >>>> >: >>>> >>>> If our approach to security is "do nothing a user >>>> could not do with their own use of javac/java" >>>> (which we have yet to have validated) then if the >>>> SharedSecrets use in JShell requires the change to >>>> the module.info.java in java.base to add jdk.jshell, >>>> then that would be a violation. >>>> >>>> If this changeset gave access only to snippets >>>> executing via the JShell API maybe that would be >>>> OK. But it, as your exploit verifies, could easily >>>> be used by anyone to change module boundaries. >>>> >>>> Maybe there would be a hack that would allow only >>>> proper JShell use, but I don't see what that would >>>> be, and that sounds dangerous and unappealing. >>>> >>>> Command-line option only would match the original >>>> request and other tools. The implementation would >>>> closely match the implementation of '-R', being on >>>> the command-line of JShellTool and the API in >>>> JShell.Builder. >>>> Alas, this is mostly a rewrite, only some code in >>>> TaskFactory, ToolBasicTest, and maybe KullaTesting >>>> would be reusable. >>>> >>>> Bummer! >>>> >>>> But thanks for catching this Jan! >>>> >>>> -Robert >>>> >>>> >>>> >>>> On 09/12/16 14:12, Jan Lahoda wrote: >>>> >>>> (Basically, the use of SharedSecrets in >>>> jdk.jshell seems highly suspicious to me.) >>>> >>>> Jan >>>> >>>> On 12.9.2016 23:05, Jan Lahoda wrote: >>>> >>>> On 12.9.2016 20:06, Robert Field wrote: >>>> >>>> The jshell tool is built on the JShell >>>> API. Command-line options, like >>>> -R, pass to the remote process via the >>>> JShell API. -R would allow >>>> --patch-module or --add-exports. Having >>>> addExports functionality >>>> >>>> >>>> I am not much worried about --add-exports >>>> added using -R, that seems OK >>>> to me. This only affects a newly spawned >>>> JVM, and the API client could >>>> spawn it even without JShell, so not a >>>> problem IMO. >>>> >>>> What I am worried about is that using the >>>> most recent proposed patch >>>> (lwebrev.04.langtools), one can use the >>>> DirectExecutionControl to change >>>> module boundaries in the _currently running >>>> VM_. Please see the attached >>>> class to see what I mean - I didn't even >>>> have to create JShell as such, >>>> simply using DirectExecutionControl was >>>> enough. It probably does not >>>> even need some special privileges to achieve >>>> the result. >>>> >>>> Jan >>>> >>>> anywhere is jshell means having it in >>>> the JShell API. >>>> >>>> I believe this cycles us, to some >>>> degree, back to the security >>>> discussion. What is our level of >>>> concern about a launched process >>>> running pure JDK code? >>>> >>>> -Robert >>>> >>>> On 09/12/16 09:57, Jan Lahoda wrote: >>>> >>>> [adding Jon] >>>> >>>> On 12.9.2016 17:31, Robert Field wrote: >>>> >>>> Both javac and java have a >>>> --add-exports option, so it >>>> isn't opening >>>> anything that isn't already open. >>>> I don't see how command-line >>>> options are any different that >>>> API in >>>> terms >>>> of exposure. >>>> >>>> >>>> I think there's a huge difference >>>> between command line and an API, in >>>> at least two aspects: >>>> a) the person that controls the >>>> command line, has a lot of power in >>>> any case (they could do >>>> -Xbootclasspath/p: in 8 or >>>> --patch-module now >>>> to get around the boundaries). API >>>> users are much more restricted in >>>> what they can do. >>>> b) affecting the command line >>>> options is generally very hard - imagine >>>> library maintainers - how can they >>>> affect the command line setting? >>>> The only thing they can do is to >>>> write some documentation, but they >>>> cannot directly affect the command >>>> line. But they can call an API (and >>>> they can call it even reflectively). >>>> >>>> I believe it is generally >>>> undesirable to create APIs that allow to >>>> create holes in module boundaries. >>>> If you think that's something >>>> JShell needs, I think we need to >>>> take that to the Jigsaw team. >>>> >>>> Jan >>>> >>>> >>>> -Robert >>>> >>>> >>>> On 09/11/16 13:17, Jan Lahoda wrote: >>>> >>>> Hi, >>>> >>>> I apologize for not >>>> following this sooner. >>>> >>>> Looking at this, it seems to >>>> me the change would >>>> effectively allow to >>>> overcome the module boundary >>>> limitations using JShell - I >>>> don't think >>>> that's something that would >>>> be acceptable. We could take >>>> this to the >>>> Jigsaw team, but I don't >>>> think they would be happy >>>> about this. >>>> >>>> I wonder what exactly is the >>>> usecase here. Would it be >>>> sufficient if >>>> the jshell tool as such >>>> would allow command line >>>> options to break >>>> through the boundaries? We >>>> already have -R, which >>>> should allow to make >>>> holes to the boundaries when >>>> running the snippets, so >>>> maybe we just >>>> need to add something for >>>> compile-time? >>>> >>>> Jan >>>> >>>> On 11.9.2016 02:12, >>>> ShinyaYoshida wrote: >>>> >>>> Hi, >>>> Please apply this webrev: >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.jdk/ >>>> >>>> >>> > >>>> >>>> Changing module-info is >>>> needed. >>>> >>>> Thanks, >>>> shinyafox(Shinya Yoshida) >>>> >>>> 2016-09-10 7:51 >>>> GMT+09:00 Robert Field >>>> >>> >>>> >>> >>: >>>> >>>> [audience reduced] >>>> >>>> BTW shinyafox, >>>> >>>> Building "make >>>> images" with this patch >>>> and the latest jdk9/dev >>>> bits >>>> fails. Probably need >>>> to change module set-up -- >>>> >>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/execution/DirectExecutionControl.java:33: >>>> >>>> >>>> >>>> >>>> error: package >>>> jdk.internal.misc does >>>> not exist >>>> import >>>> jdk.internal.misc.JavaLangReflectModuleAccess; >>>> ^ >>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/execution/DirectExecutionControl.java:34: >>>> >>>> >>>> >>>> >>>> error: package >>>> jdk.internal.misc does >>>> not exist >>>> import >>>> jdk.internal.misc.SharedSecrets; >>>> ^ >>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/execution/DirectExecutionControl.java:155: >>>> >>>> >>>> >>>> >>>> error: cannot find >>>> symbol >>>> JavaLangReflectModuleAccess >>>> moduleAccess = >>>> SharedSecrets.getJavaLangReflectModuleAccess(); >>>> ^ >>>> symbol: class >>>> JavaLangReflectModuleAccess >>>> location: class >>>> DirectExecutionControl >>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/execution/DirectExecutionControl.java:155: >>>> >>>> >>>> >>>> >>>> error: cannot find >>>> symbol >>>> JavaLangReflectModuleAccess >>>> moduleAccess = >>>> SharedSecrets.getJavaLangReflectModuleAccess(); >>>> ^ >>>> symbol: variable >>>> SharedSecrets >>>> location: class >>>> DirectExecutionControl >>>> 4 errors >>>> >>>> -Robert >>>> >>>> >>>> On 09/08/16 07:14, >>>> ShinyaYoshida wrote: >>>> >>>> Hi Robert, >>>> Thank you for >>>> your pointing out. >>>> I've understood. >>>> >>>> Here is new webrev: >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.04.langtools/ >>>> >>>> >>>> >>>> >>>> >>>> >>> > >>>> >>>> >>>> >>>> >>>> >>>> In this version, >>>> - >>>> ExecutionControl#addExports >>>> throws >>>> BadArgumentException >>>> which is >>>> extends >>>> ExecutionControlException >>>> if module or package >>>> are not >>>> found. >>>> - >>>> JShell#addExports >>>> throws >>>> IllegalArgumentException >>>> when >>>> BadArgumentException >>>> is occured >>>> >>>> I've notice that >>>> /classpath and >>>> addToClasspath says >>>> nothing when >>>> it doesn't exist. >>>> I think it >>>> should be reported, >>>> so I've created a issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8165650 >>>> >>>> >>> > >>>> >>>> What do you think? >>>> >>>> Please review me >>>> again! >>>> >>>> Thank you, >>>> shinyafox(Shinya >>>> Yoshida) >>>> >>>> >>>> 2016-09-08 4:25 >>>> GMT+09:00 Robert >>>> Field >>>> >>> >>>> >>> >>: >>>> >>>> Thanks for >>>> the update. >>>> >>>> l10n.properties -- >>>> >>>> Oops, typo: >>>> the help.set.exports >>>> entry got pasted again >>>> instead of >>>> help.retain.exports >>>> >>>> Sorry I was >>>> unclear about the >>>> exceptions... >>>> >>>> On the >>>> execution side -- >>>> >>>> ExecutionControl.InternalException >>>> is only for unexpected >>>> failures. >>>> >>>> In this case >>>> you are dealing an >>>> expected exception that >>>> occurs >>>> when the >>>> user gives the wrong >>>> input. None of the >>>> existing >>>> ExecutionControlException >>>> subclasses are good >>>> candidates, >>>> so a >>>> new >>>> ExecutionControlException >>>> subclass is needed. >>>> I was >>>> suggesting >>>> "BadArgumentException" >>>> for this exception. >>>> None of >>>> ExecutionControlException >>>> subclasses are seen >>>> at the JShell >>>> level -- >>>> this should be the >>>> case for this new >>>> one as well. >>>> >>>> I don't what >>>> kind of exceptions >>>> are thrown by >>>> moduleAccess.addExportsToAllUnnamed(target, >>>> pack), but that >>>> message text or some >>>> other appropriate >>>> descriptive message >>>> text needs >>>> to be placed in the >>>> BadArgumentException >>>> message so >>>> it can be >>>> seen all the way up >>>> (including the >>>> JShellTool). >>>> >>>> >>>> On the >>>> JShell class -- >>>> >>>> Incorrect arguments >>>> on JShell API >>>> methods generate the >>>> Java >>>> standard >>>> java.lang.IllegalArgumentException >>>> (see, for >>>> example, >>>> drop() or >>>> status() ) -- so, >>>> this is also the >>>> appropriate >>>> exception for >>>> JShell.addExports(). >>>> Thus, >>>> JShell.addExports() >>>> catchs the >>>> BadArgumentException, turning >>>> it into an >>>> IllegalArgumentException. >>>> >>>> Thanks, >>>> Robert >>>> >>>> >>>> On 09/07/16 >>>> 06:10, ShinyaYoshida >>>> wrote: >>>> >>>> Hi Robert, >>>> Thank >>>> you for your >>>> helping. >>>> >>>> I've >>>> update webrev >>>> according to >>>> your comments. >>>> If I'm >>>> missing your >>>> meaning, I'm >>>> sorry. Please >>>> point it. >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.03.langtools/ >>>> >>>> >>>> >>>> >>>> >>>> >>> > >>>> >>>> >>>> >>>> >>>> >>>> Now, >>>> - >>>> JShell#addExports will >>>> throw >>>> BadArgumentException >>>> when >>>> module >>>> or package is >>>> wrong, which is >>>> check exception. >>>> - >>>> JShellTool >>>> checks that >>>> exception. >>>> - >>>> ExecutionControl#addExports >>>> throws >>>> InternalException when >>>> something is wrong. >>>> >>>> Regards, >>>> shinyafox(Shinya >>>> Yoshida) >>>> >>>> >>>> 2016-09-06 6:28 >>>> GMT+09:00 Robert >>>> Field >>>> >>>> >>> >>>> >>> >>: >>>> >>>> Code looks >>>> good. Needs >>>> docs I promised >>>> (see below). >>>> >>>> As >>>> to completion >>>> issue you >>>> created, I see >>>> you already >>>> added discussion >>>> and tests. I >>>> added your >>>> completion >>>> code. >>>> >>>> Below is my >>>> suggested doc... >>>> >>>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> /set exports >>>> >>>> \n\t\ >>>> Allow access >>>> to some of the >>>> unexported types >>>> of a >>>> module\n\n\ >>>> >>>> >>>> /retain exports >>>> >>>> \n\t\ >>>> Allow access >>>> to some of the >>>> unexported types >>>> of a >>>> module\n\n\ >>>> >>>> >>>> help.set.exports=\ >>>> Set a package to >>>> add to those >>>> exported to >>>> snippets.\n\ >>>> \n\t\ >>>> /set exports >>>> >>>> \n\ >>>> \n\ >>>> Where >>>> is the module >>>> from which to export >>>> .\n\ >>>> Where >>>> is the package >>>> to export to >>>> snippets.\n >>>> >>>> >>>> help.retain.exports=\ >>>> Retain a package >>>> to add to those >>>> exported to >>>> snippets.\n\ >>>> \n\t\ >>>> /retain exports >>>> >>>> \n\ >>>> \n\ >>>> Where >>>> is the module >>>> from which to export >>>> .\n\ >>>> Where >>>> is the package >>>> to export to >>>> snippets.\n >>>> >>>> [I >>>> notice that >>>> 'snippet' is >>>> used in doc >>>> without being >>>> defined. If, >>>> while you are >>>> it, you change >>>> the help for >>>> /list to define it:] >>>> >>>> help.list =\ >>>> Show the source >>>> of snippets, >>>> prefaced with the >>>> snippet id >>>> (a >>>> snippet is a >>>> chunk of code >>>> that the jshell tool >>>> evaluates -- the >>>> code you enter >>>> at the prompt is a >>>> snippet).\n\ >>>> ... >>>> >>>> src/jdk.jshell/share/classes/jdk/jshell/JShell.java >>>> -- >>>> >>>> >>>> /** >>>> * Add a >>>> package to those >>>> exported to >>>> snippets. >>>> * @param >>>> module The >>>> module from >>>> which to export >>>> * @param pack >>>> The package to >>>> export >>>> * @throws >>>> NullPointerException >>>> if arguments are >>>> null. >>>> * @throws >>>> IllegalStateException >>>> if this {@code >>>> JShell} instance >>>> is closed. >>>> * @throws XYZ >>>> if .... >>>> */ >>>> >>>> OK, actually >>>> this code should >>>> change. Like >>>> addToClasspath >>>> above it, it >>>> should return >>>> void. It >>>> looks >>>> like under >>>> normal operation >>>> it can fail -- >>>> the failure >>>> should be >>>> reported with an >>>> exception. >>>> What are the >>>> failure modes? >>>> IllegalArgumentException >>>> would be likely >>>> choice at the >>>> JShell API >>>> layer. But >>>> then >>>> the exception >>>> needs to be >>>> propagated there. >>>> Since none of >>>> the existing >>>> exceptions is a >>>> match, this >>>> means a new >>>> ExecutionControlException. >>>> Maybe something >>>> general, like >>>> BadUserArgumentException. >>>> Note: I've also >>>> added >>>> IllegalStateException >>>> -- this can >>>> be >>>> thrown when you >>>> get >>>> EngineTerminationException. >>>> Also, typo, the >>>> second "module >>>> cannot be null" >>>> should be >>>> "package cannot >>>> be null" >>>> >>>> src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteCodes.java >>>> >>>> -- >>>> >>>> The comment you >>>> have is fine. >>>> Just remove PLEASE >>>> REVISE >>>> THE COMMENT >>>> >>>> src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl.java >>>> -- >>>> >>>> /** >>>> * Add a >>>> package to those >>>> exported to >>>> snippets. >>>> * @param >>>> module The >>>> module from >>>> which to export >>>> * @param pack >>>> The package to >>>> export >>>> * @throws >>>> EngineTerminationException >>>> the execution >>>> engine has >>>> terminated >>>> * @throws .... >>>> * @throws >>>> InternalException an >>>> internal problem >>>> occurred >>>> */ >>>> >>>> Plus add the bad >>>> argument exception. >>>> Whatever it is, >>>> should be added >>>> to >>>> extensionCommand() >>>> exceptions. >>>> >>>> Robert >>>> >>>> >>>> >>>> On >>>> 09/05/16 08:02, >>>> ShinyaYoshida wrote: >>>> >>>> Hi, >>>> I've update >>>> webrev of >>>> langtools: >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.02.langtools/ >>>> >>>> >>>> >>>> >>>> >>>> >>> > >>>> >>>> >>>> >>>> >>>> >>>> >>>> I added an >>>> issue for >>>> the >>>> completion >>>> feature. >>>> https://bugs.openjdk.java.net/browse/JDK-8165445 >>>> >>>> >>> > >>>> >>>> Regards, >>>> shinyafox(Shinya >>>> Yoshida) >>>> >>>> 2016-09-05 >>>> 22:49 >>>> GMT+09:00 >>>> ShinyaYoshida >>>> >>> >>>> >>> >>: >>>> >>>> Hi Robert, >>>> Thank you >>>> for the review. >>>> >>>> I totally >>>> agree with you. >>>> I also >>>> think that >>>> availableModules >>>> and >>>> availablePackages(module) >>>> are >>>> worthless >>>> excepting >>>> for the >>>> command >>>> completion >>>> feature. >>>> I'd like >>>> to avoid >>>> adding these >>>> APIs which >>>> have not >>>> been >>>> speculated >>>> and revised >>>> because if >>>> API is once >>>> added, it >>>> is too >>>> difficult to >>>> remove than >>>> adding. >>>> >>>> So >>>> currently, >>>> I'll remove >>>> the >>>> completion >>>> feature >>>> for >>>> /set or >>>> /retain >>>> exports and >>>> make the >>>> issue to >>>> JBS to >>>> add >>>> completion >>>> feature for >>>> them in future. >>>> >>>> I'll >>>> update the >>>> webrev. So >>>> please >>>> review it again >>>> later. >>>> When the >>>> silently >>>> evaluation >>>> feature is >>>> added, I'd >>>> like to >>>> work for the >>>> completion >>>> feature again. >>>> >>>> Thank you, >>>> shinyafox(Shinya >>>> Yoshida) >>>> >>>> >>>> 2016-09-05 >>>> 15:00 >>>> GMT+09:00 >>>> Robert Field >>>> >>>> >>> >>>> >>> >>: >>>> >>>> >>>> On >>>> 09/03/16 >>>> 05:07, >>>> ShinyaYoshida wrote: >>>> >>>> Hi >>>> all, >>>> >>>> I've >>>> updated >>>> my >>>> patch, >>>> new >>>> webrev >>>> is here: >>>> webrev.01.langtools: >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.01.langtools/ >>>> >>>> >>>> >>>> >>>> >>>> >>> > >>>> >>>> >>>> >>>> >>>> webrev.01.jdk: >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.01.jdk/ >>>> >>>> >>>> >>>> >>> > >>>> >>>> >>>> >>>> >>>> >>>> (Same as >>>> previous) >>>> >>>> In >>>> this >>>> version, >>>> - >>>> rename >>>> /set >>>> add-exports >>>> to /set >>>> exports >>>> >>>> >>>> OK >>>> >>>> - >>>> add >>>> /retain >>>> exports >>>> >>>> >>>> >>>> >>>> The >>>> /retain >>>> implementation >>>> looks good. >>>> >>>> - >>>> add tests >>>> >>>> >>>> Well >>>> tested >>>> >>>> - >>>> move >>>> EXT_CMD_XXX >>>> into >>>> RemoteCodes >>>> - >>>> make >>>> RemoteCodes >>>> public >>>> and move >>>> it into >>>> jdk.jshell.execution.code >>>> which is >>>> module-private >>>> >>>> >>>> So, >>>> here, in >>>> addition to >>>> addExports, >>>> there are >>>> two >>>> more methods >>>> added to the API >>>> availableModules() >>>> and >>>> availablePackage(String >>>> module). >>>> I see >>>> how in rare >>>> cases they >>>> could be useful. >>>> And >>>> the rare >>>> case that >>>> causes them >>>> to be >>>> present >>>> is for >>>> command >>>> completion >>>> in the tool. >>>> What >>>> are the options: >>>> >>>> (1) >>>> Add them to >>>> the API. If >>>> it is in the >>>> API >>>> then >>>> it is a >>>> first-class >>>> form of >>>> functionality >>>> and >>>> should be >>>> treated as >>>> such in >>>> execution >>>> >>>> support (as >>>> a command) >>>> (2) >>>> Not support >>>> them and not >>>> support command >>>> completion >>>> for /set >>>> exports. Command >>>> completion >>>> is not >>>> supported in >>>> much more >>>> common cases. >>>> Then >>>> we could >>>> support >>>> command >>>> completion in >>>> the >>>> future >>>> (see (3)). >>>> (3) >>>> What these >>>> commands do >>>> is simply >>>> execute >>>> an >>>> expression >>>> on the >>>> remote side. >>>> But we >>>> >>>> already have >>>> a mechanism >>>> to execute >>>> expressions >>>> on the >>>> remote side: >>>> Snippets. >>>> That leaves >>>> a problem: >>>> we wouldn't >>>> want >>>> these >>>> Snippets to >>>> be seen by >>>> the user, but we >>>> have a >>>> solution for >>>> that the >>>> tool uses the >>>> idGenerator. >>>> Another >>>> problem is >>>> that, by default >>>> and >>>> with >>>> no current >>>> way around >>>> the default, >>>> expressions >>>> generate >>>> temp-variables. >>>> My >>>> intention >>>> was to make >>>> this >>>> configurable >>>> -- see >>>> Eval.shouldGenTempVar(...). >>>> >>>> One >>>> goal I've >>>> been using >>>> in the >>>> design of the >>>> API is >>>> to keep it >>>> as small and >>>> simple as >>>> possible. >>>> This >>>> improves >>>> maintainability, >>>> but >>>> much >>>> more >>>> importantly >>>> makes the >>>> API easier to >>>> learn >>>> and use. >>>> So, >>>> for >>>> something to >>>> warrant >>>> inclusion it >>>> should >>>> be >>>> generally >>>> useful and >>>> have no >>>> other way of >>>> being >>>> achieved -- >>>> neither is >>>> true of >>>> these two >>>> queries. >>>> >>>> My >>>> suggestion, >>>> particularly >>>> in light of how >>>> late >>>> in the >>>> release this >>>> is, would be >>>> (2). >>>> Thoughts? >>>> >>>> -Robert >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> shinyafox(Shinya >>>> Yoshida) >>>> >>>> 2016-09-03 >>>> 18:15 >>>> GMT+09:00 ShinyaYoshida >>>> >>>> >>> >>>> >>> >>: >>>> >>>> >>>> Hi Robert, >>>> Thank >>>> you for >>>> reviewing. >>>> >>>> I'll >>>> update >>>> my patch >>>> later. >>>> >>>> 2016-09-02 >>>> 11:38 >>>> GMT+09:00 Robert >>>> Field >>>> >>> >>>> >>> >>: >>>> >>>> Thanks >>>> shiyafox! This >>>> is a >>>> significant >>>> piece of >>>> code! >>>> >>>> As to >>>> your >>>> questions -- >>>> >>>> > I >>>> wonder >>>> if you >>>> could >>>> work on the >>>> documentation >>>> of the >>>> API and >>>> the tool >>>> instead? >>>> >>>> Yes, I >>>> will do >>>> API and >>>> tool docs. >>>> >>>> Thank you! >>>> >>>> > >>>> Subcommand >>>> of /set >>>> is >>>> reasonable? >>>> Similar >>>> command, >>>> /classpath, >>>> to make >>>> users >>>> available to >>>> use new >>>> packages is >>>> not a >>>> subcommand >>>> of /set. >>>> >>>> Yes, I >>>> think >>>> /set >>>> exports >>>> is best. >>>> And, >>>> yes, >>>> /classpath >>>> is >>>> inconsistent, >>>> it >>>> should >>>> be /set >>>> classpath, >>>> that can >>>> be a >>>> separate >>>> task, >>>> unless you >>>> want to >>>> roll >>>> that in. >>>> >>>> >>>> I see, >>>> I've >>>> created >>>> the >>>> issue to >>>> move >>>> /classpath >>>> to /set >>>> classpath: >>>> https://bugs.openjdk.java.net/browse/JDK-8165405 >>>> >>>> >>> > >>>> >>>> > Should >>>> we need >>>> retain >>>> feature to >>>> this? >>>> >>>> All /set >>>> have a >>>> /retain >>>> counterpart >>>> -- >>>> we >>>> should >>>> maintain >>>> that >>>> >>>> >>>> Ok, >>>> I'll add >>>> /retain >>>> exports. >>>> >>>> I've >>>> also >>>> create >>>> the >>>> issue >>>> for >>>> retaining >>>> classpath: >>>> https://bugs.openjdk.java.net/browse/JDK-8165406 >>>> >>>> >>> > >>>> >>>> As to >>>> the code >>>> review: >>>> Looks >>>> good to >>>> me, just >>>> minor >>>> questions/issues >>>> -- >>>> >>>> JShellTool.java: >>>> >>>> * As >>>> discussed /set >>>> add-exports >>>> => >>>> /set >>>> exports >>>> >>>> * Nit: a >>>> comment >>>> got >>>> moved out of >>>> place >>>> line >>>> 1194(old) >>>> >>>> JShell.java: >>>> >>>> * >>>> EXT_CMD_AVAILABLE_MODULES >>>> and >>>> EXT_CMD_AVAILABLE_PACKAGES, >>>> these >>>> should >>>> be >>>> referenced >>>> via >>>> RemoteCodes.java >>>> rather >>>> than be >>>> coped. >>>> >>>> Absolutely! >>>> I'd like >>>> to move >>>> these into >>>> RemoteCodes >>>> but it >>>> is >>>> package-private >>>> class >>>> >>>> and >>>> cannot >>>> be >>>> referred >>>> from JShell. >>>> >>>> Can I >>>> make >>>> RemoteCodes >>>> public >>>> and move it >>>> >>>> to >>>> another >>>> module-private >>>> package like >>>> jdk.jshell.execution.code? >>>> >>>> * Which >>>> leads me >>>> to >>>> another >>>> question: >>>> why is >>>> addExports >>>> a >>>> command >>>> and these >>>> two are >>>> extensions. >>>> It seems >>>> fine, >>>> just >>>> curious. >>>> I notice >>>> that >>>> extensions >>>> are a >>>> lot less >>>> code -- ;-) >>>> >>>> Exporting module >>>> and >>>> package is >>>> similar to >>>> adding >>>> classpath to >>>> platform, so >>>> I made >>>> the >>>> addExports >>>> a >>>> command >>>> like >>>> setClasspath. >>>> >>>> And it >>>> should >>>> be added >>>> as API >>>> because >>>> it is >>>> >>>> very >>>> basic >>>> feature. >>>> >>>> TaskFactory.java: >>>> >>>> * >>>> Question: the >>>> "/" >>>> separator between >>>> module >>>> and >>>> package >>>> is that >>>> platform >>>> independent? >>>> >>>> >>>> It >>>> seems to >>>> me that >>>> "{module}/{path}" >>>> format >>>> for >>>> --add-exports >>>> option of >>>> javac is >>>> platform >>>> independent. >>>> Regards, >>>> shinyafox(Shinya >>>> Yoshida) >>>> >>>> >>>> DefaultLoaderDelegate.java: >>>> >>>> * Jan, >>>> can you >>>> look at >>>> this code? >>>> >>>> >>>> -Robert >>>> >>>> >>>> On >>>> 09/01/16 >>>> 05:36, >>>> ShinyaYoshida >>>> wrote: >>>> >>>> Hi all, >>>> I've >>>> implemented >>>> this >>>> feature to >>>> >>>> JShell >>>> API and >>>> Tool >>>> with full >>>> completion: >>>> Bugs: >>>> https://bugs.openjdk.java.net/browse/JDK-8154714 >>>> >>>> >>> > >>>> >>>> jdk: >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.jdk/ >>>> >>>> >>>> >>>> >>> > >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>> >> >>>> >>>> >>>> >>>> >>>> >>>> langtools: >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.00.langtools/ >>>> >>>> >>>> >>>> >>>> >>>> >>> > >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>> >> >>>> >>>> >>>> >>>> >>>> >>>> This >>>> is >>>> missing >>>> the >>>> train of >>>> Java >>>> 9.0 >>>> but it >>>> could >>>> catch the >>>> train of >>>> Java >>>> 9.1 or >>>> later. >>>> I >>>> want to >>>> get your >>>> comments for >>>> this. >>>> >>>> >>>> jshell> >>>> /set >>>> add-exports >>>> jdk.jconsole >>>> sun.tools.jconsole >>>> >>>> >>>> jshell> >>>> import >>>> sun.tools.jconsole.* >>>> >>>> jshell> >>>> LocalVirtualMachine.getAllVirtualMachines().forEach((k, >>>> v) >>>> -> >>>> System.out.println(k >>>> + ":" >>>> + v)) >>>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>>> 10826:jdk.jshell.execution.RemoteExecutionControl >>>> 35548 >>>> 28447:org.netbeans.Main >>>> --cachedir >>>> /home/bitter_fox/.cache/netbeans/8.0.1 >>>> >>>> --userdir >>>> /home/bitter_fox/.netbeans/8.0.1 >>>> >>>> --branding >>>> nb >>>> >>>> >>>> Currently, >>>> there is no >>>> testing, so >>>> it >>>> will be >>>> required >>>> to add test. >>>> >>>> Regards, >>>> shinyafox(Shinya >>>> Yoshida) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > > From bitterfoxc at gmail.com Mon Sep 26 22:52:02 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Mon, 26 Sep 2016 15:52:02 -0700 Subject: RFR 8166744: JShell: java.lang.IndexOutOfBoundsException for legal history access Message-ID: Hi, Could you review this? Bugs: https://bugs.openjdk.java.net/browse/JDK-8166744 Webrevs are here: jdk(fix): http://cr.openjdk.java.net/~shinyafox/kulla/8166744/webrev.00.jdk/ langtools(test): http://cr.openjdk.java.net/~shinyafox/kulla/8166744/webrev.00.langtools/ Regards, shinyafox(Shinya Yoshida) From robert.field at oracle.com Tue Sep 27 14:35:04 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 27 Sep 2016 07:35:04 -0700 Subject: RFR 8166744: JShell: java.lang.IndexOutOfBoundsException for legal history access In-Reply-To: References: Message-ID: <1576c1209c0.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Looks good to me. Jan..... ? On September 26, 2016 3:52:10 PM ShinyaYoshida wrote: > Hi, > Could you review this? > > Bugs: https://bugs.openjdk.java.net/browse/JDK-8166744 > > Webrevs are here: > jdk(fix): > http://cr.openjdk.java.net/~shinyafox/kulla/8166744/webrev.00.jdk/ > langtools(test): > http://cr.openjdk.java.net/~shinyafox/kulla/8166744/webrev.00.langtools/ > > Regards, > shinyafox(Shinya Yoshida) From jan.lahoda at oracle.com Tue Sep 27 15:44:02 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 27 Sep 2016 17:44:02 +0200 Subject: RFR 8166744: JShell: java.lang.IndexOutOfBoundsException for legal history access In-Reply-To: <1576c1209c0.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <1576c1209c0.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: <57EA93C2.5090509@oracle.com> Makes sense to me. Good catch! Thanks, Jan On 27.9.2016 16:35, Robert Field wrote: > Looks good to me. > > Jan..... ? > > > > On September 26, 2016 3:52:10 PM ShinyaYoshida > wrote: > >> Hi, >> Could you review this? >> >> Bugs: https://bugs.openjdk.java.net/browse/JDK-8166744 >> >> Webrevs are here: >> jdk(fix): >> http://cr.openjdk.java.net/~shinyafox/kulla/8166744/webrev.00.jdk/ >> langtools(test): >> http://cr.openjdk.java.net/~shinyafox/kulla/8166744/webrev.00.langtools/ >> >> Regards, >> shinyafox(Shinya Yoshida) > > From robert.field at oracle.com Wed Sep 28 02:07:07 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 27 Sep 2016 19:07:07 -0700 Subject: Kulla: Where is Robert? Message-ID: <57EB25CB.4010901@oracle.com> Gone on vacation until Tuesday. May check email, but expect responses Tuesday or later. Robert From bitterfoxc at gmail.com Wed Sep 28 07:37:12 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Wed, 28 Sep 2016 16:37:12 +0900 Subject: WIP: 8154714: JShell API: addExports support [for Java 9.X] In-Reply-To: <57EB2487.2000306@oracle.com> References: <57D069C0.8030009@oracle.com> <57D33CE9.9060305@oracle.com> <57D5BBEC.8060506@oracle.com> <57D6CA3F.4050309@oracle.com> <57D6DE8F.4070405@oracle.com> <57D6EEB1.4050506@oracle.com> <57D7189F.2070901@oracle.com> <57D71A2C.9030501@oracle.com> <57D74A77.5000905@oracle.com> <57D8289B.5030403@oracle.com> <57E4D485.80500@oracle.com> <57E9569B.1090904@oracle.com> <57EA9792.1040805@oracle.com> <57EB2487.2000306@oracle.com> Message-ID: Thank you! I've pushed: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/721c5727816d 2016-09-28 11:01 GMT+09:00 Robert Field : > > On 09/27/16 18:02, ShinyaYoshida wrote: > > Robert, > Thank you!! > > I'll push but I have a question. > Who should I put to reviewed-by? > > > Reviewed-by: jlahoda, rfield > > Robert and Jan are enough? > > > Yep > > Don't I need to put the internal reviewers? > > > Nope > > Thanks, > Robert > > > Thanks, > shinyafox(Shinya Yoshida) > > > 2016-09-28 1:00 GMT+09:00 Robert Field : > >> [audience reduced] >> >> shinyafox, >> >> This passed internal review. >> >> You are good to push! >> >> Thanks! >> Robert >> >> On 09/26/16 13:20, ShinyaYoshida wrote: >> >> Hi Robert, >> Thank you for asking for the internal review. >> >> I've updated and replaced the previous webrev! >> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.11.langtools/ >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2016-09-26 10:10 GMT-07:00 Robert Field : >> >>> That's great! >>> >>> I've submitted this to internal review of the new command-line options. >>> We should get that in less than a week. >>> >>> One nit, I've noticed that --help doesn't list the new -X option. >>> Borrowing from "java -help" this should be: >>> >>> -X Print help on non-standard options >>> >>> >>> Thanks! >>> >>> -Robert >>> >>> >>> >>> On 09/23/16 23:49, ShinyaYoshida wrote: >>> >>> Hi Robert, >>> >>> >>> 2016-09-23 0:06 GMT-07:00 Robert Field : >>> >>>> >>>> On 09/22/16 12:51, ShinyaYoshida wrote: >>>> >>>> Hi Robert and Jan, >>>> I've updated the webrev to add -C option and --add-exports option(as a >>>> non-standard option): >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.1 >>>> 0.langtools/ >>>> >>>> Could you review and give me a comment? >>>> >>>> >>>> Wow! This is so much simpler an approach! >>>> >>>> A couple little things and this is good... >>>> >>>> In JShellTool, should --add-exports have .withRequiredArg() rather than >>>> .withOptionalArg()? >>>> >>> Yeah! That's what I want to use!! >>> I've fixed >>> >>> >>>> >>>> I think >>>> >>>> 645 if (options.has("X")) { >>>> 646 printUsageX(); >>>> 647 } >>>> >>>> Should be up below "help", and, like "help", should abort by returning >>>> null. >>>> >>> Absolutely yes!! >>> >>> New version is here: >>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.11.langtools/ >>> >>> Regards, >>> shinyafox(ShinyaYoshida) >>> >>> >>>> >>>> Your comment looks fine. >>>> >>>> Test and resource file look good. >>>> >>>> Thanks, >>>> Robert >>>> >>>> >>>> >>>> >>>> Another issue is found until implementing: >>>> https://bugs.openjdk.java.net/browse/JDK-8166581 >>>> >>>> Could you confirm and address this? >>>> >>>> Regards, >>>> shinyafox(Shinya Yoshida)@JavaOne 20016 >>>> >>>> 2016-09-13 9:26 GMT-07:00 Robert Field : >>>> >>>>> >>>>> On 09/12/16 17:55, ShinyaYoshida wrote: >>>>> >>>>> Hi Jan and all, >>>>> I've confirmed your snippet. >>>>> Certainly it have a security problem and it should be avoided. >>>>> >>>>> I'll update my patch to add a new command-line option -C which give >>>>> the option to compiler. >>>>> >>>>> In addition to, I'd like to add a new command-line option >>>>> --add-exports / which is a short-circuit for >>>>> "-J--add-exports /=ALL-UNNAMED -C--add-exports >>>>> /=ALL-UNNAMED." >>>>> java and javac are also have --add-exports option, so it seems to me >>>>> that it is reasonable for jshell to have --add-exports option. >>>>> What do you think about this? >>>>> >>>>> Kind Regards, >>>>> shinyafox(Shinya Yoshida) >>>>> >>>>> >>>>> OK, great. >>>>> >>>>> I started to write that I didn't think you needed or wanted a -C >>>>> flag. But on further thought, that allows all kinds of flexibility that we >>>>> may not want to provide item by item -- for example: >>>>> --processor-module-path, --module-source-path, .... >>>>> There is a question: which compiles should these flags get applied to, >>>>> but it seems they would just be ignored where not needed, so probably all >>>>> of them. >>>>> >>>>> I notice --add-exports is on the -X help for both java and javac -- it >>>>> is non-standard. Seems wrong for it to be a non-standard option for those >>>>> two and a standard option for jshell. >>>>> >>>>> I think it is a question for Jigsaw people as to what module options: >>>>> >>>>> * should be directly jshell command-line options >>>>> * should be non-standard -X command-line options (if jshell has -X >>>>> options) >>>>> * obscure enough that users should use -R and -C >>>>> >>>>> -Robert >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2016-09-13 9:38 GMT+09:00 Robert Field : >>>>> >>>>>> If our approach to security is "do nothing a user could not do with >>>>>> their own use of javac/java" (which we have yet to have validated) then if >>>>>> the SharedSecrets use in JShell requires the change to the module.info.java >>>>>> in java.base to add jdk.jshell, then that would be a violation. >>>>>> >>>>>> If this changeset gave access only to snippets executing via the >>>>>> JShell API maybe that would be OK. But it, as your exploit verifies, could >>>>>> easily be used by anyone to change module boundaries. >>>>>> >>>>>> Maybe there would be a hack that would allow only proper JShell use, >>>>>> but I don't see what that would be, and that sounds dangerous and >>>>>> unappealing. >>>>>> >>>>>> Command-line option only would match the original request and other >>>>>> tools. The implementation would closely match the implementation of '-R', >>>>>> being on the command-line of JShellTool and the API in JShell.Builder. >>>>>> Alas, this is mostly a rewrite, only some code in TaskFactory, >>>>>> ToolBasicTest, and maybe KullaTesting would be reusable. >>>>>> >>>>>> Bummer! >>>>>> >>>>>> But thanks for catching this Jan! >>>>>> >>>>>> -Robert >>>>>> >>>>>> >>>>>> >>>>>> On 09/12/16 14:12, Jan Lahoda wrote: >>>>>> >>>>>>> (Basically, the use of SharedSecrets in jdk.jshell seems highly >>>>>>> suspicious to me.) >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>> On 12.9.2016 23:05, Jan Lahoda wrote: >>>>>>> >>>>>>>> On 12.9.2016 20:06, Robert Field wrote: >>>>>>>> >>>>>>>>> The jshell tool is built on the JShell API. Command-line options, >>>>>>>>> like >>>>>>>>> -R, pass to the remote process via the JShell API. -R would allow >>>>>>>>> --patch-module or --add-exports. Having addExports functionality >>>>>>>>> >>>>>>>> >>>>>>>> I am not much worried about --add-exports added using -R, that >>>>>>>> seems OK >>>>>>>> to me. This only affects a newly spawned JVM, and the API client >>>>>>>> could >>>>>>>> spawn it even without JShell, so not a problem IMO. >>>>>>>> >>>>>>>> What I am worried about is that using the most recent proposed patch >>>>>>>> (lwebrev.04.langtools), one can use the DirectExecutionControl to >>>>>>>> change >>>>>>>> module boundaries in the _currently running VM_. Please see the >>>>>>>> attached >>>>>>>> class to see what I mean - I didn't even have to create JShell as >>>>>>>> such, >>>>>>>> simply using DirectExecutionControl was enough. It probably does not >>>>>>>> even need some special privileges to achieve the result. >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>>> anywhere is jshell means having it in the JShell API. >>>>>>>>> >>>>>>>>> I believe this cycles us, to some degree, back to the security >>>>>>>>> discussion. What is our level of concern about a launched process >>>>>>>>> running pure JDK code? >>>>>>>>> >>>>>>>>> -Robert >>>>>>>>> >>>>>>>>> On 09/12/16 09:57, Jan Lahoda wrote: >>>>>>>>> >>>>>>>>>> [adding Jon] >>>>>>>>>> >>>>>>>>>> On 12.9.2016 17:31, Robert Field wrote: >>>>>>>>>> >>>>>>>>>>> Both javac and java have a --add-exports option, so it isn't >>>>>>>>>>> opening >>>>>>>>>>> anything that isn't already open. >>>>>>>>>>> I don't see how command-line options are any different that API >>>>>>>>>>> in >>>>>>>>>>> terms >>>>>>>>>>> of exposure. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think there's a huge difference between command line and an >>>>>>>>>> API, in >>>>>>>>>> at least two aspects: >>>>>>>>>> a) the person that controls the command line, has a lot of power >>>>>>>>>> in >>>>>>>>>> any case (they could do -Xbootclasspath/p: in 8 or --patch-module >>>>>>>>>> now >>>>>>>>>> to get around the boundaries). API users are much more restricted >>>>>>>>>> in >>>>>>>>>> what they can do. >>>>>>>>>> b) affecting the command line options is generally very hard - >>>>>>>>>> imagine >>>>>>>>>> library maintainers - how can they affect the command line >>>>>>>>>> setting? >>>>>>>>>> The only thing they can do is to write some documentation, but >>>>>>>>>> they >>>>>>>>>> cannot directly affect the command line. But they can call an API >>>>>>>>>> (and >>>>>>>>>> they can call it even reflectively). >>>>>>>>>> >>>>>>>>>> I believe it is generally undesirable to create APIs that allow to >>>>>>>>>> create holes in module boundaries. If you think that's something >>>>>>>>>> JShell needs, I think we need to take that to the Jigsaw team. >>>>>>>>>> >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -Robert >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 09/11/16 13:17, Jan Lahoda wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I apologize for not following this sooner. >>>>>>>>>>>> >>>>>>>>>>>> Looking at this, it seems to me the change would effectively >>>>>>>>>>>> allow to >>>>>>>>>>>> overcome the module boundary limitations using JShell - I don't >>>>>>>>>>>> think >>>>>>>>>>>> that's something that would be acceptable. We could take this >>>>>>>>>>>> to the >>>>>>>>>>>> Jigsaw team, but I don't think they would be happy about this. >>>>>>>>>>>> >>>>>>>>>>>> I wonder what exactly is the usecase here. Would it be >>>>>>>>>>>> sufficient if >>>>>>>>>>>> the jshell tool as such would allow command line options to >>>>>>>>>>>> break >>>>>>>>>>>> through the boundaries? We already have -R, which should allow >>>>>>>>>>>> to make >>>>>>>>>>>> holes to the boundaries when running the snippets, so maybe we >>>>>>>>>>>> just >>>>>>>>>>>> need to add something for compile-time? >>>>>>>>>>>> >>>>>>>>>>>> Jan >>>>>>>>>>>> >>>>>>>>>>>> On 11.9.2016 02:12, ShinyaYoshida wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> Please apply this webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>> 0.jdk/ >>>>>>>>>>>>> >>>>>>>>>>>> 00.jdk/> >>>>>>>>>>>>> Changing module-info is needed. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>> >>>>>>>>>>>>> 2016-09-10 7:51 GMT+09:00 Robert Field < >>>>>>>>>>>>> robert.field at oracle.com >>>>>>>>>>>>> >: >>>>>>>>>>>>> >>>>>>>>>>>>> [audience reduced] >>>>>>>>>>>>> >>>>>>>>>>>>> BTW shinyafox, >>>>>>>>>>>>> >>>>>>>>>>>>> Building "make images" with this patch and the latest >>>>>>>>>>>>> jdk9/dev >>>>>>>>>>>>> bits >>>>>>>>>>>>> fails. Probably need to change module set-up -- >>>>>>>>>>>>> >>>>>>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>>>>>> xecution/DirectExecutionControl.java:33: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> error: package jdk.internal.misc does not exist >>>>>>>>>>>>> import jdk.internal.misc.JavaLangReflectModuleAccess; >>>>>>>>>>>>> ^ >>>>>>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>>>>>> xecution/DirectExecutionControl.java:34: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> error: package jdk.internal.misc does not exist >>>>>>>>>>>>> import jdk.internal.misc.SharedSecrets; >>>>>>>>>>>>> ^ >>>>>>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>>>>>> xecution/DirectExecutionControl.java:155: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> error: cannot find symbol >>>>>>>>>>>>> JavaLangReflectModuleAccess moduleAccess = >>>>>>>>>>>>> SharedSecrets.getJavaLangReflectModuleAccess(); >>>>>>>>>>>>> ^ >>>>>>>>>>>>> symbol: class JavaLangReflectModuleAccess >>>>>>>>>>>>> location: class DirectExecutionControl >>>>>>>>>>>>> /w/y/dev/langtools/src/jdk.jshell/share/classes/jdk/jshell/e >>>>>>>>>>>>> xecution/DirectExecutionControl.java:155: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> error: cannot find symbol >>>>>>>>>>>>> JavaLangReflectModuleAccess moduleAccess = >>>>>>>>>>>>> SharedSecrets.getJavaLangReflectModuleAccess(); >>>>>>>>>>>>> ^ >>>>>>>>>>>>> symbol: variable SharedSecrets >>>>>>>>>>>>> location: class DirectExecutionControl >>>>>>>>>>>>> 4 errors >>>>>>>>>>>>> >>>>>>>>>>>>> -Robert >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 09/08/16 07:14, ShinyaYoshida wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>> Thank you for your pointing out. >>>>>>>>>>>>>> I've understood. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here is new webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>>> 4.langtools/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> v.04.langtools/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> In this version, >>>>>>>>>>>>>> - ExecutionControl#addExports throws BadArgumentException >>>>>>>>>>>>>> which is >>>>>>>>>>>>>> extends ExecutionControlException if module or package >>>>>>>>>>>>>> are not >>>>>>>>>>>>>> found. >>>>>>>>>>>>>> - JShell#addExports throws IllegalArgumentException when >>>>>>>>>>>>>> BadArgumentException is occured >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've notice that /classpath and addToClasspath says >>>>>>>>>>>>>> nothing when >>>>>>>>>>>>>> it doesn't exist. >>>>>>>>>>>>>> I think it should be reported, so I've created a issue: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165650 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review me again! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2016-09-08 4:25 GMT+09:00 Robert Field < >>>>>>>>>>>>>> robert.field at oracle.com >>>>>>>>>>>>>> >: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for the update. >>>>>>>>>>>>>> >>>>>>>>>>>>>> l10n.properties -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Oops, typo: the help.set.exports entry got pasted >>>>>>>>>>>>>> again >>>>>>>>>>>>>> instead of help.retain.exports >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry I was unclear about the exceptions... >>>>>>>>>>>>>> >>>>>>>>>>>>>> On the execution side -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> ExecutionControl.InternalException is only for >>>>>>>>>>>>>> unexpected >>>>>>>>>>>>>> failures. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In this case you are dealing an expected exception >>>>>>>>>>>>>> that >>>>>>>>>>>>>> occurs >>>>>>>>>>>>>> when the user gives the wrong input. None of the >>>>>>>>>>>>>> existing >>>>>>>>>>>>>> ExecutionControlException subclasses are good >>>>>>>>>>>>>> candidates, >>>>>>>>>>>>>> so a >>>>>>>>>>>>>> new ExecutionControlException subclass is needed. I >>>>>>>>>>>>>> was >>>>>>>>>>>>>> suggesting "BadArgumentException" for this exception. >>>>>>>>>>>>>> None of >>>>>>>>>>>>>> ExecutionControlException subclasses are seen at the >>>>>>>>>>>>>> JShell >>>>>>>>>>>>>> level -- this should be the case for this new one as >>>>>>>>>>>>>> well. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't what kind of exceptions are thrown by >>>>>>>>>>>>>> moduleAccess.addExportsToAllUnnamed(target, pack), >>>>>>>>>>>>>> but that >>>>>>>>>>>>>> message text or some other appropriate descriptive >>>>>>>>>>>>>> message >>>>>>>>>>>>>> text needs to be placed in the BadArgumentException >>>>>>>>>>>>>> message so >>>>>>>>>>>>>> it can be seen all the way up (including the >>>>>>>>>>>>>> JShellTool). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On the JShell class -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Incorrect arguments on JShell API methods generate >>>>>>>>>>>>>> the Java >>>>>>>>>>>>>> standard java.lang.IllegalArgumentException (see, for >>>>>>>>>>>>>> example, >>>>>>>>>>>>>> drop() or status() ) -- so, this is also the >>>>>>>>>>>>>> appropriate >>>>>>>>>>>>>> exception for JShell.addExports(). Thus, >>>>>>>>>>>>>> JShell.addExports() >>>>>>>>>>>>>> catchs the BadArgumentException, turning it into an >>>>>>>>>>>>>> IllegalArgumentException. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 09/07/16 06:10, ShinyaYoshida wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>>> Thank you for your helping. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've update webrev according to your comments. >>>>>>>>>>>>>>> If I'm missing your meaning, I'm sorry. Please point >>>>>>>>>>>>>>> it. >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8154714/webrev.0 >>>>>>>>>>>>>>> 3.langtools/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> v.03.langtools/> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Now, >>>>>>>>>>>>>>> - JShell#addExports will throw BadArgumentException >>>>>>>>>>>>>>> when >>>>>>>>>>>>>>> module or package is wrong, which is check exception. >>>>>>>>>>>>>>> - JShellTool checks that exception. >>>>>>>>>>>>>>> - ExecutionControl#addExports throws >>>>>>>>>>>>>>> InternalException when >>>>>>>>>>>>>>> something is wrong. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2016-09-06 6:28 GMT+09:00 Robert Field >>>>>>>>>>>>>>> >>>>>>>>>>>>>> robert.field at oracle.com>>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Code looks good. Needs docs I promised (see >>>>>>>>>>>>>>> below). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As to completion issue you created, I see you >>>>>>>>>>>>>>> already >>>>>>>>>>>>>>> added discussion and tests. I added your >>>>>>>>>>>>>>> completion >>>>>>>>>>>>>>> code. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Below is my suggested doc... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /set exports \n\t\ >>>>>>>>>>>>>>> Allow access to some of the unexported >>>>>>>>>>>>>>> types of a >>>>>>>>>>>>>>> module\n\n\ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /retain exports \n\t\ >>>>>>>>>>>>>>> Allow access to some of the unexported >>>>>>>>>>>>>>> types of a >>>>>>>>>>>>>>> module\n\n\ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> help.set.exports=\ >>>>>>>>>>>>>>> Set a package to add to those exported to >>>>>>>>>>>>>>> snippets.\n\ >>>>>>>>>>>>>>> \n\t\ >>>>>>>>>>>>>>> /set exports \n\ >>>>>>>>>>>>>>> \n\ >>>>>>>>>>>>>>> Where is the module from which to export >>>>>>>>>>>>>>> .\n\ >>>>>>>>>>>>>>> Where is the package to export to >>>>>>>>>>>>>>> snippets.\n >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> help.retain.exports=\ >>>>>>>>>>>>>>> Retain a package to add to those exported to >>>>>>>>>>>>>>> snippets.\n\ >>>>>>>>>>>>>>> \n\t\ >>>>>>>>>>>>>>> /retain exports \n\ >>>>>>>>>>>>>>> \n\ >>>>>>>>>>>>>>> Where is the module from which to export >>>>>>>>>>>>>>> .\n\ >>>>>>>>>>>>>>> Where is the package to export to >>>>>>>>>>>>>>> snippets.\n >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [I notice that 'snippet' is used in doc without >>>>>>>>>>>>>>> being >>>>>>>>>>>>>>> defined. If, while you are it, you change the >>>>>>>>>>>>>>> help for >>>>>>>>>>>>>>> /list to define it:] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> help.list =\ >>>>>>>>>>>>>>> Show the source of snippets, prefaced with the >>>>>>>>>>>>>>> snippet id >>>>>>>>>>>>>>> (a snippet is a chunk of code that the jshell >>>>>>>>>>>>>>> tool >>>>>>>>>>>>>>> evaluates -- the code you enter at the prompt is >>>>>>>>>>>>>>> a >>>>>>>>>>>>>>> snippet).\n\ >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/JShell.java -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /** >>>>>>>>>>>>>>> * Add a package to those exported to >>>>>>>>>>>>>>> snippets. >>>>>>>>>>>>>>> * @param module The module from which to >>>>>>>>>>>>>>> export >>>>>>>>>>>>>>> * @param pack The package to export >>>>>>>>>>>>>>> * @throws NullPointerException if arguments >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>> null. >>>>>>>>>>>>>>> * @throws IllegalStateException if this >>>>>>>>>>>>>>> {@code >>>>>>>>>>>>>>> JShell} instance is closed. >>>>>>>>>>>>>>> * @throws XYZ if .... >>>>>>>>>>>>>>> */ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OK, actually this code should change. Like >>>>>>>>>>>>>>> addToClasspath above it, it should return void. >>>>>>>>>>>>>>> It >>>>>>>>>>>>>>> looks >>>>>>>>>>>>>>> like under normal operation it can fail -- the >>>>>>>>>>>>>>> failure >>>>>>>>>>>>>>> should be reported with an exception. >>>>>>>>>>>>>>> What are the failure modes? >>>>>>>>>>>>>>> IllegalArgumentException >>>>>>>>>>>>>>> would be likely choice at the JShell API layer. >>>>>>>>>>>>>>> But >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> the exception needs to be propagated there. >>>>>>>>>>>>>>> Since none of the existing exceptions is a >>>>>>>>>>>>>>> match, this >>>>>>>>>>>>>>> means a new ExecutionControlException. Maybe >>>>>>>>>>>>>>> something >>>>>>>>>>>>>>> general, like BadUserArgumentException. >>>>>>>>>>>>>>> Note: I've also added IllegalStateException -- >>>>>>>>>>>>>>> this can >>>>>>>>>>>>>>> be thrown when you get >>>>>>>>>>>>>>> EngineTerminationException. >>>>>>>>>>>>>>> Also, typo, the second "module cannot be null" >>>>>>>>>>>>>>> should be >>>>>>>>>>>>>>> "package cannot be null" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteCodes.java >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The comment you have is fine. Just remove PLEASE >>>>>>>>>>>>>>> REVISE >>>>>>>>>>>>>>> THE COMMENT >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl >>>>>>>>>>>>>>> .java >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /** >>>>>>>>>>>>>>> * Add a package to those exported to >>>>>>>>>>>>>>> snippets. >>>>>>>>>>>>>>> * @param module The module from which to >>>>>>>>>>>>>>> export >>>>>>>>>>>>>>> * @param pack The package to export >>>>>>>>>>>>>>> * @throws EngineTerminationException the >>>>>>>>>>>>>>> execution >>>>>>>>>>>>>>> engine has terminated >>>>>>>>>>>>>>> * @throws .... >>>>>>>>>>>>>>> * @throws InternalException an internal >>>>>>>>>>>>>>> problem >>>>>>>>>>>>>>> occurred >>>>>>>>>>>>>>> */ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Plus add the bad argument exception. >>>>>>>>>>>>>>> Whatever it is, should be added to >>>>>>>>>>>>>>> extensionCommand() >>>>>>>>>>>>>>> exceptions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Robert >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 09/05/16 08:02, ShinyaYoshida wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> I've update webrev of langtools: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~sh >>>>>>>>>>>>>>>> inyafox/kulla/8154714/webrev.02.langtools/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Eshinyafox/kulla/8154714/webrev.02.langtools/> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I added an issue for the completion feature. >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165445 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2016-09-05 22:49 GMT+09:00 ShinyaYoshida >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bitterfoxc at gmail.com>>: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>>>> Thank you for the review. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I totally agree with you. >>>>>>>>>>>>>>>> I also think that availableModules and >>>>>>>>>>>>>>>> availablePackages(module) are worthless >>>>>>>>>>>>>>>> excepting >>>>>>>>>>>>>>>> for the command completion feature. >>>>>>>>>>>>>>>> I'd like to avoid adding these APIs which >>>>>>>>>>>>>>>> have not >>>>>>>>>>>>>>>> been speculated and revised because if API >>>>>>>>>>>>>>>> is once >>>>>>>>>>>>>>>> added, it is too difficult to remove than >>>>>>>>>>>>>>>> adding. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So currently, I'll remove the completion >>>>>>>>>>>>>>>> feature >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> /set or /retain exports and make the issue >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> JBS to >>>>>>>>>>>>>>>> add completion feature for them in future. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll update the webrev. So please review it >>>>>>>>>>>>>>>> again >>>>>>>>>>>>>>>> later. >>>>>>>>>>>>>>>> When the silently evaluation feature is >>>>>>>>>>>>>>>> added, I'd >>>>>>>>>>>>>>>> like to work for the completion feature >>>>>>>>>>>>>>>> again. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2016-09-05 15:00 GMT+09:00 Robert Field >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 09/03/16 05:07, ShinyaYoshida wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> I've updated my patch, new webrev is >>>>>>>>>>>>>>>>> here: >>>>>>>>>>>>>>>>> webrev.01.langtools: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~sh >>>>>>>>>>>>>>>>> inyafox/kulla/8154714/webrev.01.langtools/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Eshinyafox/kulla/8154714/webrev.01.langtools/> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> webrev.01.jdk: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~sh >>>>>>>>>>>>>>>>> inyafox/kulla/8154714/webrev.01.jdk/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Eshinyafox/kulla/8154714/webrev.01.jdk/> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> (Same as previous) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In this version, >>>>>>>>>>>>>>>>> - rename /set add-exports to /set >>>>>>>>>>>>>>>>> exports >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> OK >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - add /retain exports >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The /retain implementation looks good. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - add tests >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Well tested >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - move EXT_CMD_XXX into RemoteCodes >>>>>>>>>>>>>>>>> - make RemoteCodes public and move it >>>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>>> jdk.jshell.execution.code which is >>>>>>>>>>>>>>>>> module-private >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So, here, in addition to addExports, >>>>>>>>>>>>>>>> there are >>>>>>>>>>>>>>>> two more methods added to the API >>>>>>>>>>>>>>>> availableModules() and >>>>>>>>>>>>>>>> availablePackage(String >>>>>>>>>>>>>>>> module). >>>>>>>>>>>>>>>> I see how in rare cases they could be >>>>>>>>>>>>>>>> useful. >>>>>>>>>>>>>>>> And the rare case that causes them to be >>>>>>>>>>>>>>>> present >>>>>>>>>>>>>>>> is for command completion in the tool. >>>>>>>>>>>>>>>> What are the options: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (1) Add them to the API. If it is in >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> API >>>>>>>>>>>>>>>> then it is a first-class form of >>>>>>>>>>>>>>>> functionality >>>>>>>>>>>>>>>> and should be treated as such in >>>>>>>>>>>>>>>> execution >>>>>>>>>>>>>>>> support (as a command) >>>>>>>>>>>>>>>> (2) Not support them and not support >>>>>>>>>>>>>>>> command >>>>>>>>>>>>>>>> completion for /set exports. Command >>>>>>>>>>>>>>>> completion >>>>>>>>>>>>>>>> is not supported in much more common >>>>>>>>>>>>>>>> cases. >>>>>>>>>>>>>>>> Then we could support command >>>>>>>>>>>>>>>> completion in >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> future (see (3)). >>>>>>>>>>>>>>>> (3) What these commands do is simply >>>>>>>>>>>>>>>> execute >>>>>>>>>>>>>>>> an expression on the remote side. But we >>>>>>>>>>>>>>>> already have a mechanism to execute >>>>>>>>>>>>>>>> expressions >>>>>>>>>>>>>>>> on the remote side: Snippets. >>>>>>>>>>>>>>>> That leaves a problem: we >>>>>>>>>>>>>>>> wouldn't >>>>>>>>>>>>>>>> want >>>>>>>>>>>>>>>> these Snippets to be seen by the user, >>>>>>>>>>>>>>>> but we >>>>>>>>>>>>>>>> have a solution for that the tool uses >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> idGenerator. >>>>>>>>>>>>>>>> Another problem is that, by >>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> with no current way around the default, >>>>>>>>>>>>>>>> expressions generate temp-variables. My >>>>>>>>>>>>>>>> intention was to make this configurable >>>>>>>>>>>>>>>> -- see >>>>>>>>>>>>>>>> Eval.shouldGenTempVar(...). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> One goal I've been using in the design >>>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>>> API is to keep it as small and simple as >>>>>>>>>>>>>>>> possible. This improves >>>>>>>>>>>>>>>> maintainability, but >>>>>>>>>>>>>>>> much more importantly makes the API >>>>>>>>>>>>>>>> easier to >>>>>>>>>>>>>>>> learn and use. >>>>>>>>>>>>>>>> So, for something to warrant inclusion >>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>> be generally useful and have no other >>>>>>>>>>>>>>>> way of >>>>>>>>>>>>>>>> being achieved -- neither is true of >>>>>>>>>>>>>>>> these two >>>>>>>>>>>>>>>> queries. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> My suggestion, particularly in light of >>>>>>>>>>>>>>>> how >>>>>>>>>>>>>>>> late >>>>>>>>>>>>>>>> in the release this is, would be (2). >>>>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Robert >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2016-09-03 18:15 GMT+09:00 >>>>>>>>>>>>>>>>> ShinyaYoshida >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>>>>> Thank you for reviewing. >>>>>>>>>>>>>>>>> I'll update my patch later. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2016-09-02 11:38 GMT+09:00 Robert >>>>>>>>>>>>>>>>> Field >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks shiyafox! This is a >>>>>>>>>>>>>>>>> significant >>>>>>>>>>>>>>>>> piece of code! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As to your questions -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > I wonder if you could work >>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>> documentation of the API and >>>>>>>>>>>>>>>>> the tool >>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, I will do API and tool >>>>>>>>>>>>>>>>> docs. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thank you! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > Subcommand of /set is >>>>>>>>>>>>>>>>> reasonable? >>>>>>>>>>>>>>>>> Similar command, /classpath, >>>>>>>>>>>>>>>>> to make >>>>>>>>>>>>>>>>> users available to use new >>>>>>>>>>>>>>>>> packages is >>>>>>>>>>>>>>>>> not a subcommand of /set. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, I think /set exports is >>>>>>>>>>>>>>>>> best. >>>>>>>>>>>>>>>>> And, yes, /classpath is >>>>>>>>>>>>>>>>> inconsistent, >>>>>>>>>>>>>>>>> it should be /set classpath, >>>>>>>>>>>>>>>>> that can >>>>>>>>>>>>>>>>> be a separate task, unless you >>>>>>>>>>>>>>>>> want to >>>>>>>>>>>>>>>>> roll that in. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I see, I've created the issue to >>>>>>>>>>>>>>>>> move >>>>>>>>>>>>>>>>> /classpath to /set classpath: >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165405 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > Should we need retain >>>>>>>>>>>>>>>>> feature to >>>>>>>>>>>>>>>>> this? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> All /set have a /retain >>>>>>>>>>>>>>>>> counterpart -- >>>>>>>>>>>>>>>>> we should maintain that >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Ok, I'll add /retain exports. >>>>>>>>>>>>>>>>> I've also create the issue for >>>>>>>>>>>>>>>>> retaining >>>>>>>>>>>>>>>>> classpath: >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165406 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As to the code review: Looks >>>>>>>>>>>>>>>>> good to >>>>>>>>>>>>>>>>> me, just minor >>>>>>>>>>>>>>>>> questions/issues -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> JShellTool.java: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> * As discussed /set >>>>>>>>>>>>>>>>> add-exports => >>>>>>>>>>>>>>>>> /set >>>>>>>>>>>>>>>>> exports >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> * Nit: a comment got moved out >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> place >>>>>>>>>>>>>>>>> line 1194(old) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> JShell.java: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> * EXT_CMD_AVAILABLE_MODULES and >>>>>>>>>>>>>>>>> EXT_CMD_AVAILABLE_PACKAGES, these >>>>>>>>>>>>>>>>> should be referenced via >>>>>>>>>>>>>>>>> RemoteCodes.java rather than be >>>>>>>>>>>>>>>>> coped. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Absolutely! I'd like to move these >>>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>>> RemoteCodes but it is >>>>>>>>>>>>>>>>> package-private >>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>> and cannot be referred from JShell. >>>>>>>>>>>>>>>>> Can I make RemoteCodes public and >>>>>>>>>>>>>>>>> move it >>>>>>>>>>>>>>>>> to another module-private package >>>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>> jdk.jshell.execution.code? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> * Which leads me to another >>>>>>>>>>>>>>>>> question: >>>>>>>>>>>>>>>>> why is addExports a command >>>>>>>>>>>>>>>>> and these >>>>>>>>>>>>>>>>> two are extensions. It seems >>>>>>>>>>>>>>>>> fine, >>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>> curious. I notice that >>>>>>>>>>>>>>>>> extensions >>>>>>>>>>>>>>>>> are a >>>>>>>>>>>>>>>>> lot less code -- ;-) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Exporting module and package is >>>>>>>>>>>>>>>>> similar to >>>>>>>>>>>>>>>>> adding classpath to platform, so I >>>>>>>>>>>>>>>>> made >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> addExports a command like >>>>>>>>>>>>>>>>> setClasspath. >>>>>>>>>>>>>>>>> And it should be added as API >>>>>>>>>>>>>>>>> because >>>>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>>>> very basic feature. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> TaskFactory.java: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> * Question: the "/" separator >>>>>>>>>>>>>>>>> between >>>>>>>>>>>>>>>>> module and package is that >>>>>>>>>>>>>>>>> platform >>>>>>>>>>>>>>>>> independent? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It seems to me that >>>>>>>>>>>>>>>>> "{module}/{path}" >>>>>>>>>>>>>>>>> format for --add-exports option of >>>>>>>>>>>>>>>>> javac is >>>>>>>>>>>>>>>>> platform independent. >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> DefaultLoaderDelegate.java: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> * Jan, can you look at this >>>>>>>>>>>>>>>>> code? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -Robert >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 09/01/16 05:36, >>>>>>>>>>>>>>>>> ShinyaYoshida >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> I've implemented this >>>>>>>>>>>>>>>>> feature to >>>>>>>>>>>>>>>>> JShell API and Tool with >>>>>>>>>>>>>>>>> full >>>>>>>>>>>>>>>>> completion: >>>>>>>>>>>>>>>>> Bugs: >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8154714 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> jdk: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~sh >>>>>>>>>>>>>>>>> inyafox/kulla/8154714/webrev.00.jdk/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Eshinyafox/kulla/8154714/webrev.00.jdk/> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Eshinyafox/kulla/8154714/webrev.00.jdk/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Eshinyafox/kulla/8154714/webrev.00.jdk/>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> langtools: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~sh >>>>>>>>>>>>>>>>> inyafox/kulla/8154714/webrev.00.langtools/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Eshinyafox/kulla/8154714/webrev.00.langtools/> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Eshinyafox/kulla/8154714/webrev.00.langtools/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Eshinyafox/kulla/8154714/webrev.00.langtools/>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This is missing the train >>>>>>>>>>>>>>>>> of Java >>>>>>>>>>>>>>>>> 9.0 but it could catch the >>>>>>>>>>>>>>>>> train of >>>>>>>>>>>>>>>>> Java 9.1 or later. >>>>>>>>>>>>>>>>> I want to get your >>>>>>>>>>>>>>>>> comments for >>>>>>>>>>>>>>>>> this. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> jshell> /set add-exports >>>>>>>>>>>>>>>>> jdk.jconsole >>>>>>>>>>>>>>>>> sun.tools.jconsole >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> jshell> import >>>>>>>>>>>>>>>>> sun.tools.jconsole.* >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> jshell> >>>>>>>>>>>>>>>>> LocalVirtualMachine.getAllVirtualMachines().forEach((k, >>>>>>>>>>>>>>>>> v) -> System.out.println(k >>>>>>>>>>>>>>>>> + ":" >>>>>>>>>>>>>>>>> + v)) >>>>>>>>>>>>>>>>> 10778:jdk.jshell/jdk.internal.jshell.tool.JShellTool >>>>>>>>>>>>>>>>> 10826:jdk.jshell.execution.RemoteExecutionControl >>>>>>>>>>>>>>>>> 35548 >>>>>>>>>>>>>>>>> 28447:org.netbeans.Main --cachedir >>>>>>>>>>>>>>>>> /home/bitter_fox/.cache/netbeans/8.0.1 >>>>>>>>>>>>>>>>> --userdir >>>>>>>>>>>>>>>>> /home/bitter_fox/.netbeans/8.0.1 >>>>>>>>>>>>>>>>> --branding nb >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Currently, there is no >>>>>>>>>>>>>>>>> testing, so >>>>>>>>>>>>>>>>> it will be required to add >>>>>>>>>>>>>>>>> test. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> shinyafox(Shinya Yoshida) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From jan.lahoda at oracle.com Fri Sep 30 07:50:31 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 30 Sep 2016 09:50:31 +0200 Subject: RFR 8166183: jshell tool: on return from Ctrl-Z, garbage on screen, dies with Ctrl-C Message-ID: <57EE1947.9050601@oracle.com> Hello, When jshell or jjs are suspended and resumed, the terminal is reset to un-raw/cooked mode and jline editing is not working properly (as that requires raw mode). The solution I know about is to reset the terminal to raw mode on resume. This can be achieved using jdk.internal.misc.Signal (or sun.misc.Signal), which seems mostly fine to me for jshell and jjs, as s.m.Signal is a critical internal API per JEP 260. (Use of Signal would seem less fine to me in jdk.internal.le, as Signal is still an internal API.) Bug: https://bugs.openjdk.java.net/browse/JDK-8166183 Webrevs: jdk repository: http://cr.openjdk.java.net/~jlahoda/8166183/jdk.00/ langtools repository: http://cr.openjdk.java.net/~jlahoda/8166183/langtools.00/ nashorn repository: http://cr.openjdk.java.net/~jlahoda/8166183/nashorn.00/ Any feedback is welcome. Thanks, Jan From bitterfoxc at gmail.com Fri Sep 30 09:04:00 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Fri, 30 Sep 2016 18:04:00 +0900 Subject: RFR 8145263: JShell API: Change the format of SourceCodeAnalysis#documentation In-Reply-To: References: <566ED116.3080502@oracle.com> <56707E7E.4020704@oracle.com> <57E979DC.2060007@oracle.com> Message-ID: Hi Robert and Jan, I've updated the webrev to current code base: http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.10/ Could you review this? Regards, shinyafox(Shinya Yoshida) 2016-09-27 4:51 GMT+09:00 ShinyaYoshida : > Hi Robert, > Never mind! And I'm also sorry for having left this. > > I'll try updating webrev to current code base until 1/Oct. > > BTW, currently a lot of things in jshell are configurable, could signature > of documentation also be configurable in future(JDK10 or 9.1 or ...)? > > Thank you, > shinyafox(Shinya Yoshida) > > 2016-09-26 12:41 GMT-07:00 Robert Field : > >> In reviewing outstanding issues, we discovered this RFR which was left >> hanging. >> >> Our sincere apologies for dropping the ball on this. >> >> We are juggling a lot, if we miss something like this in the future, >> please let us know. >> >> I have made some changes in the issue, please note them. I know there >> have been some underlying changes as well (parameter names from source). >> >> If you would be willing to update this RFR we will review promptly. >> >> Thank you and sorry, >> Robert >> >> >> On 12/15/15 17:07, ShinyaYoshida wrote: >> >> Hi Jan and Robert, >> Thank you. >> >> I've filed: >> https://bugs.openjdk.java.net/browse/JDK-8145473 >> >> Ok, I put the type parameters for the constructor before the >> traditional(current) form: >> http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.01/ >> >> Please review it again. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >> 2015-12-16 5:56 GMT+09:00 Jan Lahoda : >> >>> Hi Shinya, >>> >>> On 14.12.2015 15:40, ShinyaYoshida wrote: >>> >>>> Hi Jan, >>>> Thank you for your review. >>>> >>>> 2015-12-14 23:24 GMT+09:00 Jan Lahoda >>> >: >>>> >>>> Hi Shinya, >>>> >>>> Generally, looks good, thanks for looking at this! Two comments: >>>> -for parameter names, I was hoping we could get them from the >>>> sources (if/when available), but we are not doing that now, and >>>> hiding synthetic parameter names makes sense to me. So this is OK, >>>> and if we at some point start to parse parameter names from the >>>> sources, we can tweak the code to do the right thing. >>>> >>>> I think that there should be the issue for the parameter names. >>>> Do you have the issue for that? >>>> >>> >>> No issue for this yet. >>> >>> If not, should I create it? >>>> >>> >>> Sure, thanks. >>> >>> >>>> >>>> -not sure if marking constructors with ".new" >>>> ("type-name.new()") will be clear - do you think the >>>> traditional form ("type-name()") is unclear? >>>> >>>> >>>> When I consider the constructor with the generics like following, I >>>> notice that the traditional(current) form is difficult to represent it. >>>> class C { C(U u) {} } >>>> So I choose that format which is like the constructor reference. >>>> >>> >>> I think generic constructors (i.e. constructors that themselves have >>> type parameters) are very uncommon, so I wouldn't optimize for those. >>> Having the format nice for usual constructors is more important, I think, >>> even if the format for these uncommon constructors would be uglier. >>> >>> Thanks, >>> Jan >>> >>> >>> >>>> Another possible representation is "new >>>> type-name()" which is similar to the invocation >>>> of >>>> the constructor with generics. >>>> >>>> What do you think? >>>> >>>> Regards, >>>> shinyafox(Shinya Yoshida) >>>> >>>> >>>> Thanks, >>>> Jan >>>> >>>> >>>> On 13.12.2015 07:33, ShinyaYoshida wrote: >>>> >>>> Hi Jan and Robert, >>>> I'd like to propose changing the format of >>>> SourceCodeAnalysis#documentation. >>>> >>>> The detail of the change is on the issue 8145263: >>>> https://bugs.openjdk.java.net/browse/JDK-8145263 >>>> Please see it. >>>> >>>> You can see the more example in the test of my patch. >>>> >>>> Patch is here: >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.00/ >>>> >>>> Please consider my proposal and review the patch. >>>> >>>> Regards, >>>> shinyafox(Shinya Yoshida) >>>> >>>> >>>> >> >> > From robert.field at oracle.com Fri Sep 30 15:06:28 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 30 Sep 2016 10:06:28 -0500 Subject: RFR 8166183: jshell tool: on return from Ctrl-Z, garbage on screen, dies with Ctrl-C In-Reply-To: <57EE1947.9050601@oracle.com> References: <57EE1947.9050601@oracle.com> Message-ID: <1577ba1d938.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Thumbs up on langtools and JDK. Thanks! Great to have this. Robert On September 30, 2016 2:50:46 AM Jan Lahoda wrote: > Hello, > > When jshell or jjs are suspended and resumed, the terminal is reset to > un-raw/cooked mode and jline editing is not working properly (as that > requires raw mode). The solution I know about is to reset the terminal > to raw mode on resume. This can be achieved using > jdk.internal.misc.Signal (or sun.misc.Signal), which seems mostly fine > to me for jshell and jjs, as s.m.Signal is a critical internal API per > JEP 260. (Use of Signal would seem less fine to me in jdk.internal.le, > as Signal is still an internal API.) > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8166183 > > Webrevs: > jdk repository: > http://cr.openjdk.java.net/~jlahoda/8166183/jdk.00/ > > langtools repository: > http://cr.openjdk.java.net/~jlahoda/8166183/langtools.00/ > > nashorn repository: > http://cr.openjdk.java.net/~jlahoda/8166183/nashorn.00/ > > Any feedback is welcome. > > Thanks, > Jan From robert.field at oracle.com Fri Sep 30 15:26:25 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 30 Sep 2016 10:26:25 -0500 Subject: RFR 8145263: JShell API: Change the format of SourceCodeAnalysis#documentation In-Reply-To: References: <566ED116.3080502@oracle.com> <56707E7E.4020704@oracle.com> <57E979DC.2060007@oracle.com> Message-ID: <1577bb420e8.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Nice! Includes a lot of touches to make it more readable and useful. Passing on one bit of feedback from Brian, put into my words: since we are going to be adding full javadoc access, we want this signature output crisp. So, the throws clause is probably overkill. Thanks, Robert On September 30, 2016 4:04:03 AM ShinyaYoshida wrote: > Hi Robert and Jan, > I've updated the webrev to current code base: > http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.10/ > > Could you review this? > > Regards, > shinyafox(Shinya Yoshida) > > > 2016-09-27 4:51 GMT+09:00 ShinyaYoshida : > >> Hi Robert, >> Never mind! And I'm also sorry for having left this. >> >> I'll try updating webrev to current code base until 1/Oct. >> >> BTW, currently a lot of things in jshell are configurable, could signature >> of documentation also be configurable in future(JDK10 or 9.1 or ...)? >> >> Thank you, >> shinyafox(Shinya Yoshida) >> >> 2016-09-26 12:41 GMT-07:00 Robert Field : >> >>> In reviewing outstanding issues, we discovered this RFR which was left >>> hanging. >>> >>> Our sincere apologies for dropping the ball on this. >>> >>> We are juggling a lot, if we miss something like this in the future, >>> please let us know. >>> >>> I have made some changes in the issue, please note them. I know there >>> have been some underlying changes as well (parameter names from source). >>> >>> If you would be willing to update this RFR we will review promptly. >>> >>> Thank you and sorry, >>> Robert >>> >>> >>> On 12/15/15 17:07, ShinyaYoshida wrote: >>> >>> Hi Jan and Robert, >>> Thank you. >>> >>> I've filed: >>> https://bugs.openjdk.java.net/browse/JDK-8145473 >>> >>> Ok, I put the type parameters for the constructor before the >>> traditional(current) form: >>> http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.01/ >>> >>> Please review it again. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> >>> 2015-12-16 5:56 GMT+09:00 Jan Lahoda : >>> >>>> Hi Shinya, >>>> >>>> On 14.12.2015 15:40, ShinyaYoshida wrote: >>>> >>>>> Hi Jan, >>>>> Thank you for your review. >>>>> >>>>> 2015-12-14 23:24 GMT+09:00 Jan Lahoda >>>> >: >>>>> >>>>> Hi Shinya, >>>>> >>>>> Generally, looks good, thanks for looking at this! Two comments: >>>>> -for parameter names, I was hoping we could get them from the >>>>> sources (if/when available), but we are not doing that now, and >>>>> hiding synthetic parameter names makes sense to me. So this is OK, >>>>> and if we at some point start to parse parameter names from the >>>>> sources, we can tweak the code to do the right thing. >>>>> >>>>> I think that there should be the issue for the parameter names. >>>>> Do you have the issue for that? >>>>> >>>> >>>> No issue for this yet. >>>> >>>> If not, should I create it? >>>>> >>>> >>>> Sure, thanks. >>>> >>>> >>>>> >>>>> -not sure if marking constructors with ".new" >>>>> ("type-name.new()") will be clear - do you think the >>>>> traditional form ("type-name()") is unclear? >>>>> >>>>> >>>>> When I consider the constructor with the generics like following, I >>>>> notice that the traditional(current) form is difficult to represent it. >>>>> class C { C(U u) {} } >>>>> So I choose that format which is like the constructor reference. >>>>> >>>> >>>> I think generic constructors (i.e. constructors that themselves have >>>> type parameters) are very uncommon, so I wouldn't optimize for those. >>>> Having the format nice for usual constructors is more important, I think, >>>> even if the format for these uncommon constructors would be uglier. >>>> >>>> Thanks, >>>> Jan >>>> >>>> >>>> >>>>> Another possible representation is "new >>>>> type-name()" which is similar to the invocation >>>>> of >>>>> the constructor with generics. >>>>> >>>>> What do you think? >>>>> >>>>> Regards, >>>>> shinyafox(Shinya Yoshida) >>>>> >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>>> >>>>> On 13.12.2015 07:33, ShinyaYoshida wrote: >>>>> >>>>> Hi Jan and Robert, >>>>> I'd like to propose changing the format of >>>>> SourceCodeAnalysis#documentation. >>>>> >>>>> The detail of the change is on the issue 8145263: >>>>> https://bugs.openjdk.java.net/browse/JDK-8145263 >>>>> Please see it. >>>>> >>>>> You can see the more example in the test of my patch. >>>>> >>>>> Patch is here: >>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.00/ >>>>> >>>>> Please consider my proposal and review the patch. >>>>> >>>>> Regards, >>>>> shinyafox(Shinya Yoshida) >>>>> >>>>> >>>>> >>> >>> >>