From jonathan.gibbons at oracle.com  Tue Jan  2 21:34:43 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 02 Jan 2018 13:34:43 -0800
Subject: Routine test failure
Message-ID: <5A4BFAF3.2060503@oracle.com>

Kulla folk,

When I run the following test locally, it routinely fails with an Out Of 
Memory error.
test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java

STDOUT:
[TestNG] Running:
   jdk/internal/shellsupport/doc/JavadocHelperTest.java

test JavadocHelperTest.testAllDocs(): failure
java.lang.OutOfMemoryError: Java heap space: failed reallocation of 
scalar replaced objects


Should it have some custom configuration to ensure it has enough memory?

-- Jon



From jan.lahoda at oracle.com  Fri Jan  5 15:07:12 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 5 Jan 2018 16:07:12 +0100
Subject: RFR: JDK-8191842: JShell: Inferred type information is lost when
 assigning types to a "var"
In-Reply-To: <5A31AA30.20204@oracle.com>
References: <5A30FACE.20309@oracle.com> <5A319FD4.4050205@oracle.com>
 <5A31AA30.20204@oracle.com>
Message-ID: <5A4F94A0.9040707@oracle.com>

Hi,

Thanks for the comments. An updated patch is here:
http://cr.openjdk.java.net/~jlahoda/8191842/webrev.01/

I addition to addressing the comments, it also fixes var behavior when 
the inferred type is inaccessible - that is allowed during normal 
compilation.

Feedback is welcome,
     Jan

On 13.12.2017 23:31, Robert Field wrote:
> 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 robert.field at oracle.com  Tue Jan  9 03:19:10 2018
From: robert.field at oracle.com (Robert Field)
Date: Mon, 8 Jan 2018 19:19:10 -0800
Subject: RFR: JDK-8191842: JShell: Inferred type information is lost when
 assigning types to a "var"
In-Reply-To: <5A4F94A0.9040707@oracle.com>
References: <5A30FACE.20309@oracle.com> <5A319FD4.4050205@oracle.com>
 <5A31AA30.20204@oracle.com> <5A4F94A0.9040707@oracle.com>
Message-ID: <242b395c-2089-41b0-58d9-ba964cf93f08@oracle.com>

Review (partial) --


Wrap:

71: The new parameter makes slightly worse a horribly out-of-date method 
comment (my bad), which could be
 ????? deleted, but better actually documented -- there are a lot of 
parameters and they would benefit from an
 ????? explanation certainly including the new one "enhanced".

82: Built as a list is a good choice.

91: Nit: The comment is helpful but much longer than anything around it 
and would be more readable formatted.
 ????? Also, the example type "int" copied from the comment below 
doesn't make any sense in this context, and so
 ????? is confusing, maybe they should both be "Foo".

Eval:

106: Action at a distance.? Document, or better, use another mechanism.

213: The parameter order and cast are inconsistent with all the other 
process* calls in this switch.

341-343/347: Inconsistent

380-529: Indenting and spacing off

389-393...: I don't get why TreeScanner is run in ExpressionToTypeInfo 
and then again in Eval with deep interlinking
 ?????????????? assumptions (like the order of the list).? The only data 
added in the Eval scan is the 'NewClassTree node' which
 ?????????????? could be in AnonymousDescription.? Then you could just 
iterate the AnonymousDescriptions.

410: I'd make this something less likely to be a captured variable 
name.? That is a unique prefix.

418: ditto

399-445: Anonymous classes are infrequent enough to make this unlikely 
an issue, so can ignore this comment.
 ??????????????? The components of a wrap have overhead:
 ??????????????? they are stored independently for the duration and they 
are sequentially searched.? Within this
 ??????????????? section these are all strings, so you could use 
StringBuilder, but the complexity of the extra variables would
 ??????????????? make that messy.? You could just use string '+' rather 
then 2-5 'add' calls inline -- there is no value in
 ??????????????? separating adjacent strings (only for Wraps).? And the 
result would probably be more readable.

436: BUG, you are double incrementing 'i'.? Please include a test like:

 ??? class D { D(int foo, String bar) { this.foo = foo; this.bar = bar; 
} int foo; String bar; }
 ??? new D(34, "hi") { String z = foo + bar; }
 ??? $3.z

-Robert


On 01/05/18 07:07, Jan Lahoda wrote:
> Hi,
>
> Thanks for the comments. An updated patch is here:
> http://cr.openjdk.java.net/~jlahoda/8191842/webrev.01/
>
> I addition to addressing the comments, it also fixes var behavior when 
> the inferred type is inaccessible - that is allowed during normal 
> compilation.
>
> Feedback is welcome,
> ??? Jan
>
> On 13.12.2017 23:31, Robert Field wrote:
>> 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 jan.lahoda at oracle.com  Thu Jan 11 17:17:48 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 11 Jan 2018 18:17:48 +0100
Subject: RFR: JDK-8191842: JShell: Inferred type information is lost when
 assigning types to a "var"
In-Reply-To: <242b395c-2089-41b0-58d9-ba964cf93f08@oracle.com>
References: <5A30FACE.20309@oracle.com> <5A319FD4.4050205@oracle.com>
 <5A31AA30.20204@oracle.com> <5A4F94A0.9040707@oracle.com>
 <242b395c-2089-41b0-58d9-ba964cf93f08@oracle.com>
Message-ID: <5A579C3C.4080708@oracle.com>

Hi,

Thanks for all the comments so far. I tried to adjust the code and add 
comments. The updated patch is here:
http://cr.openjdk.java.net/~jlahoda/8191842/webrev.02/

On 9.1.2018 04:19, Robert Field wrote:
> Review (partial) --
>
>
> Wrap:
>
> 71: The new parameter makes slightly worse a horribly out-of-date method
> comment (my bad), which could be
>        deleted, but better actually documented -- there are a lot of
> parameters and they would benefit from an
>        explanation certainly including the new one "enhanced".
>
> 82: Built as a list is a good choice.
>
> 91: Nit: The comment is helpful but much longer than anything around it
> and would be more readable formatted.
>        Also, the example type "int" copied from the comment below
> doesn't make any sense in this context, and so
>        is confusing, maybe they should both be "Foo".
>
> Eval:
>
> 106: Action at a distance.  Document, or better, use another mechanism.
>
> 213: The parameter order and cast are inconsistent with all the other
> process* calls in this switch.
>
> 341-343/347: Inconsistent
>
> 380-529: Indenting and spacing off
>
> 389-393...: I don't get why TreeScanner is run in ExpressionToTypeInfo
> and then again in Eval with deep interlinking
>                 assumptions (like the order of the list).  The only data
> added in the Eval scan is the 'NewClassTree node' which
>                 could be in AnonymousDescription.  Then you could just
> iterate the AnonymousDescriptions.

That's not quite simple, as the positions don't match (which could of 
course be solved) and the NewClassTree from the ExpressionToTypeInfo 
also already has the synthetic constructor added. I tried to define one 
method that lists the relevant NewClassTrees in order, and use it on 
both places, which should hopefully make it more robust.

Jan

>
> 410: I'd make this something less likely to be a captured variable
> name.  That is a unique prefix.
>
> 418: ditto
>
> 399-445: Anonymous classes are infrequent enough to make this unlikely
> an issue, so can ignore this comment.
>                  The components of a wrap have overhead:
>                  they are stored independently for the duration and they
> are sequentially searched.  Within this
>                  section these are all strings, so you could use
> StringBuilder, but the complexity of the extra variables would
>                  make that messy.  You could just use string '+' rather
> then 2-5 'add' calls inline -- there is no value in
>                  separating adjacent strings (only for Wraps).  And the
> result would probably be more readable.
>
> 436: BUG, you are double incrementing 'i'.  Please include a test like:
>
>      class D { D(int foo, String bar) { this.foo = foo; this.bar = bar;
> } int foo; String bar; }
>      new D(34, "hi") { String z = foo + bar; }
>      $3.z
>
> -Robert
>
>
> On 01/05/18 07:07, Jan Lahoda wrote:
>> Hi,
>>
>> Thanks for the comments. An updated patch is here:
>> http://cr.openjdk.java.net/~jlahoda/8191842/webrev.01/
>>
>> I addition to addressing the comments, it also fixes var behavior when
>> the inferred type is inaccessible - that is allowed during normal
>> compilation.
>>
>> Feedback is welcome,
>>     Jan
>>
>> On 13.12.2017 23:31, Robert Field wrote:
>>> 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 robert.field at oracle.com  Fri Jan 12 04:02:46 2018
From: robert.field at oracle.com (Robert Field)
Date: Thu, 11 Jan 2018 20:02:46 -0800
Subject: RFR: JDK-8191842: JShell: Inferred type information is lost when
 assigning types to a "var"
In-Reply-To: <5A579C3C.4080708@oracle.com>
References: <5A30FACE.20309@oracle.com> <5A319FD4.4050205@oracle.com>
 <5A31AA30.20204@oracle.com> <5A4F94A0.9040707@oracle.com>
 <242b395c-2089-41b0-58d9-ba964cf93f08@oracle.com>
 <5A579C3C.4080708@oracle.com>
Message-ID: <c53d17bf-49f3-3407-34be-2291642702ef@oracle.com>

Eval:

 ? Nicely documented!

 ? 1218: anonCount is not incremented, so you always have the same 
anonymous class name.
 ? ? ? ? ? ? Which, of course, is a problem if you have more than one:

 ? ? ? ? ? ? jshell> class A {}
 ? ? ? ? ? ? |? created class A

 ? ? ? ? ? ? jshell> new A() { int foo() {return 66; }}
 ? ? ? ? ? ? $2 ==> $0 at 7dc7cbad

 ? ? ? ? ? ? jshell> new A() { int hhoo() {return 99; }}
 ? ? ? ? ? ? $3 ==> $0 at 548a9f61

 ? ? ? ? ? ? jshell> $3.hhoo()
 ? ? ? ? ? ? An exception has occurred in the compiler (10-internal). 
Please file a bug against the Java compiler via ...
 ? ? ? ? ? ? java.lang.ClassCastException: 
jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol cannot be cast to
jdk.compiler/com.sun.tools.javac.code.Symbol$MethodSymbol
 ? ? ? ? ? ? ??????? at 
jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitApply(TransTypes.java:676)
 ? ? ? ? ? ? ??????? at 
jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634)
 ? ? ? ? ? ? ??????? ...

 ??????????? Please include tests with multiple anon classes with member 
accesses.

 ? 402: Nit: "create and explicit class that extens" --> "create AN 
explicit class that EXTENDS"

ExpressionToTypeInfo:

 ? 93: it is conventional, consistent with surrounding vars, and clearer 
to preface predicate names with "is" -- isPrimativeType

 ? 414: for variable declarations with an explicit type, it doesn't seem 
we should be processing anonymous classes in that case

TaskFactory:

 ? The new code is, for every pass through Enter (of which there are 
several per new snippet), iterating through all the
 ? snippets, filtering for valid vars, looking up the wrap class 
containing the var, iterating through the members of
 ? that class to find the field representing the var, compiling a cast 
to use to set the type by force.? The field type
 ? is restored before generation.

 ? One concern is that the performance decreases with the number of 
snippets.
 ? We need to stay aware of long-running JShell instances -- as for a 
user that leaves the jshell tool open for exploration.
 ? The filtering on fullTypeName being non-null for enhanced types 
limits the heavy processing to these rarer cases,
 ? so I'm not concerned

 ? I assume all types downstream of these variables are processed after 
Enter finishes?

 ? Thanks for the high-level description of setVariableType, however how 
it is implemented is complex enough to deserve
 ? documentation (something like the first paragraph).

TreeDissector:

 ? OK

TypePrinter:

 ? OK

Util:

 ? OK

VarSnippet:

 ? OK

Wrap:

 ? Nicely documented!

Tests:

 ? Please include a test covering the bug (above).

 ? Please include tests covering:
 ??? captured variables
 ??? extending a variety of complex library classes and interfaces
 ??? varied argument types
 ??? parameterized types
 ??? VarSnippet.typeName() under various conditions

-Robert

On 01/11/18 09:17, Jan Lahoda wrote:
> Hi,
>
> Thanks for all the comments so far. I tried to adjust the code and add 
> comments. The updated patch is here:
> http://cr.openjdk.java.net/~jlahoda/8191842/webrev.02/
>
> On 9.1.2018 04:19, Robert Field wrote:
>> Review (partial) --
>>
>>
>> Wrap:
>>
>> 71: The new parameter makes slightly worse a horribly out-of-date method
>> comment (my bad), which could be
>> ?????? deleted, but better actually documented -- there are a lot of
>> parameters and they would benefit from an
>> ?????? explanation certainly including the new one "enhanced".
>>
>> 82: Built as a list is a good choice.
>>
>> 91: Nit: The comment is helpful but much longer than anything around it
>> and would be more readable formatted.
>> ?????? Also, the example type "int" copied from the comment below
>> doesn't make any sense in this context, and so
>> ?????? is confusing, maybe they should both be "Foo".
>>
>> Eval:
>>
>> 106: Action at a distance.? Document, or better, use another mechanism.
>>
>> 213: The parameter order and cast are inconsistent with all the other
>> process* calls in this switch.
>>
>> 341-343/347: Inconsistent
>>
>> 380-529: Indenting and spacing off
>>
>> 389-393...: I don't get why TreeScanner is run in ExpressionToTypeInfo
>> and then again in Eval with deep interlinking
>> ??????????????? assumptions (like the order of the list).? The only data
>> added in the Eval scan is the 'NewClassTree node' which
>> ??????????????? could be in AnonymousDescription.? Then you could just
>> iterate the AnonymousDescriptions.
>
> That's not quite simple, as the positions don't match (which could of 
> course be solved) and the NewClassTree from the ExpressionToTypeInfo 
> also already has the synthetic constructor added. I tried to define 
> one method that lists the relevant NewClassTrees in order, and use it 
> on both places, which should hopefully make it more robust.
>
> Jan
>
>>
>> 410: I'd make this something less likely to be a captured variable
>> name.? That is a unique prefix.
>>
>> 418: ditto
>>
>> 399-445: Anonymous classes are infrequent enough to make this unlikely
>> an issue, so can ignore this comment.
>> ???????????????? The components of a wrap have overhead:
>> ???????????????? they are stored independently for the duration and they
>> are sequentially searched.? Within this
>> ???????????????? section these are all strings, so you could use
>> StringBuilder, but the complexity of the extra variables would
>> ???????????????? make that messy.? You could just use string '+' rather
>> then 2-5 'add' calls inline -- there is no value in
>> ???????????????? separating adjacent strings (only for Wraps). And the
>> result would probably be more readable.
>>
>> 436: BUG, you are double incrementing 'i'.? Please include a test like:
>>
>> ???? class D { D(int foo, String bar) { this.foo = foo; this.bar = bar;
>> } int foo; String bar; }
>> ???? new D(34, "hi") { String z = foo + bar; }
>> ???? $3.z
>>
>> -Robert
>>
>>
>> On 01/05/18 07:07, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Thanks for the comments. An updated patch is here:
>>> http://cr.openjdk.java.net/~jlahoda/8191842/webrev.01/
>>>
>>> I addition to addressing the comments, it also fixes var behavior when
>>> the inferred type is inaccessible - that is allowed during normal
>>> compilation.
>>>
>>> Feedback is welcome,
>>> ??? Jan
>>>
>>> On 13.12.2017 23:31, Robert Field wrote:
>>>> 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 jan.lahoda at oracle.com  Mon Jan 15 11:55:48 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 15 Jan 2018 12:55:48 +0100
Subject: Routine test failure
In-Reply-To: <5A4BFAF3.2060503@oracle.com>
References: <5A4BFAF3.2060503@oracle.com>
Message-ID: <5A5C96C4.8010304@oracle.com>

So, would something like the following work?
------------
diff -r d16ebd094618 
test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java
--- 
a/test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java 
     Thu Jan 11 16:22:50 2018 +0100
+++ 
b/test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java 
     Mon Jan 15 12:53:11 2018 +0100
@@ -30,7 +30,7 @@
   *          jdk.compiler/com.sun.tools.javac.main
   *          jdk.compiler/jdk.internal.shellsupport.doc
   * @build toolbox.ToolBox toolbox.JarTask toolbox.JavacTask
- * @run testng/timeout=900/othervm JavadocHelperTest
+ * @run testng/timeout=900/othervm -Xmx1024m JavadocHelperTest 
 
 

   */ 
 
 

 
 
 

  import java.io.IOException; 
 
 

------------

Jan


On 2.1.2018 22:34, Jonathan Gibbons wrote:
> Kulla folk,
>
> When I run the following test locally, it routinely fails with an Out Of
> Memory error.
> test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java
>
> STDOUT:
> [TestNG] Running:
>    jdk/internal/shellsupport/doc/JavadocHelperTest.java
>
> test JavadocHelperTest.testAllDocs(): failure
> java.lang.OutOfMemoryError: Java heap space: failed reallocation of
> scalar replaced objects
>
>
> Should it have some custom configuration to ensure it has enough memory?
>
> -- Jon
>
>

From jonathan.gibbons at oracle.com  Mon Jan 15 16:37:57 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 15 Jan 2018 08:37:57 -0800
Subject: Routine test failure
In-Reply-To: <5A5C96C4.8010304@oracle.com>
References: <5A4BFAF3.2060503@oracle.com> <5A5C96C4.8010304@oracle.com>
Message-ID: <e0a69190-bdc4-2711-0a7e-c3d4cfa280ae@oracle.com>

I'll try that out.

What's the test doing that requires so much time and memory?

-- Jon


On 1/15/18 3:55 AM, Jan Lahoda wrote:
> So, would something like the following work?
> ------------
> diff -r d16ebd094618 
> test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java
> --- 
> a/test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java 
> ??? Thu Jan 11 16:22:50 2018 +0100
> +++ 
> b/test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java 
> ??? Mon Jan 15 12:53:11 2018 +0100
> @@ -30,7 +30,7 @@
> ? *????????? jdk.compiler/com.sun.tools.javac.main
> ? *????????? jdk.compiler/jdk.internal.shellsupport.doc
> ? * @build toolbox.ToolBox toolbox.JarTask toolbox.JavacTask
> - * @run testng/timeout=900/othervm JavadocHelperTest
> + * @run testng/timeout=900/othervm -Xmx1024m JavadocHelperTest
>
>
> ? */
>
>
>
>
>
>
> ?import java.io.IOException;
>
>
> ------------
>
> Jan
>
>
> On 2.1.2018 22:34, Jonathan Gibbons wrote:
>> Kulla folk,
>>
>> When I run the following test locally, it routinely fails with an Out Of
>> Memory error.
>> test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java
>>
>> STDOUT:
>> [TestNG] Running:
>> ?? jdk/internal/shellsupport/doc/JavadocHelperTest.java
>>
>> test JavadocHelperTest.testAllDocs(): failure
>> java.lang.OutOfMemoryError: Java heap space: failed reallocation of
>> scalar replaced objects
>>
>>
>> Should it have some custom configuration to ensure it has enough memory?
>>
>> -- Jon
>>
>>


From jan.lahoda at oracle.com  Mon Jan 15 20:15:05 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 15 Jan 2018 21:15:05 +0100
Subject: Routine test failure
In-Reply-To: <e0a69190-bdc4-2711-0a7e-c3d4cfa280ae@oracle.com>
References: <5A4BFAF3.2060503@oracle.com> <5A5C96C4.8010304@oracle.com>
 <e0a69190-bdc4-2711-0a7e-c3d4cfa280ae@oracle.com>
Message-ID: <5A5D0BC9.3080504@oracle.com>

On 15.1.2018 17:37, Jonathan Gibbons wrote:
> I'll try that out.

Thanks.

>
> What's the test doing that requires so much time and memory?

Looks at all javadocs in the image (from src.zip), and checks that the 
JavadocHelper.getResolvedDocComment method does not crash on them.

Jan

>
> -- Jon
>
>
> On 1/15/18 3:55 AM, Jan Lahoda wrote:
>> So, would something like the following work?
>> ------------
>> diff -r d16ebd094618
>> test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java
>> ---
>> a/test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java
>>     Thu Jan 11 16:22:50 2018 +0100
>> +++
>> b/test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java
>>     Mon Jan 15 12:53:11 2018 +0100
>> @@ -30,7 +30,7 @@
>>   *          jdk.compiler/com.sun.tools.javac.main
>>   *          jdk.compiler/jdk.internal.shellsupport.doc
>>   * @build toolbox.ToolBox toolbox.JarTask toolbox.JavacTask
>> - * @run testng/timeout=900/othervm JavadocHelperTest
>> + * @run testng/timeout=900/othervm -Xmx1024m JavadocHelperTest
>>
>>
>>   */
>>
>>
>>
>>
>>
>>
>>  import java.io.IOException;
>>
>>
>> ------------
>>
>> Jan
>>
>>
>> On 2.1.2018 22:34, Jonathan Gibbons wrote:
>>> Kulla folk,
>>>
>>> When I run the following test locally, it routinely fails with an Out Of
>>> Memory error.
>>> test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java
>>>
>>> STDOUT:
>>> [TestNG] Running:
>>>    jdk/internal/shellsupport/doc/JavadocHelperTest.java
>>>
>>> test JavadocHelperTest.testAllDocs(): failure
>>> java.lang.OutOfMemoryError: Java heap space: failed reallocation of
>>> scalar replaced objects
>>>
>>>
>>> Should it have some custom configuration to ensure it has enough memory?
>>>
>>> -- Jon
>>>
>>>
>

From jan.lahoda at oracle.com  Mon Jan 15 20:24:59 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 15 Jan 2018 21:24:59 +0100
Subject: RFR: JDK-8191842: JShell: Inferred type information is lost when
 assigning types to a "var"
In-Reply-To: <5A579C3C.4080708@oracle.com>
References: <5A30FACE.20309@oracle.com> <5A319FD4.4050205@oracle.com>
 <5A31AA30.20204@oracle.com> <5A4F94A0.9040707@oracle.com>
 <242b395c-2089-41b0-58d9-ba964cf93f08@oracle.com>
 <5A579C3C.4080708@oracle.com>
Message-ID: <5A5D0E1B.80004@oracle.com>

Thanks for the comments. An updated patch is here:
http://cr.openjdk.java.net/~jlahoda/8191842/webrev.03/

> Eval:
>
>    Nicely documented!
>
>    1218: anonCount is not incremented, so you always have the same
> anonymous class name.
>              Which, of course, is a problem if you have more than one:
>
>              jshell> class A {}
>              |  created class A
>
>              jshell> new A() { int foo() {return 66; }}
>              $2 ==> $0 at 7dc7cbad
>
>              jshell> new A() { int hhoo() {return 99; }}
>              $3 ==> $0 at 548a9f61
>
>              jshell> $3.hhoo()
>              An exception has occurred in the compiler (10-internal).
> Please file a bug against the Java compiler via ...
>              java.lang.ClassCastException:
> jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol cannot be cast to
> jdk.compiler/com.sun.tools.javac.code.Symbol$MethodSymbol
>                      at
> jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitApply(TransTypes.java:676)
>                      at
> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634)
>                      ...
>
>              Please include tests with multiple anon classes with member
> accesses.

Oops. Fixed and done.

>
>    402: Nit: "create and explicit class that extens" --> "create AN
> explicit class that EXTENDS"

Fixed.

>
> ExpressionToTypeInfo:
>
>    93: it is conventional, consistent with surrounding vars, and clearer
> to preface predicate names with "is" -- isPrimativeType

Fixed.

>
>    414: for variable declarations with an explicit type, it doesn't seem
> we should be processing anonymous classes in that case

Fixed.

>
> TaskFactory:
>
>    The new code is, for every pass through Enter (of which there are
> several per new snippet), iterating through all the
>    snippets, filtering for valid vars, looking up the wrap class
> containing the var, iterating through the members of
>    that class to find the field representing the var, compiling a cast
> to use to set the type by force.  The field type
>    is restored before generation.
>
>    One concern is that the performance decreases with the number of
> snippets.
>    We need to stay aware of long-running JShell instances -- as for a
> user that leaves the jshell tool open for exploration.
>    The filtering on fullTypeName being non-null for enhanced types
> limits the heavy processing to these rarer cases,
>    so I'm not concerned
>
>    I assume all types downstream of these variables are processed after
> Enter finishes?

Yes. I've changed the code to run through the snippets only once.

>
>    Thanks for the high-level description of setVariableType, however how
> it is implemented is complex enough to deserve
>    documentation (something like the first paragraph).

Fixed.

>
> TreeDissector:
>
>    OK
>
> TypePrinter:
>
>    OK
>
> Util:
>
>    OK
>
> VarSnippet:
>
>    OK
>
> Wrap:
>
>    Nicely documented!
>
> Tests:
>
>    Please include a test covering the bug (above).

Done.

>
>    Please include tests covering:
>      captured variables

There already were multiple such tests? Or what exactly test is missing?

>      extending a variety of complex library classes and interfaces

Done.

>      varied argument types

Done.

>      parameterized types

Done.

>      VarSnippet.typeName() under various conditions

Done.

Jan

>
> -Robert


On 11.1.2018 18:17, Jan Lahoda wrote:
> Hi,
>
> Thanks for all the comments so far. I tried to adjust the code and add
> comments. The updated patch is here:
> http://cr.openjdk.java.net/~jlahoda/8191842/webrev.02/
>
> On 9.1.2018 04:19, Robert Field wrote:
>> Review (partial) --
>>
>>
>> Wrap:
>>
>> 71: The new parameter makes slightly worse a horribly out-of-date method
>> comment (my bad), which could be
>>        deleted, but better actually documented -- there are a lot of
>> parameters and they would benefit from an
>>        explanation certainly including the new one "enhanced".
>>
>> 82: Built as a list is a good choice.
>>
>> 91: Nit: The comment is helpful but much longer than anything around it
>> and would be more readable formatted.
>>        Also, the example type "int" copied from the comment below
>> doesn't make any sense in this context, and so
>>        is confusing, maybe they should both be "Foo".
>>
>> Eval:
>>
>> 106: Action at a distance.  Document, or better, use another mechanism.
>>
>> 213: The parameter order and cast are inconsistent with all the other
>> process* calls in this switch.
>>
>> 341-343/347: Inconsistent
>>
>> 380-529: Indenting and spacing off
>>
>> 389-393...: I don't get why TreeScanner is run in ExpressionToTypeInfo
>> and then again in Eval with deep interlinking
>>                 assumptions (like the order of the list).  The only data
>> added in the Eval scan is the 'NewClassTree node' which
>>                 could be in AnonymousDescription.  Then you could just
>> iterate the AnonymousDescriptions.
>
> That's not quite simple, as the positions don't match (which could of
> course be solved) and the NewClassTree from the ExpressionToTypeInfo
> also already has the synthetic constructor added. I tried to define one
> method that lists the relevant NewClassTrees in order, and use it on
> both places, which should hopefully make it more robust.
>
> Jan
>
>>
>> 410: I'd make this something less likely to be a captured variable
>> name.  That is a unique prefix.
>>
>> 418: ditto
>>
>> 399-445: Anonymous classes are infrequent enough to make this unlikely
>> an issue, so can ignore this comment.
>>                  The components of a wrap have overhead:
>>                  they are stored independently for the duration and they
>> are sequentially searched.  Within this
>>                  section these are all strings, so you could use
>> StringBuilder, but the complexity of the extra variables would
>>                  make that messy.  You could just use string '+' rather
>> then 2-5 'add' calls inline -- there is no value in
>>                  separating adjacent strings (only for Wraps).  And the
>> result would probably be more readable.
>>
>> 436: BUG, you are double incrementing 'i'.  Please include a test like:
>>
>>      class D { D(int foo, String bar) { this.foo = foo; this.bar = bar;
>> } int foo; String bar; }
>>      new D(34, "hi") { String z = foo + bar; }
>>      $3.z
>>
>> -Robert
>>
>>
>> On 01/05/18 07:07, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Thanks for the comments. An updated patch is here:
>>> http://cr.openjdk.java.net/~jlahoda/8191842/webrev.01/
>>>
>>> I addition to addressing the comments, it also fixes var behavior when
>>> the inferred type is inaccessible - that is allowed during normal
>>> compilation.
>>>
>>> Feedback is welcome,
>>>     Jan
>>>
>>> On 13.12.2017 23:31, Robert Field wrote:
>>>> 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 robert.field at oracle.com  Mon Jan 15 21:33:51 2018
From: robert.field at oracle.com (Robert Field)
Date: Mon, 15 Jan 2018 13:33:51 -0800
Subject: RFR: JDK-8191842: JShell: Inferred type information is lost when
 assigning types to a "var"
In-Reply-To: <5A5D0E1B.80004@oracle.com>
References: <5A30FACE.20309@oracle.com> <5A319FD4.4050205@oracle.com>
 <5A31AA30.20204@oracle.com> <5A4F94A0.9040707@oracle.com>
 <242b395c-2089-41b0-58d9-ba964cf93f08@oracle.com>
 <5A579C3C.4080708@oracle.com> <5A5D0E1B.80004@oracle.com>
Message-ID: <5d4fd676-b94b-14a4-5954-71f1ce5bf798@oracle.com>

Looks good!

There is an indentation problem in Eval.anonymous2Member.? No need for 
re-review after format.

Great new functionality to have.

-Robert



On 01/15/18 12:24, Jan Lahoda wrote:
> Thanks for the comments. An updated patch is here:
> http://cr.openjdk.java.net/~jlahoda/8191842/webrev.03/
>
>> Eval:
>>
>> ?? Nicely documented!
>>
>> ?? 1218: anonCount is not incremented, so you always have the same
>> anonymous class name.
>> ???????????? Which, of course, is a problem if you have more than one:
>>
>> ???????????? jshell> class A {}
>> ???????????? |? created class A
>>
>> ???????????? jshell> new A() { int foo() {return 66; }}
>> ???????????? $2 ==> $0 at 7dc7cbad
>>
>> ???????????? jshell> new A() { int hhoo() {return 99; }}
>> ???????????? $3 ==> $0 at 548a9f61
>>
>> ???????????? jshell> $3.hhoo()
>> ???????????? An exception has occurred in the compiler (10-internal).
>> Please file a bug against the Java compiler via ...
>> ???????????? java.lang.ClassCastException:
>> jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol cannot be 
>> cast to
>> jdk.compiler/com.sun.tools.javac.code.Symbol$MethodSymbol
>> ???????????????????? at
>> jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitApply(TransTypes.java:676) 
>>
>> ???????????????????? at
>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634) 
>>
>> ???????????????????? ...
>>
>> ???????????? Please include tests with multiple anon classes with member
>> accesses.
>
> Oops. Fixed and done.
>
>>
>> ?? 402: Nit: "create and explicit class that extens" --> "create AN
>> explicit class that EXTENDS"
>
> Fixed.
>
>>
>> ExpressionToTypeInfo:
>>
>> ?? 93: it is conventional, consistent with surrounding vars, and clearer
>> to preface predicate names with "is" -- isPrimativeType
>
> Fixed.
>
>>
>> ?? 414: for variable declarations with an explicit type, it doesn't seem
>> we should be processing anonymous classes in that case
>
> Fixed.
>
>>
>> TaskFactory:
>>
>> ?? The new code is, for every pass through Enter (of which there are
>> several per new snippet), iterating through all the
>> ?? snippets, filtering for valid vars, looking up the wrap class
>> containing the var, iterating through the members of
>> ?? that class to find the field representing the var, compiling a cast
>> to use to set the type by force.? The field type
>> ?? is restored before generation.
>>
>> ?? One concern is that the performance decreases with the number of
>> snippets.
>> ?? We need to stay aware of long-running JShell instances -- as for a
>> user that leaves the jshell tool open for exploration.
>> ?? The filtering on fullTypeName being non-null for enhanced types
>> limits the heavy processing to these rarer cases,
>> ?? so I'm not concerned
>>
>> ?? I assume all types downstream of these variables are processed after
>> Enter finishes?
>
> Yes. I've changed the code to run through the snippets only once.
>
>>
>> ?? Thanks for the high-level description of setVariableType, however how
>> it is implemented is complex enough to deserve
>> ?? documentation (something like the first paragraph).
>
> Fixed.
>
>>
>> TreeDissector:
>>
>> ?? OK
>>
>> TypePrinter:
>>
>> ?? OK
>>
>> Util:
>>
>> ?? OK
>>
>> VarSnippet:
>>
>> ?? OK
>>
>> Wrap:
>>
>> ?? Nicely documented!
>>
>> Tests:
>>
>> ?? Please include a test covering the bug (above).
>
> Done.
>
>>
>> ?? Please include tests covering:
>> ???? captured variables
>
> There already were multiple such tests? Or what exactly test is missing?
>
>> ???? extending a variety of complex library classes and interfaces
>
> Done.
>
>> ???? varied argument types
>
> Done.
>
>> ???? parameterized types
>
> Done.
>
>> ???? VarSnippet.typeName() under various conditions
>
> Done.
>
> Jan
>
>>
>> -Robert
>
>
> On 11.1.2018 18:17, Jan Lahoda wrote:
>> Hi,
>>
>> Thanks for all the comments so far. I tried to adjust the code and add
>> comments. The updated patch is here:
>> http://cr.openjdk.java.net/~jlahoda/8191842/webrev.02/
>>
>> On 9.1.2018 04:19, Robert Field wrote:
>>> Review (partial) --
>>>
>>>
>>> Wrap:
>>>
>>> 71: The new parameter makes slightly worse a horribly out-of-date 
>>> method
>>> comment (my bad), which could be
>>> ?????? deleted, but better actually documented -- there are a lot of
>>> parameters and they would benefit from an
>>> ?????? explanation certainly including the new one "enhanced".
>>>
>>> 82: Built as a list is a good choice.
>>>
>>> 91: Nit: The comment is helpful but much longer than anything around it
>>> and would be more readable formatted.
>>> ?????? Also, the example type "int" copied from the comment below
>>> doesn't make any sense in this context, and so
>>> ?????? is confusing, maybe they should both be "Foo".
>>>
>>> Eval:
>>>
>>> 106: Action at a distance.? Document, or better, use another mechanism.
>>>
>>> 213: The parameter order and cast are inconsistent with all the other
>>> process* calls in this switch.
>>>
>>> 341-343/347: Inconsistent
>>>
>>> 380-529: Indenting and spacing off
>>>
>>> 389-393...: I don't get why TreeScanner is run in ExpressionToTypeInfo
>>> and then again in Eval with deep interlinking
>>> ??????????????? assumptions (like the order of the list).? The only 
>>> data
>>> added in the Eval scan is the 'NewClassTree node' which
>>> ??????????????? could be in AnonymousDescription.? Then you could just
>>> iterate the AnonymousDescriptions.
>>
>> That's not quite simple, as the positions don't match (which could of
>> course be solved) and the NewClassTree from the ExpressionToTypeInfo
>> also already has the synthetic constructor added. I tried to define one
>> method that lists the relevant NewClassTrees in order, and use it on
>> both places, which should hopefully make it more robust.
>>
>> Jan
>>
>>>
>>> 410: I'd make this something less likely to be a captured variable
>>> name.? That is a unique prefix.
>>>
>>> 418: ditto
>>>
>>> 399-445: Anonymous classes are infrequent enough to make this unlikely
>>> an issue, so can ignore this comment.
>>> ???????????????? The components of a wrap have overhead:
>>> ???????????????? they are stored independently for the duration and 
>>> they
>>> are sequentially searched.? Within this
>>> ???????????????? section these are all strings, so you could use
>>> StringBuilder, but the complexity of the extra variables would
>>> ???????????????? make that messy.? You could just use string '+' rather
>>> then 2-5 'add' calls inline -- there is no value in
>>> ???????????????? separating adjacent strings (only for Wraps).? And the
>>> result would probably be more readable.
>>>
>>> 436: BUG, you are double incrementing 'i'.? Please include a test like:
>>>
>>> ???? class D { D(int foo, String bar) { this.foo = foo; this.bar = bar;
>>> } int foo; String bar; }
>>> ???? new D(34, "hi") { String z = foo + bar; }
>>> ???? $3.z
>>>
>>> -Robert
>>>
>>>
>>> On 01/05/18 07:07, Jan Lahoda wrote:
>>>> Hi,
>>>>
>>>> Thanks for the comments. An updated patch is here:
>>>> http://cr.openjdk.java.net/~jlahoda/8191842/webrev.01/
>>>>
>>>> I addition to addressing the comments, it also fixes var behavior when
>>>> the inferred type is inaccessible - that is allowed during normal
>>>> compilation.
>>>>
>>>> Feedback is welcome,
>>>> ??? Jan
>>>>
>>>> On 13.12.2017 23:31, Robert Field wrote:
>>>>> 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 jan.lahoda at oracle.com  Fri Jan 19 18:52:41 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 19 Jan 2018 19:52:41 +0100
Subject: RFR: JDK-8195789: Building of
 test/langtools/jdk/jshell/VariablesTest.java may fail
Message-ID: <5A623E79.8080607@oracle.com>

When pushing the fix for JDK-8191842, I accidentally broke the 
test/langtools/jdk/jshell/VariablesTest.java test, as it now requires 
access to javac internals to compile. The proposed fix is to add the 
proper @modules tag.

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

Sorry for any trouble,
      Jan

From vicente.romero at oracle.com  Fri Jan 19 19:20:56 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 19 Jan 2018 14:20:56 -0500
Subject: RFR: JDK-8195789: Building of
 test/langtools/jdk/jshell/VariablesTest.java may fail
In-Reply-To: <5A623E79.8080607@oracle.com>
References: <5A623E79.8080607@oracle.com>
Message-ID: <fd36aff6-49a7-0aa4-93c5-fd5535434f40@oracle.com>

looks good, please recall to set the right title to the bug before pushing

Vicente

On 01/19/2018 01:52 PM, Jan Lahoda wrote:
> When pushing the fix for JDK-8191842, I accidentally broke the 
> test/langtools/jdk/jshell/VariablesTest.java test, as it now requires 
> access to javac internals to compile. The proposed fix is to add the 
> proper @modules tag.
>
> Webrev: http://cr.openjdk.java.net/~jlahoda/8195789/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8195789
>
> Sorry for any trouble,
> ???? Jan