From joao.parana at gmail.com Fri Jan 1 17:31:12 2016 From: joao.parana at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Antonio_Ferreira?=) Date: Fri, 1 Jan 2016 15:31:12 -0200 Subject: How to run a JPA application using JShell In-Reply-To: References: Message-ID: Sure ! Install Docker then run this commands: The *dockerhost.local* host is *boot2docker* or *docker-machine* host on MAC OS X or Windows. On Linux you can use 127.0.0.1 docker pull parana/jshell export MYSQL_ROOT_PASSWORD=xpto docker run -d --name mysql_db -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=$MYSQL_ROOT_PASSWORD \ -e MYSQL_DATABASE=test \ -e MYSQL_USER=test \ -e MYSQL_PASSWORD=test \ mariadb bash # Verify MySQL database connection mysql -u root -h *dockerhost.local* -p # Please provide the password xpto mysql> show databases; mysql> use test; mysql> show tables; Running JPA test with JShell on Docker container docker run -i -t --rm --name jshell \ --link mysql_db:mysql \ parana/jshell bash # Verifying persistence.xml jar -tvf target/myJshellAppLib.jar META-INF/persistence.xml # Testing JAR App inside console. This run OK ! java -jar target/myJshellAppLib.jar # Testing inside Shell. This throw an javax.persistence.PersistenceException jshell /classpath target/myJshellAppLib.jar import br.com.joaoparana.* App app = new App() String[] args = {} App.main(args) Starting JPA Test with MySql Database | javax.persistence.PersistenceException thrown: *No Persistence provider for EntityManager named myPersistence* | at Persistence.createEntityManagerFactory (Persistence.java:85) | at App.getEMF (App.java:100) | at App.main (App.java:37) | at (#12:1) This simple project can be viewed on https://github.com/joao-parana/jshell/tree/master/my-jshell-app This sound like a Classloader problem. I hope this help. Jo?o Antonio ? 2015-12-30 9:44 GMT-02:00 Ben Evans : > Hi Joao, > > Could you post a minimal test case that demonstrates the problem? > > Thanks, > > Ben > > On Wed, Dec 30, 2015 at 11:36 AM, Jo?o Antonio Ferreira > wrote: > > I'm unable to load the persistence.xml file when using a Shell JPA > > application. > > > > > > Jo?o Antonio > From robert.field at oracle.com Mon Jan 4 03:42:18 2016 From: robert.field at oracle.com (Robert Field) Date: Sun, 03 Jan 2016 19:42:18 -0800 Subject: RFR 8146368(xs): JShell: couldn't smash the error when it's Japanese locale In-Reply-To: References: Message-ID: <5689EA1A.9010902@oracle.com> Thanks, Shinya, for bringing this to the forefront. Internationalization is an area that has not been addressed much at this point. I see several places in the code that use getMessage(null) and then attempt to parse the result. Behind the API: In Unit, the case you address, the diagnostic is only used to extract the unresolved symbols, so it is fine to pin it to the ROOT Locale, though the whole parsing of diagnostics approach I took is not ideal. There are uses in TaskFactory which are only used for debugging. though they do parse the result expecting English words. The one in OuterWrap should also not be visible by an end-user (and, arguably should indeed be passed null). One approach would be to define something like PARSED_LOCALE = Locale.ROOT in Util, and use that throughout the jdk.jshell package (possibly with the exception of OuterWrap). Another, much more ambitious approach would to implement the TODO comment in Unit.UnresolvedExtractor: //TODO extract from tree instead -- note: internationalization This would be a redesign for which I have no implementation in mind, so it isn't likely the right choice here. So, I think pulling the Locale definition up to a visible and shareable location is the best bet. Then there is the usage in JShellTool.printDiagnostics, here we clearly want the user's Locale (the end-user sees this message). But then the startsWith() search will fail in other Locales (the failure is not catastrophic, just extra output). I think the only thing to do for now would be to add a comment on the line, like: //TODO: Internationalize Thanks! Robert On 12/31/15 13:13, ShinyaYoshida wrote: > A HAPPY NEW YEAR!! > > Could you review this? > > webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8146368/webrev.00/ > > bugs: https://bugs.openjdk.java.net/browse/JDK-8146368 > > Regards, > shinyafox(ShinyaYoshida) From bitterfoxc at gmail.com Mon Jan 4 20:45:52 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Tue, 5 Jan 2016 05:45:52 +0900 Subject: RFR 8146368(xs): JShell: couldn't smash the error when it's Japanese locale In-Reply-To: <5689EA1A.9010902@oracle.com> References: <5689EA1A.9010902@oracle.com> Message-ID: Hi Robert, Thank you for your review. New webrev is here: http://cr.openjdk.java.net/~shinyafox/kulla/8146368/webrev.01/ 2016-01-04 12:42 GMT+09:00 Robert Field : > Thanks, Shinya, for bringing this to the forefront. Internationalization > is an area that has not been addressed much at this point. > > I see several places in the code that use getMessage(null) and then > attempt to parse the result. > > Behind the API: In Unit, the case you address, the diagnostic is only used > to extract the unresolved symbols, so it is fine to pin it to the ROOT > Locale, though the whole parsing of diagnostics approach I took is not > ideal. There are uses in TaskFactory which are only used for debugging. > though they do parse the result expecting English words. The one in > OuterWrap should also not be visible by an end-user (and, arguably should > indeed be passed null). One approach would be to define something like > PARSED_LOCALE = Locale.ROOT in Util, and use that throughout the jdk.jshell > package (possibly with the exception of OuterWrap). > I've changed doing so (excepting OuterWrap). (But I've fixed indentation around the use of #getMessage in OuterWrap) I also except one of use in TaskFactory. Because the message is not used for parsing and I think there is no reason to pin the locale to ROOT. -- state.debug(DBG_GEN, "Pos: %d (%d - %d) -- %s\n", diag.getPosition(), diag.getStartPosition(), diag.getEndPosition(), diag.getMessage(null)); -- (And I notice that TaskFactory#shortErrorMessage is not used anywhere) What do you think? > Another, much more ambitious approach would to implement the TODO comment > in Unit.UnresolvedExtractor: > //TODO extract from tree instead -- note: internationalization > This would be a redesign for which I have no implementation in mind, so it > isn't likely the right choice here. > > So, I think pulling the Locale definition up to a visible and shareable > location is the best bet. > > Then there is the usage in JShellTool.printDiagnostics, here we clearly > want the user's Locale (the end-user sees this message). But then the > startsWith() search will fail in other Locales (the failure is not > catastrophic, just extra output). I think the only thing to do for now > would be to add a comment on the line, like: //TODO: Internationalize > I've added the comment. As you mentioned, i18n has not been addressed yet. Can I address it after this? Regards, shinyafox(Shinya Yoshida) > Thanks! > Robert > > On 12/31/15 13:13, ShinyaYoshida wrote: > >> A HAPPY NEW YEAR!! >> >> Could you review this? >> >> webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8146368/webrev.00/ < >> http://cr.openjdk.java.net/%7Eshinyafox/kulla/8146368/webrev.00/> >> bugs: https://bugs.openjdk.java.net/browse/JDK-8146368 >> >> Regards, >> shinyafox(ShinyaYoshida) >> > > From jan.lahoda at oracle.com Thu Jan 7 12:34:52 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 07 Jan 2016 13:34:52 +0100 Subject: RFR 8081845: JShell: Need way to refresh relative to external state In-Reply-To: <5684D14F.80508@oracle.com> References: <5684D14F.80508@oracle.com> Message-ID: <568E5B6C.2080105@oracle.com> Seems OK to me. I wonder if we will have problems with snippets taking too long to execute, or with side-effects, but we will find out. A nit: In @@ -250,10 +261,16 @@: // Read replay history from last jshell session into previoius history -> // Read replay history from last jshell session into previous history Jan On 31.12.2015 07:55, Robert Field wrote: > JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8081845 > Webrev: http://cr.openjdk.java.net/~rfield/8081845v1/ > From robert.field at oracle.com Thu Jan 7 16:20:34 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 07 Jan 2016 08:20:34 -0800 Subject: RFR 8081845: JShell: Need way to refresh relative to external state In-Reply-To: <568E5B6C.2080105@oracle.com> References: <5684D14F.80508@oracle.com> <568E5B6C.2080105@oracle.com> Message-ID: <1521ce3c050.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Thank you Jan. Taking too long is a real concern. Anything ctrl-c'ed when initially entered will not be recorded in replay history. Any side-effects should be the same the second time. Or, an I missing your meaning? Thanks, Robert On January 7, 2016 4:34:55 AM Jan Lahoda wrote: > Seems OK to me. I wonder if we will have problems with snippets taking > too long to execute, or with side-effects, but we will find out. > > A nit: > > In @@ -250,10 +261,16 @@: > // Read replay history from last jshell session into previoius history > -> > // Read replay history from last jshell session into previous history > > Jan > > On 31.12.2015 07:55, Robert Field wrote: >> JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8081845 >> Webrev: http://cr.openjdk.java.net/~rfield/8081845v1/ >> From jan.lahoda at oracle.com Thu Jan 7 22:00:57 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 07 Jan 2016 23:00:57 +0100 Subject: RFR 8081845: JShell: Need way to refresh relative to external state In-Reply-To: <1521ce3c050.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <5684D14F.80508@oracle.com> <568E5B6C.2080105@oracle.com> <1521ce3c050.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: <568EE019.4090508@oracle.com> On 7.1.2016 17:20, Robert Field wrote: > Thank you Jan. > > Taking too long is a real concern. Anything ctrl-c'ed when initially > entered will not be recorded in replay history. > > Any side-effects should be the same the second time. Or, an I missing > your meaning? I was thinking of "external" side-effects, like creating or deleting a file. I think practice will show if (and when) that will be causing problems (i.e. to what degree it is problematic to do these the second time). Jan > > Thanks, > Robert > > > > On January 7, 2016 4:34:55 AM Jan Lahoda wrote: > >> Seems OK to me. I wonder if we will have problems with snippets taking >> too long to execute, or with side-effects, but we will find out. >> >> A nit: >> >> In @@ -250,10 +261,16 @@: >> // Read replay history from last jshell session into previoius history >> -> >> // Read replay history from last jshell session into previous history >> >> Jan >> >> On 31.12.2015 07:55, Robert Field wrote: >>> JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8081845 >>> Webrev: http://cr.openjdk.java.net/~rfield/8081845v1/ >>> > > From robert.field at oracle.com Thu Jan 7 22:29:04 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 07 Jan 2016 14:29:04 -0800 Subject: RFR 8081845: JShell: Need way to refresh relative to external state In-Reply-To: <568EE019.4090508@oracle.com> References: <5684D14F.80508@oracle.com> <568E5B6C.2080105@oracle.com> <1521ce3c050.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> <568EE019.4090508@oracle.com> Message-ID: <1521e351f80.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Yep. I think we need this functionality anyhow and we need real world data to know when it will fail and what other options we should pursue. Thanks, Robert On January 7, 2016 2:01:01 PM Jan Lahoda wrote: > On 7.1.2016 17:20, Robert Field wrote: >> Thank you Jan. >> >> Taking too long is a real concern. Anything ctrl-c'ed when initially >> entered will not be recorded in replay history. >> >> Any side-effects should be the same the second time. Or, an I missing >> your meaning? > > I was thinking of "external" side-effects, like creating or deleting a > file. I think practice will show if (and when) that will be causing > problems (i.e. to what degree it is problematic to do these the second > time). > > Jan > >> >> Thanks, >> Robert >> >> >> >> On January 7, 2016 4:34:55 AM Jan Lahoda wrote: >> >>> Seems OK to me. I wonder if we will have problems with snippets taking >>> too long to execute, or with side-effects, but we will find out. >>> >>> A nit: >>> >>> In @@ -250,10 +261,16 @@: >>> // Read replay history from last jshell session into previoius history >>> -> >>> // Read replay history from last jshell session into previous history >>> >>> Jan >>> >>> On 31.12.2015 07:55, Robert Field wrote: >>>> JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8081845 >>>> Webrev: http://cr.openjdk.java.net/~rfield/8081845v1/ >>>> >> >> From bitterfoxc at gmail.com Tue Jan 12 10:20:45 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Tue, 12 Jan 2016 19:20:45 +0900 Subject: RFR 8146368(xs): JShell: couldn't smash the error when it's Japanese locale In-Reply-To: <5694596E.7060008@oracle.com> References: <5689EA1A.9010902@oracle.com> <5694596E.7060008@oracle.com> Message-ID: Hi Robert, Thank you for pushing. 2016-01-12 10:39 GMT+09:00 Robert Field : > As you mentioned, i18n has not been addressed yet. Can I address it after > this? > > > What dd you have in mind? > In my mind: For general: - Create a umbrella issue, "Globalize" - Create subtasks for the issue, "Internationalize", "Localize for Japanese" and "Localize for Chinese" (The former add the system for localization to jshell. In the other, the message will be translated to Japanese/Chinese) - It is unnecessary to localize the messages for debug printing or exceptions For jshell tool - Add resource bundles what contains the message formats or some pieces of the message, for Locale.ROOT, Japanese and Chinese: - Translation to Japanese and Chinese will be done by oracle translation team(?, I don't know the detail of translation) - Add JShellMessage which represent the message. It has a key and arguments for the message(TextFormat) - Add JShellMessages which controls resource bundles and localize JShellMessage and has some factory methods for JShellMessage - In JShellTool, it has one instance of JShellMessages and currentLocale, and uses them to print the message (Now I have no idea how to test this.) For JShell API - Add resource bundles for the error message or warning. - Add the resource bundles to JavacMessages by TaskFactory - Use it in Eval#modifierDiagnostics What do you think? (Unfortunately I cannot spare my time to this until mid-february because I'm busy at my graduation thesis ;-( ) BTW, I notice that I have 8+ changesets in jdk9 repo: / http://hg.openjdk.java.net/jdk9/dev/rev/d9edec389373 /langtools http://hg.openjdk.java.net/jdk9/dev/langtools/rev/15bdc18525ff http://hg.openjdk.java.net/jdk9/dev/langtools/rev/cf000bae9c31 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2713a6edc13 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c5237b05fff9 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/51136404ee5e http://hg.openjdk.java.net/jdk9/dev/langtools/rev/70fe7cf1ac65 /dev http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2aae624bb833 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bf153b12450b I'm wondering if you could nominate me as a jdk9 committer? http://openjdk.java.net/projects/#project-committer Best Regards, shinyafox(Shinya Yoshida) Thanks, > Robert > > > Regards, > shinyafox(Shinya Yoshida) > > >> Thanks! >> Robert >> >> On 12/31/15 13:13, ShinyaYoshida wrote: >> >>> A HAPPY NEW YEAR!! >>> >>> Could you review this? >>> >>> webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8146368/webrev.00/ < >>> http://cr.openjdk.java.net/%7Eshinyafox/kulla/8146368/webrev.00/> >>> bugs: https://bugs.openjdk.java.net/browse/JDK-8146368 >>> >>> Regards, >>> shinyafox(ShinyaYoshida) >>> >> >> > > From jonathan.gibbons at oracle.com Tue Jan 12 21:55:02 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 12 Jan 2016 13:55:02 -0800 Subject: Persistent test failure on Windows In-Reply-To: <1365862600.335.1452628022741.JavaMail.hudson@sthinfra15> References: <1365862600.335.1452628022741.JavaMail.hudson@sthinfra15> Message-ID: <56957636.5040107@oracle.com> The test jdk/jshell/ToolReloadTest is persistently failing on Windows, according to one of our build and test systems. Could someone from the kulla team please investigate and fix. The relevant part of the .jtr file is as follows: [TestNG] Running: jdk/jshell/ToolReloadTest.java test ToolReloadTest.testReloadClasspath(): success test ToolReloadTest.testReloadCrashRestore(): failure java.lang.AssertionError: Kind: command. expected [| State engine terminated. | Restore definitions with: /reload restore ] but found [] at org.testng.Assert.fail(Assert.java:94) at org.testng.Assert.failNotEquals(Assert.java:494) at org.testng.Assert.assertEquals(Assert.java:123) at org.testng.Assert.assertEquals(Assert.java:176) at ReplToolTesting.assertOutput(ReplToolTesting.java:460) at ReplToolTesting.assertCommand(ReplToolTesting.java:418) at ReplToolTesting.assertCommand(ReplToolTesting.java:397) at ToolReloadTest.lambda$testReloadCrashRestore$52(ToolReloadTest.java:167) at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:704) at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:720) at java.io.PrintStream.write(PrintStream.java:480) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233) at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312) at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:316) at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:252) at jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2336) at jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277) at jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:153) at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:472) at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:287) at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:260) at ReplToolTesting.testRaw(ReplToolTesting.java:240) at ReplToolTesting.test(ReplToolTesting.java:203) at ReplToolTesting.test(ReplToolTesting.java:191) at ReplToolTesting.test(ReplToolTesting.java:187) at ReplToolTesting.test(ReplToolTesting.java:183) at ToolReloadTest.testReloadCrashRestore(ToolReloadTest.java:162) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:520) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) at org.testng.TestRunner.privateRun(TestRunner.java:767) at org.testng.TestRunner.run(TestRunner.java:617) at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) at org.testng.SuiteRunner.run(SuiteRunner.java:240) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) at org.testng.TestNG.run(TestNG.java:1057) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:520) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) at java.lang.Thread.run(Thread.java:804) test ToolReloadTest.testReloadDrop(): success test ToolReloadTest.testReloadExitRestore(): success test ToolReloadTest.testReloadIgnore(): success test ToolReloadTest.testReloadRepeat(): success test ToolReloadTest.testReloadResetRestore(): success test ToolReloadTest.testReloadSnippets(): success =============================================== jdk/jshell/ToolReloadTest.java Total tests run: 8, Failures: 1, Skips: 0 =============================================== ----------System.err:(11/574)---------- java.lang.Exception: failures: 1 at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:223) at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:520) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) at java.lang.Thread.run(Thread.java:804) From robert.field at oracle.com Tue Jan 12 22:50:04 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 12 Jan 2016 14:50:04 -0800 Subject: Persistent test failure on Windows In-Reply-To: <56957636.5040107@oracle.com> References: <1365862600.335.1452628022741.JavaMail.hudson@sthinfra15> <56957636.5040107@oracle.com> Message-ID: <5695831C.2070505@oracle.com> Thanks Jon, I don't have a Windows machine to test on. The test that it is failing on is evaluating "System.exit(1)" which crashes the remote machine. Does anyone have a Windows machine who can test behavior? Jon, should I just disable this test for now? Thanks, Robert On 01/12/16 13:55, Jonathan Gibbons wrote: > > The test jdk/jshell/ToolReloadTest is persistently failing on > Windows, according to one of our build and test systems. > Could someone from the kulla team please investigate and fix. > > The relevant part of the .jtr file is as follows: > > [TestNG] Running: > jdk/jshell/ToolReloadTest.java > > test ToolReloadTest.testReloadClasspath(): success > test ToolReloadTest.testReloadCrashRestore(): failure > java.lang.AssertionError: Kind: command. > expected [| State engine terminated. > | Restore definitions with: /reload restore > ] but found [] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:494) > at org.testng.Assert.assertEquals(Assert.java:123) > at org.testng.Assert.assertEquals(Assert.java:176) > at ReplToolTesting.assertOutput(ReplToolTesting.java:460) > at ReplToolTesting.assertCommand(ReplToolTesting.java:418) > at ReplToolTesting.assertCommand(ReplToolTesting.java:397) > at > ToolReloadTest.lambda$testReloadCrashRestore$52(ToolReloadTest.java:167) > at > ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:704) > at > ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:720) > at java.io.PrintStream.write(PrintStream.java:480) > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233) > at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312) > at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:316) > at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153) > at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:252) > at > jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2336) > at > jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277) > at > jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:153) > at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:472) > at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:287) > at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:260) > at ReplToolTesting.testRaw(ReplToolTesting.java:240) > at ReplToolTesting.test(ReplToolTesting.java:203) > at ReplToolTesting.test(ReplToolTesting.java:191) > at ReplToolTesting.test(ReplToolTesting.java:187) > at ReplToolTesting.test(ReplToolTesting.java:183) > at ToolReloadTest.testReloadCrashRestore(ToolReloadTest.java:162) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:520) > at > org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at > org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) > at org.testng.SuiteRunner.run(SuiteRunner.java:240) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) > at org.testng.TestNG.run(TestNG.java:1057) > at > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) > at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:520) > at > com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) > at java.lang.Thread.run(Thread.java:804) > test ToolReloadTest.testReloadDrop(): success > test ToolReloadTest.testReloadExitRestore(): success > test ToolReloadTest.testReloadIgnore(): success > test ToolReloadTest.testReloadRepeat(): success > test ToolReloadTest.testReloadResetRestore(): success > test ToolReloadTest.testReloadSnippets(): success > > =============================================== > jdk/jshell/ToolReloadTest.java > Total tests run: 8, Failures: 1, Skips: 0 > =============================================== > > ----------System.err:(11/574)---------- > java.lang.Exception: failures: 1 > at > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:223) > at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:520) > at > com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) > at java.lang.Thread.run(Thread.java:804) > > From jonathan.gibbons at oracle.com Tue Jan 12 22:55:35 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 12 Jan 2016 14:55:35 -0800 Subject: Persistent test failure on Windows In-Reply-To: <5695831C.2070505@oracle.com> References: <1365862600.335.1452628022741.JavaMail.hudson@sthinfra15> <56957636.5040107@oracle.com> <5695831C.2070505@oracle.com> Message-ID: <56958467.5010905@oracle.com> Just curious, Do you run the remote machine with any sort of security manager installed? If not, should you? It seems like you should not allow System.exit to succeed. -- Jon On 01/12/2016 02:50 PM, Robert Field wrote: > Thanks Jon, > > I don't have a Windows machine to test on. > > The test that it is failing on is evaluating "System.exit(1)" which > crashes the remote machine. Does anyone have a Windows machine who can > test behavior? > > Jon, should I just disable this test for now? > > Thanks, > Robert > > > On 01/12/16 13:55, Jonathan Gibbons wrote: >> >> The test jdk/jshell/ToolReloadTest is persistently failing on >> Windows, according to one of our build and test systems. >> Could someone from the kulla team please investigate and fix. >> >> The relevant part of the .jtr file is as follows: >> >> [TestNG] Running: >> jdk/jshell/ToolReloadTest.java >> >> test ToolReloadTest.testReloadClasspath(): success >> test ToolReloadTest.testReloadCrashRestore(): failure >> java.lang.AssertionError: Kind: command. >> expected [| State engine terminated. >> | Restore definitions with: /reload restore >> ] but found [] >> at org.testng.Assert.fail(Assert.java:94) >> at org.testng.Assert.failNotEquals(Assert.java:494) >> at org.testng.Assert.assertEquals(Assert.java:123) >> at org.testng.Assert.assertEquals(Assert.java:176) >> at ReplToolTesting.assertOutput(ReplToolTesting.java:460) >> at ReplToolTesting.assertCommand(ReplToolTesting.java:418) >> at ReplToolTesting.assertCommand(ReplToolTesting.java:397) >> at >> ToolReloadTest.lambda$testReloadCrashRestore$52(ToolReloadTest.java:167) >> at >> ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:704) >> at >> ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:720) >> at java.io.PrintStream.write(PrintStream.java:480) >> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233) >> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312) >> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:316) >> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153) >> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:252) >> at >> jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2336) >> at >> jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277) >> at >> jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:153) >> at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:472) >> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:287) >> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:260) >> at ReplToolTesting.testRaw(ReplToolTesting.java:240) >> at ReplToolTesting.test(ReplToolTesting.java:203) >> at ReplToolTesting.test(ReplToolTesting.java:191) >> at ReplToolTesting.test(ReplToolTesting.java:187) >> at ReplToolTesting.test(ReplToolTesting.java:183) >> at ToolReloadTest.testReloadCrashRestore(ToolReloadTest.java:162) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:520) >> at >> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) >> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) >> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) >> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) >> at >> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) >> at >> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) >> at org.testng.TestRunner.privateRun(TestRunner.java:767) >> at org.testng.TestRunner.run(TestRunner.java:617) >> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) >> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) >> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) >> at org.testng.SuiteRunner.run(SuiteRunner.java:240) >> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) >> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) >> at org.testng.TestNG.run(TestNG.java:1057) >> at >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) >> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:520) >> at >> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) >> at java.lang.Thread.run(Thread.java:804) >> test ToolReloadTest.testReloadDrop(): success >> test ToolReloadTest.testReloadExitRestore(): success >> test ToolReloadTest.testReloadIgnore(): success >> test ToolReloadTest.testReloadRepeat(): success >> test ToolReloadTest.testReloadResetRestore(): success >> test ToolReloadTest.testReloadSnippets(): success >> >> =============================================== >> jdk/jshell/ToolReloadTest.java >> Total tests run: 8, Failures: 1, Skips: 0 >> =============================================== >> >> ----------System.err:(11/574)---------- >> java.lang.Exception: failures: 1 >> at >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:223) >> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:520) >> at >> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) >> at java.lang.Thread.run(Thread.java:804) >> >> > From jan.lahoda at oracle.com Tue Jan 12 22:57:07 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 12 Jan 2016 23:57:07 +0100 Subject: Persistent test failure on Windows In-Reply-To: <5695831C.2070505@oracle.com> References: <1365862600.335.1452628022741.JavaMail.hudson@sthinfra15> <56957636.5040107@oracle.com> <5695831C.2070505@oracle.com> Message-ID: <569584C3.7090909@oracle.com> I suspect this may be a problem with line endings. I'll check tomorrow. There is a patch that strives to resolve (at least some of) the line endings problems here: http://mail.openjdk.java.net/pipermail/kulla-dev/2015-December/001163.html Further comments on that would be welcome. Thanks, Jan On 12.1.2016 23:50, Robert Field wrote: > Thanks Jon, > > I don't have a Windows machine to test on. > > The test that it is failing on is evaluating "System.exit(1)" which > crashes the remote machine. Does anyone have a Windows machine who can > test behavior? > > Jon, should I just disable this test for now? > > Thanks, > Robert > > > On 01/12/16 13:55, Jonathan Gibbons wrote: >> >> The test jdk/jshell/ToolReloadTest is persistently failing on >> Windows, according to one of our build and test systems. >> Could someone from the kulla team please investigate and fix. >> >> The relevant part of the .jtr file is as follows: >> >> [TestNG] Running: >> jdk/jshell/ToolReloadTest.java >> >> test ToolReloadTest.testReloadClasspath(): success >> test ToolReloadTest.testReloadCrashRestore(): failure >> java.lang.AssertionError: Kind: command. >> expected [| State engine terminated. >> | Restore definitions with: /reload restore >> ] but found [] >> at org.testng.Assert.fail(Assert.java:94) >> at org.testng.Assert.failNotEquals(Assert.java:494) >> at org.testng.Assert.assertEquals(Assert.java:123) >> at org.testng.Assert.assertEquals(Assert.java:176) >> at ReplToolTesting.assertOutput(ReplToolTesting.java:460) >> at ReplToolTesting.assertCommand(ReplToolTesting.java:418) >> at ReplToolTesting.assertCommand(ReplToolTesting.java:397) >> at >> ToolReloadTest.lambda$testReloadCrashRestore$52(ToolReloadTest.java:167) >> at >> ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:704) >> >> at >> ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:720) >> >> at java.io.PrintStream.write(PrintStream.java:480) >> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233) >> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312) >> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:316) >> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153) >> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:252) >> at >> jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2336) >> >> at >> jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277) >> >> at >> jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:153) >> >> at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:472) >> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:287) >> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:260) >> at ReplToolTesting.testRaw(ReplToolTesting.java:240) >> at ReplToolTesting.test(ReplToolTesting.java:203) >> at ReplToolTesting.test(ReplToolTesting.java:191) >> at ReplToolTesting.test(ReplToolTesting.java:187) >> at ReplToolTesting.test(ReplToolTesting.java:183) >> at ToolReloadTest.testReloadCrashRestore(ToolReloadTest.java:162) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> at java.lang.reflect.Method.invoke(Method.java:520) >> at >> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) >> >> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) >> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) >> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) >> at >> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) >> >> at >> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) >> at org.testng.TestRunner.privateRun(TestRunner.java:767) >> at org.testng.TestRunner.run(TestRunner.java:617) >> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) >> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) >> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) >> at org.testng.SuiteRunner.run(SuiteRunner.java:240) >> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) >> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) >> at org.testng.TestNG.run(TestNG.java:1057) >> at >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) >> >> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> at java.lang.reflect.Method.invoke(Method.java:520) >> at >> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) >> >> at java.lang.Thread.run(Thread.java:804) >> test ToolReloadTest.testReloadDrop(): success >> test ToolReloadTest.testReloadExitRestore(): success >> test ToolReloadTest.testReloadIgnore(): success >> test ToolReloadTest.testReloadRepeat(): success >> test ToolReloadTest.testReloadResetRestore(): success >> test ToolReloadTest.testReloadSnippets(): success >> >> =============================================== >> jdk/jshell/ToolReloadTest.java >> Total tests run: 8, Failures: 1, Skips: 0 >> =============================================== >> >> ----------System.err:(11/574)---------- >> java.lang.Exception: failures: 1 >> at >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:223) >> >> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> at java.lang.reflect.Method.invoke(Method.java:520) >> at >> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) >> >> at java.lang.Thread.run(Thread.java:804) >> >> > From robert.field at oracle.com Wed Jan 13 01:09:11 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 12 Jan 2016 17:09:11 -0800 Subject: Persistent test failure on Windows In-Reply-To: <569584C3.7090909@oracle.com> References: <1365862600.335.1452628022741.JavaMail.hudson@sthinfra15> <56957636.5040107@oracle.com> <5695831C.2070505@oracle.com> <569584C3.7090909@oracle.com> Message-ID: <5695A3B7.1090004@oracle.com> It might also be that the channel shutdown at the wrong time. Which also might be addressed by the patch you mention. I reviewed and liked that patch, but at that time I was not an official reviewer. Now I am, and so I bless that patch. Will you be able to test the patch's impact on this Windows issue? Thanks, Robert On 01/12/16 14:57, Jan Lahoda wrote: > I suspect this may be a problem with line endings. I'll check > tomorrow. There is a patch that strives to resolve (at least some of) > the line endings problems here: > http://mail.openjdk.java.net/pipermail/kulla-dev/2015-December/001163.html > > > Further comments on that would be welcome. > > Thanks, > Jan > > On 12.1.2016 23:50, Robert Field wrote: >> Thanks Jon, >> >> I don't have a Windows machine to test on. >> >> The test that it is failing on is evaluating "System.exit(1)" which >> crashes the remote machine. Does anyone have a Windows machine who can >> test behavior? >> >> Jon, should I just disable this test for now? >> >> Thanks, >> Robert >> >> >> On 01/12/16 13:55, Jonathan Gibbons wrote: >>> >>> The test jdk/jshell/ToolReloadTest is persistently failing on >>> Windows, according to one of our build and test systems. >>> Could someone from the kulla team please investigate and fix. >>> >>> The relevant part of the .jtr file is as follows: >>> >>> [TestNG] Running: >>> jdk/jshell/ToolReloadTest.java >>> >>> test ToolReloadTest.testReloadClasspath(): success >>> test ToolReloadTest.testReloadCrashRestore(): failure >>> java.lang.AssertionError: Kind: command. >>> expected [| State engine terminated. >>> | Restore definitions with: /reload restore >>> ] but found [] >>> at org.testng.Assert.fail(Assert.java:94) >>> at org.testng.Assert.failNotEquals(Assert.java:494) >>> at org.testng.Assert.assertEquals(Assert.java:123) >>> at org.testng.Assert.assertEquals(Assert.java:176) >>> at ReplToolTesting.assertOutput(ReplToolTesting.java:460) >>> at ReplToolTesting.assertCommand(ReplToolTesting.java:418) >>> at ReplToolTesting.assertCommand(ReplToolTesting.java:397) >>> at >>> ToolReloadTest.lambda$testReloadCrashRestore$52(ToolReloadTest.java:167) >>> >>> at >>> ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:704) >>> >>> >>> at >>> ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:720) >>> >>> >>> at java.io.PrintStream.write(PrintStream.java:480) >>> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233) >>> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312) >>> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:316) >>> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153) >>> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:252) >>> at >>> jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2336) >>> >>> >>> at >>> jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277) >>> >>> >>> at >>> jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:153) >>> >>> >>> at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:472) >>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:287) >>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:260) >>> at ReplToolTesting.testRaw(ReplToolTesting.java:240) >>> at ReplToolTesting.test(ReplToolTesting.java:203) >>> at ReplToolTesting.test(ReplToolTesting.java:191) >>> at ReplToolTesting.test(ReplToolTesting.java:187) >>> at ReplToolTesting.test(ReplToolTesting.java:183) >>> at ToolReloadTest.testReloadCrashRestore(ToolReloadTest.java:162) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> >>> >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> >>> at java.lang.reflect.Method.invoke(Method.java:520) >>> at >>> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) >>> >>> >>> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) >>> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) >>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) >>> at >>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) >>> >>> >>> at >>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) >>> at org.testng.TestRunner.privateRun(TestRunner.java:767) >>> at org.testng.TestRunner.run(TestRunner.java:617) >>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) >>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) >>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) >>> at org.testng.SuiteRunner.run(SuiteRunner.java:240) >>> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >>> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) >>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) >>> at org.testng.TestNG.run(TestNG.java:1057) >>> at >>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) >>> >>> >>> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> >>> at java.lang.reflect.Method.invoke(Method.java:520) >>> at >>> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) >>> >>> >>> at java.lang.Thread.run(Thread.java:804) >>> test ToolReloadTest.testReloadDrop(): success >>> test ToolReloadTest.testReloadExitRestore(): success >>> test ToolReloadTest.testReloadIgnore(): success >>> test ToolReloadTest.testReloadRepeat(): success >>> test ToolReloadTest.testReloadResetRestore(): success >>> test ToolReloadTest.testReloadSnippets(): success >>> >>> =============================================== >>> jdk/jshell/ToolReloadTest.java >>> Total tests run: 8, Failures: 1, Skips: 0 >>> =============================================== >>> >>> ----------System.err:(11/574)---------- >>> java.lang.Exception: failures: 1 >>> at >>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:223) >>> >>> >>> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> >>> at java.lang.reflect.Method.invoke(Method.java:520) >>> at >>> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) >>> >>> >>> at java.lang.Thread.run(Thread.java:804) >>> >>> >> From jan.lahoda at oracle.com Wed Jan 13 14:02:51 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 13 Jan 2016 15:02:51 +0100 Subject: Persistent test failure on Windows In-Reply-To: <5695A3B7.1090004@oracle.com> References: <1365862600.335.1452628022741.JavaMail.hudson@sthinfra15> <56957636.5040107@oracle.com> <5695831C.2070505@oracle.com> <569584C3.7090909@oracle.com> <5695A3B7.1090004@oracle.com> Message-ID: <5696590B.9040701@oracle.com> On 13.1.2016 02:09, Robert Field wrote: > It might also be that the channel shutdown at the wrong time. Which Yes, that could be also an issue. > also might be addressed by the patch you mention. > > I reviewed and liked that patch, but at that time I was not an official > reviewer. Now I am, and so I bless that patch. Thanks! > > Will you be able to test the patch's impact on this Windows issue? I did, and it seems to fix the ToolReloadTest problem. I've pushed the patch. Thanks, Jan > > Thanks, > Robert > > On 01/12/16 14:57, Jan Lahoda wrote: >> I suspect this may be a problem with line endings. I'll check >> tomorrow. There is a patch that strives to resolve (at least some of) >> the line endings problems here: >> http://mail.openjdk.java.net/pipermail/kulla-dev/2015-December/001163.html >> >> >> Further comments on that would be welcome. >> >> Thanks, >> Jan >> >> On 12.1.2016 23:50, Robert Field wrote: >>> Thanks Jon, >>> >>> I don't have a Windows machine to test on. >>> >>> The test that it is failing on is evaluating "System.exit(1)" which >>> crashes the remote machine. Does anyone have a Windows machine who can >>> test behavior? >>> >>> Jon, should I just disable this test for now? >>> >>> Thanks, >>> Robert >>> >>> >>> On 01/12/16 13:55, Jonathan Gibbons wrote: >>>> >>>> The test jdk/jshell/ToolReloadTest is persistently failing on >>>> Windows, according to one of our build and test systems. >>>> Could someone from the kulla team please investigate and fix. >>>> >>>> The relevant part of the .jtr file is as follows: >>>> >>>> [TestNG] Running: >>>> jdk/jshell/ToolReloadTest.java >>>> >>>> test ToolReloadTest.testReloadClasspath(): success >>>> test ToolReloadTest.testReloadCrashRestore(): failure >>>> java.lang.AssertionError: Kind: command. >>>> expected [| State engine terminated. >>>> | Restore definitions with: /reload restore >>>> ] but found [] >>>> at org.testng.Assert.fail(Assert.java:94) >>>> at org.testng.Assert.failNotEquals(Assert.java:494) >>>> at org.testng.Assert.assertEquals(Assert.java:123) >>>> at org.testng.Assert.assertEquals(Assert.java:176) >>>> at ReplToolTesting.assertOutput(ReplToolTesting.java:460) >>>> at ReplToolTesting.assertCommand(ReplToolTesting.java:418) >>>> at ReplToolTesting.assertCommand(ReplToolTesting.java:397) >>>> at >>>> ToolReloadTest.lambda$testReloadCrashRestore$52(ToolReloadTest.java:167) >>>> >>>> at >>>> ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:704) >>>> >>>> >>>> at >>>> ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:720) >>>> >>>> >>>> at java.io.PrintStream.write(PrintStream.java:480) >>>> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233) >>>> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312) >>>> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:316) >>>> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153) >>>> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:252) >>>> at >>>> jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2336) >>>> >>>> >>>> at >>>> jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277) >>>> >>>> >>>> at >>>> jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:153) >>>> >>>> >>>> at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:472) >>>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:287) >>>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:260) >>>> at ReplToolTesting.testRaw(ReplToolTesting.java:240) >>>> at ReplToolTesting.test(ReplToolTesting.java:203) >>>> at ReplToolTesting.test(ReplToolTesting.java:191) >>>> at ReplToolTesting.test(ReplToolTesting.java:187) >>>> at ReplToolTesting.test(ReplToolTesting.java:183) >>>> at ToolReloadTest.testReloadCrashRestore(ToolReloadTest.java:162) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> >>>> >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> >>>> >>>> at java.lang.reflect.Method.invoke(Method.java:520) >>>> at >>>> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) >>>> >>>> >>>> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) >>>> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) >>>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) >>>> at >>>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) >>>> >>>> >>>> at >>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) >>>> at org.testng.TestRunner.privateRun(TestRunner.java:767) >>>> at org.testng.TestRunner.run(TestRunner.java:617) >>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) >>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) >>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) >>>> at org.testng.SuiteRunner.run(SuiteRunner.java:240) >>>> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >>>> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >>>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) >>>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) >>>> at org.testng.TestNG.run(TestNG.java:1057) >>>> at >>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) >>>> >>>> >>>> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> >>>> >>>> at java.lang.reflect.Method.invoke(Method.java:520) >>>> at >>>> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) >>>> >>>> >>>> at java.lang.Thread.run(Thread.java:804) >>>> test ToolReloadTest.testReloadDrop(): success >>>> test ToolReloadTest.testReloadExitRestore(): success >>>> test ToolReloadTest.testReloadIgnore(): success >>>> test ToolReloadTest.testReloadRepeat(): success >>>> test ToolReloadTest.testReloadResetRestore(): success >>>> test ToolReloadTest.testReloadSnippets(): success >>>> >>>> =============================================== >>>> jdk/jshell/ToolReloadTest.java >>>> Total tests run: 8, Failures: 1, Skips: 0 >>>> =============================================== >>>> >>>> ----------System.err:(11/574)---------- >>>> java.lang.Exception: failures: 1 >>>> at >>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:223) >>>> >>>> >>>> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> >>>> >>>> at java.lang.reflect.Method.invoke(Method.java:520) >>>> at >>>> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) >>>> >>>> >>>> at java.lang.Thread.run(Thread.java:804) >>>> >>>> >>> > From kumar.x.srinivasan at oracle.com Wed Jan 13 15:12:34 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 13 Jan 2016 07:12:34 -0800 Subject: Persistent test failure on Windows In-Reply-To: <5696590B.9040701@oracle.com> References: <1365862600.335.1452628022741.JavaMail.hudson@sthinfra15> <56957636.5040107@oracle.com> <5695831C.2070505@oracle.com> <569584C3.7090909@oracle.com> <5695A3B7.1090004@oracle.com> <5696590B.9040701@oracle.com> Message-ID: <56966962.4070809@oracle.com> I don't think this is fixed, continues to fail. Kumar > On 13.1.2016 02:09, Robert Field wrote: >> It might also be that the channel shutdown at the wrong time. Which > > Yes, that could be also an issue. > >> also might be addressed by the patch you mention. >> >> I reviewed and liked that patch, but at that time I was not an official >> reviewer. Now I am, and so I bless that patch. > > Thanks! > >> >> Will you be able to test the patch's impact on this Windows issue? > > I did, and it seems to fix the ToolReloadTest problem. I've pushed the > patch. > > Thanks, > Jan > >> >> Thanks, >> Robert >> >> On 01/12/16 14:57, Jan Lahoda wrote: >>> I suspect this may be a problem with line endings. I'll check >>> tomorrow. There is a patch that strives to resolve (at least some of) >>> the line endings problems here: >>> http://mail.openjdk.java.net/pipermail/kulla-dev/2015-December/001163.html >>> >>> >>> >>> Further comments on that would be welcome. >>> >>> Thanks, >>> Jan >>> >>> On 12.1.2016 23:50, Robert Field wrote: >>>> Thanks Jon, >>>> >>>> I don't have a Windows machine to test on. >>>> >>>> The test that it is failing on is evaluating "System.exit(1)" which >>>> crashes the remote machine. Does anyone have a Windows machine who can >>>> test behavior? >>>> >>>> Jon, should I just disable this test for now? >>>> >>>> Thanks, >>>> Robert >>>> >>>> >>>> On 01/12/16 13:55, Jonathan Gibbons wrote: >>>>> >>>>> The test jdk/jshell/ToolReloadTest is persistently failing on >>>>> Windows, according to one of our build and test systems. >>>>> Could someone from the kulla team please investigate and fix. >>>>> >>>>> The relevant part of the .jtr file is as follows: >>>>> >>>>> [TestNG] Running: >>>>> jdk/jshell/ToolReloadTest.java >>>>> >>>>> test ToolReloadTest.testReloadClasspath(): success >>>>> test ToolReloadTest.testReloadCrashRestore(): failure >>>>> java.lang.AssertionError: Kind: command. >>>>> expected [| State engine terminated. >>>>> | Restore definitions with: /reload restore >>>>> ] but found [] >>>>> at org.testng.Assert.fail(Assert.java:94) >>>>> at org.testng.Assert.failNotEquals(Assert.java:494) >>>>> at org.testng.Assert.assertEquals(Assert.java:123) >>>>> at org.testng.Assert.assertEquals(Assert.java:176) >>>>> at ReplToolTesting.assertOutput(ReplToolTesting.java:460) >>>>> at ReplToolTesting.assertCommand(ReplToolTesting.java:418) >>>>> at ReplToolTesting.assertCommand(ReplToolTesting.java:397) >>>>> at >>>>> ToolReloadTest.lambda$testReloadCrashRestore$52(ToolReloadTest.java:167) >>>>> >>>>> >>>>> at >>>>> ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:704) >>>>> >>>>> >>>>> >>>>> at >>>>> ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:720) >>>>> >>>>> >>>>> >>>>> at java.io.PrintStream.write(PrintStream.java:480) >>>>> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233) >>>>> at >>>>> sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312) >>>>> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:316) >>>>> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153) >>>>> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:252) >>>>> at >>>>> jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2336) >>>>> >>>>> >>>>> >>>>> at >>>>> jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277) >>>>> >>>>> >>>>> >>>>> at >>>>> jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:153) >>>>> >>>>> >>>>> >>>>> at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:472) >>>>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:287) >>>>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:260) >>>>> at ReplToolTesting.testRaw(ReplToolTesting.java:240) >>>>> at ReplToolTesting.test(ReplToolTesting.java:203) >>>>> at ReplToolTesting.test(ReplToolTesting.java:191) >>>>> at ReplToolTesting.test(ReplToolTesting.java:187) >>>>> at ReplToolTesting.test(ReplToolTesting.java:183) >>>>> at ToolReloadTest.testReloadCrashRestore(ToolReloadTest.java:162) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at >>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>> >>>>> >>>>> >>>>> at >>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> >>>>> >>>>> >>>>> at java.lang.reflect.Method.invoke(Method.java:520) >>>>> at >>>>> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) >>>>> >>>>> >>>>> >>>>> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) >>>>> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) >>>>> at >>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) >>>>> at >>>>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) >>>>> >>>>> >>>>> >>>>> at >>>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) >>>>> at org.testng.TestRunner.privateRun(TestRunner.java:767) >>>>> at org.testng.TestRunner.run(TestRunner.java:617) >>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) >>>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) >>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) >>>>> at org.testng.SuiteRunner.run(SuiteRunner.java:240) >>>>> at >>>>> org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >>>>> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >>>>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) >>>>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) >>>>> at org.testng.TestNG.run(TestNG.java:1057) >>>>> at >>>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) >>>>> >>>>> >>>>> >>>>> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >>>>> at >>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> >>>>> >>>>> >>>>> at java.lang.reflect.Method.invoke(Method.java:520) >>>>> at >>>>> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) >>>>> >>>>> >>>>> >>>>> at java.lang.Thread.run(Thread.java:804) >>>>> test ToolReloadTest.testReloadDrop(): success >>>>> test ToolReloadTest.testReloadExitRestore(): success >>>>> test ToolReloadTest.testReloadIgnore(): success >>>>> test ToolReloadTest.testReloadRepeat(): success >>>>> test ToolReloadTest.testReloadResetRestore(): success >>>>> test ToolReloadTest.testReloadSnippets(): success >>>>> >>>>> =============================================== >>>>> jdk/jshell/ToolReloadTest.java >>>>> Total tests run: 8, Failures: 1, Skips: 0 >>>>> =============================================== >>>>> >>>>> ----------System.err:(11/574)---------- >>>>> java.lang.Exception: failures: 1 >>>>> at >>>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:223) >>>>> >>>>> >>>>> >>>>> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >>>>> at >>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> >>>>> >>>>> >>>>> at java.lang.reflect.Method.invoke(Method.java:520) >>>>> at >>>>> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) >>>>> >>>>> >>>>> >>>>> at java.lang.Thread.run(Thread.java:804) >>>>> >>>>> >>>> >> From jonathan.gibbons at oracle.com Wed Jan 13 17:21:38 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 13 Jan 2016 09:21:38 -0800 Subject: Persistent test failure on Windows In-Reply-To: <56966962.4070809@oracle.com> References: <1365862600.335.1452628022741.JavaMail.hudson@sthinfra15> <56957636.5040107@oracle.com> <5695831C.2070505@oracle.com> <569584C3.7090909@oracle.com> <5695A3B7.1090004@oracle.com> <5696590B.9040701@oracle.com> <56966962.4070809@oracle.com> Message-ID: <569687A2.4000307@oracle.com> Seems to be OK on our internal server at 7:25 a.m. -- Jon On 01/13/2016 07:12 AM, Kumar Srinivasan wrote: > > I don't think this is fixed, continues to fail. > > Kumar > >> On 13.1.2016 02:09, Robert Field wrote: >>> It might also be that the channel shutdown at the wrong time. Which >> >> Yes, that could be also an issue. >> >>> also might be addressed by the patch you mention. >>> >>> I reviewed and liked that patch, but at that time I was not an official >>> reviewer. Now I am, and so I bless that patch. >> >> Thanks! >> >>> >>> Will you be able to test the patch's impact on this Windows issue? >> >> I did, and it seems to fix the ToolReloadTest problem. I've pushed >> the patch. >> >> Thanks, >> Jan >> >>> >>> Thanks, >>> Robert >>> >>> On 01/12/16 14:57, Jan Lahoda wrote: >>>> I suspect this may be a problem with line endings. I'll check >>>> tomorrow. There is a patch that strives to resolve (at least some of) >>>> the line endings problems here: >>>> http://mail.openjdk.java.net/pipermail/kulla-dev/2015-December/001163.html >>>> >>>> >>>> >>>> Further comments on that would be welcome. >>>> >>>> Thanks, >>>> Jan >>>> >>>> On 12.1.2016 23:50, Robert Field wrote: >>>>> Thanks Jon, >>>>> >>>>> I don't have a Windows machine to test on. >>>>> >>>>> The test that it is failing on is evaluating "System.exit(1)" which >>>>> crashes the remote machine. Does anyone have a Windows machine who >>>>> can >>>>> test behavior? >>>>> >>>>> Jon, should I just disable this test for now? >>>>> >>>>> Thanks, >>>>> Robert >>>>> >>>>> >>>>> On 01/12/16 13:55, Jonathan Gibbons wrote: >>>>>> >>>>>> The test jdk/jshell/ToolReloadTest is persistently failing on >>>>>> Windows, according to one of our build and test systems. >>>>>> Could someone from the kulla team please investigate and fix. >>>>>> >>>>>> The relevant part of the .jtr file is as follows: >>>>>> >>>>>> [TestNG] Running: >>>>>> jdk/jshell/ToolReloadTest.java >>>>>> >>>>>> test ToolReloadTest.testReloadClasspath(): success >>>>>> test ToolReloadTest.testReloadCrashRestore(): failure >>>>>> java.lang.AssertionError: Kind: command. >>>>>> expected [| State engine terminated. >>>>>> | Restore definitions with: /reload restore >>>>>> ] but found [] >>>>>> at org.testng.Assert.fail(Assert.java:94) >>>>>> at org.testng.Assert.failNotEquals(Assert.java:494) >>>>>> at org.testng.Assert.assertEquals(Assert.java:123) >>>>>> at org.testng.Assert.assertEquals(Assert.java:176) >>>>>> at ReplToolTesting.assertOutput(ReplToolTesting.java:460) >>>>>> at ReplToolTesting.assertCommand(ReplToolTesting.java:418) >>>>>> at ReplToolTesting.assertCommand(ReplToolTesting.java:397) >>>>>> at >>>>>> ToolReloadTest.lambda$testReloadCrashRestore$52(ToolReloadTest.java:167) >>>>>> >>>>>> >>>>>> at >>>>>> ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:704) >>>>>> >>>>>> >>>>>> >>>>>> at >>>>>> ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:720) >>>>>> >>>>>> >>>>>> >>>>>> at java.io.PrintStream.write(PrintStream.java:480) >>>>>> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233) >>>>>> at >>>>>> sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312) >>>>>> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:316) >>>>>> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153) >>>>>> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:252) >>>>>> at >>>>>> jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2336) >>>>>> >>>>>> >>>>>> >>>>>> at >>>>>> jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277) >>>>>> >>>>>> >>>>>> >>>>>> at >>>>>> jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:153) >>>>>> >>>>>> >>>>>> >>>>>> at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:472) >>>>>> at >>>>>> jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:287) >>>>>> at >>>>>> jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:260) >>>>>> at ReplToolTesting.testRaw(ReplToolTesting.java:240) >>>>>> at ReplToolTesting.test(ReplToolTesting.java:203) >>>>>> at ReplToolTesting.test(ReplToolTesting.java:191) >>>>>> at ReplToolTesting.test(ReplToolTesting.java:187) >>>>>> at ReplToolTesting.test(ReplToolTesting.java:183) >>>>>> at >>>>>> ToolReloadTest.testReloadCrashRestore(ToolReloadTest.java:162) >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> at >>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>> >>>>>> >>>>>> >>>>>> at >>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> >>>>>> >>>>>> >>>>>> at java.lang.reflect.Method.invoke(Method.java:520) >>>>>> at >>>>>> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) >>>>>> >>>>>> >>>>>> >>>>>> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) >>>>>> at >>>>>> org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) >>>>>> at >>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) >>>>>> at >>>>>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) >>>>>> >>>>>> >>>>>> >>>>>> at >>>>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) >>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:767) >>>>>> at org.testng.TestRunner.run(TestRunner.java:617) >>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) >>>>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) >>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) >>>>>> at org.testng.SuiteRunner.run(SuiteRunner.java:240) >>>>>> at >>>>>> org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >>>>>> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >>>>>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) >>>>>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) >>>>>> at org.testng.TestNG.run(TestNG.java:1057) >>>>>> at >>>>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) >>>>>> >>>>>> >>>>>> >>>>>> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >>>>>> at >>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> >>>>>> >>>>>> >>>>>> at java.lang.reflect.Method.invoke(Method.java:520) >>>>>> at >>>>>> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) >>>>>> >>>>>> >>>>>> >>>>>> at java.lang.Thread.run(Thread.java:804) >>>>>> test ToolReloadTest.testReloadDrop(): success >>>>>> test ToolReloadTest.testReloadExitRestore(): success >>>>>> test ToolReloadTest.testReloadIgnore(): success >>>>>> test ToolReloadTest.testReloadRepeat(): success >>>>>> test ToolReloadTest.testReloadResetRestore(): success >>>>>> test ToolReloadTest.testReloadSnippets(): success >>>>>> >>>>>> =============================================== >>>>>> jdk/jshell/ToolReloadTest.java >>>>>> Total tests run: 8, Failures: 1, Skips: 0 >>>>>> =============================================== >>>>>> >>>>>> ----------System.err:(11/574)---------- >>>>>> java.lang.Exception: failures: 1 >>>>>> at >>>>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:223) >>>>>> >>>>>> >>>>>> >>>>>> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) >>>>>> at >>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> >>>>>> >>>>>> >>>>>> at java.lang.reflect.Method.invoke(Method.java:520) >>>>>> at >>>>>> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:226) >>>>>> >>>>>> >>>>>> >>>>>> at java.lang.Thread.run(Thread.java:804) >>>>>> >>>>>> >>>>> >>> > From jan.lahoda at oracle.com Fri Jan 22 11:40:09 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 22 Jan 2016 12:40:09 +0100 Subject: RFR 8131027: JShell API/tool: suggest imports for a class Message-ID: <56A21519.5050109@oracle.com> Hello, I'd like to ask for a review of a patch that adds two new features: a) add import: when there is an unresolvable identifier, press " i" (*), and a list of known FQNs should be printed, with an ability to easily import any of them. b) create variable: when there is an expression, press " v", and a variable stub will be created, with the expression as the initializer. The "" is either Alt-Enter or Alt-F1, depending on the platform. For Windows, The patch is here: http://cr.openjdk.java.net/~jlahoda/8131027/webrev.00/ For Windows, an additional patch to jdk.internal.le is needed (I'll send a separate review to core-libs for that): http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ Any comments are welcome! Thanks, Jan From jan.lahoda at oracle.com Fri Jan 22 11:41:44 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 22 Jan 2016 12:41:44 +0100 Subject: RFR 8147984: WindowsTerminal should support function keys Message-ID: <56A21578.5080105@oracle.com> Hello, I'd like to enhance the WindowsTerminal in jdk.internal.le with function keys handling. The intent is so that jshell can bind actions for shortcuts including function keys. The patch for adding the function keys support is here: http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ An example of a feature that uses/may use this support is here: http://mail.openjdk.java.net/pipermail/kulla-dev/2016-January/001226.html Any comments are welcome! Thanks, Jan From robert.field at oracle.com Mon Jan 25 03:36:25 2016 From: robert.field at oracle.com (Robert Field) Date: Sun, 24 Jan 2016 19:36:25 -0800 Subject: jshell tool: what should the interactive output look like? In-Reply-To: <56A574A2.3010207@oracle.com> References: <56A574A2.3010207@oracle.com> Message-ID: <56A59839.6090207@oracle.com> Below I list interesting snippet and command input, with the current default ('d:') and concise ('c:') feedback, Brian's proposal ('b:) and some other (numbered) alternatives COMPLEX EXPRESSION -> Math.sqrt(Math.PI) d: | Expression value is: 1.7724538509055159 | assigned to temporary variable $3 of type double c: | $3 : 1.7724538509055159 b: => 1.7724538509055159 (assigned to temporary $3 of type double) 0: | double $3 : 1.7724538509055159 | Added temporary variable $3 1: | double $3 : 1.7724538509055159 -> Arrays.asList("Hello", "World!", "How", "Are", "You").stream() // another example d: | Expression value is: java.util.stream.ReferencePipeline$Head at 5f5a92bb | assigned to temporary variable $11of type Stream c: | $11 : java.util.stream.ReferencePipeline$Head at 51016012 b: => java.util.stream.ReferencePipeline$Head at 51016012 (assigned to temporary $11 of type Stream) 0: |Stream$11 : java.util.stream.ReferencePipeline$Head at 51016012 | Added temporary variable $11 1: |Stream$11 : java.util.stream.ReferencePipeline$Head at 51016012 VAR CREATE (initial value) -> double x = Math.sqrt(Math.PI) d: | Added variable x of type double with initial value 1.7724538509055159 c: | x : 1.7724538509055159 b: (declared variable x of type double) 0: | doublex : 1.7724538509055159 | Added variable x 1: | doublex : 1.7724538509055159 4: => 1.7724538509055159 (declared variable x of type double) VAR CREATE (no initial value) -> double x d: | Added variable x of type double c: | (NO OUTPUT) b: (declared variable x of type double) 0:| Added variable x 1: | doublex : 0.0 ASSIGNMENT -> k = Math.getExponent(Math.random()) d: | Variable k has been assigned the value -2 c: | k : -2 b: (NO OUTPUT) 1: | int k : -2 4: => -2 VAR QUERY -> x d: | Variable x of type double has value 1.7724538509055159 c: | x : 1.7724538509055159 b: => 1.7724538509055159 1: | doublex : 1.7724538509055159 METHOD DECL (class, interface, enum, too similarto show) -> void m() { } d: | Added method m() c: (NO OUTPUT) b: (defined method m()) DROP -> /drop m d: (NO OUTPUT) c: (NO OUTPUT) b: (dropped method m()) 1: | Dropped method m() MISC COMMANDS Currently display in default but not concise. | Editor set to: %s | Path %s added to classpath | Feedback mode: %s | Prompt will (not) display. ----- My vote for new default is '1' (where it is shown, and current default otherwise). This is mostly like concise feedback but adding the type which is often important information. A variation would be to use '=' instead of colon, but since then it would be valid code (and in simple cases will be the same as the input) I think that would be confusing. I think it is important to set the feedback off from the user's output. Brian proposes parenthesis, which make it clear they are parenthetical and presumably not shown in concise feedback, but parenthesis are likely to occur in the user output and is very likely to occur in the feedback. The pipe symbol is currently used (to quote-off) the feedback -- I think it works well -- is visually clean. I like the clean division of what goes away in a concise mode. Option (0) shows one choice for this (which also is more symmetric with methods, classes,...). Expressions are probably the most important snippets to have crisp output, and unfortunately, this adds pure noise in this case as soon as the user understands that expressions create temporaries which are named with a dollar sign. "Added" vs "defined": I like "defined" better, but "Added" is used to differentiate it from "Modified" and "Replaced". We could use "Defined", "Modified definition", and "Replaced definition". I'd like to hear everyone's opinion. Including what options I did not list. Thanks, Robert From brian.goetz at oracle.com Mon Jan 25 14:57:53 2016 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 25 Jan 2016 09:57:53 -0500 Subject: jshell tool: what should the interactive output look like? In-Reply-To: <56A59839.6090207@oracle.com> References: <56A574A2.3010207@oracle.com> <56A59839.6090207@oracle.com> Message-ID: <56A637F1.3070306@oracle.com> Here are some (subjective) goals for the UX: - Output should not be too verbose (current default is too verbose). - Result of evaluating an expression should be placed front-and-center; this is the essence of REPL. - Results from the user program and results from the REPL application should be distinguishable. So, for example: 0: |Stream$11 : java.util.stream.ReferencePipeline$Head at 51016012 | Added temporary variable $11 seems to violate at least one of these goals -- the result of my evaluation and the diagnostic about side-effects on the REPL state are both expressed with the same formatting metaphor. (I also think that the variable and type information is "in the way" of the more important information -- the result.) I propose we start with a data model, based on the taxonomy from my 6/26/2015 message; define an intermediate data model that describes all the possible kinds of output, and then define formatting rules from that. Reproduced below: > 1. Expression results. (If the input was an expression, we probably always want to print this; if its not an expression, there's nothing to print.) > > 2. Text sent to System.{out,err}. > > 3. Diagnostics either from compiling the input or from executing a REPL command. > > 4. Runtime exceptions produced during execution. > > 5. Side-effects on the REPL state (vars/methods/classes declared/invalidated/dropped/changed state.) > > For (5), there are sub-categories: > a) a new temporary variable was created > b) a new variable was created (var declaration) > c) a new method/class was created > d) a variable/class/method was invalidated > e) a variable changed its value (assignment to existing var) On 1/24/2016 10:36 PM, Robert Field wrote: > Below I list interesting snippet and command input, with the current > default ('d:') and concise ('c:') feedback, Brian's proposal ('b:) and > some other (numbered) alternatives > > COMPLEX EXPRESSION > > -> Math.sqrt(Math.PI) > > d: | Expression value is: 1.7724538509055159 > | assigned to temporary variable $3 of type double > > c: | $3 : 1.7724538509055159 > > b: => 1.7724538509055159 > (assigned to temporary $3 of type double) > > 0: | double $3 : 1.7724538509055159 > | Added temporary variable $3 > > 1: | double $3 : 1.7724538509055159 > > > -> Arrays.asList("Hello", "World!", "How", "Are", "You").stream() // > another example > > d: | Expression value is: java.util.stream.ReferencePipeline$Head at 5f5a92bb > | assigned to temporary variable $11of type Stream > > c: | $11 : java.util.stream.ReferencePipeline$Head at 51016012 > > b: => java.util.stream.ReferencePipeline$Head at 51016012 > (assigned to temporary $11 of type Stream) > > 0: |Stream$11 : java.util.stream.ReferencePipeline$Head at 51016012 > | Added temporary variable $11 > > 1: |Stream$11 : java.util.stream.ReferencePipeline$Head at 51016012 > > > VAR CREATE (initial value) > > -> double x = Math.sqrt(Math.PI) > > d: | Added variable x of type double with initial value 1.7724538509055159 > > c: | x : 1.7724538509055159 > > b: (declared variable x of type double) > > 0: | doublex : 1.7724538509055159 > | Added variable x > > 1: | doublex : 1.7724538509055159 > > 4: => 1.7724538509055159 > (declared variable x of type double) > > > VAR CREATE (no initial value) > > -> double x > > d: | Added variable x of type double > > c: | (NO OUTPUT) > > b: (declared variable x of type double) > > 0:| Added variable x > > 1: | doublex : 0.0 > > > > ASSIGNMENT > > -> k = Math.getExponent(Math.random()) > > d: | Variable k has been assigned the value -2 > > c: | k : -2 > > b: (NO OUTPUT) > > 1: | int k : -2 > > 4: => -2 > > > VAR QUERY > > -> x > > d: | Variable x of type double has value 1.7724538509055159 > > c: | x : 1.7724538509055159 > > b: => 1.7724538509055159 > > 1: | doublex : 1.7724538509055159 > > > METHOD DECL (class, interface, enum, too similarto show) > > -> void m() { } > > d: | Added method m() > > c: (NO OUTPUT) > > b: (defined method m()) > > > DROP > > -> /drop m > > d: (NO OUTPUT) > > c: (NO OUTPUT) > > b: (dropped method m()) > > 1: | Dropped method m() > > > MISC COMMANDS > > Currently display in default but not concise. > > | Editor set to: %s > | Path %s added to classpath > | Feedback mode: %s > | Prompt will (not) display. > > ----- > > My vote for new default is '1' (where it is shown, and current default > otherwise). This is mostly like concise feedback but adding the type > which is often important information. A variation would be to use '=' > instead of colon, but since then it would be valid code (and in simple > cases will be the same as the input) I think that would be confusing. > > I think it is important to set the feedback off from the user's output. > Brian proposes parenthesis, which make it clear they are parenthetical > and presumably not shown in concise feedback, but parenthesis are likely > to occur in the user output and is very likely to occur in the feedback. > The pipe symbol is currently used (to quote-off) the feedback -- I think > it works well -- is visually clean. > > I like the clean division of what goes away in a concise mode. Option > (0) shows one choice for this (which also is more symmetric with > methods, classes,...). Expressions are probably the most important > snippets to have crisp output, and unfortunately, this adds pure noise > in this case as soon as the user understands that expressions create > temporaries which are named with a dollar sign. > > "Added" vs "defined": I like "defined" better, but "Added" is used to > differentiate it from "Modified" and "Replaced". We could use > "Defined", "Modified definition", and "Replaced definition". > > I'd like to hear everyone's opinion. Including what options I did not > list. > > > Thanks, > Robert > From daniel.smith at oracle.com Mon Jan 25 17:20:20 2016 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 25 Jan 2016 10:20:20 -0700 Subject: jshell tool: what should the interactive output look like? In-Reply-To: <56A59839.6090207@oracle.com> References: <56A574A2.3010207@oracle.com> <56A59839.6090207@oracle.com> Message-ID: I like 1, among those listed here. I'm sympathetic to Brian's concern that the metadata not drown out the main focus: the resulting value. Reordering the output might work? I'll try something below. I also think that the subtle difference between adding, updating, etc. a declaration does not require making a big deal about it. For users who care about this, they can learn to look for subtle cues, and maybe a variation in the symbols used would suffice. See below for this, too. One thing to worry about: what happens when types or 'toString' output become unwieldy? That potentially kills the nice compact representation. Is any attempt made to abbreviate, get rid of newlines, etc? (I run into this problem quite a bit when debugging javac, because 'toString' on AST nodes often produces multi-line output.) > On Jan 24, 2016, at 8:36 PM, Robert Field wrote: > > Below I list interesting snippet and command input, with the current default ('d:') and concise ('c:') feedback, Brian's proposal ('b:) and some other (numbered) alternatives > > COMPLEX EXPRESSION > > -> Math.sqrt(Math.PI) | 1.7724538509055159 => double $3 > -> Arrays.asList("Hello", "World!", "How", "Are", "You").stream() // another example | java.util.stream.ReferencePipeline$Head at 51016012 => |Stream $11 > VAR CREATE (initial value) | 1.7724538509055159 => double x > VAR CREATE (no initial value) > > -> double x | 0.0 => double x > ASSIGNMENT > > -> k = Math.getExponent(Math.random()) | -2 ~> int k (Assignment is weird, because it's officially an expression that happens to have a side-effect, but everybody treats it as a statement. I guess 'k +=' and '++k' would also be reported as an update, while 'k++' and nested assignments would be treated like complex expressions?) > VAR QUERY > > -> x > > d: | Variable x of type double has value 1.7724538509055159 > > c: | x : 1.7724538509055159 > > b: => 1.7724538509055159 > > 1: | doublex : 1.7724538509055159 | 1.7724538509055159 <= double x (A little weird that I can query vars but not methods and classes. If there were a unified way to query all of them, there might be an accompanying unified output that looks more like a declaration.) > METHOD DECL (class, interface, enum, too similarto show) > > -> void m() { } | => void m() (Or, for redeclaration, '~> void m()') > > DROP > > -> /drop m | Dropped method m() (This is fine -- when the input is a command, I think it's reasonable to have separate conventions from when the input is Java code.) ?Dan From daniel.smith at oracle.com Mon Jan 25 18:01:54 2016 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 25 Jan 2016 11:01:54 -0700 Subject: jshell tool: what should the interactive output look like? In-Reply-To: References: <56A574A2.3010207@oracle.com> <56A59839.6090207@oracle.com> Message-ID: > On Jan 25, 2016, at 10:20 AM, Dan Smith wrote: > >> COMPLEX EXPRESSION >> >> -> Math.sqrt(Math.PI) > > | 1.7724538509055159 => double $3 One other note about complex expressions (not strictly about formatting but about UX anyway): would it be possible to give these automatically-generated variables more Java-like names? I think that would help a lot to make this feel less like a strange new language. ('$exp3' rather than '$3', for example.) ?Dan From jan.lahoda at oracle.com Mon Jan 25 19:12:16 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 25 Jan 2016 20:12:16 +0100 Subject: RFR (XS): 8147949: NetBeans cannot open langtools repository because of the reserved work "aux" Message-ID: <56A67390.6030106@oracle.com> Hello, As reported in the bug: https://bugs.openjdk.java.net/browse/JDK-8147949 The NetBeans' project for langtools contains references to directory named "aux", which is causing problems on Windows. On a closer look, the "aux" references shouldn't be needed, so I propose to remove them altogether. Webrev: http://cr.openjdk.java.net/~jlahoda/8147949/webrev.00/index.html Thanks, Jan From jonathan.gibbons at oracle.com Mon Jan 25 21:30:01 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 25 Jan 2016 13:30:01 -0800 Subject: jshell tool: what should the interactive output look like? In-Reply-To: References: <56A574A2.3010207@oracle.com> <56A59839.6090207@oracle.com> Message-ID: <56A693D9.10802@oracle.com> On 01/25/2016 09:20 AM, Dan Smith wrote: > (I run into this problem quite a bit when debugging javac, because 'toString' on AST nodes often produces multi-line output.) tree.toString().replaceAll("\\s+", " ") From robert.field at oracle.com Mon Jan 25 21:43:23 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 25 Jan 2016 13:43:23 -0800 Subject: jshell tool: what should the interactive output look like? toString... In-Reply-To: <56A693D9.10802@oracle.com> References: <56A574A2.3010207@oracle.com> <56A59839.6090207@oracle.com> <56A693D9.10802@oracle.com> Message-ID: <56A696FB.3090702@oracle.com> On 01/25/16 13:30, Jonathan Gibbons wrote: > > > On 01/25/2016 09:20 AM, Dan Smith wrote: >> (I run into this problem quite a bit when debugging javac, because >> 'toString' on AST nodes often produces multi-line output.) > > tree.toString().replaceAll("\\s+", " ") In this usage, it could be quite confusing for for newlines to appear, so we would want either to get rid of them (this suggestion) or at least preface them. From john.r.rose at oracle.com Tue Jan 26 01:43:44 2016 From: john.r.rose at oracle.com (John Rose) Date: Mon, 25 Jan 2016 17:43:44 -0800 Subject: jshell tool: what should the interactive output look like? In-Reply-To: References: <56A574A2.3010207@oracle.com> <56A59839.6090207@oracle.com> Message-ID: On Jan 25, 2016, at 10:01 AM, Dan Smith wrote: > > '$exp3' rather than '$3', for example ?Or '$int3' or '$i3', some sort of type-based name generation like decompilers use. From paul.sandoz at oracle.com Tue Jan 26 11:39:11 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 26 Jan 2016 12:39:11 +0100 Subject: jshell tool: what should the interactive output look like? In-Reply-To: References: <56A574A2.3010207@oracle.com> <56A59839.6090207@oracle.com> Message-ID: <841D6E5A-BA44-4A25-824A-714B71E12635@oracle.com> > On 26 Jan 2016, at 02:43, John Rose wrote: > > On Jan 25, 2016, at 10:01 AM, Dan Smith wrote: >> >> '$exp3' rather than '$3', for example > > ?Or '$int3' or '$i3', some sort of type-based name generation like decompilers use. > From a user perspective i don?t care if the temporary variable produced is a result of a complex or simple expression, nor really about it?s type so much it should be expressed in the name. i just wanna use it, thus consistency trumps the kinds of expression and what they return. That?s my experience from using REPLs. I would prefer to see something like: -> Math.sqrt(Math.PI) | double $3 = 1.7724538509055159 -> Arrays.asList("Hello", "World!", "How", "Are", "You").stream() | Stream $11 = java.util.stream.ReferencePipeline$Head at 5f5a92bb The ?$? implies a temporary variable, is it really necessary to call this out? Paul. From roy.van.rijn at gmail.com Tue Jan 26 14:28:14 2016 From: roy.van.rijn at gmail.com (Roy van Rijn) Date: Tue, 26 Jan 2016 15:28:14 +0100 Subject: JShell API questions / feedback Message-ID: Dear kulla-dev's, I've been working on a project to incorporate the JShell API into an environment to help teach the Java language to absolute beginners (mainly kids). For this I'm using the JShell API and making my own editor. The eval() results have to be parsed and evaluated by my code. But I've ran into a few issues (or maybe just questions). First, I need to process the Snippet output. One thing I've noticed is that the Snippet API is rather limited. Image you create a method and receive a MethodSnippet. Now I want to know the return type of this method for further processing, how do I get to this? The only thing I've currently found is: MethodSnippet snippet = ...; String returnType = snippet.signature().substring(snippet.signature().lastIndexOf(')') + 1); Do I have to parse the signature myself to get to the return type? This seems rather odd. Also, in the API there seems to be a lot of String-usage. Instead of returning the actual type everything is a String. I think I'd rather love to see the API returning classes and objects. For example the 'value' of something that has been evaluated now is always a String (the toString() of the object is called) instead of the actual object. I'd rather have the API returning the object and the JShell terminal calling toString() on it for display purposes. Would this be possible? IMHO that would be a much better API. The same si true for the mentioned returnType, I'd love to have it return a class instead of a string. Also, one other thing I've noticed is that the method names used in the API are not following the bean-spec, for example to get fields from a snippet you have to call snippet.name() and snippet.typeName(). This seems very odd compared to most Java JDK code. I would have suspected snippet.getName() and snippet.getTypeName(). Is this a new preferred way of writing methods in a JDK API? Will we see this in other API's as well? Call me old-fashioned but I personally rather just have the getters. I'd love to hear what other people think about the current API design, am I the only one bothered by this? Or am I using it the wrong way, or missing the point? Roy From john.r.rose at oracle.com Tue Jan 26 01:43:44 2016 From: john.r.rose at oracle.com (John Rose) Date: Mon, 25 Jan 2016 17:43:44 -0800 Subject: jshell tool: what should the interactive output look like? In-Reply-To: References: <56A574A2.3010207@oracle.com> <56A59839.6090207@oracle.com> Message-ID: On Jan 25, 2016, at 10:01 AM, Dan Smith wrote: > > '$exp3' rather than '$3', for example ?Or '$int3' or '$i3', some sort of type-based name generation like decompilers use. From robert.field at oracle.com Thu Jan 28 21:30:44 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 28 Jan 2016 13:30:44 -0800 Subject: JShell API questions / feedback In-Reply-To: References: Message-ID: <56AA8884.6030700@oracle.com> On 01/26/16 06:28, Roy van Rijn wrote: > Dear kulla-dev's, > > I've been working on a project to incorporate the JShell API into an > environment to help teach the Java language to absolute beginners > (mainly kids). Cool! > > For this I'm using the JShell API and making my own editor. The eval() > results have to be parsed and evaluated by my code. But I've ran into > a few issues (or maybe just questions). > > First, I need to process the Snippet output. One thing I've noticed is > that the Snippet API is rather limited. Image you create a method and > receive a MethodSnippet. Now I want to know the return type of this > method for further processing, how do I get to this? The only thing > I've currently found is: > > MethodSnippet snippet = ...; > String returnType = > snippet.signature().substring(snippet.signature().lastIndexOf(')') + > 1); That looks about right. > > Do I have to parse the signature myself to get to the return type? > This seems rather odd. What do you use the return type for? > Also, in the API there seems to be a lot of > String-usage. Instead of returning the actual type everything is a > String. I think I'd rather love to see the API returning classes and > objects. For example the 'value' of something that has been evaluated > now is always a String (the toString() of the object is called) > instead of the actual object. I'd rather have the API returning the > object and the JShell terminal calling toString() on it for display > purposes. Would this be possible? IMHO that would be a much better > API. The same si true for the mentioned returnType, I'd love to have > it return a class instead of a string. Understood. It would be richer to have Object. The process executing the snippets is remote, so there is no way to return through the API that nice FooBar object that was just created on the remote side. The only thing I could imagine is to return some proxy object that you could query, but that would be awkward when the main focus is textual input and output. > > Also, one other thing I've noticed is that the method names used in > the API are not following the bean-spec, for example to get fields > from a snippet you have to call snippet.name() and snippet.typeName(). > This seems very odd compared to most Java JDK code. I would have > suspected snippet.getName() and snippet.getTypeName(). Is this a new > preferred way of writing methods in a JDK API? Will we see this in > other API's as well? Call me old-fashioned but I personally rather > just have the getters. There are and have been, for a very long time, two schools of thought in JDK world about "get" prefixes, in one you use a "get" prefix on all accessors, in the other, I think the predominant, you prefix with "get" only when there is a corresponding "set", see, for example Map: https://docs.oracle.com/javase/8/docs/api/java/util/Map.html The queries are entrySet(), keySet(), size(), and values(), not getEntrySey(), getKeySet(), getSize(), and getValues(). Or to go deeper into core, length() on String, and hashCode() on Object. > > I'd love to hear what other people think about the current API design, > am I the only one bothered by this? Or am I using it the wrong way, or > missing the point? PLEASE do give feedback on the API! The best APIs have had plenty of feedback, while still maintaining consistency. Thanks, Robert > > Roy From maurizio.cimadamore at oracle.com Thu Jan 28 21:37:28 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2016 21:37:28 +0000 Subject: RFR (XS): 8147949: NetBeans cannot open langtools repository because of the reserved work "aux" In-Reply-To: <56A67390.6030106@oracle.com> References: <56A67390.6030106@oracle.com> Message-ID: <56AA8A18.2020207@oracle.com> Looks good Maurizio On 25/01/16 19:12, Jan Lahoda wrote: > Hello, > > As reported in the bug: > https://bugs.openjdk.java.net/browse/JDK-8147949 > > The NetBeans' project for langtools contains references to directory > named "aux", which is causing problems on Windows. On a closer look, > the "aux" references shouldn't be needed, so I propose to remove them > altogether. > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8147949/webrev.00/index.html > > Thanks, > Jan From robert.field at oracle.com Thu Jan 28 21:38:41 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 28 Jan 2016 13:38:41 -0800 Subject: RFR 8131027: JShell API/tool: suggest imports for a class In-Reply-To: <56A21519.5050109@oracle.com> References: <56A21519.5050109@oracle.com> Message-ID: <56AA8A61.1040404@oracle.com> This will be a big help -- thanks for coding this. Below is a pre-review. JShell: Fine. Eval: Looks good. SourceCodeAnalysis: This is public API, so names and comments really matter... analyzeType() -- There is a description of where the expression begins, but not of where it ends. getDeclaredSymbols() -- Please document what "possible" in "possible FQNs" means. IndexResult -- This class needs a name that is more descriptive of what it is, and the name should align with whatever name and comment are finally given to getDeclaredSymbols(). NameLookup? ResolvedName? ... The class comment should describe what this class is -- and it more than a list of FQNs, as it also deals with the simple name, up-to-dateness, resolvability. getFqns() -- As above, and probably here rather than there, -- what does possible mean? getSimpleNameLength() -- Says "unresolvable", but there is a test (below) for it being resolvable -- probably just remove that word. "right left to", were you meaning "right of"? "for which the candidates could be computed" if they can't be computed, how does that effect this method? Wouldn't return still return the length? Can that phrase just be removed? Is the a reason that the length (rather than the name) is returned? isUpToDate() -- I have no idea what this means. isResolvable() -- Resolvable in the context of what? Throughout class, I would avoid "FQN". See, for example, the use of "fully qualified name" in java/lang. I would spell it out in comments. The java/lang uses "name" as the base for identifiers, but this won't work for getFqns() since it needs to be differentiated from simple names. Perhaps getQualifiedNames(). Nit: Throughout the JShell code and throughout the JDK codebase the convention is that comments start on the line after the "/**" (not on the same line). SourceCodeAnalysisImpl: getDeclaredSymbols() -- My reading of the spec (above) is that the cursor is at the beginning of the identifier to match, this is at the end. Spec needs clarification or ... If there is an @author tag on this file, you should certainly be first. currentIndexes and two other fields are declared in the middle of the class. While old conventions forbade this: https://web.archive.org/web/20130627193836/http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html others don't when there is good reason. But I mention this because there are many forward references to all three of these -- so their implied locality is misleading. I would need some code context (comments) to be able to properly review. ConsoleIOContext: Need more context (code comments) for me to be able to review. TreeDissector: See TypePrinter. TypePrinter: My (unspoken) design for this was to be as stand-alone (untied to the JShell architecture) as possible -- esp. since it is subclassed off javac, which is why I had that stuff in higher levels. It could be moved up just one level (to TreeDissector) ComputeFQNsTest: Need tests with multiple answers. If the other fields of IndexResult are interesting enough to be present they should be tested. InferTypeTest: Looks pretty good. Maybe some other express forms: boolean operators, .... Thanks, Robert On 01/22/16 03:40, Jan Lahoda wrote: > Hello, > > I'd like to ask for a review of a patch that adds two new features: > a) add import: when there is an unresolvable identifier, press > " i" (*), and a list of known FQNs should be printed, > with an ability to easily import any of them. > > b) create variable: when there is an expression, press > " v", and a variable stub will be created, with the > expression as the initializer. > > The "" is either Alt-Enter or Alt-F1, depending on the > platform. For Windows, > > The patch is here: > http://cr.openjdk.java.net/~jlahoda/8131027/webrev.00/ > > For Windows, an additional patch to jdk.internal.le is needed (I'll > send a separate review to core-libs for that): > http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ > > Any comments are welcome! > > Thanks, > Jan From robert.field at oracle.com Thu Jan 28 21:41:32 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 28 Jan 2016 13:41:32 -0800 Subject: RFR 8146138 et. al.: jshell tool: add /help command plus misc fixes Message-ID: <56AA8B0C.9000603@oracle.com> Fixes: 8146138 jshell tool: add /help 8147495 jshell tool: correctly handle arguments on /seteditor command 8147886 jshell tool: commands don't allow reference to start-up or explicit id of dropped/failed snippets 8147887 jshell tool: /list start -- fails 8147898 jshell tool: /reload quiet -- should quiet echo Webrev: http://cr.openjdk.java.net/~rfield/8146138v0.patch/ Thanks, Robert From robert.field at oracle.com Fri Jan 29 04:23:27 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 28 Jan 2016 20:23:27 -0800 Subject: RFR 8148316: jshell tool: Configurable output format Message-ID: <56AAE93F.9070205@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8148316 Webrev: http://cr.openjdk.java.net/~rfield/8148316v1.webrev/ Some example output configurations (Open with /open): http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh http://cr.openjdk.java.net/~rfield/formats/dan.jsh http://cr.openjdk.java.net/~rfield/formats/brian.jsh -Robert From robert.field at oracle.com Fri Jan 29 07:52:36 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 28 Jan 2016 23:52:36 -0800 Subject: RFR (small) 8080357: JShell: Only unqualified unresolved references should be corralled Message-ID: Bugs: https://bugs.openjdk.java.net/browse/JDK-8080357 https://bugs.openjdk.java.net/browse/JDK-8081431 Webrev: http://cr.openjdk.java.net/~rfield/8080357v0.webrev/ Thanks, Robert From paul.sandoz at oracle.com Fri Jan 29 09:38:41 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 29 Jan 2016 10:38:41 +0100 Subject: JShell API questions / feedback In-Reply-To: <56AA8884.6030700@oracle.com> References: <56AA8884.6030700@oracle.com> Message-ID: <3BA828DE-C7A5-40D7-911A-DEF32BA97214@oracle.com> > On 28 Jan 2016, at 22:30, Robert Field wrote: >> >> I'd love to hear what other people think about the current API design, >> am I the only one bothered by this? Or am I using it the wrong way, or >> missing the point? > > PLEASE do give feedback on the API! The best APIs have had plenty of feedback, while still maintaining consistency. > +1 The use-case of teaching Java using the REPL is a very important one. Paul. From arend at arendvr.com Sun Jan 31 15:31:37 2016 From: arend at arendvr.com (Arend v. Reinersdorff) Date: Sun, 31 Jan 2016 16:31:37 +0100 Subject: Running Java batch files with JShell? Message-ID: Hi, I had hoped that JShell would support running .java files as batch scripts. Like jrunscript or jjs support running Javascript batch files. Unfortunately, in the current JDK 9 early access releases JShell doesn't support this. Any plans to add such a feature in a later version? Regards, Arend From brian.goetz at oracle.com Sun Jan 31 16:40:03 2016 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 31 Jan 2016 16:40:03 +0000 Subject: Running Java batch files with JShell? In-Reply-To: References: Message-ID: While this is certainly a desirable option, there are no plans for this functionality in the current round of jshell development. On Jan 31, 2016, at 3:31 PM, Arend v. Reinersdorff wrote: > Hi, > > I had hoped that JShell would support running .java files as batch scripts. > Like jrunscript or jjs support running Javascript batch files. > Unfortunately, in the current JDK 9 early access releases JShell doesn't > support this. > > Any plans to add such a feature in a later version? > > Regards, > Arend