From bitterfoxc at gmail.com Tue Dec 1 03:41:31 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Tue, 1 Dec 2015 12:41:31 +0900 Subject: RFR 8142447: Command change: re-run n-th command should be re-run by id In-Reply-To: <565D0FFC.9080903@oracle.com> References: <5656533D.3020601@oracle.com> <565D0FFC.9080903@oracle.com> Message-ID: Oops! I've forgot to omit it from my patch. Please don't care about it. Regards, shinyafox(Shinya Yoshida) 2015-12-01 12:11 GMT+09:00 Robert Field : > Thumbs up! > > I'll push this. > > I note you changed the locale on getMessage() to Locale.US since, I > presume, that is all that would work now. Eventually this should be null > again. I'll add a bug to create a top-level static final for this. > > -Robert > > > On 11/27/15 10:27, ShinyaYoshida wrote: > > Thank you for your review! > > New one is here: > http://cr.openjdk.java.net/~shinyafox/kulla/8142447/webrev.01/ > > 2015-11-26 9:33 GMT+09:00 Robert Field : > >> The code looks good to me. >> Just a couple small review comments: >> >> The method names cmd*() are reserved for the correspondingly named >> commands called via command registration. Similar, but I'd change the name >> of cmdUseHistoryEntryById(String id). >> > I've changed the name. > So should we also change the name of cmdUseHistoryEntry like this? > > >> >> There are no associated tests. >> > Certainly. I've add the test. > > >> >> Then some questions for general discussion that this raises (they do not >> have to be resolved for this fix to proceed) -- >> >> Does it still make sense to have the /-n form which may be useful at >> times but is a different addressing mechanism? >> > > One option is that we make the command "/re |-|!" which covers > / and /-, /!. > > >> I don't think it is critical to be able to rerun commands (as opposed >> to snippets), but it would be nice. One approach would be to give them >> synthetic ids: c1, c2, ... . Thoughts? >> > I like this feature ;) > > Regards, > shinyafox(Shinya Yoshida) > > >> -Robert >> >> >> >> On 11/10/15 19:31, ShinyaYoshida wrote: >> >> Hi Robert, >> I propose changing / to /. >> >> There is no one-to-one correspondence between n-th snippet and snippet id >> because we have the name space for main, startup and error. >> (Note: When the re-run command is implemented, we have just only one name >> space for any snippet) >> >> It makes re-run difficult. >> When we re-run main snippet, we have to add the number of startup >> snippets and the number of erroneous snippets which appear prior to the >> snippet what we want to re-run. >> It is very confusing for users. >> >> You can see the example at bugs: >> https://bugs.openjdk.java.net/browse/JDK-8142447 >> >> Here is the patch. >> Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8142447/webrev.00/ >> >> Could you consider and review this? >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >> > > From bitterfoxc at gmail.com Fri Dec 4 05:48:16 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Fri, 4 Dec 2015 14:48:16 +0900 Subject: RFR 8142447: Command change: re-run n-th command should be re-run by id In-Reply-To: <565DE6F8.2030003@oracle.com> References: <5656533D.3020601@oracle.com> <565DE6F8.2030003@oracle.com> Message-ID: I've checked! Thank you!! shinyafox(ShinyaYoshida) 2015-12-02 3:29 GMT+09:00 Robert Field : > Pushed! > > -Robert > > On 11/27/15 10:27, ShinyaYoshida wrote: > > Thank you for your review! > > New one is here: > http://cr.openjdk.java.net/~shinyafox/kulla/8142447/webrev.01/ > > 2015-11-26 9:33 GMT+09:00 Robert Field : > >> The code looks good to me. >> Just a couple small review comments: >> >> The method names cmd*() are reserved for the correspondingly named >> commands called via command registration. Similar, but I'd change the name >> of cmdUseHistoryEntryById(String id). >> > I've changed the name. > So should we also change the name of cmdUseHistoryEntry like this? > > >> >> There are no associated tests. >> > Certainly. I've add the test. > > >> >> Then some questions for general discussion that this raises (they do not >> have to be resolved for this fix to proceed) -- >> >> Does it still make sense to have the /-n form which may be useful at >> times but is a different addressing mechanism? >> > > One option is that we make the command "/re |-|!" which covers > / and /-, /!. > > >> I don't think it is critical to be able to rerun commands (as opposed >> to snippets), but it would be nice. One approach would be to give them >> synthetic ids: c1, c2, ... . Thoughts? >> > I like this feature ;) > > Regards, > shinyafox(Shinya Yoshida) > > >> -Robert >> >> >> >> On 11/10/15 19:31, ShinyaYoshida wrote: >> >> Hi Robert, >> I propose changing / to /. >> >> There is no one-to-one correspondence between n-th snippet and snippet id >> because we have the name space for main, startup and error. >> (Note: When the re-run command is implemented, we have just only one name >> space for any snippet) >> >> It makes re-run difficult. >> When we re-run main snippet, we have to add the number of startup >> snippets and the number of erroneous snippets which appear prior to the >> snippet what we want to re-run. >> It is very confusing for users. >> >> You can see the example at bugs: >> https://bugs.openjdk.java.net/browse/JDK-8142447 >> >> Here is the patch. >> Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8142447/webrev.00/ >> >> Could you consider and review this? >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >> > > From robert.field at oracle.com Fri Dec 4 22:22:01 2015 From: robert.field at oracle.com (Robert Field) Date: Fri, 04 Dec 2015 14:22:01 -0800 Subject: RFR (xxs) 8144756: JShell: ToolBasicTest.java missing @bug tag for 8142447 Message-ID: <56621209.2080006@oracle.com> JDK-8142447 added a test for the new functionality in test/jdk/jshell/ToolBasicTest.java However, there was no @bug tag added. --- a/test/jdk/jshell/ToolBasicTest.java Fri Dec 04 09:46:12 2015 -0800 +++ b/test/jdk/jshell/ToolBasicTest.java Fri Dec 04 14:18:33 2015 -0800 @@ -23,7 +23,7 @@ /* * @test - * @bug 8143037 + * @bug 8143037 8142447 * @summary Tests for Basic tests for REPL tool * @ignore 8139873 * @library /tools/lib From jan.lahoda at oracle.com Mon Dec 7 16:27:18 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 07 Dec 2015 17:27:18 +0100 Subject: RFR (xxs) 8144756: JShell: ToolBasicTest.java missing @bug tag for 8142447 In-Reply-To: <56621209.2080006@oracle.com> References: <56621209.2080006@oracle.com> Message-ID: <5665B366.6040202@oracle.com> Seem OK. Jan On 4.12.2015 23:22, Robert Field wrote: > JDK-8142447 added a test for the new functionality in > test/jdk/jshell/ToolBasicTest.java > > However, there was no @bug tag added. > > --- a/test/jdk/jshell/ToolBasicTest.java Fri Dec 04 09:46:12 2015 > -0800 > +++ b/test/jdk/jshell/ToolBasicTest.java Fri Dec 04 14:18:33 2015 > -0800 > @@ -23,7 +23,7 @@ > > /* > * @test > - * @bug 8143037 > + * @bug 8143037 8142447 > * @summary Tests for Basic tests for REPL tool > * @ignore 8139873 > * @library /tools/lib > From bitterfoxc at gmail.com Tue Dec 8 09:10:05 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Tue, 8 Dec 2015 18:10:05 +0900 Subject: RFR 8144903: JShell: determine incorrectly the type of the expression which is array type of captured type Message-ID: Hi Robert, Could you review my patch for "JShell: determine incorrectly the type of the expression which is array type of captured type"? https://bugs.openjdk.java.net/browse/JDK-8144903 webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.00/ Regards, shinyafox(Shinya Yoshida) From robert.field at oracle.com Tue Dec 8 19:58:14 2015 From: robert.field at oracle.com (Robert Field) Date: Tue, 8 Dec 2015 11:58:14 -0800 Subject: RFR 8144095: JShell tool: normalize command parameter hand Message-ID: Fixes for: 8144095 : JShell tool: normalize command parameter handling 8140265 : jshell tool: /save saves rejected input Please review webrev: http://cr.openjdk.java.net/~rfield/8144095v1/ Jan, thanks for the pre-review -- J> Should the "/classes /methods /vars" be separated with a comma? R> OK J> SnippetPredicate: Note that an alternative would be to mark the nonEmptyStream metod with @SafeVarArgs. J> Having the specialized interface seems nicer, in a sense. So, I guess I'd keep that, maybe just change "work-around" to "Avoid". R> Done -Robert From robert.field at oracle.com Tue Dec 8 20:28:22 2015 From: robert.field at oracle.com (Robert Field) Date: Tue, 8 Dec 2015 12:28:22 -0800 Subject: RFR 8144903: JShell: determine incorrectly the type of the expression which is array type of captured type In-Reply-To: References: Message-ID: [Jan, I'd like your opinion] Thank you for seeing this and drilling into where the problem is. This is important to fix. I see that this would address the problem. However, I am squeamish about the solution as it unwraps to match the result of layers of underlying super class behavior. Looking at it further, I believe the problem is in the pre-existing typeToPrint, my bad! I don't think the approach I took is right. Stepping back, we want upper bound unless the type is embedded in a type that takes generic types, class types. That suggests to me replacing typeToPrint with a boolean useWildCard = false, which would be changed by visitClassType(). But alas this is recursive and this visitor does not have state that passes through the recursion, so it would be global -- in this case that should work, but ugly. Ah! Really the problem is that we want the top-level type to be erased. But that means holding an instance of Types. Deeper integration with javac. Hmmmm.... -Robert > On Dec 8, 2015, at 1:10 AM, ShinyaYoshida wrote: > > Hi Robert, > Could you review my patch for > "JShell: determine incorrectly the type of the expression which is array type of captured type"? > https://bugs.openjdk.java.net/browse/JDK-8144903 > > webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.00/ > > Regards, > shinyafox(Shinya Yoshida) From jan.lahoda at oracle.com Tue Dec 8 20:38:16 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 08 Dec 2015 21:38:16 +0100 Subject: RFR 8144095: JShell tool: normalize command parameter hand In-Reply-To: References: Message-ID: <56673FB8.5040502@oracle.com> Seems OK to me. Jan On 8.12.2015 20:58, Robert Field wrote: > Fixes for: > 8144095 : JShell tool: normalize command parameter handling > 8140265 : jshell tool: /save saves rejected input > > Please review webrev: > http://cr.openjdk.java.net/~rfield/8144095v1/ > > > Jan, thanks for the pre-review -- > > J> Should the "/classes /methods /vars" be separated with a comma? > > R> OK > > J> SnippetPredicate: Note that an alternative would be to mark the nonEmptyStream metod with @SafeVarArgs. > J> Having the specialized interface seems nicer, in a sense. So, I guess I'd keep that, maybe just change "work-around" to "Avoid". > > R> Done > > -Robert > From bitterfoxc at gmail.com Tue Dec 8 23:13:40 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Wed, 9 Dec 2015 08:13:40 +0900 Subject: RFR 8144903: JShell: determine incorrectly the type of the expression which is array type of captured type In-Reply-To: References:

Message-ID: Hi Robert, Thank you for your review and comments. 2015-12-09 5:28 GMT+09:00 Robert Field : > [Jan, I'd like your opinion] > > Thank you for seeing this and drilling into where the problem is. This is > important to fix. > > I see that this would address the problem. However, I am squeamish about > the solution as it unwraps to match the result of layers of underlying > super class behavior. Looking at it further, I believe the problem is in > the pre-existing typeToPrint, my bad! I don't think the approach I took is > right. Stepping back, we want upper bound unless the type is embedded in a > type that takes generic types, class types. That suggests to me replacing > typeToPrint with a boolean useWildCard = false, which would be changed by > visitClassType(). But alas this is recursive and this visitor does not > have state that passes through the recursion, so it would be global -- in > this case that should work, but ugly. > Certainly, my fix is too depend on the super implementation. The fix which you mentioned is like this, right? http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_0/ > Ah! Really the problem is that we want the top-level type to be erased. > But that means holding an instance of Types. Deeper integration with > javac. Hmmmm.... > Another possible fix is making TypePrinter general(no recursive state) and adding the print method what is erase top-level capture to TypePrinter, using the print method at callsite: http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_1/ Regards, shinyafox(Shinya Yoshida) > > > -Robert > > On Dec 8, 2015, at 1:10 AM, ShinyaYoshida wrote: > > Hi Robert, > Could you review my patch for > "JShell: determine incorrectly the type of the expression which is array > type of captured type"? > https://bugs.openjdk.java.net/browse/JDK-8144903 > > webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.00/ > > Regards, > shinyafox(Shinya Yoshida) > > > From robert.field at oracle.com Wed Dec 9 00:34:23 2015 From: robert.field at oracle.com (Robert Field) Date: Tue, 08 Dec 2015 16:34:23 -0800 Subject: RFR 8144903: JShell: determine incorrectly the type of the expression which is array type of captured type In-Reply-To: References:

Message-ID: <15184291298.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Exactly, Shinya. Still curious of Jan's thinking. -Robert On December 8, 2015 15:13:42 ShinyaYoshida wrote: > Hi Robert, > Thank you for your review and comments. > > 2015-12-09 5:28 GMT+09:00 Robert Field : > >> [Jan, I'd like your opinion] >> >> Thank you for seeing this and drilling into where the problem is. This is >> important to fix. >> >> I see that this would address the problem. However, I am squeamish about >> the solution as it unwraps to match the result of layers of underlying >> super class behavior. Looking at it further, I believe the problem is in >> the pre-existing typeToPrint, my bad! I don't think the approach I took is >> right. Stepping back, we want upper bound unless the type is embedded in a >> type that takes generic types, class types. That suggests to me replacing >> typeToPrint with a boolean useWildCard = false, which would be changed by >> visitClassType(). But alas this is recursive and this visitor does not >> have state that passes through the recursion, so it would be global -- in >> this case that should work, but ugly. >> > Certainly, my fix is too depend on the super implementation. > The fix which you mentioned is like this, right? > http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_0/ > > > >> Ah! Really the problem is that we want the top-level type to be erased. >> But that means holding an instance of Types. Deeper integration with >> javac. Hmmmm.... >> > Another possible fix is making TypePrinter general(no recursive state) and > adding the print method what is erase top-level capture to TypePrinter, > using the print method at callsite: > http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_1/ > > Regards, > shinyafox(Shinya Yoshida) > > >> >> >> -Robert >> >> On Dec 8, 2015, at 1:10 AM, ShinyaYoshida wrote: >> >> Hi Robert, >> Could you review my patch for >> "JShell: determine incorrectly the type of the expression which is array >> type of captured type"? >> https://bugs.openjdk.java.net/browse/JDK-8144903 >> >> webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.00/ >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >> From maurizio.cimadamore at oracle.com Wed Dec 9 12:39:40 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 9 Dec 2015 12:39:40 +0000 Subject: RFR 8144903: JShell: determine incorrectly the type of the expression which is array type of captured type In-Reply-To: <15184291298.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References:

<15184291298.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: <5668210C.4030102@oracle.com> Hi Shinya, In my experience, the best way to get to an usable declared type from a capture type is to always follow the wildcard - i.e. the upper bound of a captured type is more of an internal type system info (the result of capture conversion) and I don't think it should be used. That said, I think there's a problem here: captured vars can appear in two places, type position or type-argument position: 1) Type position class Foo { X get() { .. } } Foo fs = ... fs.get(); // you get a #CAP in a type position - i.e. the return type of get() 2) Type-argument position class Foo2 { List get() { .. } } Foo fs = ... fs.get(); // you get a List<#CAP>, so #CAP is in a type-argument position I think the TypePrinter should have some logic to detect as to whethe you are in case #1 or #2, and if in #1 it should drop wildcards to the floor; if it's in #2 it is ok to retain wildcards. So, I think a good solution would emit String for #1 and List for #2. As usual - this is my 0.02$ :-) [This is essentially an inference problem - we are trying to infer a denotable type from the type of an expression which might contain non-denotable types - the problem is not too different from what we have to do when the functional interfaces that are the target of a lambda conversion contains wildcards]. Maurizio On 09/12/15 00:34, Robert Field wrote: > Exactly, Shinya. Still curious of Jan's thinking. > > -Robert > > > > On December 8, 2015 15:13:42 ShinyaYoshida wrote: > >> Hi Robert, >> Thank you for your review and comments. >> >> 2015-12-09 5:28 GMT+09:00 Robert Field : >> >>> [Jan, I'd like your opinion] >>> >>> Thank you for seeing this and drilling into where the problem is. >>> This is >>> important to fix. >>> >>> I see that this would address the problem. However, I am squeamish >>> about >>> the solution as it unwraps to match the result of layers of underlying >>> super class behavior. Looking at it further, I believe the problem >>> is in >>> the pre-existing typeToPrint, my bad! I don't think the approach I >>> took is >>> right. Stepping back, we want upper bound unless the type is >>> embedded in a >>> type that takes generic types, class types. That suggests to me >>> replacing >>> typeToPrint with a boolean useWildCard = false, which would be >>> changed by >>> visitClassType(). But alas this is recursive and this visitor does not >>> have state that passes through the recursion, so it would be global >>> -- in >>> this case that should work, but ugly. >>> >> Certainly, my fix is too depend on the super implementation. >> The fix which you mentioned is like this, right? >> http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_0/ >> >> >> >>> Ah! Really the problem is that we want the top-level type to be erased. >>> But that means holding an instance of Types. Deeper integration with >>> javac. Hmmmm.... >>> >> Another possible fix is making TypePrinter general(no recursive >> state) and >> adding the print method what is erase top-level capture to TypePrinter, >> using the print method at callsite: >> http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_1/ >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >>> >>> >>> -Robert >>> >>> On Dec 8, 2015, at 1:10 AM, ShinyaYoshida wrote: >>> >>> Hi Robert, >>> Could you review my patch for >>> "JShell: determine incorrectly the type of the expression which is >>> array >>> type of captured type"? >>> https://bugs.openjdk.java.net/browse/JDK-8144903 >>> >>> webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.00/ >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> >>> From jan.lahoda at oracle.com Wed Dec 9 15:00:05 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 09 Dec 2015 16:00:05 +0100 Subject: RFR 8144903: JShell: determine incorrectly the type of the expression which is array type of captured type In-Reply-To: <5668210C.4030102@oracle.com> References:

<15184291298.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> <5668210C.4030102@oracle.com> Message-ID: <566841F5.9020204@oracle.com> I am looking at: http://hg.netbeans.org/jet-main/file/default/java.source.base/src/org/netbeans/api/java/source/SourceUtils.java#l1067 (which is solving a similar problem; and while I found out there may be a bug related to arrays in that.) I concur with Maurizio that CapturedType.wildcard should (presumably) be used always for CapturedTypes. When the resulting wildcard is not suitable for the given place (i.e. top-level type), then we should use getExtendsBound()/getSuperBound() to unroll the wildcard. Out of the recent two patches, I like webrev.01_0 much more. Presumably just override visitWildcardType and unroll the wildcard if needed, and change the visitCapturedType to just: return visit(t.wildcard, locale); Would that work? Jan On 9.12.2015 13:39, Maurizio Cimadamore wrote: > Hi Shinya, > In my experience, the best way to get to an usable declared type from a > capture type is to always follow the wildcard - i.e. the upper bound of > a captured type is more of an internal type system info (the result of > capture conversion) and I don't think it should be used. > > That said, I think there's a problem here: captured vars can appear in > two places, type position or type-argument position: > > 1) Type position > > class Foo { > X get() { .. } > } > > Foo fs = ... > fs.get(); // you get a #CAP in a type position - i.e. the return type of > get() > > 2) Type-argument position > > class Foo2 { > List get() { .. } > } > > Foo fs = ... > fs.get(); // you get a List<#CAP>, so #CAP is in a type-argument position > > I think the TypePrinter should have some logic to detect as to whethe > you are in case #1 or #2, and if in #1 it should drop wildcards to the > floor; if it's in #2 it is ok to retain wildcards. So, I think a good > solution would emit String for #1 and List for #2. > > As usual - this is my 0.02$ :-) > > [This is essentially an inference problem - we are trying to infer a > denotable type from the type of an expression which might contain > non-denotable types - the problem is not too different from what we have > to do when the functional interfaces that are the target of a lambda > conversion contains wildcards]. > > Maurizio > > On 09/12/15 00:34, Robert Field wrote: >> Exactly, Shinya. Still curious of Jan's thinking. >> >> -Robert >> >> >> >> On December 8, 2015 15:13:42 ShinyaYoshida wrote: >> >>> Hi Robert, >>> Thank you for your review and comments. >>> >>> 2015-12-09 5:28 GMT+09:00 Robert Field : >>> >>>> [Jan, I'd like your opinion] >>>> >>>> Thank you for seeing this and drilling into where the problem is. >>>> This is >>>> important to fix. >>>> >>>> I see that this would address the problem. However, I am squeamish >>>> about >>>> the solution as it unwraps to match the result of layers of underlying >>>> super class behavior. Looking at it further, I believe the problem >>>> is in >>>> the pre-existing typeToPrint, my bad! I don't think the approach I >>>> took is >>>> right. Stepping back, we want upper bound unless the type is >>>> embedded in a >>>> type that takes generic types, class types. That suggests to me >>>> replacing >>>> typeToPrint with a boolean useWildCard = false, which would be >>>> changed by >>>> visitClassType(). But alas this is recursive and this visitor does not >>>> have state that passes through the recursion, so it would be global >>>> -- in >>>> this case that should work, but ugly. >>>> >>> Certainly, my fix is too depend on the super implementation. >>> The fix which you mentioned is like this, right? >>> http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_0/ >>> >>> >>> >>>> Ah! Really the problem is that we want the top-level type to be erased. >>>> But that means holding an instance of Types. Deeper integration with >>>> javac. Hmmmm.... >>>> >>> Another possible fix is making TypePrinter general(no recursive >>> state) and >>> adding the print method what is erase top-level capture to TypePrinter, >>> using the print method at callsite: >>> http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_1/ >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> >>>> >>>> >>>> -Robert >>>> >>>> On Dec 8, 2015, at 1:10 AM, ShinyaYoshida wrote: >>>> >>>> Hi Robert, >>>> Could you review my patch for >>>> "JShell: determine incorrectly the type of the expression which is >>>> array >>>> type of captured type"? >>>> https://bugs.openjdk.java.net/browse/JDK-8144903 >>>> >>>> webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.00/ >>>> >>>> Regards, >>>> shinyafox(Shinya Yoshida) >>>> >>>> >>>> > From jan.lahoda at oracle.com Wed Dec 9 15:24:41 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 09 Dec 2015 16:24:41 +0100 Subject: RFR 8144906: Fix jshell's ToolBasicTest Message-ID: <566847B9.8040109@oracle.com> Hello, The ToolBasicTest is @ignored now, as it fails on some platforms. I am proposing a partial fix for that, the patch is available here: http://cr.openjdk.java.net/~jlahoda/8144906/webrev.00/ Notes: -currently, there are three communication channels between the RemoteAgent process and the main JShell process: the command socket and RemoteAgent's out and err. The problem is that it is not easy to synchronize events between these channels, so it may happen that the command is already finished, while the out and err has not been fully processed yet. My proposal here is to change the System.out and System.err so that these also use the socket stream, so that there is (normally) only one communication channel, allowing us to fully process the out/err before finishing a command. This should also fix JDK-8131013. Note I kept the existing code to copy the RemoteAgent's stdout/stderr, just in case the RemoteAgent prints something there (for debugging, for example), even though this shouldn't be typically used. -unfortunately, there are still some problems on Solaris, which I wasn't able to debug yet, so the test is excluded on Solaris. -I added synchronization to JDIConnection, which should ensure proper access to the fields, and avoid the need to catch the NPE in JDIConnection. -ReplToolTesting now converts the platform's line endings to '\n', to eliminate platform specific problems with line endings. How does this look? Thanks, Jan From bitterfoxc at gmail.com Wed Dec 9 20:46:03 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Thu, 10 Dec 2015 05:46:03 +0900 Subject: RFR 8144903: JShell: determine incorrectly the type of the expression which is array type of captured type In-Reply-To: <566841F5.9020204@oracle.com> References:

<15184291298.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> <5668210C.4030102@oracle.com> <566841F5.9020204@oracle.com> Message-ID: Hi Maurizio and Jan, Thank you for your advice. I've tried to unroll it in wildcard to take the advice. http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.02/ But I've met a problem. In this case, we get the Object instead of CharSequence, this is not acceptable for user: In TypeNameTest#testBounds assertEval("class Test1 { public X get() { return null; } }"); Snippet x = varKey(assertEval("Test1 test1 = new Test1<>();")); VarSnippet sn4 = (VarSnippet) varKey(assertEval("test1.get()")); assertEquals(sn4.typeName(), "CharSequence"); Compiler determines the upper bound of wildcard"?" as CharSequence from the declaration. But WildcardType doesn't have that information at all. Do you have any idea for this? Regards, shinyafox(Shinya Yoshida) 2015-12-10 0:00 GMT+09:00 Jan Lahoda : > I am looking at: > > http://hg.netbeans.org/jet-main/file/default/java.source.base/src/org/netbeans/api/java/source/SourceUtils.java#l1067 > > (which is solving a similar problem; and while I found out there may be a > bug related to arrays in that.) > > I concur with Maurizio that CapturedType.wildcard should (presumably) be > used always for CapturedTypes. When the resulting wildcard is not suitable > for the given place (i.e. top-level type), then we should use > getExtendsBound()/getSuperBound() to unroll the wildcard. > > Out of the recent two patches, I like webrev.01_0 much more. Presumably > just override visitWildcardType and unroll the wildcard if needed, and > change the visitCapturedType to just: > return visit(t.wildcard, locale); > > Would that work? > > Jan > > > On 9.12.2015 13:39, Maurizio Cimadamore wrote: > >> Hi Shinya, >> In my experience, the best way to get to an usable declared type from a >> capture type is to always follow the wildcard - i.e. the upper bound of >> a captured type is more of an internal type system info (the result of >> capture conversion) and I don't think it should be used. >> >> That said, I think there's a problem here: captured vars can appear in >> two places, type position or type-argument position: >> >> 1) Type position >> >> class Foo { >> X get() { .. } >> } >> >> Foo fs = ... >> fs.get(); // you get a #CAP in a type position - i.e. the return type of >> get() >> >> 2) Type-argument position >> >> class Foo2 { >> List get() { .. } >> } >> >> Foo fs = ... >> fs.get(); // you get a List<#CAP>, so #CAP is in a type-argument position >> >> I think the TypePrinter should have some logic to detect as to whethe >> you are in case #1 or #2, and if in #1 it should drop wildcards to the >> floor; if it's in #2 it is ok to retain wildcards. So, I think a good >> solution would emit String for #1 and List for #2. >> >> As usual - this is my 0.02$ :-) >> >> [This is essentially an inference problem - we are trying to infer a >> denotable type from the type of an expression which might contain >> non-denotable types - the problem is not too different from what we have >> to do when the functional interfaces that are the target of a lambda >> conversion contains wildcards]. >> >> Maurizio >> >> On 09/12/15 00:34, Robert Field wrote: >> >>> Exactly, Shinya. Still curious of Jan's thinking. >>> >>> -Robert >>> >>> >>> >>> On December 8, 2015 15:13:42 ShinyaYoshida wrote: >>> >>> Hi Robert, >>>> Thank you for your review and comments. >>>> >>>> 2015-12-09 5:28 GMT+09:00 Robert Field : >>>> >>>> [Jan, I'd like your opinion] >>>>> >>>>> Thank you for seeing this and drilling into where the problem is. >>>>> This is >>>>> important to fix. >>>>> >>>>> I see that this would address the problem. However, I am squeamish >>>>> about >>>>> the solution as it unwraps to match the result of layers of underlying >>>>> super class behavior. Looking at it further, I believe the problem >>>>> is in >>>>> the pre-existing typeToPrint, my bad! I don't think the approach I >>>>> took is >>>>> right. Stepping back, we want upper bound unless the type is >>>>> embedded in a >>>>> type that takes generic types, class types. That suggests to me >>>>> replacing >>>>> typeToPrint with a boolean useWildCard = false, which would be >>>>> changed by >>>>> visitClassType(). But alas this is recursive and this visitor does not >>>>> have state that passes through the recursion, so it would be global >>>>> -- in >>>>> this case that should work, but ugly. >>>>> >>>>> Certainly, my fix is too depend on the super implementation. >>>> The fix which you mentioned is like this, right? >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_0/ >>>> >>>> >>>> >>>> Ah! Really the problem is that we want the top-level type to be erased. >>>>> But that means holding an instance of Types. Deeper integration with >>>>> javac. Hmmmm.... >>>>> >>>>> Another possible fix is making TypePrinter general(no recursive >>>> state) and >>>> adding the print method what is erase top-level capture to TypePrinter, >>>> using the print method at callsite: >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_1/ >>>> >>>> Regards, >>>> shinyafox(Shinya Yoshida) >>>> >>>> >>>> >>>>> >>>>> -Robert >>>>> >>>>> On Dec 8, 2015, at 1:10 AM, ShinyaYoshida >>>>> wrote: >>>>> >>>>> Hi Robert, >>>>> Could you review my patch for >>>>> "JShell: determine incorrectly the type of the expression which is >>>>> array >>>>> type of captured type"? >>>>> https://bugs.openjdk.java.net/browse/JDK-8144903 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.00/ >>>>> >>>>> Regards, >>>>> shinyafox(Shinya Yoshida) >>>>> >>>>> >>>>> >>>>> >> From robert.field at oracle.com Wed Dec 9 21:10:39 2015 From: robert.field at oracle.com (Robert Field) Date: Wed, 9 Dec 2015 13:10:39 -0800 Subject: RFR 8144906: Fix jshell's ToolBasicTest In-Reply-To: <566847B9.8040109@oracle.com> References: <566847B9.8040109@oracle.com> Message-ID: Jan, Can you explain how using the same channel assures that the processing of output will be completed before the snippet completes? Thanks, Robert > On Dec 9, 2015, at 7:24 AM, Jan Lahoda wrote: > > Hello, > > The ToolBasicTest is @ignored now, as it fails on some platforms. I am proposing a partial fix for that, the patch is available here: > http://cr.openjdk.java.net/~jlahoda/8144906/webrev.00/ > > Notes: > -currently, there are three communication channels between the RemoteAgent process and the main JShell process: the command socket and RemoteAgent's out and err. The problem is that it is not easy to synchronize events between these channels, so it may happen that the command is already finished, while the out and err has not been fully processed yet. My proposal here is to change the System.out and System.err so that these also use the socket stream, so that there is (normally) only one communication channel, allowing us to fully process the out/err before finishing a command. This should also fix JDK-8131013. Note I kept the existing code to copy the RemoteAgent's stdout/stderr, just in case the RemoteAgent prints something there (for debugging, for example), even though this shouldn't be typically used. > > -unfortunately, there are still some problems on Solaris, which I wasn't able to debug yet, so the test is excluded on Solaris. > > -I added synchronization to JDIConnection, which should ensure proper access to the fields, and avoid the need to catch the NPE in JDIConnection. > > -ReplToolTesting now converts the platform's line endings to '\n', to eliminate platform specific problems with line endings. > > How does this look? > > Thanks, > Jan From maurizio.cimadamore at oracle.com Wed Dec 9 22:12:45 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 9 Dec 2015 22:12:45 +0000 Subject: RFR 8144903: JShell: determine incorrectly the type of the expression which is array type of captured type In-Reply-To: References:

<15184291298.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> <5668210C.4030102@oracle.com> <566841F5.9020204@oracle.com> Message-ID: <5668A75D.9030905@oracle.com> What we can do to improve this is to use something similar to the analysis used in JLS 9.9 for functional types: * if the bound of the corresponding parameter (the captured var bound field) contains any other formal parameter (hard case), just use the 'wildcard' type Example: class Foo> { X get(); } Foo fs = ... fs.get() --> String * if the bound B of the corresponding parameter does not contain any other formal (non fbound case) then: - if wildcard is '? extends T', the inferred type is glb(B, T) (**) - if wildcard is '? super T', the inferred type is T - if wildcard is '?', the inferred type is B This should take care of most of the nasty cases, in a way that's compatible with how things are handled for lambdas. In your CharsSequence case, since the bound is CharSequence and the wildcard type is Object, you are in the happy case (#2), so the inferred type is glb(CharSequence, Object) = Object & CharSequence. (**) as this example demonstrates, sometimes glb can return intersection types, so I'm assuming you already have some logic to 'normalize' intersection types away - and of course this logic should not throw info away - i.e. if you normalize Object & Serializable, I would expect the logic to retain Serializable, and discard the non-interesting bound. Opinions? Maurizio On 09/12/15 20:46, ShinyaYoshida wrote: > Hi Maurizio and Jan, > Thank you for your advice. > I've tried to unroll it in wildcard to take the advice. > http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.02/ > > > But I've met a problem. > In this case, we get the Object instead of CharSequence, this is not > acceptable for user: > > In TypeNameTest#testBounds > assertEval("class Test1 { public X > get() { return null; } }"); > Snippet x = varKey(assertEval("Test1 test1 = new Test1<>();")); > VarSnippet sn4 = (VarSnippet) varKey(assertEval("test1.get()")); > assertEquals(sn4.typeName(), "CharSequence"); > > Compiler determines the upper bound of wildcard"?" as CharSequence > from the declaration. > But WildcardType doesn't have that information at all. > > Do you have any idea for this? > > Regards, > shinyafox(Shinya Yoshida) > > > 2015-12-10 0:00 GMT+09:00 Jan Lahoda >: > > I am looking at: > http://hg.netbeans.org/jet-main/file/default/java.source.base/src/org/netbeans/api/java/source/SourceUtils.java#l1067 > > (which is solving a similar problem; and while I found out there > may be a bug related to arrays in that.) > > I concur with Maurizio that CapturedType.wildcard should > (presumably) be used always for CapturedTypes. When the resulting > wildcard is not suitable for the given place (i.e. top-level > type), then we should use getExtendsBound()/getSuperBound() to > unroll the wildcard. > > Out of the recent two patches, I like webrev.01_0 much more. > Presumably just override visitWildcardType and unroll the wildcard > if needed, and change the visitCapturedType to just: > return visit(t.wildcard, locale); > > Would that work? > > Jan > > > On 9.12.2015 13:39, Maurizio Cimadamore wrote: > > Hi Shinya, > In my experience, the best way to get to an usable declared > type from a > capture type is to always follow the wildcard - i.e. the upper > bound of > a captured type is more of an internal type system info (the > result of > capture conversion) and I don't think it should be used. > > That said, I think there's a problem here: captured vars can > appear in > two places, type position or type-argument position: > > 1) Type position > > class Foo { > X get() { .. } > } > > Foo fs = ... > fs.get(); // you get a #CAP in a type position - i.e. the > return type of > get() > > 2) Type-argument position > > class Foo2 { > List get() { .. } > } > > Foo fs = ... > fs.get(); // you get a List<#CAP>, so #CAP is in a > type-argument position > > I think the TypePrinter should have some logic to detect as to > whethe > you are in case #1 or #2, and if in #1 it should drop > wildcards to the > floor; if it's in #2 it is ok to retain wildcards. So, I think > a good > solution would emit String for #1 and List > for #2. > > As usual - this is my 0.02$ :-) > > [This is essentially an inference problem - we are trying to > infer a > denotable type from the type of an expression which might contain > non-denotable types - the problem is not too different from > what we have > to do when the functional interfaces that are the target of a > lambda > conversion contains wildcards]. > > Maurizio > > On 09/12/15 00:34, Robert Field wrote: > > Exactly, Shinya. Still curious of Jan's thinking. > > -Robert > > > > On December 8, 2015 15:13:42 ShinyaYoshida > > wrote: > > Hi Robert, > Thank you for your review and comments. > > 2015-12-09 5:28 GMT+09:00 Robert Field > >: > > [Jan, I'd like your opinion] > > Thank you for seeing this and drilling into where > the problem is. > This is > important to fix. > > I see that this would address the problem. > However, I am squeamish > about > the solution as it unwraps to match the result of > layers of underlying > super class behavior. Looking at it further, I > believe the problem > is in > the pre-existing typeToPrint, my bad! I don't > think the approach I > took is > right. Stepping back, we want upper bound unless > the type is > embedded in a > type that takes generic types, class types. That > suggests to me > replacing > typeToPrint with a boolean useWildCard = false, > which would be > changed by > visitClassType(). But alas this is recursive and > this visitor does not > have state that passes through the recursion, so > it would be global > -- in > this case that should work, but ugly. > > Certainly, my fix is too depend on the super > implementation. > The fix which you mentioned is like this, right? > http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_0/ > > > > > Ah! Really the problem is that we want the > top-level type to be erased. > But that means holding an instance of Types. > Deeper integration with > javac. Hmmmm.... > > Another possible fix is making TypePrinter general(no > recursive > state) and > adding the print method what is erase top-level > capture to TypePrinter, > using the print method at callsite: > http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_1/ > > > Regards, > shinyafox(Shinya Yoshida) > > > > > -Robert > > On Dec 8, 2015, at 1:10 AM, ShinyaYoshida > > wrote: > > Hi Robert, > Could you review my patch for > "JShell: determine incorrectly the type of the > expression which is > array > type of captured type"? > https://bugs.openjdk.java.net/browse/JDK-8144903 > > webrev: > http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.00/ > > > Regards, > shinyafox(Shinya Yoshida) > > > > > From robert.field at oracle.com Wed Dec 9 22:46:16 2015 From: robert.field at oracle.com (Robert Field) Date: Wed, 09 Dec 2015 14:46:16 -0800 Subject: RFR 8144903: JShell: determine incorrectly the type of the expression which is array type of captured type In-Reply-To: <5668A75D.9030905@oracle.com> References:

<15184291298.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> <5668210C.4030102@oracle.com> <566841F5.9020204@oracle.com> <5668A75D.9030905@oracle.com> Message-ID: <15188ec6ed8.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Thanks Maurizio, There is very little Type processing code in jshell, we attempt to leverage higher level javac functionality as much as possible. TypePrinter is pretty much the extent of it. So there is not "some logic to 'normalize' intersection types away". BTW: this code is currently used only to get the type of an expression. -Robert On December 9, 2015 2:12:48 PM Maurizio Cimadamore wrote: > What we can do to improve this is to use something similar to the > analysis used in JLS 9.9 for functional types: > > * if the bound of the corresponding parameter (the captured var bound > field) contains any other formal parameter (hard case), just use the > 'wildcard' type > > Example: > > class Foo> { > X get(); > } > > Foo fs = ... > fs.get() --> String > > * if the bound B of the corresponding parameter does not contain any > other formal (non fbound case) then: > > - if wildcard is '? extends T', the inferred type is glb(B, T) (**) > - if wildcard is '? super T', the inferred type is T > - if wildcard is '?', the inferred type is B > > This should take care of most of the nasty cases, in a way that's > compatible with how things are handled for lambdas. > > In your CharsSequence case, since the bound is CharSequence and the > wildcard type is Object, you are in the happy case (#2), so the inferred > type is glb(CharSequence, Object) = Object & CharSequence. > > (**) as this example demonstrates, sometimes glb can return intersection > types, so I'm assuming you already have some logic to 'normalize' > intersection types away - and of course this logic should not throw info > away - i.e. if you normalize Object & Serializable, I would expect the > logic to retain Serializable, and discard the non-interesting bound. > > Opinions? > > Maurizio > > > On 09/12/15 20:46, ShinyaYoshida wrote: >> Hi Maurizio and Jan, >> Thank you for your advice. >> I've tried to unroll it in wildcard to take the advice. >> http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.02/ >> >> >> But I've met a problem. >> In this case, we get the Object instead of CharSequence, this is not >> acceptable for user: >> >> In TypeNameTest#testBounds >> assertEval("class Test1 { public X >> get() { return null; } }"); >> Snippet x = varKey(assertEval("Test1 test1 = new Test1<>();")); >> VarSnippet sn4 = (VarSnippet) varKey(assertEval("test1.get()")); >> assertEquals(sn4.typeName(), "CharSequence"); >> >> Compiler determines the upper bound of wildcard"?" as CharSequence >> from the declaration. >> But WildcardType doesn't have that information at all. >> >> Do you have any idea for this? >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >> 2015-12-10 0:00 GMT+09:00 Jan Lahoda > >: >> >> I am looking at: >> http://hg.netbeans.org/jet-main/file/default/java.source.base/src/org/netbeans/api/java/source/SourceUtils.java#l1067 >> >> (which is solving a similar problem; and while I found out there >> may be a bug related to arrays in that.) >> >> I concur with Maurizio that CapturedType.wildcard should >> (presumably) be used always for CapturedTypes. When the resulting >> wildcard is not suitable for the given place (i.e. top-level >> type), then we should use getExtendsBound()/getSuperBound() to >> unroll the wildcard. >> >> Out of the recent two patches, I like webrev.01_0 much more. >> Presumably just override visitWildcardType and unroll the wildcard >> if needed, and change the visitCapturedType to just: >> return visit(t.wildcard, locale); >> >> Would that work? >> >> Jan >> >> >> On 9.12.2015 13:39, Maurizio Cimadamore wrote: >> >> Hi Shinya, >> In my experience, the best way to get to an usable declared >> type from a >> capture type is to always follow the wildcard - i.e. the upper >> bound of >> a captured type is more of an internal type system info (the >> result of >> capture conversion) and I don't think it should be used. >> >> That said, I think there's a problem here: captured vars can >> appear in >> two places, type position or type-argument position: >> >> 1) Type position >> >> class Foo { >> X get() { .. } >> } >> >> Foo fs = ... >> fs.get(); // you get a #CAP in a type position - i.e. the >> return type of >> get() >> >> 2) Type-argument position >> >> class Foo2 { >> List get() { .. } >> } >> >> Foo fs = ... >> fs.get(); // you get a List<#CAP>, so #CAP is in a >> type-argument position >> >> I think the TypePrinter should have some logic to detect as to >> whethe >> you are in case #1 or #2, and if in #1 it should drop >> wildcards to the >> floor; if it's in #2 it is ok to retain wildcards. So, I think >> a good >> solution would emit String for #1 and List >> for #2. >> >> As usual - this is my 0.02$ :-) >> >> [This is essentially an inference problem - we are trying to >> infer a >> denotable type from the type of an expression which might contain >> non-denotable types - the problem is not too different from >> what we have >> to do when the functional interfaces that are the target of a >> lambda >> conversion contains wildcards]. >> >> Maurizio >> >> On 09/12/15 00:34, Robert Field wrote: >> >> Exactly, Shinya. Still curious of Jan's thinking. >> >> -Robert >> >> >> >> On December 8, 2015 15:13:42 ShinyaYoshida >> > wrote: >> >> Hi Robert, >> Thank you for your review and comments. >> >> 2015-12-09 5:28 GMT+09:00 Robert Field >> > >: >> >> [Jan, I'd like your opinion] >> >> Thank you for seeing this and drilling into where >> the problem is. >> This is >> important to fix. >> >> I see that this would address the problem. >> However, I am squeamish >> about >> the solution as it unwraps to match the result of >> layers of underlying >> super class behavior. Looking at it further, I >> believe the problem >> is in >> the pre-existing typeToPrint, my bad! I don't >> think the approach I >> took is >> right. Stepping back, we want upper bound unless >> the type is >> embedded in a >> type that takes generic types, class types. That >> suggests to me >> replacing >> typeToPrint with a boolean useWildCard = false, >> which would be >> changed by >> visitClassType(). But alas this is recursive and >> this visitor does not >> have state that passes through the recursion, so >> it would be global >> -- in >> this case that should work, but ugly. >> >> Certainly, my fix is too depend on the super >> implementation. >> The fix which you mentioned is like this, right? >> http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_0/ >> >> >> >> >> Ah! Really the problem is that we want the >> top-level type to be erased. >> But that means holding an instance of Types. >> Deeper integration with >> javac. Hmmmm.... >> >> Another possible fix is making TypePrinter general(no >> recursive >> state) and >> adding the print method what is erase top-level >> capture to TypePrinter, >> using the print method at callsite: >> http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.01_1/ >> >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >> >> >> -Robert >> >> On Dec 8, 2015, at 1:10 AM, ShinyaYoshida >> > > wrote: >> >> Hi Robert, >> Could you review my patch for >> "JShell: determine incorrectly the type of the >> expression which is >> array >> type of captured type"? >> https://bugs.openjdk.java.net/browse/JDK-8144903 >> >> webrev: >> http://cr.openjdk.java.net/~shinyafox/kulla/8144903/webrev.00/ >> >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >> >> >> > From maurizio.cimadamore at oracle.com Thu Dec 10 00:37:12 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 10 Dec 2015 00:37:12 +0000 Subject: RFR 8144903: JShell: determine incorrectly the type of the expression which is array type of captured type In-Reply-To: <15188ec6ed8.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References:

<15184291298.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> <5668210C.4030102@oracle.com> <566841F5.9020204@oracle.com> <5668A75D.9030905@oracle.com> <15188ec6ed8.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> <5668C938.1000008@oracle.com> <88DF07B5-ADEE-454E-8143-05AA6E70C047@oracle.com> <566954B1.7040102@oracle.com> <5669F577.507@oracle.com> <566A80AD.8050808@oracle.com> <566AAB6B.5050204@oracle.com> <566B002B.5070202@oracle.com> <566B1274.2010301@oracle.com> <566B1998.8030202@oracle.com> Message-ID: <1519264e300.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Thanks, Maurizio. I will push. -Robert On December 11, 2015 10:44:43 AM Maurizio Cimadamore wrote: > > > On 11/12/15 18:14, Robert Field wrote: >> If others think I should just get over it, I'll push as is. > I think this fix is a stable point in the design space - the treatment > of complex types is as simple as possible: > > * captured vars are 'erased' using wildcard info > * intersection types are erased to Object > > If you want to use the upper bound of a captured variable in a safe way > you need to: > > * check as to whether the bound is not recursive i.e. X extends > Comparable > * do something for intersection types, as declared bounds can be > intersection types > > This means TypePrinter will start doing subtyping tests and other > similar stuff - which right now it's not the case. > > While it might be worthwhile to explore that direction further, I > believe that in the short term, the right thing to do is the > conservative fix Shinya has put together. The fact that the regression > test used to pass is more an accident than a feature; there are multiple > variations of that test that won't work. > > Maurizio From bitterfoxc at gmail.com Sat Dec 12 10:17:28 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Sat, 12 Dec 2015 19:17:28 +0900 Subject: RFR 8145239: JShell: throws AssertionError when replace classes with some methods which depends on these classes Message-ID: Hi Robert, Could you review my patch for issue 8145239? bugs: https://bugs.openjdk.java.net/browse/JDK-8145239 webreve: http://cr.openjdk.java.net/~shinyafox/kulla/8145239/webrev.00/ Regards, shinyafox(Shinya Yoshida) From bitterfoxc at gmail.com Sun Dec 13 06:33:55 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Sun, 13 Dec 2015 15:33:55 +0900 Subject: RFR 8145263: JShell API: Change the format of SourceCodeAnalysis#documentation Message-ID: Hi Jan and Robert, I'd like to propose changing the format of SourceCodeAnalysis#documentation. The detail of the change is on the issue 8145263: https://bugs.openjdk.java.net/browse/JDK-8145263 Please see it. You can see the more example in the test of my patch. Patch is here: http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.00/ Please consider my proposal and review the patch. Regards, shinyafox(Shinya Yoshida) From jan.lahoda at oracle.com Mon Dec 14 14:24:22 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 14 Dec 2015 15:24:22 +0100 Subject: RFR 8145263: JShell API: Change the format of SourceCodeAnalysis#documentation In-Reply-To: References: Message-ID: <566ED116.3080502@oracle.com> Hi Shinya, Generally, looks good, thanks for looking at this! Two comments: -for parameter names, I was hoping we could get them from the sources (if/when available), but we are not doing that now, and hiding synthetic parameter names makes sense to me. So this is OK, and if we at some point start to parse parameter names from the sources, we can tweak the code to do the right thing. -not sure if marking constructors with ".new" ("type-name.new()") will be clear - do you think the traditional form ("type-name()") is unclear? Thanks, Jan On 13.12.2015 07:33, ShinyaYoshida wrote: > Hi Jan and Robert, > I'd like to propose changing the format of SourceCodeAnalysis#documentation. > > The detail of the change is on the issue 8145263: > https://bugs.openjdk.java.net/browse/JDK-8145263 > Please see it. > > You can see the more example in the test of my patch. > > Patch is here: > http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.00/ > > Please consider my proposal and review the patch. > > Regards, > shinyafox(Shinya Yoshida) From bitterfoxc at gmail.com Mon Dec 14 14:40:38 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Mon, 14 Dec 2015 23:40:38 +0900 Subject: RFR 8145263: JShell API: Change the format of SourceCodeAnalysis#documentation In-Reply-To: <566ED116.3080502@oracle.com> References: <566ED116.3080502@oracle.com> Message-ID: Hi Jan, Thank you for your review. 2015-12-14 23:24 GMT+09:00 Jan Lahoda : > Hi Shinya, > > Generally, looks good, thanks for looking at this! Two comments: > -for parameter names, I was hoping we could get them from the sources > (if/when available), but we are not doing that now, and hiding synthetic > parameter names makes sense to me. So this is OK, and if we at some point > start to parse parameter names from the sources, we can tweak the code to > do the right thing. I think that there should be the issue for the parameter names. Do you have the issue for that? If not, should I create it? > > -not sure if marking constructors with ".new" > ("type-name.new()") will be clear - do you think the > traditional form ("type-name()") is unclear? > When I consider the constructor with the generics like following, I notice that the traditional(current) form is difficult to represent it. class C { C(U u) {} } So I choose that format which is like the constructor reference. Another possible representation is "new type-name()" which is similar to the invocation of the constructor with generics. What do you think? Regards, shinyafox(Shinya Yoshida) > > Thanks, > Jan > > > On 13.12.2015 07:33, ShinyaYoshida wrote: > >> Hi Jan and Robert, >> I'd like to propose changing the format of >> SourceCodeAnalysis#documentation. >> >> The detail of the change is on the issue 8145263: >> https://bugs.openjdk.java.net/browse/JDK-8145263 >> Please see it. >> >> You can see the more example in the test of my patch. >> >> Patch is here: >> http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.00/ >> >> Please consider my proposal and review the patch. >> >> Regards, >> shinyafox(Shinya Yoshida) >> > From robert.field at oracle.com Mon Dec 14 19:29:21 2015 From: robert.field at oracle.com (Robert Field) Date: Mon, 14 Dec 2015 11:29:21 -0800 Subject: RFR 8145239: JShell: throws AssertionError when replace classes with some methods which depends on these classes In-Reply-To: References: Message-ID: <566F1891.2050003@oracle.com> Another good catch, Shinya! The general fix idea is good, that the analyze for parameter types cannot be done with stale info -- it needs to the active trial Unit set as context. I'll do this review from low-level detail to global -- which means many comments will make the previous ones moot. * Stylistically, in AnalyzeTask, adding a constructor for a prepended main, when that has no inherent meaning for AnalyzeTask seems misplaced, I'd put the prepend in the caller who knows (though it is convenient for streamification). And as a result a lot of delicate things, like the flag settings are duplicated. * The main Unit is a member of ins -- so prepending it means a duplicate class, since this patch works, I guess this happens to work, but this doesn't seem something we should depend on. * The patch constructs the main Unit using the two argument constructor, which is reserved for dropped snippets and sets it as a dropped snippet, that is, probably, never exposed, but it is scary. * I wrote TreeDissector with an assumption, based on assuming there is only one class being analyzed, that the first one is the one we care about. Again, since this patch works, it must usually/frequently/always/in-this-case/who-knows map the first input as the first output tree. But I see no documentation saying that will happen. * In this case, TreeDissector could do something cleaner than it did before (picking the first), namely: it knows the class name it is interested in based on the class name of the outer wrap -- it can grab that tree. * That would mean there is no need to do the prepend trick. That, in turn, would mean the same input to analyze in each case. Thus, no reason to reanalyze with each Unit in ins. but, looking out a couple layers, that analyze has already been done in Eval. So, rather than passing ins into setStatus(), it could pass the AnalyzeTask -- saving one or many compiles. More efficient, potentially much more efficient and cleaner than my original code. The last two bullets make the previous ones moot. Thanks, Robert On 12/12/15 02:17, ShinyaYoshida wrote: > Hi Robert, > Could you review my patch for issue 8145239? > bugs: https://bugs.openjdk.java.net/browse/JDK-8145239 > webreve: > http://cr.openjdk.java.net/~shinyafox/kulla/8145239/webrev.00/ > > > Regards, > shinyafox(Shinya Yoshida) From bitterfoxc at gmail.com Tue Dec 15 02:10:48 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Tue, 15 Dec 2015 11:10:48 +0900 Subject: RFR 8145239: JShell: throws AssertionError when replace classes with some methods which depends on these classes In-Reply-To: <566F1891.2050003@oracle.com> References: <566F1891.2050003@oracle.com> Message-ID: Hi Robert, Thank you for your review and comments. I've updated my patch to take your advice: http://cr.openjdk.java.net/~shinyafox/kulla/8145239/webrev.01/ In my patch: - rename BaseTask#cuTree to firstCuTree - add "cuTrees" method which return all cu tree to BaseTask - add "findClassByName" method to TreeDissector, and use it in typeOfMethod with current snippet's class name - change method signatures of TreeDissector#first* to receive the parent Tree to find first Please review it again. Regards, shinyafox(Shinya Yoshida) 2015-12-15 4:29 GMT+09:00 Robert Field : > Another good catch, Shinya! > > The general fix idea is good, that the analyze for parameter types cannot > be done with stale info -- it needs to the active > trial Unit set as context. > > I'll do this review from low-level detail to global -- which means many > comments will make the previous ones moot. > > * Stylistically, in AnalyzeTask, adding a constructor for a prepended > main, when that has no inherent meaning for AnalyzeTask > seems misplaced, I'd put the prepend in the caller who knows (though it is > convenient for streamification). And as a result a > lot of delicate things, like the flag settings are duplicated. > > * The main Unit is a member of ins -- so prepending it means a duplicate > class, since this patch works, I guess this happens to > work, but this doesn't seem something we should depend on. > > * The patch constructs the main Unit using the two argument constructor, > which is reserved for dropped snippets and sets it > as a dropped snippet, that is, probably, never exposed, but it is scary. > > * I wrote TreeDissector with an assumption, based on assuming there is > only one class being analyzed, that the first one is the > one we care about. Again, since this patch works, it must > usually/frequently/always/in-this-case/who-knows map the first input > as the first output tree. But I see no documentation saying that will > happen. > > * In this case, TreeDissector could do something cleaner than it did > before (picking the first), namely: it knows the class name it > is interested in based on the class name of the outer wrap -- it can grab > that tree. > > * That would mean there is no need to do the prepend trick. That, in > turn, would mean the same input to analyze in each case. > Thus, no reason to reanalyze with each Unit in ins. but, looking out a > couple layers, that analyze has already been done in Eval. > So, rather than passing ins into setStatus(), it could pass the > AnalyzeTask -- saving one or many compiles. More efficient, > potentially much more efficient and cleaner than my original code. > > The last two bullets make the previous ones moot. > > Thanks, > Robert > > On 12/12/15 02:17, ShinyaYoshida wrote: > >> Hi Robert, >> Could you review my patch for issue 8145239? >> bugs: https://bugs.openjdk.java.net/browse/JDK-8145239 >> webreve: http://cr.openjdk.java.net/~shinyafox/kulla/8145239/webrev.00/ < >> http://cr.openjdk.java.net/%7Eshinyafox/kulla/8145239/webrev.00/> >> >> Regards, >> shinyafox(Shinya Yoshida) >> > > From maurizio.cimadamore at oracle.com Tue Dec 15 16:03:06 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 Dec 2015 16:03:06 +0000 Subject: RFR 8143952: JShell: space in class path causes remote launch failure In-Reply-To: <566B110E.1020907@oracle.com> References: <566B110E.1020907@oracle.com> Message-ID: <567039BA.2000905@oracle.com> Looks good! Maurizio On 11/12/15 18:08, Jan Lahoda wrote: > Hello, > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8143952 > > Problem: when running the RemoteAgent (the process in which the user's > code is being run), a problem occurs if the -classpath or > -Xbootclasspath/p: argument contains a space, as the spaces are not > properly quoted. > > We currently construct a "connection spec" string in ExecutionControl, > and then parse it in JDIConnection to construct connector arguments. > So we would need to keep some kind of quoting through this process. > This seems a little bit unnecessary - why not pass the arguments as a > map (with proper quoting of the values in the map), avoiding the parsing? > > Patch that implements this: > http://cr.openjdk.java.net/~jlahoda/8143952/webrev.00/ > > Thanks to Robert and Maurizio for their comments so far on the patch. > > Any feedback is welcome. > > Thanks! > > Jan From robert.field at oracle.com Tue Dec 15 17:02:19 2015 From: robert.field at oracle.com (Robert Field) Date: Tue, 15 Dec 2015 09:02:19 -0800 Subject: RFR 8145263: JShell API: Change the format of SourceCodeAnalysis#documentation In-Reply-To: References: <566ED116.3080502@oracle.com> Message-ID: <151a697b578.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Much better representation. Thanks. I think "new" is confusing in either location. The representation you have minus the "new" is good. -Robert P.S. they have WiFi in the jury selection room On December 14, 2015 06:40:44 ShinyaYoshida wrote: > Hi Jan, > Thank you for your review. > > 2015-12-14 23:24 GMT+09:00 Jan Lahoda : > >> Hi Shinya, >> >> Generally, looks good, thanks for looking at this! Two comments: >> -for parameter names, I was hoping we could get them from the sources >> (if/when available), but we are not doing that now, and hiding synthetic >> parameter names makes sense to me. So this is OK, and if we at some point >> start to parse parameter names from the sources, we can tweak the code to >> do the right thing. > > I think that there should be the issue for the parameter names. > Do you have the issue for that? > If not, should I create it? > > >> >> -not sure if marking constructors with ".new" >> ("type-name.new()") will be clear - do you think the >> traditional form ("type-name()") is unclear? >> > > When I consider the constructor with the generics like following, I notice > that the traditional(current) form is difficult to represent it. > class C { C(U u) {} } > So I choose that format which is like the constructor reference. > > Another possible representation is "new > type-name()" which is similar to the invocation of > the constructor with generics. > > What do you think? > > Regards, > shinyafox(Shinya Yoshida) > > >> >> Thanks, >> Jan >> >> >> On 13.12.2015 07:33, ShinyaYoshida wrote: >> >>> Hi Jan and Robert, >>> I'd like to propose changing the format of >>> SourceCodeAnalysis#documentation. >>> >>> The detail of the change is on the issue 8145263: >>> https://bugs.openjdk.java.net/browse/JDK-8145263 >>> Please see it. >>> >>> You can see the more example in the test of my patch. >>> >>> Patch is here: >>> http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.00/ >>> >>> Please consider my proposal and review the patch. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >> From jan.lahoda at oracle.com Tue Dec 15 20:56:30 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 15 Dec 2015 21:56:30 +0100 Subject: RFR 8145263: JShell API: Change the format of SourceCodeAnalysis#documentation In-Reply-To: References: <566ED116.3080502@oracle.com> Message-ID: <56707E7E.4020704@oracle.com> Hi Shinya, On 14.12.2015 15:40, ShinyaYoshida wrote: > Hi Jan, > Thank you for your review. > > 2015-12-14 23:24 GMT+09:00 Jan Lahoda >: > > Hi Shinya, > > Generally, looks good, thanks for looking at this! Two comments: > -for parameter names, I was hoping we could get them from the > sources (if/when available), but we are not doing that now, and > hiding synthetic parameter names makes sense to me. So this is OK, > and if we at some point start to parse parameter names from the > sources, we can tweak the code to do the right thing. > > I think that there should be the issue for the parameter names. > Do you have the issue for that? No issue for this yet. > If not, should I create it? Sure, thanks. > > > -not sure if marking constructors with ".new" > ("type-name.new()") will be clear - do you think the > traditional form ("type-name()") is unclear? > > > When I consider the constructor with the generics like following, I > notice that the traditional(current) form is difficult to represent it. > class C { C(U u) {} } > So I choose that format which is like the constructor reference. I think generic constructors (i.e. constructors that themselves have type parameters) are very uncommon, so I wouldn't optimize for those. Having the format nice for usual constructors is more important, I think, even if the format for these uncommon constructors would be uglier. Thanks, Jan > > Another possible representation is "new > type-name()" which is similar to the invocation of > the constructor with generics. > > What do you think? > > Regards, > shinyafox(Shinya Yoshida) > > > Thanks, > Jan > > > On 13.12.2015 07:33, ShinyaYoshida wrote: > > Hi Jan and Robert, > I'd like to propose changing the format of > SourceCodeAnalysis#documentation. > > The detail of the change is on the issue 8145263: > https://bugs.openjdk.java.net/browse/JDK-8145263 > Please see it. > > You can see the more example in the test of my patch. > > Patch is here: > http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.00/ > > Please consider my proposal and review the patch. > > Regards, > shinyafox(Shinya Yoshida) > > From bitterfoxc at gmail.com Wed Dec 16 01:07:21 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Wed, 16 Dec 2015 10:07:21 +0900 Subject: RFR 8145263: JShell API: Change the format of SourceCodeAnalysis#documentation In-Reply-To: <56707E7E.4020704@oracle.com> References: <566ED116.3080502@oracle.com> <56707E7E.4020704@oracle.com> Message-ID: Hi Jan and Robert, Thank you. I've filed: https://bugs.openjdk.java.net/browse/JDK-8145473 Ok, I put the type parameters for the constructor before the traditional(current) form: http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.01/ Please review it again. Regards, shinyafox(Shinya Yoshida) 2015-12-16 5:56 GMT+09:00 Jan Lahoda : > Hi Shinya, > > On 14.12.2015 15:40, ShinyaYoshida wrote: > >> Hi Jan, >> Thank you for your review. >> >> 2015-12-14 23:24 GMT+09:00 Jan Lahoda > >: >> >> Hi Shinya, >> >> Generally, looks good, thanks for looking at this! Two comments: >> -for parameter names, I was hoping we could get them from the >> sources (if/when available), but we are not doing that now, and >> hiding synthetic parameter names makes sense to me. So this is OK, >> and if we at some point start to parse parameter names from the >> sources, we can tweak the code to do the right thing. >> >> I think that there should be the issue for the parameter names. >> Do you have the issue for that? >> > > No issue for this yet. > > If not, should I create it? >> > > Sure, thanks. > > >> >> -not sure if marking constructors with ".new" >> ("type-name.new()") will be clear - do you think the >> traditional form ("type-name()") is unclear? >> >> >> When I consider the constructor with the generics like following, I >> notice that the traditional(current) form is difficult to represent it. >> class C { C(U u) {} } >> So I choose that format which is like the constructor reference. >> > > I think generic constructors (i.e. constructors that themselves have type > parameters) are very uncommon, so I wouldn't optimize for those. Having the > format nice for usual constructors is more important, I think, even if the > format for these uncommon constructors would be uglier. > > Thanks, > Jan > > > >> Another possible representation is "new >> type-name()" which is similar to the invocation of >> the constructor with generics. >> >> What do you think? >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >> Thanks, >> Jan >> >> >> On 13.12.2015 07:33, ShinyaYoshida wrote: >> >> Hi Jan and Robert, >> I'd like to propose changing the format of >> SourceCodeAnalysis#documentation. >> >> The detail of the change is on the issue 8145263: >> https://bugs.openjdk.java.net/browse/JDK-8145263 >> Please see it. >> >> You can see the more example in the test of my patch. >> >> Patch is here: >> http://cr.openjdk.java.net/~shinyafox/kulla/8145263/webrev.00/ >> >> Please consider my proposal and review the patch. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >> From bitterfoxc at gmail.com Thu Dec 24 08:37:18 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Thu, 24 Dec 2015 17:37:18 +0900 Subject: RFR 8145239: JShell: throws AssertionError when replace classes with some methods which depends on these classes In-Reply-To: <5678A97F.2020503@oracle.com> References: <566F1891.2050003@oracle.com> <5678A97F.2020503@oracle.com> Message-ID: Hi Robert, I'll reply inline. 2015-12-22 10:38 GMT+09:00 Robert Field : > Hi Shinya, > > Cool. > Some comments below. > > Eval.java -- > Changes are name changes, code clean-up, and, passing the parameter. > That all looks good. > In the case that some methods are corralled, a reanalysis is done. This > reanalysis will not have failures for the corralled > methods, and possibly other dependent methods -- it thus would be a > better basis for determining the parameter types > which is what the "at" parameter is used for. Since compileAndLoad only > uses "at" for for setting diagnostics, and now > this use, there is no reason a separate "cat" (corralled "at") variable > is needed, the corralled case can just reset "at". > I see. I'll reuse the re-analyzed "at" when any is corralled. But "at" will not be effectively final when I re-assign at. So I make "at" as array to hack. What do you think about this hack? > SourceCodeAnalysisImpl.java -- > Changes are name changes. Those are good. > > TaskFactory.java -- > Changes are to store a list of CompilationUnitTree, instead of just the > first. Name changes accordingly. That is good. > > AnalyzeTask constructor: Nice stream use. The line above converts > Iterable to Iterator, only to be converted back in the > argument to Util.stream. One option would be to leave cuTrees as a List > (just eliminating the conversions). It appears > only to be used in two places (getting the first element, or to create a > stream). So, leaving it an Iterable (no conversion) > seems another good option. BTW. Using "cuts" as the name of the local > variable and the field should be avoided, esp, > as in this case, where they are different. > > ParseTask constructor: While currently only one compilation unit is > returned by parse as it is currently used and as the > JShell parse code is implemented. That may change in the future, and > even without that knowledge it would be best not > base code on that unwritten assumption. So, basically, whatever > treatment is picked for the AnalyzeTask constructor > should also be applied to this. > > Nit: 383 should be empty line between these two declarations. > I've changed the return type of BaseTask#cuTrees to Iterable<...> and AnalyzeTask and ParseTask keeps the return value of analyze() and parse() without conversion. In ParseTask, I've changed collecting import trees or class trees from all of the parsed compilation units. > > > TreeDissector.java -- > Changes are to move away from the assumption that the desired code is > always in the first compilation unit and to > add functionality for searching all compilation units for the desired > class. It does indeed move in that direction with some > embedded assumptions of which uses first and which searches; And that > would be OK given that the class is a bit ad hoc > anyway. But getStartPosition or getEndPosition, used with > findClassByName would give incorrect results (which would be > hard to trace). Note that those two are not currently used together. > Given that all uses of TreeDissector require a target > class, it would be much safer and clearer if the target class and > corresponding compilation unit were immutable and > established at the instantiation of TreeDissector. So, basically two > constructors: one with the just BaseTask as a parameter > that uses the first compilation unit and first class, and the other with > the BaseTask and class name as a parameters, where > compilation unit and class are found by search. > I've added targetClass and targetCompilationUnit and changed using it instead of firstClass and cuTree. And I've created static factory methods, createByFirstClass and createBySnippet instead of constructors. > > Unit.java --- > Changes are to add AnalyzeTask parameter, with some nice code clean-up. > Looks good. > One important comment was lost with the change to conditional at 416. > Maybe reverse the sense of the test to be positive > (paren >= 0) and preface the return-conditional with something like: > // Extract the parameter type string from the method signature, > // if method did not compile use the user-supplied parameter types > Oops... I've changed as you mentioned. New webrev is here: http://cr.openjdk.java.net/~shinyafox/kulla/8145239/webrev.02/ Regards and have a merry christmas, Shinya Yoshida > > Thanks much, > Robert > > > > > > > On 12/14/15 18:10, ShinyaYoshida wrote: > > Hi Robert, > Thank you for your review and comments. > > I've updated my patch to take your advice: > http://cr.openjdk.java.net/~shinyafox/kulla/8145239/webrev.01/ > > In my patch: > - rename BaseTask#cuTree to firstCuTree > - add "cuTrees" method which return all cu tree to BaseTask > - add "findClassByName" method to TreeDissector, and use it in > typeOfMethod with current snippet's class name > - change method signatures of TreeDissector#first* to receive the parent > Tree to find first > > Please review it again. > > Regards, > shinyafox(Shinya Yoshida) > > > 2015-12-15 4:29 GMT+09:00 Robert Field : > >> Another good catch, Shinya! >> >> The general fix idea is good, that the analyze for parameter types cannot >> be done with stale info -- it needs to the active >> trial Unit set as context. >> >> I'll do this review from low-level detail to global -- which means many >> comments will make the previous ones moot. >> >> * Stylistically, in AnalyzeTask, adding a constructor for a prepended >> main, when that has no inherent meaning for AnalyzeTask >> seems misplaced, I'd put the prepend in the caller who knows (though it >> is convenient for streamification). And as a result a >> lot of delicate things, like the flag settings are duplicated. >> >> * The main Unit is a member of ins -- so prepending it means a duplicate >> class, since this patch works, I guess this happens to >> work, but this doesn't seem something we should depend on. >> >> * The patch constructs the main Unit using the two argument constructor, >> which is reserved for dropped snippets and sets it >> as a dropped snippet, that is, probably, never exposed, but it is scary. >> >> * I wrote TreeDissector with an assumption, based on assuming there is >> only one class being analyzed, that the first one is the >> one we care about. Again, since this patch works, it must >> usually/frequently/always/in-this-case/who-knows map the first input >> as the first output tree. But I see no documentation saying that will >> happen. >> >> * In this case, TreeDissector could do something cleaner than it did >> before (picking the first), namely: it knows the class name it >> is interested in based on the class name of the outer wrap -- it can grab >> that tree. >> >> * That would mean there is no need to do the prepend trick. That, in >> turn, would mean the same input to analyze in each case. >> Thus, no reason to reanalyze with each Unit in ins. but, looking out a >> couple layers, that analyze has already been done in Eval. >> So, rather than passing ins into setStatus(), it could pass the >> AnalyzeTask -- saving one or many compiles. More efficient, >> potentially much more efficient and cleaner than my original code. >> >> The last two bullets make the previous ones moot. >> >> Thanks, >> Robert >> >> On 12/12/15 02:17, ShinyaYoshida wrote: >> >>> Hi Robert, >>> Could you review my patch for issue 8145239? >>> bugs: https://bugs.openjdk.java.net/browse/JDK-8145239 >>> webreve: http://cr.openjdk.java.net/~shinyafox/kulla/8145239/webrev.00/ >>> >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >> >> > > From ryacobellis at luc.edu Mon Dec 28 06:10:02 2015 From: ryacobellis at luc.edu (Yacobellis, Robert) Date: Mon, 28 Dec 2015 06:10:02 +0000 Subject: possible Scanner input bug in jshell? Message-ID: <99cae87edf824e9fa76dae4a1c8dffbb@mbxls1.adms.luc.edu> Greetings, I was trying out jshell by printing a prompt to the console and then using a Scanner attached to System.in to read from the keyboard, all in a Windows cmd window. The output works fine, but jshell appears to hang up when doing a Scanner nextLine() method - CTRL-C and CTRL-Z don't interrupt this, so at this point I have to close the cmd window manually. Is this expected behavior, that Scanner(System.In).nextLine() doesn't connect to keyboard input, or is there something else that I should be doing to make this work? Thanks, Dr. Robert (Bob) Yacobellis Loyola University Chicago Computer Science Department From bitterfoxc at gmail.com Mon Dec 28 13:44:27 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Mon, 28 Dec 2015 22:44:27 +0900 Subject: RFR 8145239: JShell: throws AssertionError when replace classes with some methods which depends on these classes In-Reply-To: <568098EC.7000107@oracle.com> References: <566F1891.2050003@oracle.com> <5678A97F.2020503@oracle.com> <568098EC.7000107@oracle.com> Message-ID: Hi Robert, Thank you for your review! 2015-12-28 11:05 GMT+09:00 Robert Field : > > > > But "at" will not be effectively final when I re-assign at. > > > That's annoying, isn't it! > Yes, it is!!! I've changed to following: + AnalyzeTask cat;+ if (ins.stream().anyMatch(u -> u.corralIfNeeded(ins))) { // if any were corralled, re-analyze everything- AnalyzeTask cat = state.taskFactory.new AnalyzeTask(ins);+ cat = state.taskFactory.new AnalyzeTask(ins); ins.stream().forEach(u -> u.setCorralledDiagnostics(cat));+ } else {+ cat = at; }- ins.stream().forEach(u -> u.setStatus());+ ins.stream().forEach(u -> u.setStatus(cat)); > So I make "at" as array to hack. > What do you think about this hack? > > > I think you have correctly characterized it -- a hack. > > A somewhat less hacky approach would be to assign it to a new effectively > final AnalyzeTask variable just before the forEach. > > > >> >> TreeDissector.java -- >> Changes are to move away from the assumption that the desired code is >> always in the first compilation unit and to >> add functionality for searching all compilation units for the desired >> class. It does indeed move in that direction with some >> embedded assumptions of which uses first and which searches; And that >> would be OK given that the class is a bit ad hoc >> anyway. But getStartPosition or getEndPosition, used with >> findClassByName would give incorrect results (which would be >> hard to trace). Note that those two are not currently used together. >> Given that all uses of TreeDissector require a target >> class, it would be much safer and clearer if the target class and >> corresponding compilation unit were immutable and >> established at the instantiation of TreeDissector. So, basically two >> constructors: one with the just BaseTask as a parameter >> that uses the first compilation unit and first class, and the other >> with the BaseTask and class name as a parameters, where >> compilation unit and class are found by search. >> > I've added targetClass and targetCompilationUnit and changed using it > instead of firstClass and cuTree. > And I've created static factory methods, createByFirstClass > and createBySnippet instead of constructors. > > > Clean! > > I note though that createBySnippet will only find it if happens to be the > first class in the CU -- it should find it anywhere. > > Maybe instead of computeFirstClass(), you could have a utility method that > returns a stream of the classes in a CU would fill the needs of both > create*() factory methods? > Certainly!! I've changed so. The new webrev is here: http://cr.openjdk.java.net/~shinyafox/kulla/8145239/webrev.03/ Could you push it? Best Regards, shinyafox(Shinya Yoshida) > > > > >> >> Unit.java --- >> Changes are to add AnalyzeTask parameter, with some nice code clean-up. >> Looks good. >> One important comment was lost with the change to conditional at 416. >> Maybe reverse the sense of the test to be positive >> (paren >= 0) and preface the return-conditional with something like: >> // Extract the parameter type string from the method signature, >> // if method did not compile use the user-supplied parameter types >> > Oops... > I've changed as you mentioned. > > > Thanks. > > > New webrev is here: > http://cr.openjdk.java.net/~shinyafox/kulla/8145239/webrev.02/ > > Regards and have a merry christmas, > Shinya Yoshida > > > Thanks! > > I'll be working over the holidays so I can push when you have it ready. > > Much appreciated, > Robert > > > > >> >> Thanks much, >> Robert >> >> >> >> >> >> >> On 12/14/15 18:10, ShinyaYoshida wrote: >> >> Hi Robert, >> Thank you for your review and comments. >> >> I've updated my patch to take your advice: >> http://cr.openjdk.java.net/~shinyafox/kulla/8145239/webrev.01/ >> >> In my patch: >> - rename BaseTask#cuTree to firstCuTree >> - add "cuTrees" method which return all cu tree to BaseTask >> - add "findClassByName" method to TreeDissector, and use it in >> typeOfMethod with current snippet's class name >> - change method signatures of TreeDissector#first* to receive the parent >> Tree to find first >> >> Please review it again. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >> 2015-12-15 4:29 GMT+09:00 Robert Field : >> >>> Another good catch, Shinya! >>> >>> The general fix idea is good, that the analyze for parameter types >>> cannot be done with stale info -- it needs to the active >>> trial Unit set as context. >>> >>> I'll do this review from low-level detail to global -- which means many >>> comments will make the previous ones moot. >>> >>> * Stylistically, in AnalyzeTask, adding a constructor for a prepended >>> main, when that has no inherent meaning for AnalyzeTask >>> seems misplaced, I'd put the prepend in the caller who knows (though it >>> is convenient for streamification). And as a result a >>> lot of delicate things, like the flag settings are duplicated. >>> >>> * The main Unit is a member of ins -- so prepending it means a duplicate >>> class, since this patch works, I guess this happens to >>> work, but this doesn't seem something we should depend on. >>> >>> * The patch constructs the main Unit using the two argument constructor, >>> which is reserved for dropped snippets and sets it >>> as a dropped snippet, that is, probably, never exposed, but it is scary. >>> >>> * I wrote TreeDissector with an assumption, based on assuming there is >>> only one class being analyzed, that the first one is the >>> one we care about. Again, since this patch works, it must >>> usually/frequently/always/in-this-case/who-knows map the first input >>> as the first output tree. But I see no documentation saying that will >>> happen. >>> >>> * In this case, TreeDissector could do something cleaner than it did >>> before (picking the first), namely: it knows the class name it >>> is interested in based on the class name of the outer wrap -- it can >>> grab that tree. >>> >>> * That would mean there is no need to do the prepend trick. That, in >>> turn, would mean the same input to analyze in each case. >>> Thus, no reason to reanalyze with each Unit in ins. but, looking out a >>> couple layers, that analyze has already been done in Eval. >>> So, rather than passing ins into setStatus(), it could pass the >>> AnalyzeTask -- saving one or many compiles. More efficient, >>> potentially much more efficient and cleaner than my original code. >>> >>> The last two bullets make the previous ones moot. >>> >>> Thanks, >>> Robert >>> >>> On 12/12/15 02:17, ShinyaYoshida wrote: >>> >>>> Hi Robert, >>>> Could you review my patch for issue 8145239? >>>> bugs: https://bugs.openjdk.java.net/browse/JDK-8145239 >>>> webreve: http://cr.openjdk.java.net/~shinyafox/kulla/8145239/webrev.00/ >>>> >>>> >>>> Regards, >>>> shinyafox(Shinya Yoshida) >>>> >>> >>> >> >> > > From ryacobellis at luc.edu Mon Dec 28 15:24:23 2015 From: ryacobellis at luc.edu (Yacobellis, Robert) Date: Mon, 28 Dec 2015 15:24:23 +0000 Subject: more info RE: possible Scanner input bug in jshell? Message-ID: I should have mentioned this: I'm running Windows 7 Ultimate 64 bit, and I just downloaded the Java 9 jre and jdk yesterday before trying jshell. I've attached a copy of the cmd inputs I typed right up to the point where I press enter in jshell and everything locks up. From: Yacobellis, Robert Sent: Monday, December 28, 2015 12:10 AM To: 'kulla-dev at openjdk.java.net' Subject: possible Scanner input bug in jshell? Importance: High Greetings, I was trying out jshell by printing a prompt to the console and then using a Scanner attached to System.in to read from the keyboard, all in a Windows cmd window. The output works fine, but jshell appears to hang up when doing a Scanner nextLine() method - CTRL-C and CTRL-Z don't interrupt this, so at this point I have to close the cmd window manually. Is this expected behavior, that Scanner(System.In).nextLine() doesn't connect to keyboard input, or is there something else that I should be doing to make this work? Thanks, Dr. Robert (Bob) Yacobellis Loyola University Chicago Computer Science Department -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jshell-input.txt URL: From ryacobellis at luc.edu Tue Dec 29 03:21:04 2015 From: ryacobellis at luc.edu (Yacobellis, Robert) Date: Tue, 29 Dec 2015 03:21:04 +0000 Subject: a possible timing issue in jshell Message-ID: <00fc576919644fb78e98ef880c5561a2@mbxls1.adms.luc.edu> Greetings, I noticed that sometimes when I print to the console the printed output is intermixed with the jshell prompt. I think this might be happening because the println is running in a different process from jshell itself. I've attached a printout take from a cmd jshell execution that shows this (the System.out.println() output is intermixed with the jshell prompt). I've gotten around it by defining my own println, print, and printf functions that include a 5 ms Thread.sleep following the output - that seems to be enough time to avoid the problem. Regards, Bob Y. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jshell_thread_timing_issue.txt URL: From joao.parana at gmail.com Tue Dec 29 11:39:03 2015 From: joao.parana at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Antonio_Ferreira?=) Date: Tue, 29 Dec 2015 09:39:03 -0200 Subject: I am unable to register myself in kulla-dev mailing list Message-ID: I am unable to register myself in kulla-dev mailing list I'm using this page : http://mail.openjdk.java.net/mailman/listinfo/kulla-dev Although properly inform the data have not received any email confirmation Tanks in advance Jo?o Antonio From robert.field at oracle.com Wed Dec 30 03:48:53 2015 From: robert.field at oracle.com (Robert Field) Date: Tue, 29 Dec 2015 19:48:53 -0800 Subject: a possible timing issue in jshell In-Reply-To: <00fc576919644fb78e98ef880c5561a2@mbxls1.adms.luc.edu> References: <00fc576919644fb78e98ef880c5561a2@mbxls1.adms.luc.edu> Message-ID: <56835425.50909@oracle.com> Thank you for reporting this issue. It is a known issue for which a fix is currently is progress: https://bugs.openjdk.java.net/browse/JDK-8131013?filter=25814 Thanks, Robert On 12/28/15 19:21, Yacobellis, Robert wrote: > Greetings, > > I noticed that sometimes when I print to the console the printed output is intermixed with the jshell prompt. I think this might be happening because the println is running in a different process from jshell itself. I've attached a printout take from a cmd jshell execution that shows this (the System.out.println() output is intermixed with the jshell prompt). I've gotten around it by defining my own println, print, and printf functions that include a 5 ms Thread.sleep following the output - that seems to be enough time to avoid the problem. > > Regards, > Bob Y. > From robert.field at oracle.com Wed Dec 30 04:28:02 2015 From: robert.field at oracle.com (Robert Field) Date: Tue, 29 Dec 2015 20:28:02 -0800 Subject: possible Scanner input bug in jshell? In-Reply-To: <99cae87edf824e9fa76dae4a1c8dffbb@mbxls1.adms.luc.edu> References: <99cae87edf824e9fa76dae4a1c8dffbb@mbxls1.adms.luc.edu> Message-ID: <56835D52.1050805@oracle.com> Thanks for reporting this. It is a known issue that System.in does not work: https://bugs.openjdk.java.net/browse/JDK-8131023?filter=25683 It is possible that the current work inter-process communication issues (see the other issue you sent) may provide an avenue for addressing this. In the end, I have re-assigned and raised the priority. Thanks, Robert On 12/27/15 22:10, Yacobellis, Robert wrote: > Greetings, > > I was trying out jshell by printing a prompt to the console and then using a Scanner attached to System.in to read from the keyboard, all in a Windows cmd window. The output works fine, but jshell appears to hang up when doing a Scanner nextLine() method - CTRL-C and CTRL-Z don't interrupt this, so at this point I have to close the cmd window manually. > > Is this expected behavior, that Scanner(System.In).nextLine() doesn't connect to keyboard input, or is there something else that I should be doing to make this work? > > Thanks, > Dr. Robert (Bob) Yacobellis > Loyola University Chicago Computer Science Department From robert.field at oracle.com Wed Dec 30 05:07:27 2015 From: robert.field at oracle.com (Robert Field) Date: Tue, 29 Dec 2015 21:07:27 -0800 Subject: I am unable to register myself in kulla-dev mailing list In-Reply-To: References: Message-ID: <5683668F.5030606@oracle.com> Hmmm, don't know what went wrong -- I've added you manually. FYI about OpenJDK lists, you can contact the owner by appending "-owner", in this case: kulla-dev-owner at openjdk.java.net Otherwise known as me. Enjoy, Robert On 12/29/15 03:39, Jo?o Antonio Ferreira wrote: > I am unable to register myself in kulla-dev mailing list > > I'm using this page : > http://mail.openjdk.java.net/mailman/listinfo/kulla-dev > > Although properly inform the data have not received any email confirmation > > Tanks in advance > > Jo?o Antonio From joao.parana at gmail.com Wed Dec 30 11:36:02 2015 From: joao.parana at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Antonio_Ferreira?=) Date: Wed, 30 Dec 2015 09:36:02 -0200 Subject: How to run a JPA application using JShell Message-ID: I'm unable to load the persistence.xml file when using a Shell JPA application. Jo?o Antonio From benjamin.john.evans at gmail.com Wed Dec 30 11:44:37 2015 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Wed, 30 Dec 2015 11:44:37 +0000 Subject: How to run a JPA application using JShell In-Reply-To: References: Message-ID: 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 Thu Dec 31 06:55:11 2015 From: robert.field at oracle.com (Robert Field) Date: Wed, 30 Dec 2015 22:55:11 -0800 Subject: RFR 8081845: JShell: Need way to refresh relative to external state Message-ID: <5684D14F.80508@oracle.com> JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8081845 Webrev: http://cr.openjdk.java.net/~rfield/8081845v1/ From bitterfoxc at gmail.com Thu Dec 31 21:13:05 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Fri, 1 Jan 2016 06:13:05 +0900 Subject: RFR 8146368(xs): JShell: couldn't smash the error when it's Japanese locale Message-ID: 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)