From robert.field at oracle.com  Fri Dec  1 00:49:17 2017
From: robert.field at oracle.com (Robert Field)
Date: Thu, 30 Nov 2017 16:49:17 -0800
Subject: (copy editors) RFR 8179858: jshell tool: sync nomenclature from
 reference to online /help
Message-ID: <5A20A70D.10408@oracle.com>

This proceeded from a bug to sync /help with the nomenclature in the 
jshell Tool Reference.
In the process, fresh eyes also addressed other glaring issues in /help.
Please review, comments welcome from all.

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8179858

Webrev:

     http://cr.openjdk.java.net/~rfield/8179858v0.webrev/

Thanks,
Robert


From jan.lahoda at oracle.com  Mon Dec  4 17:35:44 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 4 Dec 2017 18:35:44 +0100
Subject: RFR 8191455/8191456:
 StartOptionTest/ToolProviderTest.testExitCode() and
 ExternalEditorTest.testStatementMush() failed
In-Reply-To: <5A18D236.1040302@oracle.com>
References: <5A18D236.1040302@oracle.com>
Message-ID: <5A258770.1040903@oracle.com>

Seems OK to me.

Jan

On 25.11.2017 03:15, Robert Field wrote:
> Please review.
>
> Bugs:
>
>      8191455: jdk/jshell/StartOptionTest.java and
> jdk/jshell/ToolProviderTest.java failed after changeset e0f08a
>      https://bugs.openjdk.java.net/browse/JDK-8191455
>      These saw failures on Windows due to line-end mismatches.  Fixed by
> normalizing line-ends.
>
>      8191456: jdk/jshell/ExternalEditorTest.java testStatementMush():
> failure
>      https://bugs.openjdk.java.net/browse/JDK-8191456
>      The expected output is not seen, not reproducible locally, Disabled
> the specific test and filed issue to enable.
>
> This includes undoing:
>
>      8191631: Problem list jdk/jshell/StartOptionTest.java,
> jdk/jshell/ToolProviderTest.java and jdk/jshell/ExternalEditorTest.java
> temporarily
>      https://bugs.openjdk.java.net/browse/JDK-8191631
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8191455v0.webrev/
>
> Thanks,
> Robert
>

From daniel.smith at oracle.com  Mon Dec  4 20:11:00 2017
From: daniel.smith at oracle.com (Dan Smith)
Date: Mon, 4 Dec 2017 13:11:00 -0700
Subject: (copy editors) RFR 8179858: jshell tool: sync nomenclature from
 reference to online /help
In-Reply-To: <5A20A70D.10408@oracle.com>
References: <5A20A70D.10408@oracle.com>
Message-ID: <AA651E9A-BFD9-4D15-9062-00339CCC0050@oracle.com>

Didn't find any serious problems, but here's a list of minor tweaks.

?Dan

-----

--class-path, --module-path: I don't understand the purpose of the '*' at the end, but I assume it's intentional.

"load-file": I'd tend to avoid hyphens in compound nouns and stick to "load file", but apparently conventions vary:
https://en.oxforddictionaries.com/punctuation/hyphen

"command-line": Same

"For Linux and macOS": are there other supported Unix OSes? For comparison, here's the Javadoc for System.lineSeparator: "On UNIX systems, it returns "\n"; on Microsoft Windows systems it returns "\r\n".

"A path is the directories and archives to search" --> "A path **lists** the directories and archives to search"

"module-private package": I don't know my Jigsaw terminology very well, but this may not be a standard term. javac -X says "Specify a package to be considered as exported from its defining module"

"Show the snippets, prefaced with the snippet ID": either "each snippet" or "their snippet IDs"

/save: inconsistent use of periods (this comment may apply more broadly?should do a quick pass to check)

/types: An enum is a kind of class, so it's not necessary to list it separately (and it makes me think "what about annotation types?"). Just "classes and interfaces" is fine. I'd also replace "types" with "type declarations" throughout, because "type" is such an overloaded term.

"since jshell was entered, or a /reset, or /reload command was executed" --> "since jshell was entered, or a /reset or /reload command was executed"

"Errors will display" --> "Errors will be displayed"

"the snippets will be replayed -- the replay is not shown, however, errors will display" --> "the snippits will be replayed. The replay is not shown, **but any** errors will *be displayed*."

ID ranges: these are listed everywhere as a distinct variant, but help.id suggests that they can appear within a list, interleaved with non-ranges. Which is it? (If the latter, maybe don't mention ranges at all for /vars, etc., and explain elsewhere that an "ID" may be a range of simple IDs. Or, if that's too obscure, try "specified snippet ID or range of snippet IDs" in /vars, etc. Or just give the list variant in /var, etc., more details about ranges.)

"when the jshell is started" "when jshell is restarted" "since this jshell was launched" "debugging of the jshell" "information about jshell": Need to decide is "jshell" refers to the command, or if it's another word for "shell"

"These options configure the evaluation context, they can be specified" --> "These options configure the evaluation context. They can be specified"

"A list of directories, each directory is a directory of modules." --> "A list of directories, **where** each directory **contains** modules"

"quoted strings printed as input prompts; Both" -- make that a period


From robert.field at oracle.com  Tue Dec  5 01:06:28 2017
From: robert.field at oracle.com (Robert Field)
Date: Mon, 04 Dec 2017 17:06:28 -0800
Subject: (copy editors) RFR 8179858: jshell tool: sync nomenclature from
 reference to online /help
In-Reply-To: <AA651E9A-BFD9-4D15-9062-00339CCC0050@oracle.com>
References: <5A20A70D.10408@oracle.com>
 <AA651E9A-BFD9-4D15-9062-00339CCC0050@oracle.com>
Message-ID: <5A25F114.6010309@oracle.com>

Very helpful.  See questions inline.

On 12/04/17 12:11, Dan Smith wrote:
> Didn't find any serious problems, but here's a list of minor tweaks.
>
> ?Dan
>
> -----
>
> --class-path, --module-path: I don't understand the purpose of the '*' at the end, but I assume it's intentional.

It was a reference to the path note below it.  Clearly didn't work. Will 
remove.

>
> "load-file": I'd tend to avoid hyphens in compound nouns and stick to "load file", but apparently conventions vary:
> https://en.oxforddictionaries.com/punctuation/hyphen

I choose hyphen so that in in the syntax "Usage:   jshell <option>... 
<load-file>..." it is clear that it is one thing, not two.  I'll lean on 
the varying conventions.

>
> "command-line": Same

Either is fine with me,  I can be consistent with the above, or change 
it back.

>
> "For Linux and macOS": are there other supported Unix OSes? For comparison, here's the Javadoc for System.lineSeparator: "On UNIX systems, it returns "\n"; on Microsoft Windows systems it returns "\r\n".

Good point, this wording is from the Tools Reference, will discuss with 
docs team for the Tool Reference.  Don't know if there are other 
supported OSes.

I'd be concerned that many/most macOS users are not aware they are on a 
Unix platform.  Also, Linux is not technically a Unix(tm) OS.

How about:

   For Unix, Linux and macOS, use a  colon (:) to separate items in the 
path.  For Windows, use a semicolon (;) to separate items.

Or just:

   For Windows, use a semicolon (;) to separate items in the path. On 
other platforms, use a  colon (:) to separate items.

>
> "A path is the directories and archives to search" --> "A path **lists** the directories and archives to search"

Thanks.

>
> "module-private package": I don't know my Jigsaw terminology very well, but this may not be a standard term. javac -X says "Specify a package to be considered as exported from its defining module"

Indeed best to match.  Unlike javac, the default if <other-module> is 
unspecified is ALL-UNNAMED which  exports it to JShell code (in fact, 
that =<other-module> can be specified is undocumented).

Simplest is what you suggest:

        --add-exports <module>/<package>   Specify a package to be 
considered as exported from its defining module

I like that.

>
> "Show the snippets, prefaced with the snippet ID": either "each snippet" or "their snippet IDs"

Thanks.

I like the latter:

     Show the snippets, prefaced with their snippet IDs

>
> /save: inconsistent use of periods (this comment may apply more broadly?should do a quick pass to check)

Ah, yes. line 315, and also 383, 461 and all of /set -- will survey

>
> /types: An enum is a kind of class, so it's not necessary to list it separately (and it makes me think "what about annotation types?"). Just "classes and interfaces" is fine.

Newbies may not make that connection, but they should, OK.

> I'd also replace "types" with "type declarations" throughout, because "type" is such an overloaded term.

Good, that will read more clearly too.

I guess, then, that I should change the summary from:

   list the declared types

to:

   list the type declarations

???

>
> "since jshell was entered, or a /reset, or /reload command was executed" --> "since jshell was entered, or a /reset or /reload command was executed"

Right.

>
> "Errors will display" --> "Errors will be displayed"
>
> "the snippets will be replayed -- the replay is not shown, however, errors will display" --> "the snippits will be replayed. The replay is not shown, **but any** errors will *be displayed*."

I like.

>
> ID ranges: these are listed everywhere as a distinct variant, but help.id suggests that they can appear within a list, interleaved with non-ranges. Which is it? (If the latter, maybe don't mention ranges at all for /vars, etc., and explain elsewhere that an "ID" may be a range of simple IDs. Or, if that's too obscure, try "specified snippet ID or range of snippet IDs" in /vars, etc. Or just give the list variant in /var, etc., more details about ranges.)

This was an attempt to keep it simple.  But the result is that seven 
/help descriptions are bloated by having descriptions for singleton id, 
id list, and id range -- while still not being complete.

How about, I create a new help subject "id" which will describe what an 
id is, how to discover them, and discuss ID ranges. Then I can compress 
the three in each (using /list as the example) from:

   /list <id>
        List the snippet with the specified snippet ID
   /list <id> <id>...
        List the snippets with the specified snippet IDs
   /list <id>-<id>
        List the snippets within the range of snippet IDs

to just:

   /list <id>
        List the snippet with the specified snippet ID.  One or more IDs 
or ID ranges may used, see /help id


>
> "when the jshell is started" "when jshell is restarted" "since this jshell was launched" "debugging of the jshell" "information about jshell": Need to decide is "jshell" refers to the command, or if it's another word for "shell"

Will change all to "the jshell tool"

>
> "These options configure the evaluation context, they can be specified" --> "These options configure the evaluation context. They can be specified"

Thanks.

>
> "A list of directories, each directory is a directory of modules." --> "A list of directories, **where** each directory **contains** modules"

Thanks

>
> "quoted strings printed as input prompts; Both" -- make that a period

OK.

Looking afresh, seems "quoted strings TO BE printed as input prompts." 
would be clearer.

Thanks much,
Robert


>


From robert.field at oracle.com  Tue Dec  5 06:18:11 2017
From: robert.field at oracle.com (Robert Field)
Date: Mon, 04 Dec 2017 22:18:11 -0800
Subject: RFR 8192979: jshell tool: Online help text for commands is confusing
Message-ID: <5A263A23.2080606@oracle.com>

Please review.

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8192979

Webrev:

     http://cr.openjdk.java.net/~rfield/8192979v0.webrev/

Thanks,
Robert


From jan.lahoda at oracle.com  Tue Dec  5 09:05:12 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 5 Dec 2017 10:05:12 +0100
Subject: RFR 8192979: jshell tool: Online help text for commands is
 confusing
In-Reply-To: <5A263A23.2080606@oracle.com>
References: <5A263A23.2080606@oracle.com>
Message-ID: <5A266148.6080809@oracle.com>

Seems OK.

Jan

On 5.12.2017 07:18, Robert Field wrote:
> Please review.
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8192979
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8192979v0.webrev/
>
> Thanks,
> Robert
>

From jan.lahoda at oracle.com  Tue Dec  5 14:02:36 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 5 Dec 2017 15:02:36 +0100
Subject: RFR: JDK-8189248: Jshell /open from file generate error when it tries
 to upcast to typed instance of other with type inferred from it
Message-ID: <5A26A6FC.6060204@oracle.com>

Hi,

Consider these snippet sent (in this order) to jshell:
---
public class A<T> {
   private class SomeClass {}
   public Supplier<T> m() {
     return new B<>(this);
   }
}
---

(note this depends on the future snippet declaring class B)

---
public class B<T> implements Supplier<T> {
   public B(A<T> a) {}
   public T get() {return null;}
}
---

Eval.compileAndLoad will after a few rounds try to compile inputs like:
---
package REPL;

import java.util.function.Supplier;
import static REPL.$JShell$3.B;

class $JShell$2B {

     public static class A<T>
...
}
---
package REPL;

import java.util.function.Supplier;
import static REPL.$JShell$2.A;

class $JShell$3 {

     public static class B<T> implements Supplier<T>
...
}
----

Please note that "B" is using the old (pre-Unit.markForReplacement()) 
version of A from $JShell$2. While the new declaration is inside 
$JShell$2B. I think this is because the classnames are updates only as 
setWrap(s) run, so the wraps that run first may still see old classnames 
for the latter snippets.

The proposal is to ensure the proper classnames are set before trying to 
run:
ins.stream().forEach(u -> u.setWrap(ins, ins));
which creates the real wraps that are processed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8189248
Webrev: http://cr.openjdk.java.net/~jlahoda/8189248/webrev.00/

How does it look?

Thanks,
    Jan

From robert.field at oracle.com  Tue Dec  5 20:43:54 2017
From: robert.field at oracle.com (Robert Field)
Date: Tue, 5 Dec 2017 12:43:54 -0800
Subject: RFR: JDK-8189248: Jshell /open from file generate error when it
 tries to upcast to typed instance of other with type inferred from it
In-Reply-To: <5A26A6FC.6060204@oracle.com>
References: <5A26A6FC.6060204@oracle.com>
Message-ID: <5919DB8E-9ACE-4322-898A-8A9D91B722FA@oracle.com>

I believe you want the second argument to setWrap to be ?legit? rather than ?ins? (as on line 807) so that you don?t attempt to import failed snippet names.

Otherwise looks fine.

It would be good to upgrade the issue Subject so that it will make sense in the future (and include your comments, below).

-Robert

P.S. Apologies, the logic of compileAndLoad is super twisty, I/we should think about a design review.


> On Dec 5, 2017, at 6:02 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> 
> Hi,
> 
> Consider these snippet sent (in this order) to jshell:
> ---
> public class A<T> {
>  private class SomeClass {}
>  public Supplier<T> m() {
>    return new B<>(this);
>  }
> }
> ---
> 
> (note this depends on the future snippet declaring class B)
> 
> ---
> public class B<T> implements Supplier<T> {
>  public B(A<T> a) {}
>  public T get() {return null;}
> }
> ---
> 
> Eval.compileAndLoad will after a few rounds try to compile inputs like:
> ---
> package REPL;
> 
> import java.util.function.Supplier;
> import static REPL.$JShell$3.B;
> 
> class $JShell$2B {
> 
>    public static class A<T>
> ...
> }
> ---
> package REPL;
> 
> import java.util.function.Supplier;
> import static REPL.$JShell$2.A;
> 
> class $JShell$3 {
> 
>    public static class B<T> implements Supplier<T>
> ...
> }
> ----
> 
> Please note that "B" is using the old (pre-Unit.markForReplacement()) version of A from $JShell$2. While the new declaration is inside $JShell$2B. I think this is because the classnames are updates only as setWrap(s) run, so the wraps that run first may still see old classnames for the latter snippets.
> 
> The proposal is to ensure the proper classnames are set before trying to run:
> ins.stream().forEach(u -> u.setWrap(ins, ins));
> which creates the real wraps that are processed.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189248
> Webrev: http://cr.openjdk.java.net/~jlahoda/8189248/webrev.00/
> 
> How does it look?
> 
> Thanks,
>   Jan


From jan.lahoda at oracle.com  Wed Dec  6 14:12:17 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 6 Dec 2017 15:12:17 +0100
Subject: RFR: JDK-8189248: Jshell /open from file generate error when it
 tries to upcast to typed instance of other with type inferred from it
In-Reply-To: <5919DB8E-9ACE-4322-898A-8A9D91B722FA@oracle.com>
References: <5A26A6FC.6060204@oracle.com>
 <5919DB8E-9ACE-4322-898A-8A9D91B722FA@oracle.com>
Message-ID: <5A27FAC1.9090906@oracle.com>

On 5.12.2017 21:43, Robert Field wrote:
> I believe you want the second argument to setWrap to be ?legit? rather than ?ins? (as on line 807) so that you don?t attempt to import failed snippet names.

Ok, done.

>
> Otherwise looks fine.
>
> It would be good to upgrade the issue Subject so that it will make sense in the future (and include your comments, below).

Done.

Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8189248/webrev.01/

Jan

>
> -Robert
>
> P.S. Apologies, the logic of compileAndLoad is super twisty, I/we should think about a design review.
>
>
>> On Dec 5, 2017, at 6:02 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>>
>> Hi,
>>
>> Consider these snippet sent (in this order) to jshell:
>> ---
>> public class A<T> {
>>   private class SomeClass {}
>>   public Supplier<T> m() {
>>     return new B<>(this);
>>   }
>> }
>> ---
>>
>> (note this depends on the future snippet declaring class B)
>>
>> ---
>> public class B<T> implements Supplier<T> {
>>   public B(A<T> a) {}
>>   public T get() {return null;}
>> }
>> ---
>>
>> Eval.compileAndLoad will after a few rounds try to compile inputs like:
>> ---
>> package REPL;
>>
>> import java.util.function.Supplier;
>> import static REPL.$JShell$3.B;
>>
>> class $JShell$2B {
>>
>>     public static class A<T>
>> ...
>> }
>> ---
>> package REPL;
>>
>> import java.util.function.Supplier;
>> import static REPL.$JShell$2.A;
>>
>> class $JShell$3 {
>>
>>     public static class B<T> implements Supplier<T>
>> ...
>> }
>> ----
>>
>> Please note that "B" is using the old (pre-Unit.markForReplacement()) version of A from $JShell$2. While the new declaration is inside $JShell$2B. I think this is because the classnames are updates only as setWrap(s) run, so the wraps that run first may still see old classnames for the latter snippets.
>>
>> The proposal is to ensure the proper classnames are set before trying to run:
>> ins.stream().forEach(u -> u.setWrap(ins, ins));
>> which creates the real wraps that are processed.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189248
>> Webrev: http://cr.openjdk.java.net/~jlahoda/8189248/webrev.00/
>>
>> How does it look?
>>
>> Thanks,
>>    Jan
>

From robert.field at oracle.com  Wed Dec  6 17:00:06 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 06 Dec 2017 09:00:06 -0800
Subject: RFR: JDK-8189248: Jshell /open from file generate error when it
 tries to upcast to typed instance of other with type inferred from it
In-Reply-To: <5A27FAC1.9090906@oracle.com>
References: <5A26A6FC.6060204@oracle.com>
 <5919DB8E-9ACE-4322-898A-8A9D91B722FA@oracle.com>
 <5A27FAC1.9090906@oracle.com>
Message-ID: <1602cc525f0.2794.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Thumbs up!

-Robert



On December 6, 2017 6:12:20 AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> On 5.12.2017 21:43, Robert Field wrote:
>> I believe you want the second argument to setWrap to be ?legit? rather than 
>> ?ins? (as on line 807) so that you don?t attempt to import failed snippet 
>> names.
>
> Ok, done.
>
>>
>> Otherwise looks fine.
>>
>> It would be good to upgrade the issue Subject so that it will make sense in 
>> the future (and include your comments, below).
>
> Done.
>
> Updated webrev:
> http://cr.openjdk.java.net/~jlahoda/8189248/webrev.01/
>
> Jan
>
>>
>> -Robert
>>
>> P.S. Apologies, the logic of compileAndLoad is super twisty, I/we should 
>> think about a design review.
>>
>>
>>> On Dec 5, 2017, at 6:02 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> Consider these snippet sent (in this order) to jshell:
>>> ---
>>> public class A<T> {
>>>   private class SomeClass {}
>>>   public Supplier<T> m() {
>>>     return new B<>(this);
>>>   }
>>> }
>>> ---
>>>
>>> (note this depends on the future snippet declaring class B)
>>>
>>> ---
>>> public class B<T> implements Supplier<T> {
>>>   public B(A<T> a) {}
>>>   public T get() {return null;}
>>> }
>>> ---
>>>
>>> Eval.compileAndLoad will after a few rounds try to compile inputs like:
>>> ---
>>> package REPL;
>>>
>>> import java.util.function.Supplier;
>>> import static REPL.$JShell$3.B;
>>>
>>> class $JShell$2B {
>>>
>>>     public static class A<T>
>>> ...
>>> }
>>> ---
>>> package REPL;
>>>
>>> import java.util.function.Supplier;
>>> import static REPL.$JShell$2.A;
>>>
>>> class $JShell$3 {
>>>
>>>     public static class B<T> implements Supplier<T>
>>> ...
>>> }
>>> ----
>>>
>>> Please note that "B" is using the old (pre-Unit.markForReplacement()) 
>>> version of A from $JShell$2. While the new declaration is inside 
>>> $JShell$2B. I think this is because the classnames are updates only as 
>>> setWrap(s) run, so the wraps that run first may still see old classnames 
>>> for the latter snippets.
>>>
>>> The proposal is to ensure the proper classnames are set before trying to run:
>>> ins.stream().forEach(u -> u.setWrap(ins, ins));
>>> which creates the real wraps that are processed.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189248
>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8189248/webrev.00/
>>>
>>> How does it look?
>>>
>>> Thanks,
>>>    Jan
>>



From jan.lahoda at oracle.com  Wed Dec  6 21:11:58 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 6 Dec 2017 22:11:58 +0100
Subject: RFR: JDK-8189778: Jshell crash on tab for StringBuilder.append(
In-Reply-To: <59FB10F5.4000407@oracle.com>
References: <59F1AC72.4020202@oracle.com> <59F8A8E6.6030609@oracle.com>
 <59FB10F5.4000407@oracle.com>
Message-ID: <5A285D1E.5090205@oracle.com>

Hi,

A webrev updated to the current state and with some further fixes is here:
http://cr.openjdk.java.net/~jlahoda/8189778/webrev.02/

On 2.11.2017 13:35, Kumar Srinivasan wrote:
>
> Hi Jan,
>
> Generally it looks fine to me, a few nits...
>
> JavadocHelper.java
>
> 1.
>
> -                        //which will be resolve in visitInheritDoc:
> suggest....
> +                        //which will be resolved in visitInheritDoc:

Done.

>
> 2. Suggest adding a space after /** or /* makes it a little easier
> to read the comments.

Done.

>
> 3.
>
> - //insertPos (as future missing elements should be inserted behind
> + //insertPos (as future missing elements should be inserted before

The missing elements are inserted behind the tree that was visited by 
the method.

>
> 4.
> -  //if there is a newline immediatelly after this tree, insert after
> +   //if there is a newline immediately after this tree, insert after

Done. Also changed "after" to "behind".

>
> 5. Several private methods have have javadoc comments /**, do you
> run javadoc -private on jshell sources ?

Changed to comments to /*.

Any feedback is welcome!

Thanks,
    Jan

>
> You may want to get Jon's review on this, he is much more familiar
> with these things, than I.
>
> Thanks
> Kumar
>
>> 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(<tab><tab>
>>>
>>> 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  Thu Dec  7 03:31:24 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 06 Dec 2017 19:31:24 -0800
Subject: RFR 8192863: jshell tool: /<id><tab> gives "No such command"
Message-ID: <5A28B60C.20404@oracle.com>

Please review the fix to this bug.

Note: a couple of other things were fixed or given improved readability 
in this process:

     * An incorrect trim() was removed which would cause a slash with a 
leading space to be considered a command for the purpose of a completion
     * Tab completion only special-cased "/help foo" but not "/he foo" 
or "/? foo" -- this was generalized
     * Patterns rather than on-the-fly reg-ex are now used in 
commandDocumentation()
     * Subclasses of UITesting were made more readable by substituting 
named strings for Unicode and using a single call for resource retrieval.

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8192863

Webrev:

     http://cr.openjdk.java.net/~rfield/8192863v0.webrev/

Thanks,
Robert


From jan.lahoda at oracle.com  Thu Dec  7 18:19:19 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 7 Dec 2017 19:19:19 +0100
Subject: RFR 8192863: jshell tool: /<id><tab> gives "No such command"
In-Reply-To: <5A28B60C.20404@oracle.com>
References: <5A28B60C.20404@oracle.com>
Message-ID: <5A298627.4080202@oracle.com>

Look OK.

Jan

On 7.12.2017 04:31, Robert Field wrote:
> Please review the fix to this bug.
>
> Note: a couple of other things were fixed or given improved readability
> in this process:
>
>      * An incorrect trim() was removed which would cause a slash with a
> leading space to be considered a command for the purpose of a completion
>      * Tab completion only special-cased "/help foo" but not "/he foo"
> or "/? foo" -- this was generalized
>      * Patterns rather than on-the-fly reg-ex are now used in
> commandDocumentation()
>      * Subclasses of UITesting were made more readable by substituting
> named strings for Unicode and using a single call for resource retrieval.
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8192863
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8192863v0.webrev/
>
> Thanks,
> Robert
>

From robert.field at oracle.com  Fri Dec  8 04:03:33 2017
From: robert.field at oracle.com (Robert Field)
Date: Thu, 07 Dec 2017 20:03:33 -0800
Subject: RFR 8162989: jshell tool: /edit with external editor leaks files
 in /tmp
Message-ID: <5A2A0F15.5000406@oracle.com>

Please review...

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8162989

Webrev:

     http://cr.openjdk.java.net/~rfield/8162989v0.webrev/

Thanks,
Robert


From jonathan.gibbons at oracle.com  Fri Dec  8 19:17:38 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 08 Dec 2017 11:17:38 -0800
Subject: RFR: JDK-8189778: Jshell crash on tab for StringBuilder.append(
In-Reply-To: <5A285D1E.5090205@oracle.com>
References: <59F1AC72.4020202@oracle.com> <59F8A8E6.6030609@oracle.com>
 <59FB10F5.4000407@oracle.com> <5A285D1E.5090205@oracle.com>
Message-ID: <5A2AE552.9080507@oracle.com>

OK.

Long term, we should have a utility class/method somewhere, either in 
DocTrees, or in the jdk.javadoc module, to provide "official" support 
for obtaining a doc comment with `{@inheritDoc}` resolved.  One gotcha 
in that sort of code that we are becoming more aware of, is the need to 
handle inline references using `<a href="/link/">`. At least for you in 
this Shell console world, that is not such an issue.

-- Jon

On 12/06/2017 01:11 PM, Jan Lahoda wrote:
> Hi,
>
> A webrev updated to the current state and with some further fixes is 
> here:
> http://cr.openjdk.java.net/~jlahoda/8189778/webrev.02/
>
> On 2.11.2017 13:35, Kumar Srinivasan wrote:
>>
>> Hi Jan,
>>
>> Generally it looks fine to me, a few nits...
>>
>> JavadocHelper.java
>>
>> 1.
>>
>> -                        //which will be resolve in visitInheritDoc:
>> suggest....
>> +                        //which will be resolved in visitInheritDoc:
>
> Done.
>
>>
>> 2. Suggest adding a space after /** or /* makes it a little easier
>> to read the comments.
>
> Done.
>
>>
>> 3.
>>
>> - //insertPos (as future missing elements should be inserted behind
>> + //insertPos (as future missing elements should be inserted before
>
> The missing elements are inserted behind the tree that was visited by 
> the method.
>
>>
>> 4.
>> -  //if there is a newline immediatelly after this tree, insert after
>> +   //if there is a newline immediately after this tree, insert after
>
> Done. Also changed "after" to "behind".
>
>>
>> 5. Several private methods have have javadoc comments /**, do you
>> run javadoc -private on jshell sources ?
>
> Changed to comments to /*.
>
> Any feedback is welcome!
>
> Thanks,
>    Jan
>
>>
>> You may want to get Jon's review on this, he is much more familiar
>> with these things, than I.
>>
>> Thanks
>> Kumar
>>
>>> 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(<tab><tab>
>>>>
>>>> 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 jonathan.gibbons at oracle.com  Mon Dec 11 18:17:53 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 11 Dec 2017 10:17:53 -0800
Subject: RFR 8162989: jshell tool: /edit with external editor leaks files
 in /tmp
In-Reply-To: <5A2A0F15.5000406@oracle.com>
References: <5A2A0F15.5000406@oracle.com>
Message-ID: <51da7c85-7305-c1c2-7136-1714da0858a9@oracle.com>

+1

-- Jon


On 12/7/17 8:03 PM, Robert Field wrote:
> Please review...
>
> Bug:
>
> ??? https://bugs.openjdk.java.net/browse/JDK-8162989
>
> Webrev:
>
> ??? http://cr.openjdk.java.net/~rfield/8162989v0.webrev/
>
> Thanks,
> Robert
>


From jan.lahoda at oracle.com  Mon Dec 11 18:34:25 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 11 Dec 2017 19:34:25 +0100
Subject: RFR: JDK-8191636: [Windows] jshell tool: Wrong character in /env
 class-path command crashes jshell
Message-ID: <5A2ECFB1.7090707@oracle.com>

Hi,

Doing this in JShell on Windows:
jshell> /env --class-path ?

Leads to a crash, as Paths.get(...) will throw InvalidPathException on 
Windows for path '?'. The proposed fix is to handle/catch the exception.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191636
Webrev: http://cr.openjdk.java.net/~jlahoda/8191636/webrev.00/

How does it look?

Thanks,
     Jan

From robert.field at oracle.com  Tue Dec 12 03:29:27 2017
From: robert.field at oracle.com (Robert Field)
Date: Mon, 11 Dec 2017 19:29:27 -0800
Subject: RFR: JDK-8191636: [Windows] jshell tool: Wrong character in /env
 class-path command crashes jshell
In-Reply-To: <5A2ECFB1.7090707@oracle.com>
References: <5A2ECFB1.7090707@oracle.com>
Message-ID: <5A2F4D17.3000003@oracle.com>

Thumbs up!

Thanks,
Robert

On 12/11/17 10:34, Jan Lahoda wrote:
> Hi,
>
> Doing this in JShell on Windows:
> jshell> /env --class-path ?
>
> Leads to a crash, as Paths.get(...) will throw InvalidPathException on 
> Windows for path '?'. The proposed fix is to handle/catch the exception.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191636
> Webrev: http://cr.openjdk.java.net/~jlahoda/8191636/webrev.00/
>
> How does it look?
>
> Thanks,
>     Jan


From daniel.smith at oracle.com  Tue Dec 12 22:26:03 2017
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 12 Dec 2017 15:26:03 -0700
Subject: (copy editors) RFR 8179858: jshell tool: sync nomenclature from
 reference to online /help
In-Reply-To: <5A25F114.6010309@oracle.com>
References: <5A20A70D.10408@oracle.com>
 <AA651E9A-BFD9-4D15-9062-00339CCC0050@oracle.com>
 <5A25F114.6010309@oracle.com>
Message-ID: <FA1D4D71-2BEF-4F11-A5EF-76287242460E@oracle.com>

> On Dec 4, 2017, at 6:06 PM, Robert Field <robert.field at oracle.com> wrote:
> 
> Very helpful.  See questions inline.
> 
>> "command-line": Same
> 
> Either is fine with me,  I can be consistent with the above, or change it back.

Whatever you like is fine. Just wanted to draw some attention to it.

> How about:
> 
>  For Unix, Linux and macOS, use a  colon (:) to separate items in the path.  For Windows, use a semicolon (;) to separate items.
> 
> Or just:
> 
>  For Windows, use a semicolon (;) to separate items in the path. On other platforms, use a  colon (:) to separate items.

Yeah, that last one seems the least brittle.

>> I'd also replace "types" with "type declarations" throughout, because "type" is such an overloaded term.
> 
> Good, that will read more clearly too.
> 
> I guess, then, that I should change the summary from:
> 
>  list the declared types
> 
> to:
> 
>  list the type declarations
> 
> ???

I'd lean slightly towards the latter. I'm not so concerned about "declared types", because it's clear you're talking about the subset of types that have declarations. But there's a one-to-many relationship between generic class declarations and class types, and of course you're not claiming to list every parameterization of that generic class.

>> ID ranges: these are listed everywhere as a distinct variant, but help.id suggests that they can appear within a list, interleaved with non-ranges. Which is it? (If the latter, maybe don't mention ranges at all for /vars, etc., and explain elsewhere that an "ID" may be a range of simple IDs. Or, if that's too obscure, try "specified snippet ID or range of snippet IDs" in /vars, etc. Or just give the list variant in /var, etc., more details about ranges.)
> 
> This was an attempt to keep it simple.  But the result is that seven /help descriptions are bloated by having descriptions for singleton id, id list, and id range -- while still not being complete.
> 
> How about, I create a new help subject "id" which will describe what an id is, how to discover them, and discuss ID ranges. Then I can compress the three in each (using /list as the example) from:
> 
>  /list <id>
>       List the snippet with the specified snippet ID
>  /list <id> <id>...
>       List the snippets with the specified snippet IDs
>  /list <id>-<id>
>       List the snippets within the range of snippet IDs
> 
> to just:
> 
>  /list <id>
>       List the snippet with the specified snippet ID.  One or more IDs or ID ranges may used, see /help id

I like that.

?Dan

From jan.lahoda at oracle.com  Wed Dec 13 10:02:54 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 13 Dec 2017 11:02:54 +0100
Subject: RFR: JDK-8191842: JShell: Inferred type information is lost when
 assigning types to a "var"
Message-ID: <5A30FACE.20309@oracle.com>

Hi,

When doing:
var r = new Object() { String s; }

the type of "r" is the anonymous class itself. JShell handles this by 
"upgrading" the anonymous class to be a member class, so that it can be 
properly used from other snippets.

But JShell is not prepared for anonymous classes inside the expression 
(that are part of the resulting type), like:
---
jshell> var list = Stream.of(1, 2, 3).map(j -> new Object() { int i = j; 
}).collect(Collectors.toList());

jshell> list.forEach(a -> System.out.println(a.i));
---

So, part of the proposed fix is to upgrade all anonymous classes to 
member classes if needed. Also, intersection types are cleared from 
fields before writing (the intersection types are installed to ensure 
var semantics for cases like:
<Z extends Runnable & CharSequence> Z get1() { return null; }
var i1 = get1();
)

Bug: https://bugs.openjdk.java.net/browse/JDK-8191842
Webrev: http://cr.openjdk.java.net/~jlahoda/8191842/webrev.00/

Thanks,
     Jan


From robert.field at oracle.com  Wed Dec 13 18:52:07 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 13 Dec 2017 10:52:07 -0800
Subject: 8188894: jdk/jshell/ToolShiftTabTest.java failed with
 IllegalStateException
Message-ID: <5A3176D7.4050606@oracle.com>

Please review by tomorrow 11/14...

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8188894

Webrev:

     http://cr.openjdk.java.net/~rfield/8188894v1.webrev/

Thanks,
Robert


From robert.field at oracle.com  Wed Dec 13 18:56:59 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 13 Dec 2017 10:56:59 -0800
Subject: RFR 8188894: jdk/jshell/ToolShiftTabTest.java failed with
 IllegalStateException
Message-ID: <5A3177FB.2020705@oracle.com>

[resending with RFR prefix...]


Please review by tomorrow 11/14...

Bug:

https://bugs.openjdk.java.net/browse/JDK-8188894

Webrev:

http://cr.openjdk.java.net/~rfield/8188894v1.webrev/

Thanks,
Robert

From jan.lahoda at oracle.com  Wed Dec 13 20:40:31 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 13 Dec 2017 21:40:31 +0100
Subject: RFR 8188894: jdk/jshell/ToolShiftTabTest.java failed with
 IllegalStateException
In-Reply-To: <5A3177FB.2020705@oracle.com>
References: <5A3177FB.2020705@oracle.com>
Message-ID: <5A31903F.2080507@oracle.com>

Seems OK.

Jan

On 13.12.2017 19:56, Robert Field wrote:
> [resending with RFR prefix...]
>
>
> Please review by tomorrow 11/14...
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8188894
>
> Webrev:
>
> http://cr.openjdk.java.net/~rfield/8188894v1.webrev/
>
> Thanks,
> Robert

From robert.field at oracle.com  Wed Dec 13 21:47:00 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 13 Dec 2017 13:47:00 -0800
Subject: RFR: JDK-8191842: JShell: Inferred type information is lost when
 assigning types to a "var"
In-Reply-To: <5A30FACE.20309@oracle.com>
References: <5A30FACE.20309@oracle.com>
Message-ID: <5A319FD4.4050205@oracle.com>

Nice generalization.

Wrap:

90: this breaks array initialization -- this would no longer work: int[] 
d = {1, 2, 3}

Eval:

559: This code should be designed to work the same for automatically 
created scratch variables -- aka $1, $2, ... -- they should also have 
anonymous types.

? 322: Can ei.anonymousClasses be used rather than depending on the 
naming added in Util.JSHELL_ANONYMOUS?

389, 419, 421, 486-493: the name "constructor" is confusing because it 
contains other things and not the complete constructor.  One of the 
unwritten rules of wraps in that
they consist of a complete component, this code has several hanging 
pieces.  Note the two closing braces in 492, braces et. al. should 
always be matched in a wrap.
The mixture of strings and wraps does make this challenging.
I'd suggest doing the bodyParts/extraInit computation first, then build 
up each component as complete entities: constructor body, class body, 
class -- all wraps.

ExpressionToTypeInfo:

355: Seems fragile to assume that the constructor is first

-Robert


On 12/13/17 02:02, Jan Lahoda wrote:
> Hi,
>
> When doing:
> var r = new Object() { String s; }
>
> the type of "r" is the anonymous class itself. JShell handles this by 
> "upgrading" the anonymous class to be a member class, so that it can 
> be properly used from other snippets.
>
> But JShell is not prepared for anonymous classes inside the expression 
> (that are part of the resulting type), like:
> ---
> jshell> var list = Stream.of(1, 2, 3).map(j -> new Object() { int i = 
> j; }).collect(Collectors.toList());
>
> jshell> list.forEach(a -> System.out.println(a.i));
> ---
>
> So, part of the proposed fix is to upgrade all anonymous classes to 
> member classes if needed. Also, intersection types are cleared from 
> fields before writing (the intersection types are installed to ensure 
> var semantics for cases like:
> <Z extends Runnable & CharSequence> Z get1() { return null; }
> var i1 = get1();
> )
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191842
> Webrev: http://cr.openjdk.java.net/~jlahoda/8191842/webrev.00/
>
> Thanks,
>     Jan
>


From robert.field at oracle.com  Wed Dec 13 22:31:12 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 13 Dec 2017 14:31:12 -0800
Subject: RFR: JDK-8191842: JShell: Inferred type information is lost when
 assigning types to a "var"
In-Reply-To: <5A319FD4.4050205@oracle.com>
References: <5A30FACE.20309@oracle.com> <5A319FD4.4050205@oracle.com>
Message-ID: <5A31AA30.20204@oracle.com>

Part 2: tests

ToolSimpleTest is missing the bug number.

VariablesTest needs a copyright update.

Please add tests for:
    * anon classes with added method access
    * anon class scratch var

-Robert


On 12/13/17 13:47, Robert Field wrote:
> Nice generalization.
>
> Wrap:
>
> 90: this breaks array initialization -- this would no longer work: 
> int[] d = {1, 2, 3}
>
> Eval:
>
> 559: This code should be designed to work the same for automatically 
> created scratch variables -- aka $1, $2, ... -- they should also have 
> anonymous types.
>
> ? 322: Can ei.anonymousClasses be used rather than depending on the 
> naming added in Util.JSHELL_ANONYMOUS?
>
> 389, 419, 421, 486-493: the name "constructor" is confusing because it 
> contains other things and not the complete constructor.  One of the 
> unwritten rules of wraps in that
> they consist of a complete component, this code has several hanging 
> pieces.  Note the two closing braces in 492, braces et. al. should 
> always be matched in a wrap.
> The mixture of strings and wraps does make this challenging.
> I'd suggest doing the bodyParts/extraInit computation first, then 
> build up each component as complete entities: constructor body, class 
> body, class -- all wraps.
>
> ExpressionToTypeInfo:
>
> 355: Seems fragile to assume that the constructor is first
>
> -Robert
>
>
> On 12/13/17 02:02, Jan Lahoda wrote:
>> Hi,
>>
>> When doing:
>> var r = new Object() { String s; }
>>
>> the type of "r" is the anonymous class itself. JShell handles this by 
>> "upgrading" the anonymous class to be a member class, so that it can 
>> be properly used from other snippets.
>>
>> But JShell is not prepared for anonymous classes inside the 
>> expression (that are part of the resulting type), like:
>> ---
>> jshell> var list = Stream.of(1, 2, 3).map(j -> new Object() { int i = 
>> j; }).collect(Collectors.toList());
>>
>> jshell> list.forEach(a -> System.out.println(a.i));
>> ---
>>
>> So, part of the proposed fix is to upgrade all anonymous classes to 
>> member classes if needed. Also, intersection types are cleared from 
>> fields before writing (the intersection types are installed to ensure 
>> var semantics for cases like:
>> <Z extends Runnable & CharSequence> Z get1() { return null; }
>> var i1 = get1();
>> )
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191842
>> Webrev: http://cr.openjdk.java.net/~jlahoda/8191842/webrev.00/
>>
>> Thanks,
>>     Jan
>>
>


From jonathan.gibbons at oracle.com  Thu Dec 14 18:26:41 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 14 Dec 2017 10:26:41 -0800
Subject: Fwd: License: openjdk version 9: files under GPL v2.0 only - (outside
 of hotspot) - please review
In-Reply-To: <bd051291d87b4515bb3471e551a502d5@R01UKEXCASM111.r01.fujitsu.local>
References: <bd051291d87b4515bb3471e551a502d5@R01UKEXCASM111.r01.fujitsu.local>
Message-ID: <5A32C261.202@oracle.com>

One JShell file in this list:

langtools/src/jdk.jshell/share/classes/jdk/internal/jshell/debug/InternalDebugControl.java




-------- Forwarded Message --------
Subject: 	License: openjdk version 9: files under GPL v2.0 only - 
(outside of hotspot) - please review
Date: 	Thu, 14 Dec 2017 08:28:19 +0000
From: 	monika.schnizer at ts.fujitsu.com <monika.schnizer at ts.fujitsu.com>
To: 	jdk-dev at openjdk.java.net <jdk-dev at openjdk.java.net>



Dear developers of openjdk,

thank you very much for providing this open version of java.
It is really great!

We recently run a Fossology license scan on openjdk version 9 and identified the following files to be under
GPL v2.0 only. We assume that most of them should be GPL v2.0 + Java Classpath Exception.
Please could you kindly investigate into this (possibly together with your license expert).

jdk/src/java.base/share/classes/java/lang/PublicMethods.java
jdk/src/java.base/share/classes/java/lang/StringConcatHelper.java
jdk/src/java.base/share/classes/java/lang/invoke/StringConcatException.java
jdk/src/java.base/share/classes/jdk/internal/loader/AbstractClassLoaderValue.java
jdk/src/java.base/share/classes/jdk/internal/loader/ClassLoaderValue.java
jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.c
jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.h
jdk/src/java.desktop/windows/native/common/awt/systemscale/systemScale.cpp
jdk/src/java.desktop/windows/native/common/awt/systemscale/systemScale.h
jdk/make/src/classes/build/tools/blacklistedcertsconverter/BlacklistedCertsConverter.java
langtools/src/jdk.jshell/share/classes/jdk/internal/jshell/debug/InternalDebugControl.java
langtools/make/tools/crules/AbstractCodingRulesAnalyzer.java
langtools/make/tools/crules/AssertCheckAnalyzer.java
langtools/make/tools/crules/CodingRulesAnalyzerPlugin.java
langtools/make/tools/crules/DefinedByAnalyzer.java
langtools/make/tools/crules/MutableFieldsAnalyzer.java
langtools/make/tools/propertiesparser/gen/ClassGenerator.java
langtools/make/tools/propertiesparser/parser/Message.java
langtools/make/tools/propertiesparser/parser/MessageFile.java
langtools/make/tools/propertiesparser/parser/MessageInfo.java
langtools/make/tools/propertiesparser/parser/MessageLine.java
langtools/make/tools/propertiesparser/parser/MessageType.java
nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js
nashorn/buildtools/nasgen/build.xml
nashorn/buildtools/nasgen/nasgen.iml
nashorn/buildtools/nashorntask/build.xml
nashorn/buildtools/nashorntask/project.properties

Thank you very much,
Monika Schnizer



---
Sent from my Fujitsu LIFEBOOK T904

With best regards

Monika Schnizer
Senior Software Developer
FJ EMEIA PR PSO PM&D SVR SW Server View? Configuration Dev



FUJITSU
Mies-van-der-Rohe-Str. 8, 80807 Munich, Germany
Tel.: +49 (89) 62060 2995
E-mail: Monika.Schnizer at ts.fujitsu.com<mailto:Monika.Schnizer at ts.fujitsu.com>
Web: ts.fujitsu.com<http://ts.fujitsu.com/>
Company details: ts.fujitsu.com/imprint<http://ts.fujitsu.com/imprint.html>

This communication contains information that is confidential, proprietary in nature and/or privileged.  It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation.
Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.






From daniel.smith at oracle.com  Tue Dec 19 18:08:51 2017
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 19 Dec 2017 11:08:51 -0700
Subject: (copy editors) RFR 8179858: jshell tool: sync nomenclature from
 reference to online /help
In-Reply-To: <5A3215DD.1050904@oracle.com>
References: <5A20A70D.10408@oracle.com>
 <AA651E9A-BFD9-4D15-9062-00339CCC0050@oracle.com>
 <5A25F114.6010309@oracle.com>
 <FA1D4D71-2BEF-4F11-A5EF-76287242460E@oracle.com>
 <5A3215DD.1050904@oracle.com>
Message-ID: <4E406CF8-81A6-4E4D-88A6-080D2D5125CA@oracle.com>

Thumbs up.

> On Dec 13, 2017, at 11:10 PM, Robert Field <robert.field at oracle.com> wrote:
> 
> Here is the updated webrev, based on the discussion below -- please review:
> 
>     http://cr.openjdk.java.net/~rfield/8179858v1.webrev/ <http://cr.openjdk.java.net/~rfield/8179858v1.webrev/>
> 
> Bug:
> 
>     https://bugs.openjdk.java.net/browse/JDK-8179858 <https://bugs.openjdk.java.net/browse/JDK-8179858>
> 
> Thanks,
> Robert
> 
> On 12/12/17 14:26, Dan Smith wrote:
>>> On Dec 4, 2017, at 6:06 PM, Robert Field <robert.field at oracle.com> <mailto:robert.field at oracle.com> wrote:
>>> 
>>> Very helpful.  See questions inline.
>>> 
>>>> "command-line": Same
>>> Either is fine with me,  I can be consistent with the above, or change it back.
>> Whatever you like is fine. Just wanted to draw some attention to it.
>> 
>>> How about:
>>> 
>>>  For Unix, Linux and macOS, use a  colon (:) to separate items in the path.  For Windows, use a semicolon (;) to separate items.
>>> 
>>> Or just:
>>> 
>>>  For Windows, use a semicolon (;) to separate items in the path. On other platforms, use a  colon (:) to separate items.
>> Yeah, that last one seems the least brittle.
>> 
>>>> I'd also replace "types" with "type declarations" throughout, because "type" is such an overloaded term.
>>> Good, that will read more clearly too.
>>> 
>>> I guess, then, that I should change the summary from:
>>> 
>>>  list the declared types
>>> 
>>> to:
>>> 
>>>  list the type declarations
>>> 
>>> ???
>> I'd lean slightly towards the latter. I'm not so concerned about "declared types", because it's clear you're talking about the subset of types that have declarations. But there's a one-to-many relationship between generic class declarations and class types, and of course you're not claiming to list every parameterization of that generic class.
>> 
>>>> ID ranges: these are listed everywhere as a distinct variant, but help.id suggests that they can appear within a list, interleaved with non-ranges. Which is it? (If the latter, maybe don't mention ranges at all for /vars, etc., and explain elsewhere that an "ID" may be a range of simple IDs. Or, if that's too obscure, try "specified snippet ID or range of snippet IDs" in /vars, etc. Or just give the list variant in /var, etc., more details about ranges.)
>>> This was an attempt to keep it simple.  But the result is that seven /help descriptions are bloated by having descriptions for singleton id, id list, and id range -- while still not being complete.
>>> 
>>> How about, I create a new help subject "id" which will describe what an id is, how to discover them, and discuss ID ranges. Then I can compress the three in each (using /list as the example) from:
>>> 
>>>  /list <id>
>>>       List the snippet with the specified snippet ID
>>>  /list <id> <id>...
>>>       List the snippets with the specified snippet IDs
>>>  /list <id>-<id>
>>>       List the snippets within the range of snippet IDs
>>> 
>>> to just:
>>> 
>>>  /list <id>
>>>       List the snippet with the specified snippet ID.  One or more IDs or ID ranges may used, see /help id
>> I like that.
>> 
>> ?Dan
> 
> Very helpful.  See questions inline. 
> 
> On 12/04/17 12:11, Dan Smith wrote: 
>> Didn't find any serious problems, but here's a list of minor tweaks. 
>> 
>> ?Dan 
>> 
>> ----- 
>> 
>> --class-path, --module-path: I don't understand the purpose of the '*' at the end, but I assume it's intentional. 
> 
> It was a reference to the path note below it.  Clearly didn't work. Will remove. 
> 
>> 
>> "load-file": I'd tend to avoid hyphens in compound nouns and stick to "load file", but apparently conventions vary: 
>> https://en.oxforddictionaries.com/punctuation/hyphen <https://en.oxforddictionaries.com/punctuation/hyphen> 
> 
> I choose hyphen so that in in the syntax "Usage:   jshell <option>... <load-file>..." it is clear that it is one thing, not two.  I'll lean on the varying conventions. 
> 
>> 
>> "command-line": Same 
> 
> Either is fine with me,  I can be consistent with the above, or change it back. 
> 
>> 
>> "For Linux and macOS": are there other supported Unix OSes? For comparison, here's the Javadoc for System.lineSeparator: "On UNIX systems, it returns "\n"; on Microsoft Windows systems it returns "\r\n". 
> 
> Good point, this wording is from the Tools Reference, will discuss with docs team for the Tool Reference.  Don't know if there are other supported OSes. 
> 
> I'd be concerned that many/most macOS users are not aware they are on a Unix platform.  Also, Linux is not technically a Unix(tm) OS. 
> 
> How about: 
> 
>   For Unix, Linux and macOS, use a  colon (:) to separate items in the path.  For Windows, use a semicolon (;) to separate items. 
> 
> Or just: 
> 
>   For Windows, use a semicolon (;) to separate items in the path. On other platforms, use a  colon (:) to separate items. 
> 
>> 
>> "A path is the directories and archives to search" --> "A path **lists** the directories and archives to search" 
> 
> Thanks. 
> 
>> 
>> "module-private package": I don't know my Jigsaw terminology very well, but this may not be a standard term. javac -X says "Specify a package to be considered as exported from its defining module" 
> 
> Indeed best to match.  Unlike javac, the default if <other-module> is unspecified is ALL-UNNAMED which  exports it to JShell code (in fact, that =<other-module> can be specified is undocumented). 
> 
> Simplest is what you suggest: 
> 
>        --add-exports <module>/<package>   Specify a package to be considered as exported from its defining module 
> 
> I like that. 
> 
>> 
>> "Show the snippets, prefaced with the snippet ID": either "each snippet" or "their snippet IDs" 
> 
> Thanks. 
> 
> I like the latter: 
> 
>     Show the snippets, prefaced with their snippet IDs 
> 
>> 
>> /save: inconsistent use of periods (this comment may apply more broadly?should do a quick pass to check) 
> 
> Ah, yes. line 315, and also 383, 461 and all of /set -- will survey 
> 
>> 
>> /types: An enum is a kind of class, so it's not necessary to list it separately (and it makes me think "what about annotation types?"). Just "classes and interfaces" is fine. 
> 
> Newbies may not make that connection, but they should, OK. 
> 
>> I'd also replace "types" with "type declarations" throughout, because "type" is such an overloaded term. 
> 
> Good, that will read more clearly too. 
> 
> I guess, then, that I should change the summary from: 
> 
>   list the declared types 
> 
> to: 
> 
>   list the type declarations 
> 
> ??? 
> 
>> 
>> "since jshell was entered, or a /reset, or /reload command was executed" --> "since jshell was entered, or a /reset or /reload command was executed" 
> 
> Right. 
> 
>> 
>> "Errors will display" --> "Errors will be displayed" 
>> 
>> "the snippets will be replayed -- the replay is not shown, however, errors will display" --> "the snippits will be replayed. The replay is not shown, **but any** errors will *be displayed*." 
> 
> I like. 
> 
>> 
>> ID ranges: these are listed everywhere as a distinct variant, but help.id suggests that they can appear within a list, interleaved with non-ranges. Which is it? (If the latter, maybe don't mention ranges at all for /vars, etc., and explain elsewhere that an "ID" may be a range of simple IDs. Or, if that's too obscure, try "specified snippet ID or range of snippet IDs" in /vars, etc. Or just give the list variant in /var, etc., more details about ranges.) 
> 
> This was an attempt to keep it simple.  But the result is that seven /help descriptions are bloated by having descriptions for singleton id, id list, and id range -- while still not being complete. 
> 
> How about, I create a new help subject "id" which will describe what an id is, how to discover them, and discuss ID ranges. Then I can compress the three in each (using /list as the example) from: 
> 
>   /list <id> 
>        List the snippet with the specified snippet ID 
>   /list <id> <id>... 
>        List the snippets with the specified snippet IDs 
>   /list <id>-<id> 
>        List the snippets within the range of snippet IDs 
> 
> to just: 
> 
>   /list <id> 
>        List the snippet with the specified snippet ID.  One or more IDs or ID ranges may used, see /help id 
> 
> 
>> 
>> "when the jshell is started" "when jshell is restarted" "since this jshell was launched" "debugging of the jshell" "information about jshell": Need to decide is "jshell" refers to the command, or if it's another word for "shell" 
> 
> Will change all to "the jshell tool" 
> 
>> 
>> "These options configure the evaluation context, they can be specified" --> "These options configure the evaluation context. They can be specified" 
> 
> Thanks. 
> 
>> 
>> "A list of directories, each directory is a directory of modules." --> "A list of directories, **where** each directory **contains** modules" 
> 
> Thanks 
> 
>> 
>> "quoted strings printed as input prompts; Both" -- make that a period 
> 
> OK. 
> 
> Looking afresh, seems "quoted strings TO BE printed as input prompts." would be clearer. 
> 
> Thanks much, 
> Robert 
> 
> 
>> 
> 
> 


From jonathan.gibbons at oracle.com  Tue Dec 19 19:06:58 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 19 Dec 2017 11:06:58 -0800
Subject: (copy editors) RFR 8179858: jshell tool: sync nomenclature from
 reference to online /help
In-Reply-To: <4E406CF8-81A6-4E4D-88A6-080D2D5125CA@oracle.com>
References: <5A20A70D.10408@oracle.com>
 <AA651E9A-BFD9-4D15-9062-00339CCC0050@oracle.com>
 <5A25F114.6010309@oracle.com>
 <FA1D4D71-2BEF-4F11-A5EF-76287242460E@oracle.com>
 <5A3215DD.1050904@oracle.com>
 <4E406CF8-81A6-4E4D-88A6-080D2D5125CA@oracle.com>
Message-ID: <5A396352.8090908@oracle.com>

Mostly OK/approved.   I found one line that needs to be fixed.

Reading

http://cr.openjdk.java.net/~rfield/8179858v1.webrev/

In l10n.properties, two "a the".

  570         a the jshell tool command, or, in some cases, a the jshell tool command argument,\n\t\t\


Stylistically, for a future edit, unless you are doing specific custom 
processing on the resource strings for tabs after newlines, I would 
suggest using the convention of a slash at the beginning of a line, as in

OLD:

property.name=property value\n\t\
     indented value


NEW:

property.name=property value\n\
\    indented value

The leading slash character "protects the spaces that follow.

-- Jon


On 12/19/2017 10:08 AM, Dan Smith wrote:
> Thumbs up.
>
>> On Dec 13, 2017, at 11:10 PM, Robert Field <robert.field at oracle.com> wrote:
>>
>> Here is the updated webrev, based on the discussion below -- please review:
>>
>>      http://cr.openjdk.java.net/~rfield/8179858v1.webrev/ <http://cr.openjdk.java.net/~rfield/8179858v1.webrev/>
>>
>> Bug:
>>
>>      https://bugs.openjdk.java.net/browse/JDK-8179858 <https://bugs.openjdk.java.net/browse/JDK-8179858>
>>
>> Thanks,
>> Robert
>>
>> On 12/12/17 14:26, Dan Smith wrote:
>>>> On Dec 4, 2017, at 6:06 PM, Robert Field <robert.field at oracle.com> <mailto:robert.field at oracle.com> wrote:
>>>>
>>>> Very helpful.  See questions inline.
>>>>
>>>>> "command-line": Same
>>>> Either is fine with me,  I can be consistent with the above, or change it back.
>>> Whatever you like is fine. Just wanted to draw some attention to it.
>>>
>>>> How about:
>>>>
>>>>   For Unix, Linux and macOS, use a  colon (:) to separate items in the path.  For Windows, use a semicolon (;) to separate items.
>>>>
>>>> Or just:
>>>>
>>>>   For Windows, use a semicolon (;) to separate items in the path. On other platforms, use a  colon (:) to separate items.
>>> Yeah, that last one seems the least brittle.
>>>
>>>>> I'd also replace "types" with "type declarations" throughout, because "type" is such an overloaded term.
>>>> Good, that will read more clearly too.
>>>>
>>>> I guess, then, that I should change the summary from:
>>>>
>>>>   list the declared types
>>>>
>>>> to:
>>>>
>>>>   list the type declarations
>>>>
>>>> ???
>>> I'd lean slightly towards the latter. I'm not so concerned about "declared types", because it's clear you're talking about the subset of types that have declarations. But there's a one-to-many relationship between generic class declarations and class types, and of course you're not claiming to list every parameterization of that generic class.
>>>
>>>>> ID ranges: these are listed everywhere as a distinct variant, but help.id suggests that they can appear within a list, interleaved with non-ranges. Which is it? (If the latter, maybe don't mention ranges at all for /vars, etc., and explain elsewhere that an "ID" may be a range of simple IDs. Or, if that's too obscure, try "specified snippet ID or range of snippet IDs" in /vars, etc. Or just give the list variant in /var, etc., more details about ranges.)
>>>> This was an attempt to keep it simple.  But the result is that seven /help descriptions are bloated by having descriptions for singleton id, id list, and id range -- while still not being complete.
>>>>
>>>> How about, I create a new help subject "id" which will describe what an id is, how to discover them, and discuss ID ranges. Then I can compress the three in each (using /list as the example) from:
>>>>
>>>>   /list <id>
>>>>        List the snippet with the specified snippet ID
>>>>   /list <id> <id>...
>>>>        List the snippets with the specified snippet IDs
>>>>   /list <id>-<id>
>>>>        List the snippets within the range of snippet IDs
>>>>
>>>> to just:
>>>>
>>>>   /list <id>
>>>>        List the snippet with the specified snippet ID.  One or more IDs or ID ranges may used, see /help id
>>> I like that.
>>>
>>> ?Dan
>> Very helpful.  See questions inline.
>>
>> On 12/04/17 12:11, Dan Smith wrote:
>>> Didn't find any serious problems, but here's a list of minor tweaks.
>>>
>>> ?Dan
>>>
>>> -----
>>>
>>> --class-path, --module-path: I don't understand the purpose of the '*' at the end, but I assume it's intentional.
>> It was a reference to the path note below it.  Clearly didn't work. Will remove.
>>
>>> "load-file": I'd tend to avoid hyphens in compound nouns and stick to "load file", but apparently conventions vary:
>>> https://en.oxforddictionaries.com/punctuation/hyphen <https://en.oxforddictionaries.com/punctuation/hyphen>
>> I choose hyphen so that in in the syntax "Usage:   jshell <option>... <load-file>..." it is clear that it is one thing, not two.  I'll lean on the varying conventions.
>>
>>> "command-line": Same
>> Either is fine with me,  I can be consistent with the above, or change it back.
>>
>>> "For Linux and macOS": are there other supported Unix OSes? For comparison, here's the Javadoc for System.lineSeparator: "On UNIX systems, it returns "\n"; on Microsoft Windows systems it returns "\r\n".
>> Good point, this wording is from the Tools Reference, will discuss with docs team for the Tool Reference.  Don't know if there are other supported OSes.
>>
>> I'd be concerned that many/most macOS users are not aware they are on a Unix platform.  Also, Linux is not technically a Unix(tm) OS.
>>
>> How about:
>>
>>    For Unix, Linux and macOS, use a  colon (:) to separate items in the path.  For Windows, use a semicolon (;) to separate items.
>>
>> Or just:
>>
>>    For Windows, use a semicolon (;) to separate items in the path. On other platforms, use a  colon (:) to separate items.
>>
>>> "A path is the directories and archives to search" --> "A path **lists** the directories and archives to search"
>> Thanks.
>>
>>> "module-private package": I don't know my Jigsaw terminology very well, but this may not be a standard term. javac -X says "Specify a package to be considered as exported from its defining module"
>> Indeed best to match.  Unlike javac, the default if <other-module> is unspecified is ALL-UNNAMED which  exports it to JShell code (in fact, that =<other-module> can be specified is undocumented).
>>
>> Simplest is what you suggest:
>>
>>         --add-exports <module>/<package>   Specify a package to be considered as exported from its defining module
>>
>> I like that.
>>
>>> "Show the snippets, prefaced with the snippet ID": either "each snippet" or "their snippet IDs"
>> Thanks.
>>
>> I like the latter:
>>
>>      Show the snippets, prefaced with their snippet IDs
>>
>>> /save: inconsistent use of periods (this comment may apply more broadly?should do a quick pass to check)
>> Ah, yes. line 315, and also 383, 461 and all of /set -- will survey
>>
>>> /types: An enum is a kind of class, so it's not necessary to list it separately (and it makes me think "what about annotation types?"). Just "classes and interfaces" is fine.
>> Newbies may not make that connection, but they should, OK.
>>
>>> I'd also replace "types" with "type declarations" throughout, because "type" is such an overloaded term.
>> Good, that will read more clearly too.
>>
>> I guess, then, that I should change the summary from:
>>
>>    list the declared types
>>
>> to:
>>
>>    list the type declarations
>>
>> ???
>>
>>> "since jshell was entered, or a /reset, or /reload command was executed" --> "since jshell was entered, or a /reset or /reload command was executed"
>> Right.
>>
>>> "Errors will display" --> "Errors will be displayed"
>>>
>>> "the snippets will be replayed -- the replay is not shown, however, errors will display" --> "the snippits will be replayed. The replay is not shown, **but any** errors will *be displayed*."
>> I like.
>>
>>> ID ranges: these are listed everywhere as a distinct variant, but help.id suggests that they can appear within a list, interleaved with non-ranges. Which is it? (If the latter, maybe don't mention ranges at all for /vars, etc., and explain elsewhere that an "ID" may be a range of simple IDs. Or, if that's too obscure, try "specified snippet ID or range of snippet IDs" in /vars, etc. Or just give the list variant in /var, etc., more details about ranges.)
>> This was an attempt to keep it simple.  But the result is that seven /help descriptions are bloated by having descriptions for singleton id, id list, and id range -- while still not being complete.
>>
>> How about, I create a new help subject "id" which will describe what an id is, how to discover them, and discuss ID ranges. Then I can compress the three in each (using /list as the example) from:
>>
>>    /list <id>
>>         List the snippet with the specified snippet ID
>>    /list <id> <id>...
>>         List the snippets with the specified snippet IDs
>>    /list <id>-<id>
>>         List the snippets within the range of snippet IDs
>>
>> to just:
>>
>>    /list <id>
>>         List the snippet with the specified snippet ID.  One or more IDs or ID ranges may used, see /help id
>>
>>
>>> "when the jshell is started" "when jshell is restarted" "since this jshell was launched" "debugging of the jshell" "information about jshell": Need to decide is "jshell" refers to the command, or if it's another word for "shell"
>> Will change all to "the jshell tool"
>>
>>> "These options configure the evaluation context, they can be specified" --> "These options configure the evaluation context. They can be specified"
>> Thanks.
>>
>>> "A list of directories, each directory is a directory of modules." --> "A list of directories, **where** each directory **contains** modules"
>> Thanks
>>
>>> "quoted strings printed as input prompts; Both" -- make that a period
>> OK.
>>
>> Looking afresh, seems "quoted strings TO BE printed as input prompts." would be clearer.
>>
>> Thanks much,
>> Robert
>>
>>
>>


From robert.field at oracle.com  Tue Dec 19 19:30:17 2017
From: robert.field at oracle.com (Robert Field)
Date: Tue, 19 Dec 2017 11:30:17 -0800
Subject: (copy editors) RFR 8179858: jshell tool: sync nomenclature from
 reference to online /help
In-Reply-To: <5A396352.8090908@oracle.com>
References: <5A20A70D.10408@oracle.com>
 <AA651E9A-BFD9-4D15-9062-00339CCC0050@oracle.com>
 <5A25F114.6010309@oracle.com>
 <FA1D4D71-2BEF-4F11-A5EF-76287242460E@oracle.com>
 <5A3215DD.1050904@oracle.com>
 <4E406CF8-81A6-4E4D-88A6-080D2D5125CA@oracle.com>
 <5A396352.8090908@oracle.com>
Message-ID: <5A3968C9.8090203@oracle.com>


On 12/19/17 11:06, Jonathan Gibbons wrote:
> Mostly OK/approved.   I found one line that needs to be fixed.
>
> Reading
>
> http://cr.openjdk.java.net/~rfield/8179858v1.webrev/
>
> In l10n.properties, two "a the".
>
>  570         a the jshell tool command, or, in some cases, a the 
> jshell tool command argument,\n\t\t\

Oops! Fixed

>
>
> Stylistically, for a future edit, unless you are doing specific custom 
> processing on the resource strings for tabs after newlines, I would 
> suggest using the convention of a slash at the beginning of a line, as in
>
> OLD:
>
> property.name=property value\n\t\
>     indented value
>
>
> NEW:
>
> property.name=property value\n\
> \    indented value
>
> The leading slash character "protects the spaces that follow.

Yes, that would be more readable.  Will migrate to that in future revs.

Do you want another review cycle?

Thanks,
Robert


>
> -- Jon
>
>
> On 12/19/2017 10:08 AM, Dan Smith wrote:
>> Thumbs up.
>>
>>> On Dec 13, 2017, at 11:10 PM, Robert Field <robert.field at oracle.com> 
>>> wrote:
>>>
>>> Here is the updated webrev, based on the discussion below -- please 
>>> review:
>>>
>>>      http://cr.openjdk.java.net/~rfield/8179858v1.webrev/ 
>>> <http://cr.openjdk.java.net/~rfield/8179858v1.webrev/>
>>>
>>> Bug:
>>>
>>>      https://bugs.openjdk.java.net/browse/JDK-8179858 
>>> <https://bugs.openjdk.java.net/browse/JDK-8179858>
>>>
>>> Thanks,
>>> Robert
>>>
>>> On 12/12/17 14:26, Dan Smith wrote:
>>>>> On Dec 4, 2017, at 6:06 PM, Robert Field <robert.field at oracle.com> 
>>>>> <mailto:robert.field at oracle.com> wrote:
>>>>>
>>>>> Very helpful.  See questions inline.
>>>>>
>>>>>> "command-line": Same
>>>>> Either is fine with me,  I can be consistent with the above, or 
>>>>> change it back.
>>>> Whatever you like is fine. Just wanted to draw some attention to it.
>>>>
>>>>> How about:
>>>>>
>>>>>   For Unix, Linux and macOS, use a  colon (:) to separate items in 
>>>>> the path.  For Windows, use a semicolon (;) to separate items.
>>>>>
>>>>> Or just:
>>>>>
>>>>>   For Windows, use a semicolon (;) to separate items in the path. 
>>>>> On other platforms, use a  colon (:) to separate items.
>>>> Yeah, that last one seems the least brittle.
>>>>
>>>>>> I'd also replace "types" with "type declarations" throughout, 
>>>>>> because "type" is such an overloaded term.
>>>>> Good, that will read more clearly too.
>>>>>
>>>>> I guess, then, that I should change the summary from:
>>>>>
>>>>>   list the declared types
>>>>>
>>>>> to:
>>>>>
>>>>>   list the type declarations
>>>>>
>>>>> ???
>>>> I'd lean slightly towards the latter. I'm not so concerned about 
>>>> "declared types", because it's clear you're talking about the 
>>>> subset of types that have declarations. But there's a one-to-many 
>>>> relationship between generic class declarations and class types, 
>>>> and of course you're not claiming to list every parameterization of 
>>>> that generic class.
>>>>
>>>>>> ID ranges: these are listed everywhere as a distinct variant, but 
>>>>>> help.id suggests that they can appear within a list, interleaved 
>>>>>> with non-ranges. Which is it? (If the latter, maybe don't mention 
>>>>>> ranges at all for /vars, etc., and explain elsewhere that an "ID" 
>>>>>> may be a range of simple IDs. Or, if that's too obscure, try 
>>>>>> "specified snippet ID or range of snippet IDs" in /vars, etc. Or 
>>>>>> just give the list variant in /var, etc., more details about 
>>>>>> ranges.)
>>>>> This was an attempt to keep it simple.  But the result is that 
>>>>> seven /help descriptions are bloated by having descriptions for 
>>>>> singleton id, id list, and id range -- while still not being 
>>>>> complete.
>>>>>
>>>>> How about, I create a new help subject "id" which will describe 
>>>>> what an id is, how to discover them, and discuss ID ranges. Then I 
>>>>> can compress the three in each (using /list as the example) from:
>>>>>
>>>>>   /list <id>
>>>>>        List the snippet with the specified snippet ID
>>>>>   /list <id> <id>...
>>>>>        List the snippets with the specified snippet IDs
>>>>>   /list <id>-<id>
>>>>>        List the snippets within the range of snippet IDs
>>>>>
>>>>> to just:
>>>>>
>>>>>   /list <id>
>>>>>        List the snippet with the specified snippet ID. One or more 
>>>>> IDs or ID ranges may used, see /help id
>>>> I like that.
>>>>
>>>> ?Dan
>>> Very helpful.  See questions inline.
>>>
>>> On 12/04/17 12:11, Dan Smith wrote:
>>>> Didn't find any serious problems, but here's a list of minor tweaks.
>>>>
>>>> ?Dan
>>>>
>>>> -----
>>>>
>>>> --class-path, --module-path: I don't understand the purpose of the 
>>>> '*' at the end, but I assume it's intentional.
>>> It was a reference to the path note below it.  Clearly didn't work. 
>>> Will remove.
>>>
>>>> "load-file": I'd tend to avoid hyphens in compound nouns and stick 
>>>> to "load file", but apparently conventions vary:
>>>> https://en.oxforddictionaries.com/punctuation/hyphen 
>>>> <https://en.oxforddictionaries.com/punctuation/hyphen>
>>> I choose hyphen so that in in the syntax "Usage:   jshell 
>>> <option>... <load-file>..." it is clear that it is one thing, not 
>>> two.  I'll lean on the varying conventions.
>>>
>>>> "command-line": Same
>>> Either is fine with me,  I can be consistent with the above, or 
>>> change it back.
>>>
>>>> "For Linux and macOS": are there other supported Unix OSes? For 
>>>> comparison, here's the Javadoc for System.lineSeparator: "On UNIX 
>>>> systems, it returns "\n"; on Microsoft Windows systems it returns 
>>>> "\r\n".
>>> Good point, this wording is from the Tools Reference, will discuss 
>>> with docs team for the Tool Reference.  Don't know if there are 
>>> other supported OSes.
>>>
>>> I'd be concerned that many/most macOS users are not aware they are 
>>> on a Unix platform.  Also, Linux is not technically a Unix(tm) OS.
>>>
>>> How about:
>>>
>>>    For Unix, Linux and macOS, use a  colon (:) to separate items in 
>>> the path.  For Windows, use a semicolon (;) to separate items.
>>>
>>> Or just:
>>>
>>>    For Windows, use a semicolon (;) to separate items in the path. 
>>> On other platforms, use a  colon (:) to separate items.
>>>
>>>> "A path is the directories and archives to search" --> "A path 
>>>> **lists** the directories and archives to search"
>>> Thanks.
>>>
>>>> "module-private package": I don't know my Jigsaw terminology very 
>>>> well, but this may not be a standard term. javac -X says "Specify a 
>>>> package to be considered as exported from its defining module"
>>> Indeed best to match.  Unlike javac, the default if <other-module> 
>>> is unspecified is ALL-UNNAMED which exports it to JShell code (in 
>>> fact, that =<other-module> can be specified is undocumented).
>>>
>>> Simplest is what you suggest:
>>>
>>>         --add-exports <module>/<package>   Specify a package to be 
>>> considered as exported from its defining module
>>>
>>> I like that.
>>>
>>>> "Show the snippets, prefaced with the snippet ID": either "each 
>>>> snippet" or "their snippet IDs"
>>> Thanks.
>>>
>>> I like the latter:
>>>
>>>      Show the snippets, prefaced with their snippet IDs
>>>
>>>> /save: inconsistent use of periods (this comment may apply more 
>>>> broadly?should do a quick pass to check)
>>> Ah, yes. line 315, and also 383, 461 and all of /set -- will survey
>>>
>>>> /types: An enum is a kind of class, so it's not necessary to list 
>>>> it separately (and it makes me think "what about annotation 
>>>> types?"). Just "classes and interfaces" is fine.
>>> Newbies may not make that connection, but they should, OK.
>>>
>>>> I'd also replace "types" with "type declarations" throughout, 
>>>> because "type" is such an overloaded term.
>>> Good, that will read more clearly too.
>>>
>>> I guess, then, that I should change the summary from:
>>>
>>>    list the declared types
>>>
>>> to:
>>>
>>>    list the type declarations
>>>
>>> ???
>>>
>>>> "since jshell was entered, or a /reset, or /reload command was 
>>>> executed" --> "since jshell was entered, or a /reset or /reload 
>>>> command was executed"
>>> Right.
>>>
>>>> "Errors will display" --> "Errors will be displayed"
>>>>
>>>> "the snippets will be replayed -- the replay is not shown, however, 
>>>> errors will display" --> "the snippits will be replayed. The replay 
>>>> is not shown, **but any** errors will *be displayed*."
>>> I like.
>>>
>>>> ID ranges: these are listed everywhere as a distinct variant, but 
>>>> help.id suggests that they can appear within a list, interleaved 
>>>> with non-ranges. Which is it? (If the latter, maybe don't mention 
>>>> ranges at all for /vars, etc., and explain elsewhere that an "ID" 
>>>> may be a range of simple IDs. Or, if that's too obscure, try 
>>>> "specified snippet ID or range of snippet IDs" in /vars, etc. Or 
>>>> just give the list variant in /var, etc., more details about ranges.)
>>> This was an attempt to keep it simple.  But the result is that seven 
>>> /help descriptions are bloated by having descriptions for singleton 
>>> id, id list, and id range -- while still not being complete.
>>>
>>> How about, I create a new help subject "id" which will describe what 
>>> an id is, how to discover them, and discuss ID ranges. Then I can 
>>> compress the three in each (using /list as the example) from:
>>>
>>>    /list <id>
>>>         List the snippet with the specified snippet ID
>>>    /list <id> <id>...
>>>         List the snippets with the specified snippet IDs
>>>    /list <id>-<id>
>>>         List the snippets within the range of snippet IDs
>>>
>>> to just:
>>>
>>>    /list <id>
>>>         List the snippet with the specified snippet ID.  One or more 
>>> IDs or ID ranges may used, see /help id
>>>
>>>
>>>> "when the jshell is started" "when jshell is restarted" "since this 
>>>> jshell was launched" "debugging of the jshell" "information about 
>>>> jshell": Need to decide is "jshell" refers to the command, or if 
>>>> it's another word for "shell"
>>> Will change all to "the jshell tool"
>>>
>>>> "These options configure the evaluation context, they can be 
>>>> specified" --> "These options configure the evaluation context. 
>>>> They can be specified"
>>> Thanks.
>>>
>>>> "A list of directories, each directory is a directory of modules." 
>>>> --> "A list of directories, **where** each directory **contains** 
>>>> modules"
>>> Thanks
>>>
>>>> "quoted strings printed as input prompts; Both" -- make that a period
>>> OK.
>>>
>>> Looking afresh, seems "quoted strings TO BE printed as input 
>>> prompts." would be clearer.
>>>
>>> Thanks much,
>>> Robert
>>>
>>>
>>>
>


From jonathan.gibbons at oracle.com  Tue Dec 19 19:39:17 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 19 Dec 2017 11:39:17 -0800
Subject: (copy editors) RFR 8179858: jshell tool: sync nomenclature from
 reference to online /help
In-Reply-To: <5A3968C9.8090203@oracle.com>
References: <5A20A70D.10408@oracle.com>
 <AA651E9A-BFD9-4D15-9062-00339CCC0050@oracle.com>
 <5A25F114.6010309@oracle.com>
 <FA1D4D71-2BEF-4F11-A5EF-76287242460E@oracle.com>
 <5A3215DD.1050904@oracle.com>
 <4E406CF8-81A6-4E4D-88A6-080D2D5125CA@oracle.com>
 <5A396352.8090908@oracle.com> <5A3968C9.8090203@oracle.com>
Message-ID: <5A396AE5.4080300@oracle.com>

Thumbs up.

-- Jon

On 12/19/2017 11:30 AM, Robert Field wrote:
>
> On 12/19/17 11:06, Jonathan Gibbons wrote:
>> Mostly OK/approved.   I found one line that needs to be fixed.
>>
>> Reading
>>
>> http://cr.openjdk.java.net/~rfield/8179858v1.webrev/
>>
>> In l10n.properties, two "a the".
>>
>>  570         a the jshell tool command, or, in some cases, a the 
>> jshell tool command argument,\n\t\t\
>
> Oops! Fixed
>
>>
>>
>> Stylistically, for a future edit, unless you are doing specific 
>> custom processing on the resource strings for tabs after newlines, I 
>> would suggest using the convention of a slash at the beginning of a 
>> line, as in
>>
>> OLD:
>>
>> property.name=property value\n\t\
>>     indented value
>>
>>
>> NEW:
>>
>> property.name=property value\n\
>> \    indented value
>>
>> The leading slash character "protects the spaces that follow.
>
> Yes, that would be more readable.  Will migrate to that in future revs.
>
> Do you want another review cycle?

No.

>
> Thanks,
> Robert
>
>
>>
>> -- Jon
>>
>>
>> On 12/19/2017 10:08 AM, Dan Smith wrote:
>>> Thumbs up.
>>>
>>>> On Dec 13, 2017, at 11:10 PM, Robert Field 
>>>> <robert.field at oracle.com> wrote:
>>>>
>>>> Here is the updated webrev, based on the discussion below -- please 
>>>> review:
>>>>
>>>>      http://cr.openjdk.java.net/~rfield/8179858v1.webrev/ 
>>>> <http://cr.openjdk.java.net/~rfield/8179858v1.webrev/>
>>>>
>>>> Bug:
>>>>
>>>>      https://bugs.openjdk.java.net/browse/JDK-8179858 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8179858>
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>> On 12/12/17 14:26, Dan Smith wrote:
>>>>>> On Dec 4, 2017, at 6:06 PM, Robert Field 
>>>>>> <robert.field at oracle.com> <mailto:robert.field at oracle.com> wrote:
>>>>>>
>>>>>> Very helpful.  See questions inline.
>>>>>>
>>>>>>> "command-line": Same
>>>>>> Either is fine with me,  I can be consistent with the above, or 
>>>>>> change it back.
>>>>> Whatever you like is fine. Just wanted to draw some attention to it.
>>>>>
>>>>>> How about:
>>>>>>
>>>>>>   For Unix, Linux and macOS, use a  colon (:) to separate items 
>>>>>> in the path.  For Windows, use a semicolon (;) to separate items.
>>>>>>
>>>>>> Or just:
>>>>>>
>>>>>>   For Windows, use a semicolon (;) to separate items in the path. 
>>>>>> On other platforms, use a  colon (:) to separate items.
>>>>> Yeah, that last one seems the least brittle.
>>>>>
>>>>>>> I'd also replace "types" with "type declarations" throughout, 
>>>>>>> because "type" is such an overloaded term.
>>>>>> Good, that will read more clearly too.
>>>>>>
>>>>>> I guess, then, that I should change the summary from:
>>>>>>
>>>>>>   list the declared types
>>>>>>
>>>>>> to:
>>>>>>
>>>>>>   list the type declarations
>>>>>>
>>>>>> ???
>>>>> I'd lean slightly towards the latter. I'm not so concerned about 
>>>>> "declared types", because it's clear you're talking about the 
>>>>> subset of types that have declarations. But there's a one-to-many 
>>>>> relationship between generic class declarations and class types, 
>>>>> and of course you're not claiming to list every parameterization 
>>>>> of that generic class.
>>>>>
>>>>>>> ID ranges: these are listed everywhere as a distinct variant, 
>>>>>>> but help.id suggests that they can appear within a list, 
>>>>>>> interleaved with non-ranges. Which is it? (If the latter, maybe 
>>>>>>> don't mention ranges at all for /vars, etc., and explain 
>>>>>>> elsewhere that an "ID" may be a range of simple IDs. Or, if 
>>>>>>> that's too obscure, try "specified snippet ID or range of 
>>>>>>> snippet IDs" in /vars, etc. Or just give the list variant in 
>>>>>>> /var, etc., more details about ranges.)
>>>>>> This was an attempt to keep it simple.  But the result is that 
>>>>>> seven /help descriptions are bloated by having descriptions for 
>>>>>> singleton id, id list, and id range -- while still not being 
>>>>>> complete.
>>>>>>
>>>>>> How about, I create a new help subject "id" which will describe 
>>>>>> what an id is, how to discover them, and discuss ID ranges. Then 
>>>>>> I can compress the three in each (using /list as the example) from:
>>>>>>
>>>>>>   /list <id>
>>>>>>        List the snippet with the specified snippet ID
>>>>>>   /list <id> <id>...
>>>>>>        List the snippets with the specified snippet IDs
>>>>>>   /list <id>-<id>
>>>>>>        List the snippets within the range of snippet IDs
>>>>>>
>>>>>> to just:
>>>>>>
>>>>>>   /list <id>
>>>>>>        List the snippet with the specified snippet ID. One or 
>>>>>> more IDs or ID ranges may used, see /help id
>>>>> I like that.
>>>>>
>>>>> ?Dan
>>>> Very helpful.  See questions inline.
>>>>
>>>> On 12/04/17 12:11, Dan Smith wrote:
>>>>> Didn't find any serious problems, but here's a list of minor tweaks.
>>>>>
>>>>> ?Dan
>>>>>
>>>>> -----
>>>>>
>>>>> --class-path, --module-path: I don't understand the purpose of the 
>>>>> '*' at the end, but I assume it's intentional.
>>>> It was a reference to the path note below it.  Clearly didn't work. 
>>>> Will remove.
>>>>
>>>>> "load-file": I'd tend to avoid hyphens in compound nouns and stick 
>>>>> to "load file", but apparently conventions vary:
>>>>> https://en.oxforddictionaries.com/punctuation/hyphen 
>>>>> <https://en.oxforddictionaries.com/punctuation/hyphen>
>>>> I choose hyphen so that in in the syntax "Usage:   jshell 
>>>> <option>... <load-file>..." it is clear that it is one thing, not 
>>>> two.  I'll lean on the varying conventions.
>>>>
>>>>> "command-line": Same
>>>> Either is fine with me,  I can be consistent with the above, or 
>>>> change it back.
>>>>
>>>>> "For Linux and macOS": are there other supported Unix OSes? For 
>>>>> comparison, here's the Javadoc for System.lineSeparator: "On UNIX 
>>>>> systems, it returns "\n"; on Microsoft Windows systems it returns 
>>>>> "\r\n".
>>>> Good point, this wording is from the Tools Reference, will discuss 
>>>> with docs team for the Tool Reference.  Don't know if there are 
>>>> other supported OSes.
>>>>
>>>> I'd be concerned that many/most macOS users are not aware they are 
>>>> on a Unix platform.  Also, Linux is not technically a Unix(tm) OS.
>>>>
>>>> How about:
>>>>
>>>>    For Unix, Linux and macOS, use a  colon (:) to separate items in 
>>>> the path.  For Windows, use a semicolon (;) to separate items.
>>>>
>>>> Or just:
>>>>
>>>>    For Windows, use a semicolon (;) to separate items in the path. 
>>>> On other platforms, use a  colon (:) to separate items.
>>>>
>>>>> "A path is the directories and archives to search" --> "A path 
>>>>> **lists** the directories and archives to search"
>>>> Thanks.
>>>>
>>>>> "module-private package": I don't know my Jigsaw terminology very 
>>>>> well, but this may not be a standard term. javac -X says "Specify 
>>>>> a package to be considered as exported from its defining module"
>>>> Indeed best to match.  Unlike javac, the default if <other-module> 
>>>> is unspecified is ALL-UNNAMED which exports it to JShell code (in 
>>>> fact, that =<other-module> can be specified is undocumented).
>>>>
>>>> Simplest is what you suggest:
>>>>
>>>>         --add-exports <module>/<package> Specify a package to be 
>>>> considered as exported from its defining module
>>>>
>>>> I like that.
>>>>
>>>>> "Show the snippets, prefaced with the snippet ID": either "each 
>>>>> snippet" or "their snippet IDs"
>>>> Thanks.
>>>>
>>>> I like the latter:
>>>>
>>>>      Show the snippets, prefaced with their snippet IDs
>>>>
>>>>> /save: inconsistent use of periods (this comment may apply more 
>>>>> broadly?should do a quick pass to check)
>>>> Ah, yes. line 315, and also 383, 461 and all of /set -- will survey
>>>>
>>>>> /types: An enum is a kind of class, so it's not necessary to list 
>>>>> it separately (and it makes me think "what about annotation 
>>>>> types?"). Just "classes and interfaces" is fine.
>>>> Newbies may not make that connection, but they should, OK.
>>>>
>>>>> I'd also replace "types" with "type declarations" throughout, 
>>>>> because "type" is such an overloaded term.
>>>> Good, that will read more clearly too.
>>>>
>>>> I guess, then, that I should change the summary from:
>>>>
>>>>    list the declared types
>>>>
>>>> to:
>>>>
>>>>    list the type declarations
>>>>
>>>> ???
>>>>
>>>>> "since jshell was entered, or a /reset, or /reload command was 
>>>>> executed" --> "since jshell was entered, or a /reset or /reload 
>>>>> command was executed"
>>>> Right.
>>>>
>>>>> "Errors will display" --> "Errors will be displayed"
>>>>>
>>>>> "the snippets will be replayed -- the replay is not shown, 
>>>>> however, errors will display" --> "the snippits will be replayed. 
>>>>> The replay is not shown, **but any** errors will *be displayed*."
>>>> I like.
>>>>
>>>>> ID ranges: these are listed everywhere as a distinct variant, but 
>>>>> help.id suggests that they can appear within a list, interleaved 
>>>>> with non-ranges. Which is it? (If the latter, maybe don't mention 
>>>>> ranges at all for /vars, etc., and explain elsewhere that an "ID" 
>>>>> may be a range of simple IDs. Or, if that's too obscure, try 
>>>>> "specified snippet ID or range of snippet IDs" in /vars, etc. Or 
>>>>> just give the list variant in /var, etc., more details about ranges.)
>>>> This was an attempt to keep it simple.  But the result is that 
>>>> seven /help descriptions are bloated by having descriptions for 
>>>> singleton id, id list, and id range -- while still not being complete.
>>>>
>>>> How about, I create a new help subject "id" which will describe 
>>>> what an id is, how to discover them, and discuss ID ranges. Then I 
>>>> can compress the three in each (using /list as the example) from:
>>>>
>>>>    /list <id>
>>>>         List the snippet with the specified snippet ID
>>>>    /list <id> <id>...
>>>>         List the snippets with the specified snippet IDs
>>>>    /list <id>-<id>
>>>>         List the snippets within the range of snippet IDs
>>>>
>>>> to just:
>>>>
>>>>    /list <id>
>>>>         List the snippet with the specified snippet ID.  One or 
>>>> more IDs or ID ranges may used, see /help id
>>>>
>>>>
>>>>> "when the jshell is started" "when jshell is restarted" "since 
>>>>> this jshell was launched" "debugging of the jshell" "information 
>>>>> about jshell": Need to decide is "jshell" refers to the command, 
>>>>> or if it's another word for "shell"
>>>> Will change all to "the jshell tool"
>>>>
>>>>> "These options configure the evaluation context, they can be 
>>>>> specified" --> "These options configure the evaluation context. 
>>>>> They can be specified"
>>>> Thanks.
>>>>
>>>>> "A list of directories, each directory is a directory of modules." 
>>>>> --> "A list of directories, **where** each directory **contains** 
>>>>> modules"
>>>> Thanks
>>>>
>>>>> "quoted strings printed as input prompts; Both" -- make that a period
>>>> OK.
>>>>
>>>> Looking afresh, seems "quoted strings TO BE printed as input 
>>>> prompts." would be clearer.
>>>>
>>>> Thanks much,
>>>> Robert
>>>>
>>>>
>>>>
>>
>