From jan.lahoda at oracle.com Mon Oct 2 15:35:33 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 2 Oct 2017 17:35:33 +0200 Subject: RFR JDK-8188225: AST could be improved in presence of var types. Message-ID: <59D25CC5.5080809@oracle.com> Hello, JShell produces not ideal errors related to local variable type inference in some cases: --- jshell> var i = () -> {}; | Error: | incompatible types: java.lang.Object is not a functional interface | var i = () -> {}; | ^------^ --- Better would be: --- jshell> var i = () -> {}; | Error: | cannot infer type for local variable i | (lambda expression needs an explicit target-type) | var i = () -> {}; | ^---------------^ --- (which is the error produced by javac) The AST model could also be improved for local variables whose type have been inferred (which also improves the jshell errors in some cases): - for "var i = 0;", the VariableTree.getType() will be null even after attribution, but for: "for (var i : Arrays.asList(0, 1)) {}", the VariableTree.getType() will be filled in by Attr. (The inferred type is also filled in for lambda parameters.) This is not only inconsistent, but also Attr.PostAttrAnalyzer.visitVarDef may fill in the type with an ErroneousTree (with a wrong position). The proposal here is to always fill in the type for consistency, and to consistently use NOPOS for the synthetic type position -for "var i = 0;" SourcePositions.getStartPosition does not return a proper starting position (the position of "var"), but rather the position of the synthetic type, if any (which can also be ErroneousTree) or the position of the variable name. The proposal here is to remember the real start of the variable and return it. Bug: https://bugs.openjdk.java.net/browse/JDK-8188225 Webrev: http://cr.openjdk.java.net/~jlahoda/8188225/webrev.00/index.html What do you think? Thanks, Jan From maurizio.cimadamore at oracle.com Tue Oct 3 15:59:41 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 3 Oct 2017 16:59:41 +0100 Subject: RFR JDK-8188225: AST could be improved in presence of var types. In-Reply-To: <59D25CC5.5080809@oracle.com> References: <59D25CC5.5080809@oracle.com> Message-ID: <5ffd68fa-6455-b412-351f-54778be3cf4a@oracle.com> Thanks for taking care of this, I have a couple of suggestion: * the routine for generating synthetic type tree should be shared. E.g. you need a method that takes a type and generates something that is suitable for a local variable or a lambda parameter - e.g. toSyntheticTypeTree(Type t) { ?? if (t.isErroneous()) { ?? ?? return make.at(Position.NOPOS).Erroneous(); ?? } else { ????? return make.at(Position.NOPOS).Type(t); ?? } } * secondly, while adding the startpos tree is fine - here it seems like we morally would like to override the getStartPosition for the synthetic type trees created above, so that the former position is returned (e.g. that of 'var'). So, I wonder if something like this could work: toSyntheticTypeTree(Type t, int preferredPos) { ?? if (t.isErroneous()) { ?? ?? return make.at(preferredPos).Erroneous(); ?? } else { ????? return make.at(preferredPos).Type(t); ?? } } Then, assuming the parser creates the local variable node with the correct pos (which it doesn't now), I think everything should work even w/o a dedicated field? Maurizio On 02/10/17 16:35, Jan Lahoda wrote: > Hello, > > JShell produces not ideal errors related to local variable type > inference in some cases: > --- > jshell> var i = () -> {}; > |? Error: > |? incompatible types: java.lang.Object is not a functional interface > |? var i = () -> {}; > |????????? ^------^ > --- > > Better would be: > --- > jshell> var i = () -> {}; > |? Error: > |? cannot infer type for local variable i > |??? (lambda expression needs an explicit target-type) > |? var i = () -> {}; > |? ^---------------^ > --- > > (which is the error produced by javac) > > The AST model could also be improved for local variables whose type > have been inferred (which also improves the jshell errors in some cases): > - for "var i = 0;", the VariableTree.getType() will be null even after > attribution, but for: "for (var i : Arrays.asList(0, 1)) {}", the > VariableTree.getType() will be filled in by Attr. (The inferred type > is also filled in for lambda parameters.) This is not only > inconsistent, but also Attr.PostAttrAnalyzer.visitVarDef may fill in > the type with an ErroneousTree (with a wrong position). The proposal > here is to always fill in the type for consistency, and to > consistently use NOPOS for the synthetic type position > > -for "var i = 0;" SourcePositions.getStartPosition does not return a > proper starting position (the position of "var"), but rather the > position of the synthetic type, if any (which can also be > ErroneousTree) or the position of the variable name. The proposal here > is to remember the real start of the variable and return it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188225 > Webrev: http://cr.openjdk.java.net/~jlahoda/8188225/webrev.00/index.html > > What do you think? > > Thanks, > ??? Jan From jan.lahoda at oracle.com Tue Oct 3 17:53:46 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 3 Oct 2017 19:53:46 +0200 Subject: RFR JDK-8188225: AST could be improved in presence of var types. In-Reply-To: <5ffd68fa-6455-b412-351f-54778be3cf4a@oracle.com> References: <59D25CC5.5080809@oracle.com> <5ffd68fa-6455-b412-351f-54778be3cf4a@oracle.com> Message-ID: <59D3CEAA.5010302@oracle.com> Hi Maurizio, Thanks for the comments - some responses inline. On 3.10.2017 17:59, Maurizio Cimadamore wrote: > Thanks for taking care of this, I have a couple of suggestion: > > * the routine for generating synthetic type tree should be shared. E.g. > you need a method that takes a type and generates something that is > suitable for a local variable or a lambda parameter - e.g. > > toSyntheticTypeTree(Type t) { > if (t.isErroneous()) { > return make.at(Position.NOPOS).Erroneous(); > } else { > return make.at(Position.NOPOS).Type(t); > } > } Sure, will do. > > * secondly, while adding the startpos tree is fine - here it seems like > we morally would like to override the getStartPosition for the synthetic > type trees created above, so that the former position is returned (e.g. > that of 'var'). So, I wonder if something like this could work: > > toSyntheticTypeTree(Type t, int preferredPos) { > if (t.isErroneous()) { > return make.at(preferredPos).Erroneous(); > } else { > return make.at(preferredPos).Type(t); > } > } > > Then, assuming the parser creates the local variable node with the > correct pos (which it doesn't now), I think everything should work even Hm, you mean put the starting position to the JCVariableDecl.pos? If that would be the value, we could surely avoid the field, but AFAIK the JCVariableDecl.pos usually points to the name of the variable, and I didn't want to add an inconsistency, or change that (as the position is useful for error reporting), Alternatives I was thinking of included playing tricks with modifiers (setting the position to modifiers (if there are no/empty modifiers) and filtering it in getStartPos), with nameexpr or having a subclass of JCVariableDecl for vars which would include the extra field. (I was also trying to have -1 as the position of the synthetic type to aid its detection, but it could still be detected by looking at the end position, so this is not that big deal.) Thanks, Jan > w/o a dedicated field? > > Maurizio > > > > > On 02/10/17 16:35, Jan Lahoda wrote: >> Hello, >> >> JShell produces not ideal errors related to local variable type >> inference in some cases: >> --- >> jshell> var i = () -> {}; >> | Error: >> | incompatible types: java.lang.Object is not a functional interface >> | var i = () -> {}; >> | ^------^ >> --- >> >> Better would be: >> --- >> jshell> var i = () -> {}; >> | Error: >> | cannot infer type for local variable i >> | (lambda expression needs an explicit target-type) >> | var i = () -> {}; >> | ^---------------^ >> --- >> >> (which is the error produced by javac) >> >> The AST model could also be improved for local variables whose type >> have been inferred (which also improves the jshell errors in some cases): >> - for "var i = 0;", the VariableTree.getType() will be null even after >> attribution, but for: "for (var i : Arrays.asList(0, 1)) {}", the >> VariableTree.getType() will be filled in by Attr. (The inferred type >> is also filled in for lambda parameters.) This is not only >> inconsistent, but also Attr.PostAttrAnalyzer.visitVarDef may fill in >> the type with an ErroneousTree (with a wrong position). The proposal >> here is to always fill in the type for consistency, and to >> consistently use NOPOS for the synthetic type position >> >> -for "var i = 0;" SourcePositions.getStartPosition does not return a >> proper starting position (the position of "var"), but rather the >> position of the synthetic type, if any (which can also be >> ErroneousTree) or the position of the variable name. The proposal here >> is to remember the real start of the variable and return it. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8188225 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8188225/webrev.00/index.html >> >> What do you think? >> >> Thanks, >> Jan > From maurizio.cimadamore at oracle.com Tue Oct 3 17:58:56 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 3 Oct 2017 18:58:56 +0100 Subject: RFR JDK-8188225: AST could be improved in presence of var types. In-Reply-To: <59D3CEAA.5010302@oracle.com> References: <59D25CC5.5080809@oracle.com> <5ffd68fa-6455-b412-351f-54778be3cf4a@oracle.com> <59D3CEAA.5010302@oracle.com> Message-ID: On 03/10/17 18:53, Jan Lahoda wrote: > Hi Maurizio, > > Thanks for the comments - some responses inline. > > On 3.10.2017 17:59, Maurizio Cimadamore wrote: >> Thanks for taking care of this, I have a couple of suggestion: >> >> * the routine for generating synthetic type tree should be shared. E.g. >> you need a method that takes a type and generates something that is >> suitable for a local variable or a lambda parameter - e.g. >> >> toSyntheticTypeTree(Type t) { >> ??? if (t.isErroneous()) { >> ?????? return make.at(Position.NOPOS).Erroneous(); >> ??? } else { >> ?????? return make.at(Position.NOPOS).Type(t); >> ??? } >> } > > Sure, will do. > >> >> * secondly, while adding the startpos tree is fine - here it seems like >> we morally would like to override the getStartPosition for the synthetic >> type trees created above, so that the former position is returned (e.g. >> that of 'var'). So, I wonder if something like this could work: >> >> toSyntheticTypeTree(Type t, int preferredPos) { >> ??? if (t.isErroneous()) { >> ?????? return make.at(preferredPos).Erroneous(); >> ??? } else { >> ?????? return make.at(preferredPos).Type(t); >> ??? } >> } >> >> Then, assuming the parser creates the local variable node with the >> correct pos (which it doesn't now), I think everything should work even > > Hm, you mean put the starting position to the JCVariableDecl.pos? If > that would be the value, we could surely avoid the field, but AFAIK > the JCVariableDecl.pos usually points to the name of the variable, and > I didn't want to add an inconsistency, or change that (as the position > is useful for error reporting), > > Alternatives I was thinking of included playing tricks with modifiers > (setting the position to modifiers (if there are no/empty modifiers) > and filtering it in getStartPos), with nameexpr or having a subclass > of JCVariableDecl for vars which would include the extra field. I see good points. I also thought about using a tree copier, but that also goes through TreeMaker, which makes it hard to e.g. create anon tree instances which override getStartPosition. No bother - your original solution is good enough, at least for now. I appreciate that the new pos field is just for var AST nodes. Maurizio > > (I was also trying to have -1 as the position of the synthetic type to > aid its detection, but it could still be detected by looking at the > end position, so this is not that big deal.) > > Thanks, > ??? Jan > >> w/o a dedicated field? >> >> Maurizio >> >> >> >> >> On 02/10/17 16:35, Jan Lahoda wrote: >>> Hello, >>> >>> JShell produces not ideal errors related to local variable type >>> inference in some cases: >>> --- >>> jshell> var i = () -> {}; >>> |? Error: >>> |? incompatible types: java.lang.Object is not a functional interface >>> |? var i = () -> {}; >>> |????????? ^------^ >>> --- >>> >>> Better would be: >>> --- >>> jshell> var i = () -> {}; >>> |? Error: >>> |? cannot infer type for local variable i >>> |??? (lambda expression needs an explicit target-type) >>> |? var i = () -> {}; >>> |? ^---------------^ >>> --- >>> >>> (which is the error produced by javac) >>> >>> The AST model could also be improved for local variables whose type >>> have been inferred (which also improves the jshell errors in some >>> cases): >>> - for "var i = 0;", the VariableTree.getType() will be null even after >>> attribution, but for: "for (var i : Arrays.asList(0, 1)) {}", the >>> VariableTree.getType() will be filled in by Attr. (The inferred type >>> is also filled in for lambda parameters.) This is not only >>> inconsistent, but also Attr.PostAttrAnalyzer.visitVarDef may fill in >>> the type with an ErroneousTree (with a wrong position). The proposal >>> here is to always fill in the type for consistency, and to >>> consistently use NOPOS for the synthetic type position >>> >>> -for "var i = 0;" SourcePositions.getStartPosition does not return a >>> proper starting position (the position of "var"), but rather the >>> position of the synthetic type, if any (which can also be >>> ErroneousTree) or the position of the variable name. The proposal here >>> is to remember the real start of the variable and return it. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188225 >>> Webrev: >>> http://cr.openjdk.java.net/~jlahoda/8188225/webrev.00/index.html >>> >>> What do you think? >>> >>> Thanks, >>> ??? Jan >> From jan.lahoda at oracle.com Thu Oct 5 08:15:37 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 5 Oct 2017 10:15:37 +0200 Subject: RFR JDK-8188225: AST could be improved in presence of var types. In-Reply-To: References: <59D25CC5.5080809@oracle.com> <5ffd68fa-6455-b412-351f-54778be3cf4a@oracle.com> <59D3CEAA.5010302@oracle.com> Message-ID: <59D5EA29.4090305@oracle.com> Hi, An updated patch that has a method to generate the synthetic type trees is here: http://cr.openjdk.java.net/~jlahoda/8188225/webrev.01/ Thanks for any feedback, Jan On 3.10.2017 19:58, Maurizio Cimadamore wrote: > > > On 03/10/17 18:53, Jan Lahoda wrote: >> Hi Maurizio, >> >> Thanks for the comments - some responses inline. >> >> On 3.10.2017 17:59, Maurizio Cimadamore wrote: >>> Thanks for taking care of this, I have a couple of suggestion: >>> >>> * the routine for generating synthetic type tree should be shared. E.g. >>> you need a method that takes a type and generates something that is >>> suitable for a local variable or a lambda parameter - e.g. >>> >>> toSyntheticTypeTree(Type t) { >>> if (t.isErroneous()) { >>> return make.at(Position.NOPOS).Erroneous(); >>> } else { >>> return make.at(Position.NOPOS).Type(t); >>> } >>> } >> >> Sure, will do. >> >>> >>> * secondly, while adding the startpos tree is fine - here it seems like >>> we morally would like to override the getStartPosition for the synthetic >>> type trees created above, so that the former position is returned (e.g. >>> that of 'var'). So, I wonder if something like this could work: >>> >>> toSyntheticTypeTree(Type t, int preferredPos) { >>> if (t.isErroneous()) { >>> return make.at(preferredPos).Erroneous(); >>> } else { >>> return make.at(preferredPos).Type(t); >>> } >>> } >>> >>> Then, assuming the parser creates the local variable node with the >>> correct pos (which it doesn't now), I think everything should work even >> >> Hm, you mean put the starting position to the JCVariableDecl.pos? If >> that would be the value, we could surely avoid the field, but AFAIK >> the JCVariableDecl.pos usually points to the name of the variable, and >> I didn't want to add an inconsistency, or change that (as the position >> is useful for error reporting), >> >> Alternatives I was thinking of included playing tricks with modifiers >> (setting the position to modifiers (if there are no/empty modifiers) >> and filtering it in getStartPos), with nameexpr or having a subclass >> of JCVariableDecl for vars which would include the extra field. > I see good points. I also thought about using a tree copier, but that > also goes through TreeMaker, which makes it hard to e.g. create anon > tree instances which override getStartPosition. > > No bother - your original solution is good enough, at least for now. I > appreciate that the new pos field is just for var AST nodes. > > Maurizio >> >> (I was also trying to have -1 as the position of the synthetic type to >> aid its detection, but it could still be detected by looking at the >> end position, so this is not that big deal.) >> >> Thanks, >> Jan >> >>> w/o a dedicated field? >>> >>> Maurizio >>> >>> >>> >>> >>> On 02/10/17 16:35, Jan Lahoda wrote: >>>> Hello, >>>> >>>> JShell produces not ideal errors related to local variable type >>>> inference in some cases: >>>> --- >>>> jshell> var i = () -> {}; >>>> | Error: >>>> | incompatible types: java.lang.Object is not a functional interface >>>> | var i = () -> {}; >>>> | ^------^ >>>> --- >>>> >>>> Better would be: >>>> --- >>>> jshell> var i = () -> {}; >>>> | Error: >>>> | cannot infer type for local variable i >>>> | (lambda expression needs an explicit target-type) >>>> | var i = () -> {}; >>>> | ^---------------^ >>>> --- >>>> >>>> (which is the error produced by javac) >>>> >>>> The AST model could also be improved for local variables whose type >>>> have been inferred (which also improves the jshell errors in some >>>> cases): >>>> - for "var i = 0;", the VariableTree.getType() will be null even after >>>> attribution, but for: "for (var i : Arrays.asList(0, 1)) {}", the >>>> VariableTree.getType() will be filled in by Attr. (The inferred type >>>> is also filled in for lambda parameters.) This is not only >>>> inconsistent, but also Attr.PostAttrAnalyzer.visitVarDef may fill in >>>> the type with an ErroneousTree (with a wrong position). The proposal >>>> here is to always fill in the type for consistency, and to >>>> consistently use NOPOS for the synthetic type position >>>> >>>> -for "var i = 0;" SourcePositions.getStartPosition does not return a >>>> proper starting position (the position of "var"), but rather the >>>> position of the synthetic type, if any (which can also be >>>> ErroneousTree) or the position of the variable name. The proposal here >>>> is to remember the real start of the variable and return it. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188225 >>>> Webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8188225/webrev.00/index.html >>>> >>>> What do you think? >>>> >>>> Thanks, >>>> Jan >>> > From maurizio.cimadamore at oracle.com Thu Oct 5 15:44:18 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 5 Oct 2017 16:44:18 +0100 Subject: RFR JDK-8188225: AST could be improved in presence of var types. In-Reply-To: <59D5EA29.4090305@oracle.com> References: <59D25CC5.5080809@oracle.com> <5ffd68fa-6455-b412-351f-54778be3cf4a@oracle.com> <59D3CEAA.5010302@oracle.com> <59D5EA29.4090305@oracle.com> Message-ID: <98026a5b-0bf9-eb81-a55e-fb0db9092470@oracle.com> Looks good. Maurizio On 05/10/17 09:15, Jan Lahoda wrote: > Hi, > > An updated patch that has a method to generate the synthetic type > trees is here: > > http://cr.openjdk.java.net/~jlahoda/8188225/webrev.01/ > > Thanks for any feedback, > ??? Jan > > On 3.10.2017 19:58, Maurizio Cimadamore wrote: >> >> >> On 03/10/17 18:53, Jan Lahoda wrote: >>> Hi Maurizio, >>> >>> Thanks for the comments - some responses inline. >>> >>> On 3.10.2017 17:59, Maurizio Cimadamore wrote: >>>> Thanks for taking care of this, I have a couple of suggestion: >>>> >>>> * the routine for generating synthetic type tree should be shared. >>>> E.g. >>>> you need a method that takes a type and generates something that is >>>> suitable for a local variable or a lambda parameter - e.g. >>>> >>>> toSyntheticTypeTree(Type t) { >>>> ??? if (t.isErroneous()) { >>>> ?????? return make.at(Position.NOPOS).Erroneous(); >>>> ??? } else { >>>> ?????? return make.at(Position.NOPOS).Type(t); >>>> ??? } >>>> } >>> >>> Sure, will do. >>> >>>> >>>> * secondly, while adding the startpos tree is fine - here it seems >>>> like >>>> we morally would like to override the getStartPosition for the >>>> synthetic >>>> type trees created above, so that the former position is returned >>>> (e.g. >>>> that of 'var'). So, I wonder if something like this could work: >>>> >>>> toSyntheticTypeTree(Type t, int preferredPos) { >>>> ??? if (t.isErroneous()) { >>>> ?????? return make.at(preferredPos).Erroneous(); >>>> ??? } else { >>>> ?????? return make.at(preferredPos).Type(t); >>>> ??? } >>>> } >>>> >>>> Then, assuming the parser creates the local variable node with the >>>> correct pos (which it doesn't now), I think everything should work >>>> even >>> >>> Hm, you mean put the starting position to the JCVariableDecl.pos? If >>> that would be the value, we could surely avoid the field, but AFAIK >>> the JCVariableDecl.pos usually points to the name of the variable, and >>> I didn't want to add an inconsistency, or change that (as the position >>> is useful for error reporting), >>> >>> Alternatives I was thinking of included playing tricks with modifiers >>> (setting the position to modifiers (if there are no/empty modifiers) >>> and filtering it in getStartPos), with nameexpr or having a subclass >>> of JCVariableDecl for vars which would include the extra field. >> I see good points. I also thought about using a tree copier, but that >> also goes through TreeMaker, which makes it hard to e.g. create anon >> tree instances which override getStartPosition. >> >> No bother - your original solution is good enough, at least for now. I >> appreciate that the new pos field is just for var AST nodes. >> >> Maurizio >>> >>> (I was also trying to have -1 as the position of the synthetic type to >>> aid its detection, but it could still be detected by looking at the >>> end position, so this is not that big deal.) >>> >>> Thanks, >>> ??? Jan >>> >>>> w/o a dedicated field? >>>> >>>> Maurizio >>>> >>>> >>>> >>>> >>>> On 02/10/17 16:35, Jan Lahoda wrote: >>>>> Hello, >>>>> >>>>> JShell produces not ideal errors related to local variable type >>>>> inference in some cases: >>>>> --- >>>>> jshell> var i = () -> {}; >>>>> |? Error: >>>>> |? incompatible types: java.lang.Object is not a functional interface >>>>> |? var i = () -> {}; >>>>> |????????? ^------^ >>>>> --- >>>>> >>>>> Better would be: >>>>> --- >>>>> jshell> var i = () -> {}; >>>>> |? Error: >>>>> |? cannot infer type for local variable i >>>>> |??? (lambda expression needs an explicit target-type) >>>>> |? var i = () -> {}; >>>>> |? ^---------------^ >>>>> --- >>>>> >>>>> (which is the error produced by javac) >>>>> >>>>> The AST model could also be improved for local variables whose type >>>>> have been inferred (which also improves the jshell errors in some >>>>> cases): >>>>> - for "var i = 0;", the VariableTree.getType() will be null even >>>>> after >>>>> attribution, but for: "for (var i : Arrays.asList(0, 1)) {}", the >>>>> VariableTree.getType() will be filled in by Attr. (The inferred type >>>>> is also filled in for lambda parameters.) This is not only >>>>> inconsistent, but also Attr.PostAttrAnalyzer.visitVarDef may fill in >>>>> the type with an ErroneousTree (with a wrong position). The proposal >>>>> here is to always fill in the type for consistency, and to >>>>> consistently use NOPOS for the synthetic type position >>>>> >>>>> -for "var i = 0;" SourcePositions.getStartPosition does not return a >>>>> proper starting position (the position of "var"), but rather the >>>>> position of the synthetic type, if any (which can also be >>>>> ErroneousTree) or the position of the variable name. The proposal >>>>> here >>>>> is to remember the real start of the variable and return it. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188225 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~jlahoda/8188225/webrev.00/index.html >>>>> >>>>> What do you think? >>>>> >>>>> Thanks, >>>>> ??? Jan >>>> >> From jan.lahoda at oracle.com Wed Oct 11 14:45:57 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 11 Oct 2017 16:45:57 +0200 Subject: RFR: JDK-8186694: JShell: speed-up compilation by reusing compiler instances In-Reply-To: References: <59A5C776.9090209@oracle.com> <59A5CA7D.5070304@oracle.com> <59A7D35E.8090102@oracle.com> <9a6dc679-7ff2-9984-58e4-b9f6ba3bec2c@oracle.com> <59A950DE.6060206@oracle.com> Message-ID: <59DE2EA5.4090803@oracle.com> I've updated the patch to the consolidated repository and to the LVTI changes, webrev is available here: http://cr.openjdk.java.net/~jlahoda/8186694/webrev.03/ The only significant change should be use of TaskListener instead of a subclass of com.sun.tools.javac.main.JavaCompiler to fix the intersection types. Is this still OK? Thanks, Jan On 1.9.2017 17:57, Maurizio Cimadamore wrote: > I like this - ship it! > > Thanks > Maurizio > > > On 01/09/17 13:21, Jan Lahoda wrote: >> Hi, >> >> Thanks. I've updated the patch so that the pool (and both JShell and >> tests) take a worker and the tasks are only valid while the worker is >> running: >> >> http://cr.openjdk.java.net/~jlahoda/8186694/webrev.02/ >> >> What do you think? >> >> Thanks, >> Jan >> >> On 31.8.2017 16:17, Maurizio Cimadamore wrote: >>> Looks better, thanks. >>> >>> On the issue of getTask/returnTask, I think that either a >>> lambda-accepting method or a TWR approach would be good in enforcing the >>> 'right' idiom. Another alternative would be to return a task which >>> overrides the parse()/analze()... methods so that the returnTask logic >>> is called at the end. But that seems weaker than the lambda based >>> approach. >>> >>> I'm not too worried w.r.t. inconsistencies with the JavaCompiler.getTask >>> because (i) even having a pair of methods is inconsistent with that API >>> and (ii) JavacPoolTask represents a pool of compilation tasks, so I'm >>> not sure it has to be 100% consistent with what's done in JavaCompiler. >>> >>> Updating the clients would probably be the biggest chunk of work, so I >>> leave with you as to whether this should be addressed. My sense is that >>> some of the jshell clients have already changes because of this (with >>> try/finally, so adding a method call with a lambda would probably be >>> rather similar). But combo tests would also need same treatment (e.g. >>> ComboInstance::newCompilationTask should probably become a >>> lambda-accepting ComboInstance::withCompilatonTask). >>> >>> Maurizio >>> >>> >>> On 31/08/17 10:14, Jan Lahoda wrote: >>>> Thanks for the comments so far. >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8186694/webrev.01/ >>>> >>>> I've moved the class to the javac.api package as suggested, and did >>>> more changes as noted below. >>>> >>>> One of the additional changes is a Scope related fix to TypeEnter and >>>> corresponding ScopeClassHeaderTest.java test, which is mostly >>>> independent to the rest of this patch, and I can split that out. (Some >>>> of the fixes in this webrev caused this bug was revealed.) >>>> >>>> On 30.8.2017 12:43, Maurizio Cimadamore wrote: >>>>> Good work, some comments: >>>>> >>>>> * in the combo test API, who is calling returnTask()? >>>> >>>> Ooops. Fixed (when a new task is to be issued, the previous one is >>>> closed). >>>> >>>>> >>>>> * would it make sense to use try with resources for JavacPoolTask and >>>>> jshell AnalyzeTask, to minimize chances of errors? >>>> >>>> Makes sense, done. >>>> >>>>> >>>>> * not sure about the getTask/returnTask handshake - the logic seems to >>>>> work in this way: >>>>> >>>>> - when a new task is requested, you check the caches, and if a context >>>>> is there (with given options) you return it, otherwise you create a >>>>> fresh one >>>>> - when a task is returned, if it's not polluted, you add it to the >>>>> caches. Then you need to trim the caches to make sure there's room for >>>>> the new context >>>> >>>> Yes, that's the intent. >>>> >>>>> >>>>> We badly miss a circular queue here (not a fault of this patch of >>>>> course >>>>> :-)). >>>>> >>>>> If we could reduce the state to the options2Context map, then we could >>>>> probably use a CHM and get rid of synchronized block. >>>>> >>>>> Even w/ synchronized map, it seems like 'pool' is only used to get at >>>>> the first cached context, so maybe a simple field (which you >>>>> overwrite) >>>>> might suffice? >>>> >>>> I've got rid of the pool field. But not sure if the code can be >>>> rewritten to CHM - might be safer to simply use a simple synchronized >>>> block. >>>> >>>>> >>>>> More generally, I tend to view pair of coupled methods such as >>>>> getTask/returnTask as suspicious and error prone (in case somebody >>>>> forgets to call the second method) - so I tend to try to avoid writing >>>>> such APIs unless absolutely necessary - here I'm not 100% on why >>>>> this is >>>>> necessary... on the one hand I get the desire of knowing when a client >>>>> is done with a task, on the other hand there's nothing stopping the >>>>> same >>>>> client from keep using same task after returning it, so... >>>> >>>> In principle I agree having a pair of methods can lead to errors. But >>>> the error here is that a Context won't be reused, which just should >>>> mean things will be somewhat slower, but the results should be OK. I >>>> can see there are some options, but I am not sure if they are better: >>>> a) when asked for a task, we could simply reuse the last Context, >>>> without checking if the previous user is finished with that. (This is >>>> what the tests are doing now.) I think this was OK for tests, and >>>> might work for JShell as well. But if the previous user would be still >>>> using the Context, the outcomes are hardly predictable (can lead to >>>> surprising broken results). So in JShell, each time we would create a >>>> new task, we would need to ask ourselves if there's another task >>>> currently in use. So this seems like complicating maintenance. >>>> >>>> b) make the tasks only available inside a worker method. Like: >>>> Z getTask(, Function worker) { >>>> ... >>>> } >>>> >>>> the task is only valid while "worker" is running. This is safer, as >>>> one cannot forget to close the task. (And I rewrote JShell to do this >>>> as an experiment.) But not sure if this is not too complex as this >>>> means significant changes to the callers, and is also inconsistent >>>> with JavaCompiler.getTask. >>>> >>>> Jan >>>> >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> On 29/08/17 21:11, Jonathan Gibbons wrote: >>>>>> I don't think JavacTaskPool belongs in the javac.util package. >>>>>> >>>>>> Unless there are good reasons for doing otherwise, how about using >>>>>> javac.api instead ... i..e closed to JavacTaskImpl and friend. >>>>>> >>>>>> -- Jon >>>>>> >>>>>> >>>>>> On 08/29/2017 12:58 PM, Jan Lahoda wrote: >>>>>>> Hello, >>>>>>> >>>>>>> When starting jshell like this (where "/tmp/script" is a file which >>>>>>> has just "/exit"): >>>>>>> $ jshell PRINTING --execution local /tmp/script >>>>>>> >>>>>>> It currently takes approx. 5-6s on my laptop. PRINTING will add >>>>>>> quite >>>>>>> a few startup snippets. Each of these snippets is processed >>>>>>> separately and needs several instances of javac to be created to be >>>>>>> processed correctly. >>>>>>> >>>>>>> So, the idea in this patch is to reuse the javac instances multiple >>>>>>> (many) times. This avoids initializing the javac instances just to >>>>>>> process a very small ("single line") input. >>>>>>> >>>>>>> This patch is based on the ReusableContext by Maurizio used in >>>>>>> tests. >>>>>>> The ReusableContext handling is wrapped in JavacTaskPool, which >>>>>>> keeps >>>>>>> the ReusableContext and issues JavacTask possibly based on a reused >>>>>>> Context. The pool is not currently general purpose, but should work >>>>>>> for tests for which ReusableContext worked and for JShell. >>>>>>> >>>>>>> One tricky thing is that in JShell, it is necessary to prune >>>>>>> everything in the "REPL" package when reusing the Context, as it is >>>>>>> necessary to reload the correct/updated classes again from the file >>>>>>> manager (this is achieved by additional cleaning in TaskFactory). >>>>>>> >>>>>>> Overall, with this patch, the time to execute the above command is >>>>>>> approx. 2.5s >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186694 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8186694/webrev.00/ >>>>>>> >>>>>>> How does this look? >>>>>>> >>>>>>> Thanks, >>>>>>> Jan >>>>>> >>>>> >>> > From robert.field at oracle.com Wed Oct 11 22:22:17 2017 From: robert.field at oracle.com (Robert Field) Date: Wed, 11 Oct 2017 15:22:17 -0700 Subject: RFR: JDK-8186694: JShell: speed-up compilation by reusing compiler instances In-Reply-To: <59DE2EA5.4090803@oracle.com> References: <59A5C776.9090209@oracle.com> <59A5CA7D.5070304@oracle.com> <59A7D35E.8090102@oracle.com> <9a6dc679-7ff2-9984-58e4-b9f6ba3bec2c@oracle.com> <59A950DE.6060206@oracle.com> <59DE2EA5.4090803@oracle.com> Message-ID: <59DE9999.9020608@oracle.com> Fine by me. But you probably want compiler folk review... -Robert On 10/11/17 07:45, Jan Lahoda wrote: > I've updated the patch to the consolidated repository and to the LVTI > changes, webrev is available here: > http://cr.openjdk.java.net/~jlahoda/8186694/webrev.03/ > > The only significant change should be use of TaskListener instead of a > subclass of com.sun.tools.javac.main.JavaCompiler to fix the > intersection types. > > Is this still OK? > > Thanks, > Jan > > On 1.9.2017 17:57, Maurizio Cimadamore wrote: >> I like this - ship it! >> >> Thanks >> Maurizio >> >> >> On 01/09/17 13:21, Jan Lahoda wrote: >>> Hi, >>> >>> Thanks. I've updated the patch so that the pool (and both JShell and >>> tests) take a worker and the tasks are only valid while the worker is >>> running: >>> >>> http://cr.openjdk.java.net/~jlahoda/8186694/webrev.02/ >>> >>> What do you think? >>> >>> Thanks, >>> Jan >>> >>> On 31.8.2017 16:17, Maurizio Cimadamore wrote: >>>> Looks better, thanks. >>>> >>>> On the issue of getTask/returnTask, I think that either a >>>> lambda-accepting method or a TWR approach would be good in >>>> enforcing the >>>> 'right' idiom. Another alternative would be to return a task which >>>> overrides the parse()/analze()... methods so that the returnTask logic >>>> is called at the end. But that seems weaker than the lambda based >>>> approach. >>>> >>>> I'm not too worried w.r.t. inconsistencies with the >>>> JavaCompiler.getTask >>>> because (i) even having a pair of methods is inconsistent with that >>>> API >>>> and (ii) JavacPoolTask represents a pool of compilation tasks, so I'm >>>> not sure it has to be 100% consistent with what's done in >>>> JavaCompiler. >>>> >>>> Updating the clients would probably be the biggest chunk of work, so I >>>> leave with you as to whether this should be addressed. My sense is >>>> that >>>> some of the jshell clients have already changes because of this (with >>>> try/finally, so adding a method call with a lambda would probably be >>>> rather similar). But combo tests would also need same treatment (e.g. >>>> ComboInstance::newCompilationTask should probably become a >>>> lambda-accepting ComboInstance::withCompilatonTask). >>>> >>>> Maurizio >>>> >>>> >>>> On 31/08/17 10:14, Jan Lahoda wrote: >>>>> Thanks for the comments so far. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~jlahoda/8186694/webrev.01/ >>>>> >>>>> I've moved the class to the javac.api package as suggested, and did >>>>> more changes as noted below. >>>>> >>>>> One of the additional changes is a Scope related fix to TypeEnter and >>>>> corresponding ScopeClassHeaderTest.java test, which is mostly >>>>> independent to the rest of this patch, and I can split that out. >>>>> (Some >>>>> of the fixes in this webrev caused this bug was revealed.) >>>>> >>>>> On 30.8.2017 12:43, Maurizio Cimadamore wrote: >>>>>> Good work, some comments: >>>>>> >>>>>> * in the combo test API, who is calling returnTask()? >>>>> >>>>> Ooops. Fixed (when a new task is to be issued, the previous one is >>>>> closed). >>>>> >>>>>> >>>>>> * would it make sense to use try with resources for JavacPoolTask >>>>>> and >>>>>> jshell AnalyzeTask, to minimize chances of errors? >>>>> >>>>> Makes sense, done. >>>>> >>>>>> >>>>>> * not sure about the getTask/returnTask handshake - the logic >>>>>> seems to >>>>>> work in this way: >>>>>> >>>>>> - when a new task is requested, you check the caches, and if a >>>>>> context >>>>>> is there (with given options) you return it, otherwise you create a >>>>>> fresh one >>>>>> - when a task is returned, if it's not polluted, you add it to the >>>>>> caches. Then you need to trim the caches to make sure there's >>>>>> room for >>>>>> the new context >>>>> >>>>> Yes, that's the intent. >>>>> >>>>>> >>>>>> We badly miss a circular queue here (not a fault of this patch of >>>>>> course >>>>>> :-)). >>>>>> >>>>>> If we could reduce the state to the options2Context map, then we >>>>>> could >>>>>> probably use a CHM and get rid of synchronized block. >>>>>> >>>>>> Even w/ synchronized map, it seems like 'pool' is only used to >>>>>> get at >>>>>> the first cached context, so maybe a simple field (which you >>>>>> overwrite) >>>>>> might suffice? >>>>> >>>>> I've got rid of the pool field. But not sure if the code can be >>>>> rewritten to CHM - might be safer to simply use a simple synchronized >>>>> block. >>>>> >>>>>> >>>>>> More generally, I tend to view pair of coupled methods such as >>>>>> getTask/returnTask as suspicious and error prone (in case somebody >>>>>> forgets to call the second method) - so I tend to try to avoid >>>>>> writing >>>>>> such APIs unless absolutely necessary - here I'm not 100% on why >>>>>> this is >>>>>> necessary... on the one hand I get the desire of knowing when a >>>>>> client >>>>>> is done with a task, on the other hand there's nothing stopping the >>>>>> same >>>>>> client from keep using same task after returning it, so... >>>>> >>>>> In principle I agree having a pair of methods can lead to errors. But >>>>> the error here is that a Context won't be reused, which just should >>>>> mean things will be somewhat slower, but the results should be OK. I >>>>> can see there are some options, but I am not sure if they are better: >>>>> a) when asked for a task, we could simply reuse the last Context, >>>>> without checking if the previous user is finished with that. (This is >>>>> what the tests are doing now.) I think this was OK for tests, and >>>>> might work for JShell as well. But if the previous user would be >>>>> still >>>>> using the Context, the outcomes are hardly predictable (can lead to >>>>> surprising broken results). So in JShell, each time we would create a >>>>> new task, we would need to ask ourselves if there's another task >>>>> currently in use. So this seems like complicating maintenance. >>>>> >>>>> b) make the tasks only available inside a worker method. Like: >>>>> Z getTask(, Function worker) { >>>>> ... >>>>> } >>>>> >>>>> the task is only valid while "worker" is running. This is safer, as >>>>> one cannot forget to close the task. (And I rewrote JShell to do this >>>>> as an experiment.) But not sure if this is not too complex as this >>>>> means significant changes to the callers, and is also inconsistent >>>>> with JavaCompiler.getTask. >>>>> >>>>> Jan >>>>> >>>>>> >>>>>> Maurizio >>>>>> >>>>>> >>>>>> On 29/08/17 21:11, Jonathan Gibbons wrote: >>>>>>> I don't think JavacTaskPool belongs in the javac.util package. >>>>>>> >>>>>>> Unless there are good reasons for doing otherwise, how about using >>>>>>> javac.api instead ... i..e closed to JavacTaskImpl and friend. >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> >>>>>>> On 08/29/2017 12:58 PM, Jan Lahoda wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> When starting jshell like this (where "/tmp/script" is a file >>>>>>>> which >>>>>>>> has just "/exit"): >>>>>>>> $ jshell PRINTING --execution local /tmp/script >>>>>>>> >>>>>>>> It currently takes approx. 5-6s on my laptop. PRINTING will add >>>>>>>> quite >>>>>>>> a few startup snippets. Each of these snippets is processed >>>>>>>> separately and needs several instances of javac to be created >>>>>>>> to be >>>>>>>> processed correctly. >>>>>>>> >>>>>>>> So, the idea in this patch is to reuse the javac instances >>>>>>>> multiple >>>>>>>> (many) times. This avoids initializing the javac instances just to >>>>>>>> process a very small ("single line") input. >>>>>>>> >>>>>>>> This patch is based on the ReusableContext by Maurizio used in >>>>>>>> tests. >>>>>>>> The ReusableContext handling is wrapped in JavacTaskPool, which >>>>>>>> keeps >>>>>>>> the ReusableContext and issues JavacTask possibly based on a >>>>>>>> reused >>>>>>>> Context. The pool is not currently general purpose, but should >>>>>>>> work >>>>>>>> for tests for which ReusableContext worked and for JShell. >>>>>>>> >>>>>>>> One tricky thing is that in JShell, it is necessary to prune >>>>>>>> everything in the "REPL" package when reusing the Context, as >>>>>>>> it is >>>>>>>> necessary to reload the correct/updated classes again from the >>>>>>>> file >>>>>>>> manager (this is achieved by additional cleaning in TaskFactory). >>>>>>>> >>>>>>>> Overall, with this patch, the time to execute the above command is >>>>>>>> approx. 2.5s >>>>>>>> >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186694 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8186694/webrev.00/ >>>>>>>> >>>>>>>> How does this look? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jan >>>>>>> >>>>>> >>>> >> From robert.field at oracle.com Sat Oct 14 21:09:00 2017 From: robert.field at oracle.com (Robert Field) Date: Sat, 14 Oct 2017 14:09:00 -0700 Subject: RFR 8187359: JShell: Give comprehensible error when user method name matches Object method In-Reply-To: <59B83A87.4070503@oracle.com> References: <59B22CE3.2010609@oracle.com> <59B83A87.4070503@oracle.com> Message-ID: <59E27CEC.1040205@oracle.com> Thanks Jan! Coming back to this, post repo consolidation, I see this is unnecessarily restrictive, the error occurs only when the signatures match as well. Ideally we want users to never see this error, so making it less common is good. I've changed the new error to only appear when it would have failed (with a confusing error). Now methods like: boolean equals(foo f1, Foo f2) ... would be allowed. The code remains the same in concept but is distributed differently -- switching out diagnostics after compilation. And a corresponding update and additions to the tests. Updated webrev: http://cr.openjdk.java.net/~rfield/8187359v3.webrev/ -Robert On 09/12/17 12:50, Jan Lahoda wrote: > Seems OK. > > Jan > > On 8.9.2017 07:38, Robert Field wrote: >> Please review. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8187359 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8187359v0.webrev/ >> >> Thanks, >> Robert >> From robert.field at oracle.com Mon Oct 16 07:18:58 2017 From: robert.field at oracle.com (Robert Field) Date: Mon, 16 Oct 2017 00:18:58 -0700 Subject: RFR 8179856: jshell tool: not suitable for pipeline use In-Reply-To: <59BBA20D.3080304@oracle.com> References: <599E579B.1020900@oracle.com> <59B657C6.1090809@oracle.com> <59B6BB47.6050605@oracle.com> <59B8018A.9070809@oracle.com> <80E15A95-A294-495A-B8D8-AC524C928B03@oracle.com> <59B89546.1080705@oracle.com> <59BBA20D.3080304@oracle.com> Message-ID: <59E45D62.2080801@oracle.com> Thanks Jan! During CSR review, John pointed out problems with the --help text (suggesting an alternative) and one case where fluff (informative non-essential information) is printed for a load file (including "-") and the fluff is wrong (for load files). The new webrev is here: http://cr.openjdk.java.net/~rfield/8179856v5.webrev/ But all that changed is the --help output, instead of my poorly crafted words, now ends with: A file argument may be a file name, or one of the predefined file names: DEFAULT, PRINTING, or JAVASE. A load file may also be "-" to indicate standard input, without interactive I/O. And on unexpected termination, the output has been broken into two parts: jshell.msg.terminated = State engine terminated. jshell.msg.terminated.restore = Restore definitions with: /reload -restore The latter is now printed as fluff (and thus not showing up for load files or quiet feedback modes): shutdownSubscription = state.onShutdown((JShell deadState) -> { if (deadState == state) { hardmsg("jshell.msg.terminated"); + fluffmsg("jshell.msg.terminated.restore"); live = false; } }); And, of course, the test files are in their new post-consolidation locations. Thanks, Robert On 09/15/17 02:49, Jan Lahoda wrote: > Seems OK to me. > > Jan > > On 13.9.2017 04:17, Robert Field wrote: >> Please review updated webrev (now uses file "-" rather than option >> "--pipe") -- >> >> Bugs: >> >> 8179856: jshell tool: not suitable for pipeline use >> https://bugs.openjdk.java.net/browse/JDK-8179856 >> >> 8186708: jshell tool: bad load file garbles message and does not >> abort >> https://bugs.openjdk.java.net/browse/JDK-8186708 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8179856v2.webrev/ >> >> Thanks, >> Robert >> >> >> On 09/12/17 12:53, Robert Field wrote: >>> I like it! >>> >>> Both because it is clean and a standard. >>> I agree that considering stdin exhausted (so exiting after) makes >>> sense. >>> >>> It will mean somewhat of a rewrite, but that?s fine. >>> >>> I?ll redo and send out. >>> >>> -Robert >>> >>>> On Sep 12, 2017, at 8:47 AM, Jan Lahoda wrote: >>>> >>>> What would happen if we processed "-" (stdin) as a file? One >>>> difference I see is that after processing the files, the interactive >>>> shell is started unless there is an explicit /exit in the files. But >>>> given we have already processed the stdin, it would seem OK to me to >>>> not start the interactive part (there's an EOF at the end of the >>>> stdin, I assume, which for stdin could be seen as an explicit /exit). >>>> >>>> I also tried bash: >>>> $ echo 'echo X' | bash - >>>> X >>>> >>>> Jan >>>> >>>> On 11.9.2017 18:35, Robert Field wrote: >>>>> On 09/11/17 02:30, Jan Lahoda wrote: >>>>>> Hi Robert, >>>>>> >>>>>> Overall seems OK to me. One question: why use "--pipe" instead of >>>>>> simply "-" (which is AFAIK common option for "read stdin")? >>>>> From Linux "cat" ----- >>>>> >>>>> SYNOPSIS >>>>> cat [OPTION]... [FILE]... >>>>> >>>>> DESCRIPTION >>>>> ... >>>>> >>>>> With no FILE, or when FILE is -, read standard input. >>>>> >>>>> EXAMPLES >>>>> cat f - g >>>>> Output f's contents, then standard input, then g's >>>>> contents. >>>>> >>>>> cat Copy standard input to standard output. >>>>> >>>>> ------------ >>>>> >>>>> The jshell tool always reads from standard in (unless somehow >>>>> aborted). >>>>> This "--pipe" argument is an option, whereas "-" in the *nix world >>>>> is a >>>>> file. >>>>> >>>>> The option does not change what is read, but how it is processed. >>>>> >>>>> But maybe that is too pedantic, and it still the natural choice. >>>>> >>>>> Thoughts? >>>>> >>>>> -Robert >>>>> >>>>> >>>>>> Jan >>>>>> >>>>>> On 24.8.2017 06:35, Robert Field wrote: >>>>>>> Please review -- >>>>>>> >>>>>>> Bugs: >>>>>>> >>>>>>> 8179856: jshell tool: not suitable for pipeline use >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179856 >>>>>>> >>>>>>> 8186708: jshell tool: bad load file garbles message and >>>>>>> does not >>>>>>> abort >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186708 >>>>>>> >>>>>>> Webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~rfield/8179856v1.webrev/ >>>>>>> >>>>>>> Thanks, >>>>>>> Robert >>>>>>> >> From maurizio.cimadamore at oracle.com Mon Oct 16 13:10:29 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 16 Oct 2017 14:10:29 +0100 Subject: RFR: JDK-8186694: JShell: speed-up compilation by reusing compiler instances In-Reply-To: <59DE2EA5.4090803@oracle.com> References: <59A5C776.9090209@oracle.com> <59A5CA7D.5070304@oracle.com> <59A7D35E.8090102@oracle.com> <9a6dc679-7ff2-9984-58e4-b9f6ba3bec2c@oracle.com> <59A950DE.6060206@oracle.com> <59DE2EA5.4090803@oracle.com> Message-ID: <627b6431-c12d-aff6-8745-132c955148f0@oracle.com> Looks good Maurizio On 11/10/17 15:45, Jan Lahoda wrote: > I've updated the patch to the consolidated repository and to the LVTI > changes, webrev is available here: > http://cr.openjdk.java.net/~jlahoda/8186694/webrev.03/ > > The only significant change should be use of TaskListener instead of a > subclass of com.sun.tools.javac.main.JavaCompiler to fix the > intersection types. > > Is this still OK? > > Thanks, > ??? Jan > > On 1.9.2017 17:57, Maurizio Cimadamore wrote: >> I like this - ship it! >> >> Thanks >> Maurizio >> >> >> On 01/09/17 13:21, Jan Lahoda wrote: >>> Hi, >>> >>> Thanks. I've updated the patch so that the pool (and both JShell and >>> tests) take a worker and the tasks are only valid while the worker is >>> running: >>> >>> http://cr.openjdk.java.net/~jlahoda/8186694/webrev.02/ >>> >>> What do you think? >>> >>> Thanks, >>> ??? Jan >>> >>> On 31.8.2017 16:17, Maurizio Cimadamore wrote: >>>> Looks better, thanks. >>>> >>>> On the issue of getTask/returnTask, I think that either a >>>> lambda-accepting method or a TWR approach would be good in >>>> enforcing the >>>> 'right' idiom. Another alternative would be to return a task which >>>> overrides the parse()/analze()... methods so that the returnTask logic >>>> is called at the end. But that seems weaker than the lambda based >>>> approach. >>>> >>>> I'm not too worried w.r.t. inconsistencies with the >>>> JavaCompiler.getTask >>>> because (i) even having a pair of methods is inconsistent with that >>>> API >>>> and (ii) JavacPoolTask represents a pool of compilation tasks, so I'm >>>> not sure it has to be 100% consistent with what's done in >>>> JavaCompiler. >>>> >>>> Updating the clients would probably be the biggest chunk of work, so I >>>> leave with you as to whether this should be addressed. My sense is >>>> that >>>> some of the jshell clients have already changes because of this (with >>>> try/finally, so adding a method call with a lambda would probably be >>>> rather similar). But combo tests would also need same treatment (e.g. >>>> ComboInstance::newCompilationTask should probably become a >>>> lambda-accepting ComboInstance::withCompilatonTask). >>>> >>>> Maurizio >>>> >>>> >>>> On 31/08/17 10:14, Jan Lahoda wrote: >>>>> Thanks for the comments so far. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~jlahoda/8186694/webrev.01/ >>>>> >>>>> I've moved the class to the javac.api package as suggested, and did >>>>> more changes as noted below. >>>>> >>>>> One of the additional changes is a Scope related fix to TypeEnter and >>>>> corresponding ScopeClassHeaderTest.java test, which is mostly >>>>> independent to the rest of this patch, and I can split that out. >>>>> (Some >>>>> of the fixes in this webrev caused this bug was revealed.) >>>>> >>>>> On 30.8.2017 12:43, Maurizio Cimadamore wrote: >>>>>> Good work, some comments: >>>>>> >>>>>> * in the combo test API, who is calling returnTask()? >>>>> >>>>> Ooops. Fixed (when a new task is to be issued, the previous one is >>>>> closed). >>>>> >>>>>> >>>>>> * would it make sense to use try with resources for JavacPoolTask >>>>>> and >>>>>> jshell AnalyzeTask, to minimize chances of errors? >>>>> >>>>> Makes sense, done. >>>>> >>>>>> >>>>>> * not sure about the getTask/returnTask handshake - the logic >>>>>> seems to >>>>>> work in this way: >>>>>> >>>>>> - when a new task is requested, you check the caches, and if a >>>>>> context >>>>>> is there (with given options) you return it, otherwise you create a >>>>>> fresh one >>>>>> - when a task is returned, if it's not polluted, you add it to the >>>>>> caches. Then you need to trim the caches to make sure there's >>>>>> room for >>>>>> the new context >>>>> >>>>> Yes, that's the intent. >>>>> >>>>>> >>>>>> We badly miss a circular queue here (not a fault of this patch of >>>>>> course >>>>>> :-)). >>>>>> >>>>>> If we could reduce the state to the options2Context map, then we >>>>>> could >>>>>> probably use a CHM and get rid of synchronized block. >>>>>> >>>>>> Even w/ synchronized map, it seems like 'pool' is only used to >>>>>> get at >>>>>> the first cached context, so maybe a simple field (which you >>>>>> overwrite) >>>>>> might suffice? >>>>> >>>>> I've got rid of the pool field. But not sure if the code can be >>>>> rewritten to CHM - might be safer to simply use a simple synchronized >>>>> block. >>>>> >>>>>> >>>>>> More generally, I tend to view pair of coupled methods such as >>>>>> getTask/returnTask as suspicious and error prone (in case somebody >>>>>> forgets to call the second method) - so I tend to try to avoid >>>>>> writing >>>>>> such APIs unless absolutely necessary - here I'm not 100% on why >>>>>> this is >>>>>> necessary... on the one hand I get the desire of knowing when a >>>>>> client >>>>>> is done with a task, on the other hand there's nothing stopping the >>>>>> same >>>>>> client from keep using same task after returning it, so... >>>>> >>>>> In principle I agree having a pair of methods can lead to errors. But >>>>> the error here is that a Context won't be reused, which just should >>>>> mean things will be somewhat slower, but the results should be OK. I >>>>> can see there are some options, but I am not sure if they are better: >>>>> a) when asked for a task, we could simply reuse the last Context, >>>>> without checking if the previous user is finished with that. (This is >>>>> what the tests are doing now.) I think this was OK for tests, and >>>>> might work for JShell as well. But if the previous user would be >>>>> still >>>>> using the Context, the outcomes are hardly predictable (can lead to >>>>> surprising broken results). So in JShell, each time we would create a >>>>> new task, we would need to ask ourselves if there's another task >>>>> currently in use. So this seems like complicating maintenance. >>>>> >>>>> b) make the tasks only available inside a worker method. Like: >>>>> Z getTask(, Function worker) { >>>>> ... >>>>> } >>>>> >>>>> the task is only valid while "worker" is running. This is safer, as >>>>> one cannot forget to close the task. (And I rewrote JShell to do this >>>>> as an experiment.) But not sure if this is not too complex as this >>>>> means significant changes to the callers, and is also inconsistent >>>>> with JavaCompiler.getTask. >>>>> >>>>> Jan >>>>> >>>>>> >>>>>> Maurizio >>>>>> >>>>>> >>>>>> On 29/08/17 21:11, Jonathan Gibbons wrote: >>>>>>> I don't think JavacTaskPool belongs in the javac.util package. >>>>>>> >>>>>>> Unless there are good reasons for doing otherwise, how about using >>>>>>> javac.api instead ... i..e closed to JavacTaskImpl and friend. >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> >>>>>>> On 08/29/2017 12:58 PM, Jan Lahoda wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> When starting jshell like this (where "/tmp/script" is a file >>>>>>>> which >>>>>>>> has just "/exit"): >>>>>>>> $ jshell PRINTING --execution local /tmp/script >>>>>>>> >>>>>>>> It currently takes approx. 5-6s on my laptop. PRINTING will add >>>>>>>> quite >>>>>>>> a few startup snippets. Each of these snippets is processed >>>>>>>> separately and needs several instances of javac to be created >>>>>>>> to be >>>>>>>> processed correctly. >>>>>>>> >>>>>>>> So, the idea in this patch is to reuse the javac instances >>>>>>>> multiple >>>>>>>> (many) times. This avoids initializing the javac instances just to >>>>>>>> process a very small ("single line") input. >>>>>>>> >>>>>>>> This patch is based on the ReusableContext by Maurizio used in >>>>>>>> tests. >>>>>>>> The ReusableContext handling is wrapped in JavacTaskPool, which >>>>>>>> keeps >>>>>>>> the ReusableContext and issues JavacTask possibly based on a >>>>>>>> reused >>>>>>>> Context. The pool is not currently general purpose, but should >>>>>>>> work >>>>>>>> for tests for which ReusableContext worked and for JShell. >>>>>>>> >>>>>>>> One tricky thing is that in JShell, it is necessary to prune >>>>>>>> everything in the "REPL" package when reusing the Context, as >>>>>>>> it is >>>>>>>> necessary to reload the correct/updated classes again from the >>>>>>>> file >>>>>>>> manager (this is achieved by additional cleaning in TaskFactory). >>>>>>>> >>>>>>>> Overall, with this patch, the time to execute the above command is >>>>>>>> approx. 2.5s >>>>>>>> >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186694 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8186694/webrev.00/ >>>>>>>> >>>>>>>> How does this look? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> ??? Jan >>>>>>> >>>>>> >>>> >> From jan.lahoda at oracle.com Thu Oct 19 15:25:16 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 19 Oct 2017 17:25:16 +0200 Subject: RFR 8179856: jshell tool: not suitable for pipeline use In-Reply-To: <59E45D62.2080801@oracle.com> References: <599E579B.1020900@oracle.com> <59B657C6.1090809@oracle.com> <59B6BB47.6050605@oracle.com> <59B8018A.9070809@oracle.com> <80E15A95-A294-495A-B8D8-AC524C928B03@oracle.com> <59B89546.1080705@oracle.com> <59BBA20D.3080304@oracle.com> <59E45D62.2080801@oracle.com> Message-ID: <59E8C3DC.6050202@oracle.com> Looking at l10n.properties, isn't the --help-extra text duplicated? -\ --help-extra, -X Print help on non-standard options and exit\n +\ --help-extra, -X Print help on non-standard options and exit\n\ +\ --help-extra, -X Print help on non-standard options and exit\n\ Otherwise looks OK, no need to another review. Jan On 16.10.2017 09:18, Robert Field wrote: > Thanks Jan! > > During CSR review, John pointed out problems with the --help text > (suggesting an alternative) and one case where fluff (informative > non-essential information) is printed for a load file (including "-") > and the fluff is wrong (for load files). > > The new webrev is here: > > http://cr.openjdk.java.net/~rfield/8179856v5.webrev/ > > But all that changed is the --help output, instead of my poorly crafted > words, now ends with: > > A file argument may be a file name, or one of the predefined file > names: DEFAULT, > PRINTING, or JAVASE. > A load file may also be "-" to indicate standard input, without > interactive I/O. > > And on unexpected termination, the output has been broken into two parts: > > jshell.msg.terminated = State engine terminated. > jshell.msg.terminated.restore = Restore definitions with: /reload > -restore > > The latter is now printed as fluff (and thus not showing up for load > files or quiet feedback modes): > > shutdownSubscription = state.onShutdown((JShell deadState) -> { > if (deadState == state) { > hardmsg("jshell.msg.terminated"); > + fluffmsg("jshell.msg.terminated.restore"); > live = false; > } > }); > > And, of course, the test files are in their new post-consolidation > locations. > > Thanks, > Robert > > On 09/15/17 02:49, Jan Lahoda wrote: >> Seems OK to me. >> >> Jan >> >> On 13.9.2017 04:17, Robert Field wrote: >>> Please review updated webrev (now uses file "-" rather than option >>> "--pipe") -- >>> >>> Bugs: >>> >>> 8179856: jshell tool: not suitable for pipeline use >>> https://bugs.openjdk.java.net/browse/JDK-8179856 >>> >>> 8186708: jshell tool: bad load file garbles message and does not >>> abort >>> https://bugs.openjdk.java.net/browse/JDK-8186708 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8179856v2.webrev/ >>> >>> Thanks, >>> Robert >>> >>> >>> On 09/12/17 12:53, Robert Field wrote: >>>> I like it! >>>> >>>> Both because it is clean and a standard. >>>> I agree that considering stdin exhausted (so exiting after) makes >>>> sense. >>>> >>>> It will mean somewhat of a rewrite, but that?s fine. >>>> >>>> I?ll redo and send out. >>>> >>>> -Robert >>>> >>>>> On Sep 12, 2017, at 8:47 AM, Jan Lahoda wrote: >>>>> >>>>> What would happen if we processed "-" (stdin) as a file? One >>>>> difference I see is that after processing the files, the interactive >>>>> shell is started unless there is an explicit /exit in the files. But >>>>> given we have already processed the stdin, it would seem OK to me to >>>>> not start the interactive part (there's an EOF at the end of the >>>>> stdin, I assume, which for stdin could be seen as an explicit /exit). >>>>> >>>>> I also tried bash: >>>>> $ echo 'echo X' | bash - >>>>> X >>>>> >>>>> Jan >>>>> >>>>> On 11.9.2017 18:35, Robert Field wrote: >>>>>> On 09/11/17 02:30, Jan Lahoda wrote: >>>>>>> Hi Robert, >>>>>>> >>>>>>> Overall seems OK to me. One question: why use "--pipe" instead of >>>>>>> simply "-" (which is AFAIK common option for "read stdin")? >>>>>> From Linux "cat" ----- >>>>>> >>>>>> SYNOPSIS >>>>>> cat [OPTION]... [FILE]... >>>>>> >>>>>> DESCRIPTION >>>>>> ... >>>>>> >>>>>> With no FILE, or when FILE is -, read standard input. >>>>>> >>>>>> EXAMPLES >>>>>> cat f - g >>>>>> Output f's contents, then standard input, then g's >>>>>> contents. >>>>>> >>>>>> cat Copy standard input to standard output. >>>>>> >>>>>> ------------ >>>>>> >>>>>> The jshell tool always reads from standard in (unless somehow >>>>>> aborted). >>>>>> This "--pipe" argument is an option, whereas "-" in the *nix world >>>>>> is a >>>>>> file. >>>>>> >>>>>> The option does not change what is read, but how it is processed. >>>>>> >>>>>> But maybe that is too pedantic, and it still the natural choice. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> -Robert >>>>>> >>>>>> >>>>>>> Jan >>>>>>> >>>>>>> On 24.8.2017 06:35, Robert Field wrote: >>>>>>>> Please review -- >>>>>>>> >>>>>>>> Bugs: >>>>>>>> >>>>>>>> 8179856: jshell tool: not suitable for pipeline use >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179856 >>>>>>>> >>>>>>>> 8186708: jshell tool: bad load file garbles message and >>>>>>>> does not >>>>>>>> abort >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186708 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~rfield/8179856v1.webrev/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Robert >>>>>>>> >>> > From jan.lahoda at oracle.com Thu Oct 19 16:00:03 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 19 Oct 2017 18:00:03 +0200 Subject: RFR 8187359: JShell: Give comprehensible error when user method name matches Object method In-Reply-To: <59E27CEC.1040205@oracle.com> References: <59B22CE3.2010609@oracle.com> <59B83A87.4070503@oracle.com> <59E27CEC.1040205@oracle.com> Message-ID: <59E8CC03.1050502@oracle.com> On 14.10.2017 23:09, Robert Field wrote: > Thanks Jan! > > Coming back to this, post repo consolidation, I see this is > unnecessarily restrictive, the error occurs only when the signatures > match as well. Ideally we want users to never see this error, so > making it less common is good. I've changed the new error to only > appear when it would have failed (with a confusing error). Now methods > like: > > boolean equals(foo f1, Foo f2) ... > > would be allowed. I was thinking of that on the first review. But declaring such (top level) methods does not seem very useful. Unless I am mistaken, there is no good way to use them: --- jshell> boolean equals(int i1, int i2) { return i1 == i2; } | created method equals(int,int) jshell> equals(1, 2) | Error: | method equals in class java.lang.Object cannot be applied to given types; | required: java.lang.Object | found: int,int | reason: actual and formal argument lists differ in length | equals(1, 2) | ^----^ --- So, I didn't mind the approach where such methods were rejected. Jan > > The code remains the same in concept but is distributed differently -- > switching out diagnostics after compilation. > > And a corresponding update and additions to the tests. > > Updated webrev: > > http://cr.openjdk.java.net/~rfield/8187359v3.webrev/ > > -Robert > > On 09/12/17 12:50, Jan Lahoda wrote: >> Seems OK. >> >> Jan >> >> On 8.9.2017 07:38, Robert Field wrote: >>> Please review. >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8187359 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8187359v0.webrev/ >>> >>> Thanks, >>> Robert >>> > From jan.lahoda at oracle.com Thu Oct 26 09:35:46 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 26 Oct 2017 11:35:46 +0200 Subject: RFR: JDK-8189778: Jshell crash on tab for StringBuilder.append( Message-ID: <59F1AC72.4020202@oracle.com> Hi, Typing: jshell> StringBuilder sb = new StringBuilder(); jshell> sb.append( Will lead to an exception: jshell> sb.append(Exception in thread "main" java.lang.StringIndexOutOfBoundsException: start -59, end -59, length 238 [snip] jdk.compiler/jdk.internal.shellsupport.doc.JavadocHelper$OnDemandJavadocHelper.getResolvedDocComment(JavadocHelper.java:481) The reason is that the javadoc for StringBuilder.append(CharSequence, int, int) is: /** * @throws IndexOutOfBoundsException {@inheritDoc} */ The JavadocHelper tries to fill in the missing javadoc entries, but that fails because it tries to insert the preceding entries at an uninitialized place. The proposed patch: -fixes the above -adds a test that runs the JavadocHelper on all methods/fields/constructors of top-level types in all exported packages (this runs for a considerable time, and we may need to disable this test if it proves to be too heavyweight) -adds a few more test cases for problems found by the above test -fixes the javadoc resolution to treat missing javadoc body as {@inheritDoc} (so that the overridden method's javadoc text is used if missing in this method) Bug: https://bugs.openjdk.java.net/browse/JDK-8189778 Webrev: http://cr.openjdk.java.net/~jlahoda/8189778/webrev.00/ Feedback is welcome. Thanks, Jan From jan.lahoda at oracle.com Thu Oct 26 17:49:49 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 26 Oct 2017 19:49:49 +0200 Subject: RFR: JDK-8189595: jshell tool: line redrawn on each completion Message-ID: <59F2203D.4000709@oracle.com> Hi, Please review fix: http://cr.openjdk.java.net/~jlahoda/8189595/webrev.00/ For bug: https://bugs.openjdk.java.net/browse/JDK-8189595 Thanks, Jan From robert.field at oracle.com Fri Oct 27 17:14:29 2017 From: robert.field at oracle.com (Robert Field) Date: Fri, 27 Oct 2017 10:14:29 -0700 Subject: RFR: JDK-8189595: jshell tool: line redrawn on each completion In-Reply-To: <59F2203D.4000709@oracle.com> References: <59F2203D.4000709@oracle.com> Message-ID: <59F36975.3030402@oracle.com> As is, there are a couple of nits: "hasSmart && hasBoth" is redundant, "hasBoth" implies "hasSmart". And with the approach, the last parameter of the OrdinaryCompletionTask constructor is incorrectly named. However, to the extent this fix works, it works by changing the behavior of: 494 boolean showItems = toShow.size() > 1 || smart; But I think this is the wrong test to be making. Rather, I think, what needs to be tested is whether putting the prefixStr completes the completion. Example, before and after the fix: jshell> int zxgrr zxgrr ==> 0 jshell> double zxgrr() { return 0; } | created method zxgrr() jshell> int x = zx Yields a completion with "grr" and a show: jshell> int x = zxgrr zxgrr jshell> int x = zxgr -Robert On 10/26/17 10:49, Jan Lahoda wrote: > Hi, > > Please review fix: > http://cr.openjdk.java.net/~jlahoda/8189595/webrev.00/ > > For bug: > https://bugs.openjdk.java.net/browse/JDK-8189595 > > Thanks, > Jan From jan.lahoda at oracle.com Sun Oct 29 14:40:36 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Sun, 29 Oct 2017 15:40:36 +0100 Subject: RFR: JDK-8189595: jshell tool: line redrawn on each completion In-Reply-To: <59F36975.3030402@oracle.com> References: <59F2203D.4000709@oracle.com> <59F36975.3030402@oracle.com> Message-ID: <59F5E864.3030909@oracle.com> On 27.10.2017 19:14, Robert Field wrote: > As is, there are a couple of nits: "hasSmart && hasBoth" is redundant, > "hasBoth" implies "hasSmart". And with the approach, the last parameter > of the OrdinaryCompletionTask constructor is incorrectly named. > > However, to the extent this fix works, it works by changing the behavior > of: > > 494 boolean showItems = toShow.size() > 1 || smart; > > But I think this is the wrong test to be making. Rather, I think, what > needs to be tested is whether putting the prefixStr completes the > completion. > > Example, before and after the fix: > > jshell> int zxgrr > zxgrr ==> 0 > > jshell> double zxgrr() { return 0; } > | created method zxgrr() > > jshell> int x = zx > > Yields a completion with "grr" and a show: > > jshell> int x = zxgrr > zxgrr > > jshell> int x = zxgr I guess the question is what should happen if one types: jshell> zx It currently does: jshell> zxgrr zxgrr zxgrr() jshell> zxgrr And I think the smart handling is consistent with that (the items are present, only not displayed - overall the user needs to get to full items by pressing ). An alternative would be: jshell> zx //note - not repeat jshell> zxgrr zxgrr zxgrr() jshell> zxgrr In which case for in the smart case it would be: jshell> int x = zx jshell> int x = zxgrr zsgrr jshell> int x = zxgrr Jan > > -Robert > > > > On 10/26/17 10:49, Jan Lahoda wrote: >> Hi, >> >> Please review fix: >> http://cr.openjdk.java.net/~jlahoda/8189595/webrev.00/ >> >> For bug: >> https://bugs.openjdk.java.net/browse/JDK-8189595 >> >> Thanks, >> Jan > From robert.field at oracle.com Sun Oct 29 15:19:52 2017 From: robert.field at oracle.com (Robert Field) Date: Sun, 29 Oct 2017 08:19:52 -0700 Subject: RFR: JDK-8189595: jshell tool: line redrawn on each completion In-Reply-To: <59F5E864.3030909@oracle.com> References: <59F2203D.4000709@oracle.com> <59F36975.3030402@oracle.com> <59F5E864.3030909@oracle.com> Message-ID: The most consistent (if not, in this case, the most helpful) would be like that but with the press tab for more message. Robert Sent from my iPad > On Oct 29, 2017, at 7:40 AM, Jan Lahoda wrote: > >> On 27.10.2017 19:14, Robert Field wrote: >> As is, there are a couple of nits: "hasSmart && hasBoth" is redundant, >> "hasBoth" implies "hasSmart". And with the approach, the last parameter >> of the OrdinaryCompletionTask constructor is incorrectly named. >> >> However, to the extent this fix works, it works by changing the behavior >> of: >> >> 494 boolean showItems = toShow.size() > 1 || smart; >> >> But I think this is the wrong test to be making. Rather, I think, what >> needs to be tested is whether putting the prefixStr completes the >> completion. >> >> Example, before and after the fix: >> >> jshell> int zxgrr >> zxgrr ==> 0 >> >> jshell> double zxgrr() { return 0; } >> | created method zxgrr() >> >> jshell> int x = zx >> >> Yields a completion with "grr" and a show: >> >> jshell> int x = zxgrr >> zxgrr >> >> jshell> int x = zxgr > > I guess the question is what should happen if one types: > jshell> zx > > It currently does: > jshell> zxgrr > zxgrr zxgrr() > > jshell> zxgrr > > And I think the smart handling is consistent with that (the items are present, only not displayed - overall the user needs to get to full items by pressing ). > > An alternative would be: > jshell> zx > //note - not repeat > jshell> zxgrr > zxgrr zxgrr() > > jshell> zxgrr > > In which case for in the smart case it would be: > jshell> int x = zx > jshell> int x = zxgrr > zsgrr > jshell> int x = zxgrr > > Jan > >> >> -Robert >> >> >> >>> On 10/26/17 10:49, Jan Lahoda wrote: >>> Hi, >>> >>> Please review fix: >>> http://cr.openjdk.java.net/~jlahoda/8189595/webrev.00/ >>> >>> For bug: >>> https://bugs.openjdk.java.net/browse/JDK-8189595 >>> >>> Thanks, >>> Jan >> From jan.lahoda at oracle.com Tue Oct 31 13:51:08 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 31 Oct 2017 14:51:08 +0100 Subject: RFR: JDK-8189595: jshell tool: line redrawn on each completion In-Reply-To: References: <59F2203D.4000709@oracle.com> <59F36975.3030402@oracle.com> <59F5E864.3030909@oracle.com> Message-ID: <59F87FCC.2000903@oracle.com> The patch updated to print a message like "press to see more" is here: http://cr.openjdk.java.net/~jlahoda/8189595/webrev.01/ Does that look better? Thanks, Jan On 29.10.2017 16:19, Robert Field wrote: > The most consistent (if not, in this case, the most helpful) would be like that but with the press tab for more message. > > Robert > > > Sent from my iPad > >> On Oct 29, 2017, at 7:40 AM, Jan Lahoda wrote: >> >>> On 27.10.2017 19:14, Robert Field wrote: >>> As is, there are a couple of nits: "hasSmart && hasBoth" is redundant, >>> "hasBoth" implies "hasSmart". And with the approach, the last parameter >>> of the OrdinaryCompletionTask constructor is incorrectly named. >>> >>> However, to the extent this fix works, it works by changing the behavior >>> of: >>> >>> 494 boolean showItems = toShow.size() > 1 || smart; >>> >>> But I think this is the wrong test to be making. Rather, I think, what >>> needs to be tested is whether putting the prefixStr completes the >>> completion. >>> >>> Example, before and after the fix: >>> >>> jshell> int zxgrr >>> zxgrr ==> 0 >>> >>> jshell> double zxgrr() { return 0; } >>> | created method zxgrr() >>> >>> jshell> int x = zx >>> >>> Yields a completion with "grr" and a show: >>> >>> jshell> int x = zxgrr >>> zxgrr >>> >>> jshell> int x = zxgr >> >> I guess the question is what should happen if one types: >> jshell> zx >> >> It currently does: >> jshell> zxgrr >> zxgrr zxgrr() >> >> jshell> zxgrr >> >> And I think the smart handling is consistent with that (the items are present, only not displayed - overall the user needs to get to full items by pressing ). >> >> An alternative would be: >> jshell> zx >> //note - not repeat >> jshell> zxgrr >> zxgrr zxgrr() >> >> jshell> zxgrr >> >> In which case for in the smart case it would be: >> jshell> int x = zx >> jshell> int x = zxgrr >> zsgrr >> jshell> int x = zxgrr >> >> Jan >> >>> >>> -Robert >>> >>> >>> >>>> On 10/26/17 10:49, Jan Lahoda wrote: >>>> Hi, >>>> >>>> Please review fix: >>>> http://cr.openjdk.java.net/~jlahoda/8189595/webrev.00/ >>>> >>>> For bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8189595 >>>> >>>> Thanks, >>>> Jan >>> > From jan.lahoda at oracle.com Tue Oct 31 16:46:30 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 31 Oct 2017 17:46:30 +0100 Subject: RFR: JDK-8189778: Jshell crash on tab for StringBuilder.append( In-Reply-To: <59F1AC72.4020202@oracle.com> References: <59F1AC72.4020202@oracle.com> Message-ID: <59F8A8E6.6030609@oracle.com> I've updated to patch to have some comments at places that seemed important: http://cr.openjdk.java.net/~jlahoda/8189778/webrev.01/ Jan On 26.10.2017 11:35, Jan Lahoda wrote: > Hi, > > Typing: > jshell> StringBuilder sb = new StringBuilder(); > jshell> sb.append( > > Will lead to an exception: > jshell> sb.append(Exception in thread "main" > java.lang.StringIndexOutOfBoundsException: start -59, end -59, length 238 > [snip] > jdk.compiler/jdk.internal.shellsupport.doc.JavadocHelper$OnDemandJavadocHelper.getResolvedDocComment(JavadocHelper.java:481) > > > The reason is that the javadoc for StringBuilder.append(CharSequence, > int, int) is: > /** > * @throws IndexOutOfBoundsException {@inheritDoc} > */ > > The JavadocHelper tries to fill in the missing javadoc entries, but that > fails because it tries to insert the preceding entries at an > uninitialized place. > > The proposed patch: > -fixes the above > -adds a test that runs the JavadocHelper on all > methods/fields/constructors of top-level types in all exported packages > (this runs for a considerable time, and we may need to disable this test > if it proves to be too heavyweight) > -adds a few more test cases for problems found by the above test > -fixes the javadoc resolution to treat missing javadoc body as > {@inheritDoc} (so that the overridden method's javadoc text is used if > missing in this method) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189778 > Webrev: http://cr.openjdk.java.net/~jlahoda/8189778/webrev.00/ > > Feedback is welcome. > > Thanks, > Jan From robert.field at oracle.com Tue Oct 31 18:55:51 2017 From: robert.field at oracle.com (Robert Field) Date: Tue, 31 Oct 2017 11:55:51 -0700 Subject: RFR: JDK-8189595: jshell tool: line redrawn on each completion In-Reply-To: <59F87FCC.2000903@oracle.com> References: <59F2203D.4000709@oracle.com> <59F36975.3030402@oracle.com> <59F5E864.3030909@oracle.com> <59F87FCC.2000903@oracle.com> Message-ID: <59F8C737.80306@oracle.com> Thumbs up. -Robert On 10/31/17 06:51, Jan Lahoda wrote: > The patch updated to print a message like "press to see more" is > here: > http://cr.openjdk.java.net/~jlahoda/8189595/webrev.01/ > > Does that look better? > > Thanks, > Jan > > On 29.10.2017 16:19, Robert Field wrote: >> The most consistent (if not, in this case, the most helpful) would be >> like that but with the press tab for more message. >> >> Robert >> >> >> Sent from my iPad >> >>> On Oct 29, 2017, at 7:40 AM, Jan Lahoda wrote: >>> >>>> On 27.10.2017 19:14, Robert Field wrote: >>>> As is, there are a couple of nits: "hasSmart && hasBoth" is redundant, >>>> "hasBoth" implies "hasSmart". And with the approach, the last >>>> parameter >>>> of the OrdinaryCompletionTask constructor is incorrectly named. >>>> >>>> However, to the extent this fix works, it works by changing the >>>> behavior >>>> of: >>>> >>>> 494 boolean showItems = toShow.size() > 1 || smart; >>>> >>>> But I think this is the wrong test to be making. Rather, I think, >>>> what >>>> needs to be tested is whether putting the prefixStr completes the >>>> completion. >>>> >>>> Example, before and after the fix: >>>> >>>> jshell> int zxgrr >>>> zxgrr ==> 0 >>>> >>>> jshell> double zxgrr() { return 0; } >>>> | created method zxgrr() >>>> >>>> jshell> int x = zx >>>> >>>> Yields a completion with "grr" and a show: >>>> >>>> jshell> int x = zxgrr >>>> zxgrr >>>> >>>> jshell> int x = zxgr >>> >>> I guess the question is what should happen if one types: >>> jshell> zx >>> >>> It currently does: >>> jshell> zxgrr >>> zxgrr zxgrr() >>> >>> jshell> zxgrr >>> >>> And I think the smart handling is consistent with that (the items >>> are present, only not displayed - overall the user needs to get to >>> full items by pressing ). >>> >>> An alternative would be: >>> jshell> zx >>> //note - not repeat >>> jshell> zxgrr >>> zxgrr zxgrr() >>> >>> jshell> zxgrr >>> >>> In which case for in the smart case it would be: >>> jshell> int x = zx >>> jshell> int x = zxgrr >>> zsgrr >>> jshell> int x = zxgrr >>> >>> Jan >>> >>>> >>>> -Robert >>>> >>>> >>>> >>>>> On 10/26/17 10:49, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> Please review fix: >>>>> http://cr.openjdk.java.net/~jlahoda/8189595/webrev.00/ >>>>> >>>>> For bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8189595 >>>>> >>>>> Thanks, >>>>> Jan >>>> >>