From roy.van.rijn at gmail.com Mon Feb 1 16:01:04 2016 From: roy.van.rijn at gmail.com (Roy van Rijn) Date: Mon, 1 Feb 2016 17:01:04 +0100 Subject: JShell API questions / feedback In-Reply-To: References: Message-ID: Some more information about what I've been trying to do with the JShell API. > I've been working on a project to incorporate the JShell API into an > environment to help teach the Java language to absolute beginners > (mainly kids). For this I'm using the JShell API and making my own editor. The eval() > results have to be parsed and evaluated by my code. But I've ran into > a few issues (or maybe just questions). The reason for me to have more information in the resulting Snippets is the following. First I'd love to teach people more about the code they've just written. My goal is to make an application (in JavaFX) with small programming exercises, much like the language-teaching website Duolingo, but to teach Java programming instead. For example I ask the user to type a number between 1 and 100 and press 'Evaluate!' The user now types: 42 The program receives a SnippetEvent with Snippet and this gets evaluated by my application. In this case I'm looking for a VarSnippet of type int etc. Another question would be: Create a method that returns your name (as a String) The result should be a Snippet that declares a method, with return type String (etc). Also I want to have a more explanatory description of what happens if you evaluate some code, for absolute beginners. For example: Evaluate: "int age = 33;" the program responds with: "You've created a variable of type 'int' and named it 'age' and the current value is: 33" For this I'd like to have access to more meta info, for example the return type (so I don't have to parse this). Also hence the question about having access to the created objects. Currently the implementation is that SnippetEvent.value() returns the toString, so for example if you evaluate: class MyClass { } new MyClass(); The result is: "You've created a nameless variable of type 'MyClass', I've named it 'odin' and the current value is: MyClass at 445b84c0" In my application, I'd like to give challenges like "write a method that returns your current age". When I eval() the created code I don't have many options, I'm unable to access the created code using the JShell API. Currently I'm stuck with: Input: "int myAge() { return 12; }" Output: "You've created the method 'myAge' without any arguments and returns 'int'" The only way I can currently 'check' if the inputted code works is to execute it myself in an instance of the shell behind the scenes: shell.eval(methodName+"("+optionalArguments+");"); Now I get the result as VarSnippet, I can parse it to an int safely because I know the method returns int... and check the value. But that is rather ugly and error-prone of course. Another way would be to parse the given code itself (kind of beating the reason I'm using the JShell API). Having a proxy object surrounding the created objects and methods would certainly be useful for me in this case. Not sure about other use cases but I'm pretty sure they exist as well. Regarding the API's get-less method names: understood, it just seemed strange to me initially. The resulting Snippet instance 'feels' like a data object that has fields with information. For those types of objects I'm used to just type 'get' and let my IDE give me suggestions on the fields. But this obviously doesn't work when all the fields have get-less method names. But indeed, String has length() etc. There are also counter examples of course String.getBytes(), it has a getter with no corresponding setter. It would be nice if there was no longer "two schools of thought in the JDK world", but I have the sneaking suspicion this is neither the place nor the time for that discussion. Roy From jan.lahoda at oracle.com Tue Feb 2 06:40:31 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 02 Feb 2016 06:40:31 +0000 Subject: RFR (small) 8080357: JShell: Only unqualified unresolved references should be corralled In-Reply-To: References: Message-ID: <56B04F5F.2060807@oracle.com> Hi Robert, I think this is OK for now at least, but at some point, we may want to discuss if there is a way for us to avoid the dependency on the format of the diagnostic message (for example, by inspecting JCDiagnostic.getDiagnosticPosition().getTree(), or JCDiagnostic.getArgs()). Jan On 29.1.2016 07:52, Robert Field wrote: > Bugs: > https://bugs.openjdk.java.net/browse/JDK-8080357 > https://bugs.openjdk.java.net/browse/JDK-8081431 > > Webrev: > http://cr.openjdk.java.net/~rfield/8080357v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Tue Feb 2 07:16:47 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 01 Feb 2016 23:16:47 -0800 Subject: RFR (small) 8080357: JShell: Only unqualified unresolved references should be corralled In-Reply-To: <56B04F5F.2060807@oracle.com> References: <56B04F5F.2060807@oracle.com> Message-ID: <152a0d73f18.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Thanks, Jan! Yes, eventually I'd like to get rid of all the diagnostic message parsing. -Robert On February 1, 2016 10:40:36 PM Jan Lahoda wrote: > Hi Robert, > > I think this is OK for now at least, but at some point, we may want to > discuss if there is a way for us to avoid the dependency on the format > of the diagnostic message (for example, by inspecting > JCDiagnostic.getDiagnosticPosition().getTree(), or JCDiagnostic.getArgs()). > > Jan > > On 29.1.2016 07:52, Robert Field wrote: >> Bugs: >> https://bugs.openjdk.java.net/browse/JDK-8080357 >> >> https://bugs.openjdk.java.net/browse/JDK-8081431 >> >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8080357v0.webrev/ >> >> >> Thanks, >> Robert >> From jan.lahoda at oracle.com Tue Feb 9 12:27:20 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 09 Feb 2016 13:27:20 +0100 Subject: RFR 8146138 et. al.: jshell tool: add /help command plus misc fixes In-Reply-To: <56AA8B0C.9000603@oracle.com> References: <56AA8B0C.9000603@oracle.com> Message-ID: <56B9DB28.7050305@oracle.com> Hi Robert, Overall, seems OK to me. Comments: -in the external editor handling, do we need to care about editor commands that have a space in the path? (I.e. is there a need for the user to quote the external editor path?) -I am not quite sure which part of the patch relates to JDK-8147898 (/reload quiet)? -in JShellTool.cmdHelp(), when the full help is constructed for commands, it always ends with "\n\n", which then produces several empty lines at the end of the help when printed. Would it make sense to strip some of the trailing newlines so that there would be only a single empty line between the help and the prompt? -just a note about future - we might provide a completion for /help as well. Jan On 28.1.2016 22:41, Robert Field wrote: > Fixes: > > 8146138 jshell tool: add /help > 8147495 jshell tool: correctly handle arguments on /seteditor command > 8147886 jshell tool: commands don't allow reference to start-up or > explicit id of dropped/failed snippets > 8147887 jshell tool: /list start -- fails > 8147898 jshell tool: /reload quiet -- should quiet echo > > Webrev: > > http://cr.openjdk.java.net/~rfield/8146138v0.patch/ > > Thanks, > Robert > From jan.lahoda at oracle.com Tue Feb 9 13:03:59 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 09 Feb 2016 14:03:59 +0100 Subject: RFR 8131027: JShell API/tool: suggest imports for a class In-Reply-To: <56AA8A61.1040404@oracle.com> References: <56A21519.5050109@oracle.com> <56AA8A61.1040404@oracle.com> Message-ID: <56B9E3BF.8000503@oracle.com> Hi Robert, Thanks for the comments - I've uploaded an updated webrev here: http://cr.openjdk.java.net/~jlahoda/8131027/webrev.01/ A delta webrev from the previous iteration: http://cr.openjdk.java.net/~jlahoda/8131027/webrev.01/delta/webrev/index.html Some more comments inline. On 28.1.2016 22:38, Robert Field wrote: > This will be a big help -- thanks for coding this. > > Below is a pre-review. > > JShell: > > Fine. > > > Eval: > > Looks good. > > > SourceCodeAnalysis: > > This is public API, so names and comments really matter... I tried to improve the names and javadoc. > > analyzeType() -- There is a description of where the expression > begins, but not of where it ends. > > getDeclaredSymbols() -- Please document what "possible" in > "possible FQNs" means. > > IndexResult -- > > This class needs a name that is more descriptive of what it is, > and the name should align with whatever name and comment are finally > given to getDeclaredSymbols(). NameLookup? ResolvedName? ... > > The class comment should describe what this class is -- and it > more than a list of FQNs, as it also deals with the simple name, > up-to-dateness, resolvability. > getFqns() -- As above, and probably here rather than there, -- > what does possible mean? > > getSimpleNameLength() -- Says "unresolvable", but there is a > test (below) for it being resolvable -- probably just remove that word. > "right left to", were you meaning "right of"? "for which the > candidates could be computed" if they can't be computed, how does that > effect this method? Wouldn't return still return the length? Can that > phrase just be removed? Is the a reason that the length (rather than > the name) is returned? > > isUpToDate() -- I have no idea what this means. > > isResolvable() -- Resolvable in the context of what? > > Throughout class, I would avoid "FQN". See, for example, the use > of "fully qualified name" in java/lang. I would spell it out in > comments. The java/lang uses "name" as the base for identifiers, but > this won't work for getFqns() since it needs to be differentiated from > simple names. Perhaps getQualifiedNames(). > > Nit: Throughout the JShell code and throughout the JDK codebase the > convention is that comments start on the line after the "/**" (not on > the same line). > > SourceCodeAnalysisImpl: > > getDeclaredSymbols() -- My reading of the spec (above) is that the > cursor is at the beginning of the identifier to match, this is at the > end. Spec needs clarification or ... The cursor is expected to be immediately after the identifier, I tried to clarify that in the javadoc. > > If there is an @author tag on this file, you should certainly be > first. > > currentIndexes and two other fields are declared in the middle of > the class. While old conventions forbade this: > https://web.archive.org/web/20130627193836/http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html > > others don't when there is good reason. But I mention this because > there are many forward references to all three of these -- so their > implied locality is misleading. > > I would need some code context (comments) to be able to properly > review. I've added comments. Please let me know where I need to add more. > > ConsoleIOContext: > > Need more context (code comments) for me to be able to review. I've added comments. Please let me know where I need to add more. > > TreeDissector: > > See TypePrinter. > > TypePrinter: > > My (unspoken) design for this was to be as stand-alone (untied to > the JShell architecture) as possible -- esp. since it is subclassed off > javac, which is why I had that stuff in higher levels. It could be > moved up just one level (to TreeDissector) Ok, I've moved the method to TreeDissector - TypePrinter would still seem to be a nice place for it, to me, though. > > ComputeFQNsTest: > > Need tests with multiple answers. If the other fields of > IndexResult are interesting enough to be present they should be tested. > > InferTypeTest: > > Looks pretty good. Maybe some other express forms: boolean > operators, .... Thanks - there turned out to be a bug with binary operators, should be fixed now. Any comments are welcome! Thanks, Jan > > Thanks, > Robert > > > On 01/22/16 03:40, Jan Lahoda wrote: >> Hello, >> >> I'd like to ask for a review of a patch that adds two new features: >> a) add import: when there is an unresolvable identifier, press >> " i" (*), and a list of known FQNs should be printed, >> with an ability to easily import any of them. >> >> b) create variable: when there is an expression, press >> " v", and a variable stub will be created, with the >> expression as the initializer. >> >> The "" is either Alt-Enter or Alt-F1, depending on the >> platform. For Windows, >> >> The patch is here: >> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.00/ >> >> For Windows, an additional patch to jdk.internal.le is needed (I'll >> send a separate review to core-libs for that): >> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >> >> Any comments are welcome! >> >> Thanks, >> Jan > From joao.parana at gmail.com Tue Feb 9 18:47:32 2016 From: joao.parana at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Antonio_Ferreira?=) Date: Tue, 9 Feb 2016 16:47:32 -0200 Subject: How to run a JPA application using JShell In-Reply-To: References: Message-ID: Does anyone have any ideas on how to solve this problem ? Tanks. Jo?o Antonio (*Paran?*) *cel. 21-99403-4143* 2016-01-01 15:31 GMT-02:00 Jo?o Antonio Ferreira : > Sure ! > > Install Docker then run this commands: > > The *dockerhost.local* host is *boot2docker* or *docker-machine* host on > MAC OS X or Windows. On Linux you can use 127.0.0.1 > > docker pull parana/jshell > > export MYSQL_ROOT_PASSWORD=xpto > docker run -d --name mysql_db -p 3306:3306 \ > -e MYSQL_ROOT_PASSWORD=$MYSQL_ROOT_PASSWORD \ > -e MYSQL_DATABASE=test \ > -e MYSQL_USER=test \ > -e MYSQL_PASSWORD=test \ > mariadb bash > > # Verify MySQL database connection > mysql -u root -h *dockerhost.local* -p # Please provide the password xpto > mysql> show databases; > mysql> use test; > mysql> show tables; > > > Running JPA test with JShell on Docker container > > docker run -i -t --rm --name jshell \ > --link mysql_db:mysql \ > parana/jshell bash > > # Verifying persistence.xml > jar -tvf target/myJshellAppLib.jar META-INF/persistence.xml > # Testing JAR App inside console. This run OK ! > java -jar target/myJshellAppLib.jar > > # Testing inside Shell. This throw an > javax.persistence.PersistenceException > jshell > /classpath target/myJshellAppLib.jar > import br.com.joaoparana.* > App app = new App() > String[] args = {} > App.main(args) > > Starting JPA Test with MySql Database > > | javax.persistence.PersistenceException thrown: *No Persistence > provider for EntityManager named myPersistence* > > | at Persistence.createEntityManagerFactory (Persistence.java:85) > > | at App.getEMF (App.java:100) > > | at App.main (App.java:37) > > | at (#12:1) > > This simple project can be viewed on > https://github.com/joao-parana/jshell/tree/master/my-jshell-app > > This sound like a Classloader problem. > > I hope this help. > > Jo?o Antonio > ? > > > > 2015-12-30 9:44 GMT-02:00 Ben Evans : > >> Hi Joao, >> >> Could you post a minimal test case that demonstrates the problem? >> >> Thanks, >> >> Ben >> >> On Wed, Dec 30, 2015 at 11:36 AM, Jo?o Antonio Ferreira >> wrote: >> > I'm unable to load the persistence.xml file when using a Shell JPA >> > application. >> > >> > >> > Jo?o Antonio >> > > From robert.field at oracle.com Wed Feb 10 01:17:59 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 09 Feb 2016 17:17:59 -0800 Subject: RFR 8146138 et. al.: jshell tool: add /help command plus misc fixes In-Reply-To: <56B9DB28.7050305@oracle.com> References: <56AA8B0C.9000603@oracle.com> <56B9DB28.7050305@oracle.com> Message-ID: <56BA8FC7.8050101@oracle.com> New webrev: http://cr.openjdk.java.net/~rfield/8146138v2.webrev/ See below... On 02/09/16 04:27, Jan Lahoda wrote: > Hi Robert, > > Overall, seems OK to me. > > Comments: > -in the external editor handling, do we need to care about editor > commands that have a space in the path? (I.e. is there a need for the > user to quote the external editor path?) Absolutely true, new webrev allows quoting of command and parameters; Also, does argument splitting in a cleaner way. > -I am not quite sure which part of the patch relates to JDK-8147898 > (/reload quiet)? It already works (fixed not sure when), all it was missing was a test, which this adds. Note: the new webrev includes tests for 8147886 and 8147887. > -in JShellTool.cmdHelp(), when the full help is constructed for > commands, it always ends with "\n\n", which then produces several > empty lines at the end of the help when printed. Would it make sense > to strip some of the trailing newlines so that there would be only a > single empty line between the help and the prompt? Yeah, it printed three blank lines -- which is too much. Tried with one, but since help messages are so long, didn't seem enough to see the prompt. Also, starting the command/subject title without blank line looks weird. So, what I've done is rotate one new-line to the top -- this keeps a two-blank separator between subjects if there are more than one. > -just a note about future - we might provide a completion for /help as > well. True. Added: 8149498:jshell tool: command completion on /help and Thanks Jan! -Robert > > Jan > > On 28.1.2016 22:41, Robert Field wrote: >> Fixes: >> >> 8146138 jshell tool: add /help >> 8147495 jshell tool: correctly handle arguments on /seteditor command >> 8147886 jshell tool: commands don't allow reference to start-up or >> explicit id of dropped/failed snippets >> 8147887 jshell tool: /list start -- fails >> 8147898 jshell tool: /reload quiet -- should quiet echo >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8146138v0.patch/ >> >> Thanks, >> Robert >> From robert.field at oracle.com Wed Feb 10 19:58:19 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 10 Feb 2016 11:58:19 -0800 Subject: RFR 8148316: jshell tool: Configurable output format In-Reply-To: <56AAE93F.9070205@oracle.com> References: <56AAE93F.9070205@oracle.com> Message-ID: <2A1F2501-51F0-429F-A270-421F8BDB3D3C@oracle.com> I got feedback from the team that the configuration formats were cryptic and insufficiently expressive. Here is a re-write,,, ...please review Bugs (the second (unrelated) bug was discovered and fixed in the process of testing): https://bugs.openjdk.java.net/browse/JDK-8148316 https://bugs.openjdk.java.net/browse/JDK-8149524 Webrev: http://cr.openjdk.java.net/~rfield/8148316v7.webrev/ An example output configuration (Open with /open): http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh Thanks, Robert > On Jan 28, 2016, at 8:23 PM, Robert Field wrote: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8148316 > > Webrev: > http://cr.openjdk.java.net/~rfield/8148316v1.webrev/ > > Some example output configurations (Open with /open): > http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh > http://cr.openjdk.java.net/~rfield/formats/dan.jsh > http://cr.openjdk.java.net/~rfield/formats/brian.jsh > > -Robert > From bitterfoxc at gmail.com Thu Feb 11 06:48:33 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Thu, 11 Feb 2016 15:48:33 +0900 Subject: RFR 8148316: jshell tool: Configurable output format In-Reply-To: <2A1F2501-51F0-429F-A270-421F8BDB3D3C@oracle.com> References: <56AAE93F.9070205@oracle.com> <2A1F2501-51F0-429F-A270-421F8BDB3D3C@oracle.com> Message-ID: Hi Robert, This feature is very amazing!!! This will be really helpful to internationalize! Just trivial comment: You've updated the copyright in JShellTools.java excepting the others. Don't you update it in the other files? shinyafox(Shinya Yoshida) 2016-02-11 4:58 GMT+09:00 Robert Field : > I got feedback from the team that the configuration formats were cryptic > and insufficiently expressive. > > Here is a re-write,,, ...please review > > Bugs (the second (unrelated) bug was discovered and fixed in the process > of testing): > https://bugs.openjdk.java.net/browse/JDK-8148316 < > https://bugs.openjdk.java.net/browse/JDK-8148316> > https://bugs.openjdk.java.net/browse/JDK-8149524 < > https://bugs.openjdk.java.net/browse/JDK-8149524> > > Webrev: > http://cr.openjdk.java.net/~rfield/8148316v7.webrev/ < > http://cr.openjdk.java.net/~rfield/8148316v7.webrev/> > > An example output configuration (Open with /open): > http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh < > http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh> > > Thanks, > Robert > > > > On Jan 28, 2016, at 8:23 PM, Robert Field > wrote: > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8148316 > > > > Webrev: > > http://cr.openjdk.java.net/~rfield/8148316v1.webrev/ > > > > Some example output configurations (Open with /open): > > http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh > > http://cr.openjdk.java.net/~rfield/formats/dan.jsh > > http://cr.openjdk.java.net/~rfield/formats/brian.jsh > > > > -Robert > > > > From robert.field at oracle.com Thu Feb 11 07:43:21 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 10 Feb 2016 23:43:21 -0800 Subject: RFR 8131027: JShell API/tool: suggest imports for a class In-Reply-To: <56B9E3BF.8000503@oracle.com> References: <56A21519.5050109@oracle.com> <56AA8A61.1040404@oracle.com> <56B9E3BF.8000503@oracle.com> Message-ID: HI Jan, Review of version 01 --- ConsoleIOContext.java -- fixes() -- on unexpected character it just cycles, waiting for another, for a user stuck where not wanted that could be confusing. If a user is here by mistake and typing ahead then ignoring unexpected characters increases the chance that a random character will have an unexpected effect. Some options (depending on the perceived likelihood of legitimately typing a wrong char: (1) no loop, if an unexpected char beep and exit (2) loop for a small number of times, three?, beeping on bad input. (3) print some help "Type a number" on bad input. FixComputer[] -- FQN is used in user error: "\nNo candidate FQNs found to import." Eval.java -- OK JShell.java -- OK SourceCodeAnalysis.java -- analyzeType() & listQualifiedNames() -- Nice javadoc. QualifiedNames -- The constructor is only use by us, exposing in the API is messy and potentially confusing. Luckily the solution is just to remove "public" off the constructor, since package-private is all we need. (while you are at it, can you tuck CompletionInfo constructor in too (impl used to be in a separate package)?) isResolvable() -- the methods above refer to "the simple name in the original code". This calls it "the given identifier", I assume this is the same thing? I'd stick with "the simple name in the original code" SourceCodeAnalysisImpl.java -- analyzeType() -- It aborts with null when not complete, which seems fine. Why does it proceed (and add a semicolon) when the input in empty -- I'd think it should also abort. Seems you would want to add the semicolon when completeness == COMPLETE_WITH_SEMI. The TODO comment says "comment handling" -- this is what MaskCommentsAndModifiers.java does -- just plug into that -- see Eval.eval(). IMPORT and METHOD are rejected, but I'd think CLASS, ENUM, ANNOTATION_TYPE, INTERFACE, and VARIABLE would be as well. ... to be continued ... ------- On mi Fedora (KDE-spin) machine I could get neither Alt-f1 or Alt-Enter to work. Send me a sketch of what user docs would say and I'll incorporate it in /help Thanks, Robert > On Feb 9, 2016, at 5:03 AM, Jan Lahoda wrote: > > Hi Robert, > > Thanks for the comments - I've uploaded an updated webrev here: > http://cr.openjdk.java.net/~jlahoda/8131027/webrev.01/ > > A delta webrev from the previous iteration: > http://cr.openjdk.java.net/~jlahoda/8131027/webrev.01/delta/webrev/index.html > > Some more comments inline. > > On 28.1.2016 22:38, Robert Field wrote: >> This will be a big help -- thanks for coding this. >> >> Below is a pre-review. >> >> JShell: >> >> Fine. >> >> >> Eval: >> >> Looks good. >> >> >> SourceCodeAnalysis: >> >> This is public API, so names and comments really matter... > > I tried to improve the names and javadoc. > >> >> analyzeType() -- There is a description of where the expression >> begins, but not of where it ends. >> >> getDeclaredSymbols() -- Please document what "possible" in >> "possible FQNs" means. >> >> IndexResult -- >> >> This class needs a name that is more descriptive of what it is, >> and the name should align with whatever name and comment are finally >> given to getDeclaredSymbols(). NameLookup? ResolvedName? ... >> >> The class comment should describe what this class is -- and it >> more than a list of FQNs, as it also deals with the simple name, >> up-to-dateness, resolvability. >> getFqns() -- As above, and probably here rather than there, -- >> what does possible mean? >> >> getSimpleNameLength() -- Says "unresolvable", but there is a >> test (below) for it being resolvable -- probably just remove that word. >> "right left to", were you meaning "right of"? "for which the >> candidates could be computed" if they can't be computed, how does that >> effect this method? Wouldn't return still return the length? Can that >> phrase just be removed? Is the a reason that the length (rather than >> the name) is returned? >> >> isUpToDate() -- I have no idea what this means. >> >> isResolvable() -- Resolvable in the context of what? >> >> Throughout class, I would avoid "FQN". See, for example, the use >> of "fully qualified name" in java/lang. I would spell it out in >> comments. The java/lang uses "name" as the base for identifiers, but >> this won't work for getFqns() since it needs to be differentiated from >> simple names. Perhaps getQualifiedNames(). >> >> Nit: Throughout the JShell code and throughout the JDK codebase the >> convention is that comments start on the line after the "/**" (not on >> the same line). >> >> SourceCodeAnalysisImpl: >> >> getDeclaredSymbols() -- My reading of the spec (above) is that the >> cursor is at the beginning of the identifier to match, this is at the >> end. Spec needs clarification or ... > > The cursor is expected to be immediately after the identifier, I tried to clarify that in the javadoc. > >> >> If there is an @author tag on this file, you should certainly be >> first. >> >> currentIndexes and two other fields are declared in the middle of >> the class. While old conventions forbade this: >> https://web.archive.org/web/20130627193836/http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html >> >> others don't when there is good reason. But I mention this because >> there are many forward references to all three of these -- so their >> implied locality is misleading. >> >> I would need some code context (comments) to be able to properly >> review. > > I've added comments. Please let me know where I need to add more. > >> >> ConsoleIOContext: >> >> Need more context (code comments) for me to be able to review. > > I've added comments. Please let me know where I need to add more. > >> >> TreeDissector: >> >> See TypePrinter. >> >> TypePrinter: >> >> My (unspoken) design for this was to be as stand-alone (untied to >> the JShell architecture) as possible -- esp. since it is subclassed off >> javac, which is why I had that stuff in higher levels. It could be >> moved up just one level (to TreeDissector) > > Ok, I've moved the method to TreeDissector - TypePrinter would still seem to be a nice place for it, to me, though. > >> >> ComputeFQNsTest: >> >> Need tests with multiple answers. If the other fields of >> IndexResult are interesting enough to be present they should be tested. >> >> InferTypeTest: >> >> Looks pretty good. Maybe some other express forms: boolean >> operators, .... > > Thanks - there turned out to be a bug with binary operators, should be fixed now. > > Any comments are welcome! > > Thanks, > Jan > >> >> Thanks, >> Robert >> >> >> On 01/22/16 03:40, Jan Lahoda wrote: >>> Hello, >>> >>> I'd like to ask for a review of a patch that adds two new features: >>> a) add import: when there is an unresolvable identifier, press >>> " i" (*), and a list of known FQNs should be printed, >>> with an ability to easily import any of them. >>> >>> b) create variable: when there is an expression, press >>> " v", and a variable stub will be created, with the >>> expression as the initializer. >>> >>> The "" is either Alt-Enter or Alt-F1, depending on the >>> platform. For Windows, >>> >>> The patch is here: >>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.00/ >>> >>> For Windows, an additional patch to jdk.internal.le is needed (I'll >>> send a separate review to core-libs for that): >>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >>> >>> Any comments are welcome! >>> >>> Thanks, >>> Jan From robert.field at oracle.com Thu Feb 11 07:46:46 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 10 Feb 2016 23:46:46 -0800 Subject: RFR 8148316: jshell tool: Configurable output format In-Reply-To: References: <56AAE93F.9070205@oracle.com> <2A1F2501-51F0-429F-A270-421F8BDB3D3C@oracle.com> Message-ID: On 02/10/16 22:48, ShinyaYoshida wrote: > Hi Robert, > This feature is very amazing!!! Thanks. > This will be really helpful to internationalize! Typically internationalization uses resource files. > > Just trivial comment: > You've updated the copyright in JShellTools.java excepting the others. > Don't you update it in the other files? True! I have copyrights to update. Thanks, Robert > > shinyafox(Shinya Yoshida) > > > > 2016-02-11 4:58 GMT+09:00 Robert Field >: > I got feedback from the team that the configuration formats were cryptic and insufficiently expressive. > > Here is a re-write,,, ...please review > > Bugs (the second (unrelated) bug was discovered and fixed in the process of testing): > https://bugs.openjdk.java.net/browse/JDK-8148316 > > https://bugs.openjdk.java.net/browse/JDK-8149524 > > > Webrev: > http://cr.openjdk.java.net/~rfield/8148316v7.webrev/ > > > An example output configuration (Open with /open): > http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh > > > Thanks, > Robert > > > > On Jan 28, 2016, at 8:23 PM, Robert Field > wrote: > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8148316 > > > > Webrev: > > http://cr.openjdk.java.net/~rfield/8148316v1.webrev/ > > > > Some example output configurations (Open with /open): > > http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh > > http://cr.openjdk.java.net/~rfield/formats/dan.jsh > > http://cr.openjdk.java.net/~rfield/formats/brian.jsh > > > > -Robert > > > > From jan.lahoda at oracle.com Fri Feb 12 10:44:12 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 12 Feb 2016 11:44:12 +0100 Subject: RFR 8146138 et. al.: jshell tool: add /help command plus misc fixes In-Reply-To: <56BA8FC7.8050101@oracle.com> References: <56AA8B0C.9000603@oracle.com> <56B9DB28.7050305@oracle.com> <56BA8FC7.8050101@oracle.com> Message-ID: <56BDB77C.7090909@oracle.com> Hi Robert, v2 seems Ok to me. Jan On 10.2.2016 02:17, Robert Field wrote: > New webrev: > http://cr.openjdk.java.net/~rfield/8146138v2.webrev/ > > See below... > > On 02/09/16 04:27, Jan Lahoda wrote: >> Hi Robert, >> >> Overall, seems OK to me. >> >> Comments: >> -in the external editor handling, do we need to care about editor >> commands that have a space in the path? (I.e. is there a need for the >> user to quote the external editor path?) > > Absolutely true, new webrev allows quoting of command and parameters; > Also, does argument splitting in a cleaner way. > >> -I am not quite sure which part of the patch relates to JDK-8147898 >> (/reload quiet)? > > It already works (fixed not sure when), all it was missing was a test, > which this adds. > > Note: the new webrev includes tests for 8147886 and 8147887. > >> -in JShellTool.cmdHelp(), when the full help is constructed for >> commands, it always ends with "\n\n", which then produces several >> empty lines at the end of the help when printed. Would it make sense >> to strip some of the trailing newlines so that there would be only a >> single empty line between the help and the prompt? > > Yeah, it printed three blank lines -- which is too much. Tried with > one, but since help messages are so long, didn't seem enough to see the > prompt. Also, starting the command/subject title without blank line > looks weird. So, what I've done is rotate one new-line to the top -- > this keeps a two-blank separator between subjects if there are more than > one. > >> -just a note about future - we might provide a completion for /help as >> well. > > True. Added: > 8149498:jshell tool: command completion on /help and > > > Thanks Jan! > > -Robert > >> >> Jan >> >> On 28.1.2016 22:41, Robert Field wrote: >>> Fixes: >>> >>> 8146138 jshell tool: add /help >>> 8147495 jshell tool: correctly handle arguments on /seteditor command >>> 8147886 jshell tool: commands don't allow reference to start-up or >>> explicit id of dropped/failed snippets >>> 8147887 jshell tool: /list start -- fails >>> 8147898 jshell tool: /reload quiet -- should quiet echo >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8146138v0.patch/ >>> >>> Thanks, >>> Robert >>> > From jan.lahoda at oracle.com Fri Feb 12 21:47:34 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 12 Feb 2016 22:47:34 +0100 Subject: RFR 8131027: JShell API/tool: suggest imports for a class In-Reply-To: References: <56A21519.5050109@oracle.com> <56AA8A61.1040404@oracle.com> <56B9E3BF.8000503@oracle.com> Message-ID: <56BE52F6.1070606@oracle.com> Hi Robert, Thanks for the comments. I've uploaded a new iteration here: http://cr.openjdk.java.net/~jlahoda/8131027/webrev.02/ Delta webrev: http://cr.openjdk.java.net/~jlahoda/8131027/webrev.02/delta/webrev/index.html On 11.2.2016 08:43, Robert Field wrote: > HI Jan, > > Review of version 01 --- > > ConsoleIOContext.java -- > > fixes() -- on unexpected character it just cycles, waiting for > another, for a user stuck where not wanted that could be confusing. > If a user is here by mistake and typing ahead then ignoring > unexpected characters increases the chance that a random character > will have an unexpected effect. Some options (depending on the > perceived likelihood of legitimately typing a wrong char: (1) no > loop, if an unexpected char beep and exit (2) loop for a small > number of times, three?, beeping on bad input. (3) print some help > "Type a number" on bad input. I've removed the loop. > > FixComputer[] -- FQN is used in user error: "\nNo candidate FQNs > found to import." Fixed. > > > Eval.java -- > > OK > > > JShell.java -- > > OK > > > SourceCodeAnalysis.java -- > > analyzeType() & listQualifiedNames() -- Nice javadoc. > > QualifiedNames -- > > The constructor is only use by us, exposing in the API is messy > and potentially confusing. Luckily the solution is just to > remove "public" off the constructor, since package-private is > all we need. (while you are at it, can you tuck CompletionInfo > constructor in too (impl used to be in a separate package)?) Fixed. > > isResolvable() -- the methods above refer to "the simple name in > the original code". This calls it "the given identifier", I > assume this is the same thing? I'd stick with "the simple name > in the original code" Fixed. > > SourceCodeAnalysisImpl.java -- > > analyzeType() -- > > It aborts with null when not complete, which seems fine. Why > does it proceed (and add a semicolon) when the input in empty -- > I'd think it should also abort. It turned out the "empty input" section was unnecessary - Completeness.EMPTY has isComplete == false, so the method should automatically abort for the empty input. > Seems you would want to add the semicolon when completeness == > COMPLETE_WITH_SEMI. Done. > The TODO comment says "comment handling" -- this is what > MaskCommentsAndModifiers.java does -- just plug into that -- see > Eval.eval(). The empty input section has been removed. > IMPORT and METHOD are rejected, but I'd think CLASS, ENUM, > ANNOTATION_TYPE, INTERFACE, and VARIABLE would be as well. Yes, thanks; done. > > ... to be continued ... > > ------- > > On mi Fedora (KDE-spin) machine I could get neither Alt-f1 or Alt-Enter > to work. > > Send me a sketch of what user docs would say and I'll incorporate it in > /help I've added the help text into the review. > On 11.2.2016 20:50, Robert Field wrote:> Continuing (see below for first part) ... > > SourceCodeAnalysisImpl.java -- > > Both listQualifiedNames() and analyzeType() -- at.firstCuTree() can > be null, are you safe if that happens? The code/wrap that is being passed to AnalyzeTask should ensure there is always a CompilationUnit, I think. Or do I miss some case where that wouldn't happen? (I've found a few bugs and added some more tests while looking at this.) Any comments are welcome. Thanks! Jan > > > TreeDissector.java -- > > Looks good > > > Tests -- > > Look good. > > > Thanks, > Robert > > >> On Feb 9, 2016, at 5:03 AM, Jan Lahoda > > wrote: >> >> Hi Robert, >> >> Thanks for the comments - I've uploaded an updated webrev here: >> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.01/ >> >> A delta webrev from the previous iteration: >> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.01/delta/webrev/index.html >> >> Some more comments inline. >> >> On 28.1.2016 22:38, Robert Field wrote: >>> This will be a big help -- thanks for coding this. >>> >>> Below is a pre-review. >>> >>> JShell: >>> >>> Fine. >>> >>> >>> Eval: >>> >>> Looks good. >>> >>> >>> SourceCodeAnalysis: >>> >>> This is public API, so names and comments really matter... >> >> I tried to improve the names and javadoc. >> >>> >>> analyzeType() -- There is a description of where the expression >>> begins, but not of where it ends. >>> >>> getDeclaredSymbols() -- Please document what "possible" in >>> "possible FQNs" means. >>> >>> IndexResult -- >>> >>> This class needs a name that is more descriptive of what it is, >>> and the name should align with whatever name and comment are finally >>> given to getDeclaredSymbols(). NameLookup? ResolvedName? ... >>> >>> The class comment should describe what this class is -- and it >>> more than a list of FQNs, as it also deals with the simple name, >>> up-to-dateness, resolvability. >>> getFqns() -- As above, and probably here rather than there, -- >>> what does possible mean? >>> >>> getSimpleNameLength() -- Says "unresolvable", but there is a >>> test (below) for it being resolvable -- probably just remove that word. >>> "right left to", were you meaning "right of"? "for which the >>> candidates could be computed" if they can't be computed, how does that >>> effect this method? Wouldn't return still return the length? Can that >>> phrase just be removed? Is the a reason that the length (rather than >>> the name) is returned? >>> >>> isUpToDate() -- I have no idea what this means. >>> >>> isResolvable() -- Resolvable in the context of what? >>> >>> Throughout class, I would avoid "FQN". See, for example, the use >>> of "fully qualified name" in java/lang. I would spell it out in >>> comments. The java/lang uses "name" as the base for identifiers, but >>> this won't work for getFqns() since it needs to be differentiated from >>> simple names. Perhaps getQualifiedNames(). >>> >>> Nit: Throughout the JShell code and throughout the JDK codebase the >>> convention is that comments start on the line after the "/**" (not on >>> the same line). >>> >>> SourceCodeAnalysisImpl: >>> >>> getDeclaredSymbols() -- My reading of the spec (above) is that the >>> cursor is at the beginning of the identifier to match, this is at the >>> end. Spec needs clarification or ... >> >> The cursor is expected to be immediately after the identifier, I tried >> to clarify that in the javadoc. >> >>> >>> If there is an @author tag on this file, you should certainly be >>> first. >>> >>> currentIndexes and two other fields are declared in the middle of >>> the class. While old conventions forbade this: >>> https://web.archive.org/web/20130627193836/http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html >>> >>> others don't when there is good reason. But I mention this because >>> there are many forward references to all three of these -- so their >>> implied locality is misleading. >>> >>> I would need some code context (comments) to be able to properly >>> review. >> >> I've added comments. Please let me know where I need to add more. >> >>> >>> ConsoleIOContext: >>> >>> Need more context (code comments) for me to be able to review. >> >> I've added comments. Please let me know where I need to add more. >> >>> >>> TreeDissector: >>> >>> See TypePrinter. >>> >>> TypePrinter: >>> >>> My (unspoken) design for this was to be as stand-alone (untied to >>> the JShell architecture) as possible -- esp. since it is subclassed off >>> javac, which is why I had that stuff in higher levels. It could be >>> moved up just one level (to TreeDissector) >> >> Ok, I've moved the method to TreeDissector - TypePrinter would still >> seem to be a nice place for it, to me, though. >> >>> >>> ComputeFQNsTest: >>> >>> Need tests with multiple answers. If the other fields of >>> IndexResult are interesting enough to be present they should be tested. >>> >>> InferTypeTest: >>> >>> Looks pretty good. Maybe some other express forms: boolean >>> operators, .... >> >> Thanks - there turned out to be a bug with binary operators, should be >> fixed now. >> >> Any comments are welcome! >> >> Thanks, >> Jan >> >>> >>> Thanks, >>> Robert >>> >>> >>> On 01/22/16 03:40, Jan Lahoda wrote: >>>> Hello, >>>> >>>> I'd like to ask for a review of a patch that adds two new features: >>>> a) add import: when there is an unresolvable identifier, press >>>> " i" (*), and a list of known FQNs should be printed, >>>> with an ability to easily import any of them. >>>> >>>> b) create variable: when there is an expression, press >>>> " v", and a variable stub will be created, with the >>>> expression as the initializer. >>>> >>>> The "" is either Alt-Enter or Alt-F1, depending on the >>>> platform. For Windows, >>>> >>>> The patch is here: >>>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.00/ >>>> >>>> For Windows, an additional patch to jdk.internal.le is needed (I'll >>>> send a separate review to core-libs for that): >>>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >>>> >>>> Any comments are welcome! >>>> >>>> Thanks, >>>> Jan > From robert.field at oracle.com Fri Feb 12 22:19:03 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 12 Feb 2016 14:19:03 -0800 Subject: RFR 8131027: JShell API/tool: suggest imports for a class In-Reply-To: <56BE52F6.1070606@oracle.com> References: <56A21519.5050109@oracle.com> <56AA8A61.1040404@oracle.com> <56B9E3BF.8000503@oracle.com> <56BE52F6.1070606@oracle.com> Message-ID: <152d790e3d8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> A sufficiently bad syntax error could mean no compilation unit. A null test and I'm thumbs up! -Robert On February 12, 2016 1:47:39 PM Jan Lahoda wrote: > Hi Robert, > > Thanks for the comments. I've uploaded a new iteration here: > http://cr.openjdk.java.net/~jlahoda/8131027/webrev.02/ > > Delta webrev: > http://cr.openjdk.java.net/~jlahoda/8131027/webrev.02/delta/webrev/index.html > > On 11.2.2016 08:43, Robert Field wrote: >> HI Jan, >> >> Review of version 01 --- >> >> ConsoleIOContext.java -- >> >> fixes() -- on unexpected character it just cycles, waiting for >> another, for a user stuck where not wanted that could be confusing. >> If a user is here by mistake and typing ahead then ignoring >> unexpected characters increases the chance that a random character >> will have an unexpected effect. Some options (depending on the >> perceived likelihood of legitimately typing a wrong char: (1) no >> loop, if an unexpected char beep and exit (2) loop for a small >> number of times, three?, beeping on bad input. (3) print some help >> "Type a number" on bad input. > > I've removed the loop. > >> >> FixComputer[] -- FQN is used in user error: "\nNo candidate FQNs >> found to import." > > Fixed. > >> >> >> Eval.java -- >> >> OK >> >> >> JShell.java -- >> >> OK >> >> >> SourceCodeAnalysis.java -- >> >> analyzeType() & listQualifiedNames() -- Nice javadoc. >> >> QualifiedNames -- >> >> The constructor is only use by us, exposing in the API is messy >> and potentially confusing. Luckily the solution is just to >> remove "public" off the constructor, since package-private is >> all we need. (while you are at it, can you tuck CompletionInfo >> constructor in too (impl used to be in a separate package)?) > > Fixed. > >> >> isResolvable() -- the methods above refer to "the simple name in >> the original code". This calls it "the given identifier", I >> assume this is the same thing? I'd stick with "the simple name >> in the original code" > > Fixed. > >> >> SourceCodeAnalysisImpl.java -- >> >> analyzeType() -- >> >> It aborts with null when not complete, which seems fine. Why >> does it proceed (and add a semicolon) when the input in empty -- >> I'd think it should also abort. > > It turned out the "empty input" section was unnecessary - > Completeness.EMPTY has isComplete == false, so the method should > automatically abort for the empty input. > > >> Seems you would want to add the semicolon when completeness == >> COMPLETE_WITH_SEMI. > > Done. > >> The TODO comment says "comment handling" -- this is what >> MaskCommentsAndModifiers.java does -- just plug into that -- see >> Eval.eval(). > > The empty input section has been removed. > >> IMPORT and METHOD are rejected, but I'd think CLASS, ENUM, >> ANNOTATION_TYPE, INTERFACE, and VARIABLE would be as well. > > Yes, thanks; done. > >> >> ... to be continued ... >> >> ------- >> >> On mi Fedora (KDE-spin) machine I could get neither Alt-f1 or Alt-Enter >> to work. >> >> Send me a sketch of what user docs would say and I'll incorporate it in >> /help > > I've added the help text into the review. > >> > On 11.2.2016 20:50, Robert Field wrote:> Continuing (see below for first > part) ... >> >> SourceCodeAnalysisImpl.java -- >> >> Both listQualifiedNames() and analyzeType() -- at.firstCuTree() can >> be null, are you safe if that happens? > > The code/wrap that is being passed to AnalyzeTask should ensure there is > always a CompilationUnit, I think. Or do I miss some case where that > wouldn't happen? (I've found a few bugs and added some more tests while > looking at this.) > > Any comments are welcome. > > Thanks! > > Jan > >> >> >> TreeDissector.java -- >> >> Looks good >> >> >> Tests -- >> >> Look good. >> >> >> Thanks, >> Robert >> >> >>> On Feb 9, 2016, at 5:03 AM, Jan Lahoda >> > wrote: >>> >>> Hi Robert, >>> >>> Thanks for the comments - I've uploaded an updated webrev here: >>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.01/ >>> >>> A delta webrev from the previous iteration: >>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.01/delta/webrev/index.html >>> >>> Some more comments inline. >>> >>> On 28.1.2016 22:38, Robert Field wrote: >>>> This will be a big help -- thanks for coding this. >>>> >>>> Below is a pre-review. >>>> >>>> JShell: >>>> >>>> Fine. >>>> >>>> >>>> Eval: >>>> >>>> Looks good. >>>> >>>> >>>> SourceCodeAnalysis: >>>> >>>> This is public API, so names and comments really matter... >>> >>> I tried to improve the names and javadoc. >>> >>>> >>>> analyzeType() -- There is a description of where the expression >>>> begins, but not of where it ends. >>>> >>>> getDeclaredSymbols() -- Please document what "possible" in >>>> "possible FQNs" means. >>>> >>>> IndexResult -- >>>> >>>> This class needs a name that is more descriptive of what it is, >>>> and the name should align with whatever name and comment are finally >>>> given to getDeclaredSymbols(). NameLookup? ResolvedName? ... >>>> >>>> The class comment should describe what this class is -- and it >>>> more than a list of FQNs, as it also deals with the simple name, >>>> up-to-dateness, resolvability. >>>> getFqns() -- As above, and probably here rather than there, -- >>>> what does possible mean? >>>> >>>> getSimpleNameLength() -- Says "unresolvable", but there is a >>>> test (below) for it being resolvable -- probably just remove that word. >>>> "right left to", were you meaning "right of"? "for which the >>>> candidates could be computed" if they can't be computed, how does that >>>> effect this method? Wouldn't return still return the length? Can that >>>> phrase just be removed? Is the a reason that the length (rather than >>>> the name) is returned? >>>> >>>> isUpToDate() -- I have no idea what this means. >>>> >>>> isResolvable() -- Resolvable in the context of what? >>>> >>>> Throughout class, I would avoid "FQN". See, for example, the use >>>> of "fully qualified name" in java/lang. I would spell it out in >>>> comments. The java/lang uses "name" as the base for identifiers, but >>>> this won't work for getFqns() since it needs to be differentiated from >>>> simple names. Perhaps getQualifiedNames(). >>>> >>>> Nit: Throughout the JShell code and throughout the JDK codebase the >>>> convention is that comments start on the line after the "/**" (not on >>>> the same line). >>>> >>>> SourceCodeAnalysisImpl: >>>> >>>> getDeclaredSymbols() -- My reading of the spec (above) is that the >>>> cursor is at the beginning of the identifier to match, this is at the >>>> end. Spec needs clarification or ... >>> >>> The cursor is expected to be immediately after the identifier, I tried >>> to clarify that in the javadoc. >>> >>>> >>>> If there is an @author tag on this file, you should certainly be >>>> first. >>>> >>>> currentIndexes and two other fields are declared in the middle of >>>> the class. While old conventions forbade this: >>>> https://web.archive.org/web/20130627193836/http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html >>>> >>>> others don't when there is good reason. But I mention this because >>>> there are many forward references to all three of these -- so their >>>> implied locality is misleading. >>>> >>>> I would need some code context (comments) to be able to properly >>>> review. >>> >>> I've added comments. Please let me know where I need to add more. >>> >>>> >>>> ConsoleIOContext: >>>> >>>> Need more context (code comments) for me to be able to review. >>> >>> I've added comments. Please let me know where I need to add more. >>> >>>> >>>> TreeDissector: >>>> >>>> See TypePrinter. >>>> >>>> TypePrinter: >>>> >>>> My (unspoken) design for this was to be as stand-alone (untied to >>>> the JShell architecture) as possible -- esp. since it is subclassed off >>>> javac, which is why I had that stuff in higher levels. It could be >>>> moved up just one level (to TreeDissector) >>> >>> Ok, I've moved the method to TreeDissector - TypePrinter would still >>> seem to be a nice place for it, to me, though. >>> >>>> >>>> ComputeFQNsTest: >>>> >>>> Need tests with multiple answers. If the other fields of >>>> IndexResult are interesting enough to be present they should be tested. >>>> >>>> InferTypeTest: >>>> >>>> Looks pretty good. Maybe some other express forms: boolean >>>> operators, .... >>> >>> Thanks - there turned out to be a bug with binary operators, should be >>> fixed now. >>> >>> Any comments are welcome! >>> >>> Thanks, >>> Jan >>> >>>> >>>> Thanks, >>>> Robert >>>> >>>> >>>> On 01/22/16 03:40, Jan Lahoda wrote: >>>>> Hello, >>>>> >>>>> I'd like to ask for a review of a patch that adds two new features: >>>>> a) add import: when there is an unresolvable identifier, press >>>>> " i" (*), and a list of known FQNs should be printed, >>>>> with an ability to easily import any of them. >>>>> >>>>> b) create variable: when there is an expression, press >>>>> " v", and a variable stub will be created, with the >>>>> expression as the initializer. >>>>> >>>>> The "" is either Alt-Enter or Alt-F1, depending on the >>>>> platform. For Windows, >>>>> >>>>> The patch is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.00/ >>>>> >>>>> For Windows, an additional patch to jdk.internal.le is needed (I'll >>>>> send a separate review to core-libs for that): >>>>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >>>>> >>>>> Any comments are welcome! >>>>> >>>>> Thanks, >>>>> Jan >> From jan.lahoda at oracle.com Mon Feb 15 13:28:58 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 15 Feb 2016 14:28:58 +0100 Subject: RFR 8131027: JShell API/tool: suggest imports for a class In-Reply-To: <152d790e3d8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <56A21519.5050109@oracle.com> <56AA8A61.1040404@oracle.com> <56B9E3BF.8000503@oracle.com> <56BE52F6.1070606@oracle.com> <152d790e3d8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: <56C1D29A.50102@oracle.com> Hi Robert, I am sorry to oppose here, but I couldn't find a way to get a null from BaseTask.firstCuTree() - that would mean that the "cuts" Iterable would need to contain null. "cuts" is filled from JavacTask.parse, and I don't see a way that could contain null (JavacTaskImpl.parseInternal is even dereferencing all CompilationUnitTrees in the list). The JavacParser(/ReplParser).parseCompilationUnit should always return a non-null value, as far as I can tell (even for an empty file, there should be an (empty/without any ClassTrees) CompilationUnitTree instance created). Is there a particular case where firstCuTree() returns null? Thanks, Jan On 12.2.2016 23:19, Robert Field wrote: > A sufficiently bad syntax error could mean no compilation unit. A null > test and I'm thumbs up! > > -Robert > > > > On February 12, 2016 1:47:39 PM Jan Lahoda wrote: > >> Hi Robert, >> >> Thanks for the comments. I've uploaded a new iteration here: >> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.02/ >> >> Delta webrev: >> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.02/delta/webrev/index.html >> >> >> On 11.2.2016 08:43, Robert Field wrote: >>> HI Jan, >>> >>> Review of version 01 --- >>> >>> ConsoleIOContext.java -- >>> >>> fixes() -- on unexpected character it just cycles, waiting for >>> another, for a user stuck where not wanted that could be confusing. >>> If a user is here by mistake and typing ahead then ignoring >>> unexpected characters increases the chance that a random character >>> will have an unexpected effect. Some options (depending on the >>> perceived likelihood of legitimately typing a wrong char: (1) no >>> loop, if an unexpected char beep and exit (2) loop for a small >>> number of times, three?, beeping on bad input. (3) print some help >>> "Type a number" on bad input. >> >> I've removed the loop. >> >>> >>> FixComputer[] -- FQN is used in user error: "\nNo candidate FQNs >>> found to import." >> >> Fixed. >> >>> >>> >>> Eval.java -- >>> >>> OK >>> >>> >>> JShell.java -- >>> >>> OK >>> >>> >>> SourceCodeAnalysis.java -- >>> >>> analyzeType() & listQualifiedNames() -- Nice javadoc. >>> >>> QualifiedNames -- >>> >>> The constructor is only use by us, exposing in the API is messy >>> and potentially confusing. Luckily the solution is just to >>> remove "public" off the constructor, since package-private is >>> all we need. (while you are at it, can you tuck CompletionInfo >>> constructor in too (impl used to be in a separate package)?) >> >> Fixed. >> >>> >>> isResolvable() -- the methods above refer to "the simple name in >>> the original code". This calls it "the given identifier", I >>> assume this is the same thing? I'd stick with "the simple name >>> in the original code" >> >> Fixed. >> >>> >>> SourceCodeAnalysisImpl.java -- >>> >>> analyzeType() -- >>> >>> It aborts with null when not complete, which seems fine. Why >>> does it proceed (and add a semicolon) when the input in empty -- >>> I'd think it should also abort. >> >> It turned out the "empty input" section was unnecessary - >> Completeness.EMPTY has isComplete == false, so the method should >> automatically abort for the empty input. >> >> >>> Seems you would want to add the semicolon when completeness == >>> COMPLETE_WITH_SEMI. >> >> Done. >> >>> The TODO comment says "comment handling" -- this is what >>> MaskCommentsAndModifiers.java does -- just plug into that -- see >>> Eval.eval(). >> >> The empty input section has been removed. >> >>> IMPORT and METHOD are rejected, but I'd think CLASS, ENUM, >>> ANNOTATION_TYPE, INTERFACE, and VARIABLE would be as well. >> >> Yes, thanks; done. >> >>> >>> ... to be continued ... >>> >>> ------- >>> >>> On mi Fedora (KDE-spin) machine I could get neither Alt-f1 or Alt-Enter >>> to work. >>> >>> Send me a sketch of what user docs would say and I'll incorporate it in >>> /help >> >> I've added the help text into the review. >> >>> >> On 11.2.2016 20:50, Robert Field wrote:> Continuing (see below for first >> part) ... >>> >>> SourceCodeAnalysisImpl.java -- >>> >>> Both listQualifiedNames() and analyzeType() -- at.firstCuTree() can >>> be null, are you safe if that happens? >> >> The code/wrap that is being passed to AnalyzeTask should ensure there is >> always a CompilationUnit, I think. Or do I miss some case where that >> wouldn't happen? (I've found a few bugs and added some more tests while >> looking at this.) >> >> Any comments are welcome. >> >> Thanks! >> >> Jan >> >>> >>> >>> TreeDissector.java -- >>> >>> Looks good >>> >>> >>> Tests -- >>> >>> Look good. >>> >>> >>> Thanks, >>> Robert >>> >>> >>>> On Feb 9, 2016, at 5:03 AM, Jan Lahoda >>> > wrote: >>>> >>>> Hi Robert, >>>> >>>> Thanks for the comments - I've uploaded an updated webrev here: >>>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.01/ >>>> >>>> A delta webrev from the previous iteration: >>>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.01/delta/webrev/index.html >>>> >>>> >>>> Some more comments inline. >>>> >>>> On 28.1.2016 22:38, Robert Field wrote: >>>>> This will be a big help -- thanks for coding this. >>>>> >>>>> Below is a pre-review. >>>>> >>>>> JShell: >>>>> >>>>> Fine. >>>>> >>>>> >>>>> Eval: >>>>> >>>>> Looks good. >>>>> >>>>> >>>>> SourceCodeAnalysis: >>>>> >>>>> This is public API, so names and comments really matter... >>>> >>>> I tried to improve the names and javadoc. >>>> >>>>> >>>>> analyzeType() -- There is a description of where the expression >>>>> begins, but not of where it ends. >>>>> >>>>> getDeclaredSymbols() -- Please document what "possible" in >>>>> "possible FQNs" means. >>>>> >>>>> IndexResult -- >>>>> >>>>> This class needs a name that is more descriptive of what it >>>>> is, >>>>> and the name should align with whatever name and comment are finally >>>>> given to getDeclaredSymbols(). NameLookup? ResolvedName? ... >>>>> >>>>> The class comment should describe what this class is -- and it >>>>> more than a list of FQNs, as it also deals with the simple name, >>>>> up-to-dateness, resolvability. >>>>> getFqns() -- As above, and probably here rather than there, -- >>>>> what does possible mean? >>>>> >>>>> getSimpleNameLength() -- Says "unresolvable", but there is a >>>>> test (below) for it being resolvable -- probably just remove that >>>>> word. >>>>> "right left to", were you meaning "right of"? "for which the >>>>> candidates could be computed" if they can't be computed, how does that >>>>> effect this method? Wouldn't return still return the length? Can >>>>> that >>>>> phrase just be removed? Is the a reason that the length (rather than >>>>> the name) is returned? >>>>> >>>>> isUpToDate() -- I have no idea what this means. >>>>> >>>>> isResolvable() -- Resolvable in the context of what? >>>>> >>>>> Throughout class, I would avoid "FQN". See, for example, the use >>>>> of "fully qualified name" in java/lang. I would spell it out in >>>>> comments. The java/lang uses "name" as the base for identifiers, but >>>>> this won't work for getFqns() since it needs to be differentiated from >>>>> simple names. Perhaps getQualifiedNames(). >>>>> >>>>> Nit: Throughout the JShell code and throughout the JDK codebase >>>>> the >>>>> convention is that comments start on the line after the "/**" (not on >>>>> the same line). >>>>> >>>>> SourceCodeAnalysisImpl: >>>>> >>>>> getDeclaredSymbols() -- My reading of the spec (above) is that the >>>>> cursor is at the beginning of the identifier to match, this is at the >>>>> end. Spec needs clarification or ... >>>> >>>> The cursor is expected to be immediately after the identifier, I tried >>>> to clarify that in the javadoc. >>>> >>>>> >>>>> If there is an @author tag on this file, you should certainly be >>>>> first. >>>>> >>>>> currentIndexes and two other fields are declared in the middle of >>>>> the class. While old conventions forbade this: >>>>> https://web.archive.org/web/20130627193836/http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html >>>>> >>>>> >>>>> others don't when there is good reason. But I mention this >>>>> because >>>>> there are many forward references to all three of these -- so their >>>>> implied locality is misleading. >>>>> >>>>> I would need some code context (comments) to be able to properly >>>>> review. >>>> >>>> I've added comments. Please let me know where I need to add more. >>>> >>>>> >>>>> ConsoleIOContext: >>>>> >>>>> Need more context (code comments) for me to be able to review. >>>> >>>> I've added comments. Please let me know where I need to add more. >>>> >>>>> >>>>> TreeDissector: >>>>> >>>>> See TypePrinter. >>>>> >>>>> TypePrinter: >>>>> >>>>> My (unspoken) design for this was to be as stand-alone (untied to >>>>> the JShell architecture) as possible -- esp. since it is subclassed >>>>> off >>>>> javac, which is why I had that stuff in higher levels. It could be >>>>> moved up just one level (to TreeDissector) >>>> >>>> Ok, I've moved the method to TreeDissector - TypePrinter would still >>>> seem to be a nice place for it, to me, though. >>>> >>>>> >>>>> ComputeFQNsTest: >>>>> >>>>> Need tests with multiple answers. If the other fields of >>>>> IndexResult are interesting enough to be present they should be >>>>> tested. >>>>> >>>>> InferTypeTest: >>>>> >>>>> Looks pretty good. Maybe some other express forms: boolean >>>>> operators, .... >>>> >>>> Thanks - there turned out to be a bug with binary operators, should be >>>> fixed now. >>>> >>>> Any comments are welcome! >>>> >>>> Thanks, >>>> Jan >>>> >>>>> >>>>> Thanks, >>>>> Robert >>>>> >>>>> >>>>> On 01/22/16 03:40, Jan Lahoda wrote: >>>>>> Hello, >>>>>> >>>>>> I'd like to ask for a review of a patch that adds two new features: >>>>>> a) add import: when there is an unresolvable identifier, press >>>>>> " i" (*), and a list of known FQNs should be printed, >>>>>> with an ability to easily import any of them. >>>>>> >>>>>> b) create variable: when there is an expression, press >>>>>> " v", and a variable stub will be created, with the >>>>>> expression as the initializer. >>>>>> >>>>>> The "" is either Alt-Enter or Alt-F1, depending on the >>>>>> platform. For Windows, >>>>>> >>>>>> The patch is here: >>>>>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.00/ >>>>>> >>>>>> For Windows, an additional patch to jdk.internal.le is needed (I'll >>>>>> send a separate review to core-libs for that): >>>>>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >>>>>> >>>>>> Any comments are welcome! >>>>>> >>>>>> Thanks, >>>>>> Jan >>> > > From robert.field at oracle.com Mon Feb 15 16:32:28 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 15 Feb 2016 08:32:28 -0800 Subject: RFR 8131027: JShell API/tool: suggest imports for a class In-Reply-To: <56C1D29A.50102@oracle.com> References: <56A21519.5050109@oracle.com> <56AA8A61.1040404@oracle.com> <56B9E3BF.8000503@oracle.com> <56BE52F6.1070606@oracle.com> <152d790e3d8.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> <56C1D29A.50102@oracle.com> Message-ID: <56C1FD9C.8080107@oracle.com> On 02/15/16 05:28, Jan Lahoda wrote: > Hi Robert, > > I am sorry to oppose here, but I couldn't find a way to get a null > from BaseTask.firstCuTree() - that would mean that the "cuts" Iterable > would need to contain null. "cuts" is filled from JavacTask.parse, and > I don't see a way that could contain null (JavacTaskImpl.parseInternal > is even dereferencing all CompilationUnitTrees in the list). The > JavacParser(/ReplParser).parseCompilationUnit should always return a > non-null value, as far as I can tell (even for an empty file, there > should be an (empty/without any ClassTrees) CompilationUnitTree > instance created). Is there a particular case where firstCuTree() > returns null? You are right. For one, firstCuTree() is ...iterator().next() which will throw an exception rather than return null. And that exception should never be thrown since the parser will return a Compilation Unit tree (not null) in all cases. Retract that. Sorry. So, thumbs up! -Robert > > Thanks, > Jan > > On 12.2.2016 23:19, Robert Field wrote: >> A sufficiently bad syntax error could mean no compilation unit. A null >> test and I'm thumbs up! >> >> -Robert >> >> >> >> On February 12, 2016 1:47:39 PM Jan Lahoda >> wrote: >> >>> Hi Robert, >>> >>> Thanks for the comments. I've uploaded a new iteration here: >>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.02/ >>> >>> Delta webrev: >>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.02/delta/webrev/index.html >>> >>> >>> >>> On 11.2.2016 08:43, Robert Field wrote: >>>> HI Jan, >>>> >>>> Review of version 01 --- >>>> >>>> ConsoleIOContext.java -- >>>> >>>> fixes() -- on unexpected character it just cycles, waiting for >>>> another, for a user stuck where not wanted that could be >>>> confusing. >>>> If a user is here by mistake and typing ahead then ignoring >>>> unexpected characters increases the chance that a random character >>>> will have an unexpected effect. Some options (depending on the >>>> perceived likelihood of legitimately typing a wrong char: (1) no >>>> loop, if an unexpected char beep and exit (2) loop for a small >>>> number of times, three?, beeping on bad input. (3) print some help >>>> "Type a number" on bad input. >>> >>> I've removed the loop. >>> >>>> >>>> FixComputer[] -- FQN is used in user error: "\nNo candidate FQNs >>>> found to import." >>> >>> Fixed. >>> >>>> >>>> >>>> Eval.java -- >>>> >>>> OK >>>> >>>> >>>> JShell.java -- >>>> >>>> OK >>>> >>>> >>>> SourceCodeAnalysis.java -- >>>> >>>> analyzeType() & listQualifiedNames() -- Nice javadoc. >>>> >>>> QualifiedNames -- >>>> >>>> The constructor is only use by us, exposing in the API is >>>> messy >>>> and potentially confusing. Luckily the solution is just to >>>> remove "public" off the constructor, since package-private is >>>> all we need. (while you are at it, can you tuck CompletionInfo >>>> constructor in too (impl used to be in a separate package)?) >>> >>> Fixed. >>> >>>> >>>> isResolvable() -- the methods above refer to "the simple >>>> name in >>>> the original code". This calls it "the given identifier", I >>>> assume this is the same thing? I'd stick with "the simple >>>> name >>>> in the original code" >>> >>> Fixed. >>> >>>> >>>> SourceCodeAnalysisImpl.java -- >>>> >>>> analyzeType() -- >>>> >>>> It aborts with null when not complete, which seems fine. Why >>>> does it proceed (and add a semicolon) when the input in >>>> empty -- >>>> I'd think it should also abort. >>> >>> It turned out the "empty input" section was unnecessary - >>> Completeness.EMPTY has isComplete == false, so the method should >>> automatically abort for the empty input. >>> >>> >>>> Seems you would want to add the semicolon when completeness == >>>> COMPLETE_WITH_SEMI. >>> >>> Done. >>> >>>> The TODO comment says "comment handling" -- this is what >>>> MaskCommentsAndModifiers.java does -- just plug into that >>>> -- see >>>> Eval.eval(). >>> >>> The empty input section has been removed. >>> >>>> IMPORT and METHOD are rejected, but I'd think CLASS, ENUM, >>>> ANNOTATION_TYPE, INTERFACE, and VARIABLE would be as well. >>> >>> Yes, thanks; done. >>> >>>> >>>> ... to be continued ... >>>> >>>> ------- >>>> >>>> On mi Fedora (KDE-spin) machine I could get neither Alt-f1 or >>>> Alt-Enter >>>> to work. >>>> >>>> Send me a sketch of what user docs would say and I'll incorporate >>>> it in >>>> /help >>> >>> I've added the help text into the review. >>> >>>> >>> On 11.2.2016 20:50, Robert Field wrote:> Continuing (see below for >>> first >>> part) ... >>>> >>>> SourceCodeAnalysisImpl.java -- >>>> >>>> Both listQualifiedNames() and analyzeType() -- at.firstCuTree() >>>> can >>>> be null, are you safe if that happens? >>> >>> The code/wrap that is being passed to AnalyzeTask should ensure >>> there is >>> always a CompilationUnit, I think. Or do I miss some case where that >>> wouldn't happen? (I've found a few bugs and added some more tests while >>> looking at this.) >>> >>> Any comments are welcome. >>> >>> Thanks! >>> >>> Jan >>> >>>> >>>> >>>> TreeDissector.java -- >>>> >>>> Looks good >>>> >>>> >>>> Tests -- >>>> >>>> Look good. >>>> >>>> >>>> Thanks, >>>> Robert >>>> >>>> >>>>> On Feb 9, 2016, at 5:03 AM, Jan Lahoda >>>> > wrote: >>>>> >>>>> Hi Robert, >>>>> >>>>> Thanks for the comments - I've uploaded an updated webrev here: >>>>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.01/ >>>>> >>>>> A delta webrev from the previous iteration: >>>>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.01/delta/webrev/index.html >>>>> >>>>> >>>>> >>>>> Some more comments inline. >>>>> >>>>> On 28.1.2016 22:38, Robert Field wrote: >>>>>> This will be a big help -- thanks for coding this. >>>>>> >>>>>> Below is a pre-review. >>>>>> >>>>>> JShell: >>>>>> >>>>>> Fine. >>>>>> >>>>>> >>>>>> Eval: >>>>>> >>>>>> Looks good. >>>>>> >>>>>> >>>>>> SourceCodeAnalysis: >>>>>> >>>>>> This is public API, so names and comments really matter... >>>>> >>>>> I tried to improve the names and javadoc. >>>>> >>>>>> >>>>>> analyzeType() -- There is a description of where the expression >>>>>> begins, but not of where it ends. >>>>>> >>>>>> getDeclaredSymbols() -- Please document what "possible" in >>>>>> "possible FQNs" means. >>>>>> >>>>>> IndexResult -- >>>>>> >>>>>> This class needs a name that is more descriptive of what it >>>>>> is, >>>>>> and the name should align with whatever name and comment are finally >>>>>> given to getDeclaredSymbols(). NameLookup? ResolvedName? ... >>>>>> >>>>>> The class comment should describe what this class is -- >>>>>> and it >>>>>> more than a list of FQNs, as it also deals with the simple name, >>>>>> up-to-dateness, resolvability. >>>>>> getFqns() -- As above, and probably here rather than >>>>>> there, -- >>>>>> what does possible mean? >>>>>> >>>>>> getSimpleNameLength() -- Says "unresolvable", but there is a >>>>>> test (below) for it being resolvable -- probably just remove that >>>>>> word. >>>>>> "right left to", were you meaning "right of"? "for which the >>>>>> candidates could be computed" if they can't be computed, how does >>>>>> that >>>>>> effect this method? Wouldn't return still return the length? Can >>>>>> that >>>>>> phrase just be removed? Is the a reason that the length (rather >>>>>> than >>>>>> the name) is returned? >>>>>> >>>>>> isUpToDate() -- I have no idea what this means. >>>>>> >>>>>> isResolvable() -- Resolvable in the context of what? >>>>>> >>>>>> Throughout class, I would avoid "FQN". See, for example, the >>>>>> use >>>>>> of "fully qualified name" in java/lang. I would spell it out in >>>>>> comments. The java/lang uses "name" as the base for >>>>>> identifiers, but >>>>>> this won't work for getFqns() since it needs to be differentiated >>>>>> from >>>>>> simple names. Perhaps getQualifiedNames(). >>>>>> >>>>>> Nit: Throughout the JShell code and throughout the JDK codebase >>>>>> the >>>>>> convention is that comments start on the line after the "/**" >>>>>> (not on >>>>>> the same line). >>>>>> >>>>>> SourceCodeAnalysisImpl: >>>>>> >>>>>> getDeclaredSymbols() -- My reading of the spec (above) is >>>>>> that the >>>>>> cursor is at the beginning of the identifier to match, this is at >>>>>> the >>>>>> end. Spec needs clarification or ... >>>>> >>>>> The cursor is expected to be immediately after the identifier, I >>>>> tried >>>>> to clarify that in the javadoc. >>>>> >>>>>> >>>>>> If there is an @author tag on this file, you should certainly be >>>>>> first. >>>>>> >>>>>> currentIndexes and two other fields are declared in the >>>>>> middle of >>>>>> the class. While old conventions forbade this: >>>>>> https://web.archive.org/web/20130627193836/http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html >>>>>> >>>>>> >>>>>> >>>>>> others don't when there is good reason. But I mention this >>>>>> because >>>>>> there are many forward references to all three of these -- so their >>>>>> implied locality is misleading. >>>>>> >>>>>> I would need some code context (comments) to be able to properly >>>>>> review. >>>>> >>>>> I've added comments. Please let me know where I need to add more. >>>>> >>>>>> >>>>>> ConsoleIOContext: >>>>>> >>>>>> Need more context (code comments) for me to be able to review. >>>>> >>>>> I've added comments. Please let me know where I need to add more. >>>>> >>>>>> >>>>>> TreeDissector: >>>>>> >>>>>> See TypePrinter. >>>>>> >>>>>> TypePrinter: >>>>>> >>>>>> My (unspoken) design for this was to be as stand-alone >>>>>> (untied to >>>>>> the JShell architecture) as possible -- esp. since it is subclassed >>>>>> off >>>>>> javac, which is why I had that stuff in higher levels. It could be >>>>>> moved up just one level (to TreeDissector) >>>>> >>>>> Ok, I've moved the method to TreeDissector - TypePrinter would still >>>>> seem to be a nice place for it, to me, though. >>>>> >>>>>> >>>>>> ComputeFQNsTest: >>>>>> >>>>>> Need tests with multiple answers. If the other fields of >>>>>> IndexResult are interesting enough to be present they should be >>>>>> tested. >>>>>> >>>>>> InferTypeTest: >>>>>> >>>>>> Looks pretty good. Maybe some other express forms: boolean >>>>>> operators, .... >>>>> >>>>> Thanks - there turned out to be a bug with binary operators, >>>>> should be >>>>> fixed now. >>>>> >>>>> Any comments are welcome! >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>>>> >>>>>> Thanks, >>>>>> Robert >>>>>> >>>>>> >>>>>> On 01/22/16 03:40, Jan Lahoda wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I'd like to ask for a review of a patch that adds two new features: >>>>>>> a) add import: when there is an unresolvable identifier, press >>>>>>> " i" (*), and a list of known FQNs should be >>>>>>> printed, >>>>>>> with an ability to easily import any of them. >>>>>>> >>>>>>> b) create variable: when there is an expression, press >>>>>>> " v", and a variable stub will be created, with the >>>>>>> expression as the initializer. >>>>>>> >>>>>>> The "" is either Alt-Enter or Alt-F1, depending >>>>>>> on the >>>>>>> platform. For Windows, >>>>>>> >>>>>>> The patch is here: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8131027/webrev.00/ >>>>>>> >>>>>>> For Windows, an additional patch to jdk.internal.le is needed (I'll >>>>>>> send a separate review to core-libs for that): >>>>>>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >>>>>>> >>>>>>> Any comments are welcome! >>>>>>> >>>>>>> Thanks, >>>>>>> Jan >>>> >> >> From robert.field at oracle.com Sat Feb 20 01:23:47 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 19 Feb 2016 17:23:47 -0800 Subject: RFR 8148316: jshell tool: Configurable output format In-Reply-To: <2A1F2501-51F0-429F-A270-421F8BDB3D3C@oracle.com> References: <56AAE93F.9070205@oracle.com> <2A1F2501-51F0-429F-A270-421F8BDB3D3C@oracle.com> Message-ID: <56C7C023.60405@oracle.com> Other changes have gone back since I put this out for review. This is just a refresh sync'ed to the current dev repo. And with fixed copyrights -- thanks, Shinya. Bugs (the second (unrelated) bug was discovered and fixed in the process of testing): https://bugs.openjdk.java.net/browse/JDK-8148316 https://bugs.openjdk.java.net/browse/JDK-8149524 Webrev: http://cr.openjdk.java.net/~rfield/8148316v8.webrev/ An example output configuration (Open with /open): http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh Thanks, Robert From joe.darcy at oracle.com Tue Feb 23 18:10:45 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 23 Feb 2016 10:10:45 -0800 Subject: RFR for JDK 9 fix of JDK-8150427: Demote ToolReloadTest.java and mark as intermittently failing Message-ID: <56CCA0A5.9090201@oracle.com> Hello, The test jdk/jshell/ToolReloadTest.java has been seen to intermittently fail (JDK-8149046). Until that failure is addressed, the test should be marked as "@key intermittent" and the test should be demoted from tier 1 to tier 2. Patch below. Thanks, -Joe diff -r 3cdfbbdb6f61 test/TEST.groups --- a/test/TEST.groups Mon Feb 22 16:17:25 2016 -0800 +++ b/test/TEST.groups Tue Feb 23 09:52:43 2016 -0800 @@ -22,15 +22,17 @@ # Tiered testing definitions -# All langtools tests are tier 1. +# (Nearly) all langtools tests are tier 1. tier1 = \ com \ jdk \ lib \ - tools + tools \ + -jdk/jshell/ToolReloadTest.java -# No langtools tests are tier 2. -tier2 = +# (Almost) No langtools tests are tier 2. +tier2 = \ + jdk/jshell/ToolReloadTest.java # No langtools tests are tier 3 either. tier3 = diff -r 3cdfbbdb6f61 test/jdk/jshell/ToolReloadTest.java --- a/test/jdk/jshell/ToolReloadTest.java Mon Feb 22 16:17:25 2016 -0800 +++ b/test/jdk/jshell/ToolReloadTest.java Tue Feb 23 09:52:43 2016 -0800 @@ -31,6 +31,7 @@ * @library /tools/lib * @build KullaTesting TestingInputStream ToolBox Compiler * @run testng ToolReloadTest + * @key intermittent */ import java.nio.file.Path; From jonathan.gibbons at oracle.com Tue Feb 23 18:50:28 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 23 Feb 2016 10:50:28 -0800 Subject: RFR for JDK 9 fix of JDK-8150427: Demote ToolReloadTest.java and mark as intermittently failing In-Reply-To: <56CCA0A5.9090201@oracle.com> References: <56CCA0A5.9090201@oracle.com> Message-ID: <56CCA9F4.9090906@oracle.com> Looks good to me, although I would recommend placing the @key tag earlier in the test description (before or after @library) as a matter of style. -- Jon On 02/23/2016 10:10 AM, joe darcy wrote: > Hello, > > The test > > jdk/jshell/ToolReloadTest.java > > has been seen to intermittently fail (JDK-8149046). Until that failure > is addressed, the test should be marked as "@key intermittent" and the > test should be demoted from tier 1 to tier 2. > > Patch below. > > Thanks, > > -Joe > > > diff -r 3cdfbbdb6f61 test/TEST.groups > --- a/test/TEST.groups Mon Feb 22 16:17:25 2016 -0800 > +++ b/test/TEST.groups Tue Feb 23 09:52:43 2016 -0800 > @@ -22,15 +22,17 @@ > > # Tiered testing definitions > > -# All langtools tests are tier 1. > +# (Nearly) all langtools tests are tier 1. > tier1 = \ > com \ > jdk \ > lib \ > - tools > + tools \ > + -jdk/jshell/ToolReloadTest.java > > -# No langtools tests are tier 2. > -tier2 = > +# (Almost) No langtools tests are tier 2. > +tier2 = \ > + jdk/jshell/ToolReloadTest.java > > # No langtools tests are tier 3 either. > tier3 = > diff -r 3cdfbbdb6f61 test/jdk/jshell/ToolReloadTest.java > --- a/test/jdk/jshell/ToolReloadTest.java Mon Feb 22 16:17:25 2016 > -0800 > +++ b/test/jdk/jshell/ToolReloadTest.java Tue Feb 23 09:52:43 2016 > -0800 > @@ -31,6 +31,7 @@ > * @library /tools/lib > * @build KullaTesting TestingInputStream ToolBox Compiler > * @run testng ToolReloadTest > + * @key intermittent > */ > > import java.nio.file.Path; > From jan.lahoda at oracle.com Fri Feb 26 13:20:46 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 26 Feb 2016 14:20:46 +0100 Subject: RFR 8148316: jshell tool: Configurable output format In-Reply-To: <56C7C023.60405@oracle.com> References: <56AAE93F.9070205@oracle.com> <2A1F2501-51F0-429F-A270-421F8BDB3D3C@oracle.com> <56C7C023.60405@oracle.com> Message-ID: <56D0512E.5020507@oracle.com> Comments on the code: -the help could be more descriptive - describing the relationship between format and field, etc. Also: -> /help /set [snip] /set See /set -> /set | The /set command requires arguments. See: /help /set -"/set format" prints a help, but "/set field" crashes jshell for me: -> /set field Exception in thread "main" java.lang.NullPointerException at jdk.internal.jshell.tool.JShellTool$1FormatSetter.parseFormatSelector(JShellTool.java:1782) at jdk.internal.jshell.tool.JShellTool$1FormatSetter.setField(JShellTool.java:1592) at jdk.internal.jshell.tool.JShellTool.cmdSet(JShellTool.java:1836) at jdk.internal.jshell.tool.JShellTool.lambda$new$43(JShellTool.java:1435) at jdk.internal.jshell.tool.JShellTool.processCommand(JShellTool.java:1021) at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:963) at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:760) at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:733) at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:723) -generally, I'd suggest to also include tests for invalid input -the output for "/set field foo foo" is: | | Error: Not a valid case: foo -- must be one of when action resolve name type result pre post errorpre errorpost Note the doubled '|', and also I'd suggest to wrap 'when action resolve name type result pre post errorpre errorpost' with quotes to make it more obvious that is a list of keywords. -String.toLowerCase() may produce surprising result on some locales, I'd suggest to use toLowerCase(Locale.US) in this patch -the JShellTool.cmdSet method has a very (very) long local class. It seems that a class is may be not necessary at all, and the parsing could be done using ordinary methods. So I'd suggest to avoid this local class, replacing it with methods in the enclosing class. Or, maybe, this configurable format is big enough to have its own class? -nit: the /set command registration has its own initializer block, I assume that could be merged into the main command registration block? Jan On 20.2.2016 02:23, Robert Field wrote: > Other changes have gone back since I put this out for review. This is > just a refresh sync'ed to the current dev repo. And with fixed > copyrights -- thanks, Shinya. > > Bugs (the second (unrelated) bug was discovered and fixed in the process > of testing): > https://bugs.openjdk.java.net/browse/JDK-8148316 > https://bugs.openjdk.java.net/browse/JDK-8149524 > > Webrev: > http://cr.openjdk.java.net/~rfield/8148316v8.webrev/ > > An example output configuration (Open with /open): > http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh > > Thanks, > Robert > From volker.simonis at gmail.com Mon Feb 29 09:20:01 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 29 Feb 2016 10:20:01 +0100 Subject: Fwd: RFR(XS): 8150632: jdk.jshell.TaskFactory should use jdk.Version to check for java.specification.version In-Reply-To: References: Message-ID: Also forwarding to kulla-dev which may be more appropriate than compiler-dev. ---------- Forwarded message ---------- From: Volker Simonis Date: Thu, Feb 25, 2016 at 1:11 PM Subject: RFR(XS): 8150632: jdk.jshell.TaskFactory should use jdk.Version to check for java.specification.version To: compiler-dev at openjdk.java.net Hi, can I please have a review for the following small patch which fixes a problem with the jshell java.specification.version check: http://cr.openjdk.java.net/~simonis/webrevs/2016/8150632/ https://bugs.openjdk.java.net/browse/JDK-8150632 Currently, jdk.jshell.TaskFactory does a hard check against java.specification.version being "9". Until JDK-8149519 [1] will be resolved, this check will fail for any newer Java release (i.e. 9.0.0.1). But even if JDK-8149519 will be resolved, I think the compare should actually check that java.specification.version is greater or equal to "9". This can be easily done with the new jdk.Version API. Thank you and best regards, Volker [1] https://bugs.openjdk.java.net/browse/JDK-8149519 From jan.lahoda at oracle.com Mon Feb 29 18:30:57 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 29 Feb 2016 19:30:57 +0100 Subject: @ignore the ComputeFQNsTest.java Message-ID: <56D48E61.9020706@oracle.com> Hello, The recently added ComputeFQNsTest.testSuspendIndexing test is currently failing on Windows. I'd like to ignore it temporarily: > diff -r ddfdf0304052 test/jdk/jshell/ComputeFQNsTest.java > --- a/test/jdk/jshell/ComputeFQNsTest.java Mon Feb 29 11:54:06 2016 +0100 > +++ b/test/jdk/jshell/ComputeFQNsTest.java Mon Feb 29 19:28:49 2016 +0100 > @@ -73,6 +73,7 @@ > assertInferredFQNs("class X { ArrayList", "ArrayList".length(), false, "java.util.ArrayList"); > } > > + @Test(enabled = false) //JDK-8150860 > public void testSuspendIndexing() throws Exception { > compiler.compile(outDir, "package test; public class FQNTest { }"); > String jarName = "test.jar"; Thanks, Jan From robert.field at oracle.com Mon Feb 29 20:02:58 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 29 Feb 2016 12:02:58 -0800 Subject: RFR 8148316: jshell tool: Configurable output format In-Reply-To: <56D0512E.5020507@oracle.com> References: <56AAE93F.9070205@oracle.com> <2A1F2501-51F0-429F-A270-421F8BDB3D3C@oracle.com> <56C7C023.60405@oracle.com> <56D0512E.5020507@oracle.com> Message-ID: <56D4A3F2.9010101@oracle.com> On 02/26/16 05:20, Jan Lahoda wrote: > Comments on the code: > -the help could be more descriptive - describing the relationship > between format and field, etc. Also: > -> /help /set > [snip] > /set > > See /set > > -> /set > | The /set command requires arguments. See: /help /set ;-) Oops! > > > -"/set format" prints a help, but "/set field" crashes jshell for me: > -> /set field > Exception in thread "main" java.lang.NullPointerException > at > jdk.internal.jshell.tool.JShellTool$1FormatSetter.parseFormatSelector(JShellTool.java:1782) > at > jdk.internal.jshell.tool.JShellTool$1FormatSetter.setField(JShellTool.java:1592) > at > jdk.internal.jshell.tool.JShellTool.cmdSet(JShellTool.java:1836) > at > jdk.internal.jshell.tool.JShellTool.lambda$new$43(JShellTool.java:1435) > at > jdk.internal.jshell.tool.JShellTool.processCommand(JShellTool.java:1021) > at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:963) > at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:760) > at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:733) > at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:723) I'll clean up the help. > > -generally, I'd suggest to also include tests for invalid input Good idea. > > -the output for "/set field foo foo" is: > | | Error: Not a valid case: foo -- must be one of when action > resolve name type result pre post errorpre errorpost > > Note the doubled '|', and also I'd suggest to wrap 'when action > resolve name type result pre post errorpre errorpost' with quotes to > make it more obvious that is a list of keywords. Oy! Reads like nonsense without some punctuation. How about a colon? | Error: Not a valid case: foo -- must be one of: when action resolve name type result pre post errorpre errorpost OK, will fix the double | | > -String.toLowerCase() may produce surprising result on some locales, > I'd suggest to use toLowerCase(Locale.US) in this patch Thanks. > > -the JShellTool.cmdSet method has a very (very) long local class. It > seems that a class is may be not necessary at all, and the parsing > could be done using ordinary methods. So I'd suggest to avoid this > local class, replacing it with methods in the enclosing class. Or, > maybe, this configurable format is big enough to have its own class? Moving the format command class to its own top-level class/file is the reorganization I was referring to when you told me you were in the middle of reviewing, so I deferred. Will do that now. > > -nit: the /set command registration has its own initializer block, I > assume that could be merged into the main command registration block? I set that apart to reduce clashes on merging with the /help changeset. I can merge in now. Thanks! Will update and send out a new webrev. -Robert > > Jan > > On 20.2.2016 02:23, Robert Field wrote: >> Other changes have gone back since I put this out for review. This is >> just a refresh sync'ed to the current dev repo. And with fixed >> copyrights -- thanks, Shinya. >> >> Bugs (the second (unrelated) bug was discovered and fixed in the process >> of testing): >> https://bugs.openjdk.java.net/browse/JDK-8148316 >> https://bugs.openjdk.java.net/browse/JDK-8149524 >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8148316v8.webrev/ >> >> An example output configuration (Open with /open): >> http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh >> >> Thanks, >> Robert >>