RFR 8171981: JShell: Fails compilation: new Object().getClass().getSuperclass()

[Robert Field]

Oops, I just changed the one location you highlighted before. I didn't 
notice there were more.

Thanks for checking.  Will fix.

Robert






On January 10, 2017 3:22:45 AM Maurizio Cimadamore 
<maurizio.cimadamore at oracle.com> wrote:

> Seems like list.stream().map() is still used instead of list.map() in at
> least one place?
>
> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/9ed8e9a27b00#l10.187
>
> Maurizio
>
>
> On 09/01/17 21:44, Robert Field wrote:
>> Thanks.
>>
>> Will repair the list operation and push.
>>
>> I’ve create this issue for the refinement in handling intersection types:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8172453
>>
>> -Robert
>>
>>> On Jan 9, 2017, at 9:35 AM, Maurizio Cimadamore
>>> <maurizio.cimadamore at oracle.com
>>> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>>
>>>
>>>
>>> On 09/01/17 16:29, Robert Field wrote:
>>>> This inferencing is for the automatically generated scratch
>>>> variables that get generated for every expression.  A new user won't
>>>> even know they exist. So we don't want messages about things being
>>>> created behind the scenes (they are actually created behind the API
>>>> layer, where there is no UI).  In cases where it picks the wrong
>>>> type, the user can explicitly create a variable. That said, picking
>>>> a more specific type is more likely to be unsurprising when they use
>>>> the variable than if Object is picked. I played with picking any
>>>> common class if there are any and any interface if not.  Wasn't sure
>>>> the ideal location for that. Also, would need predictable ordering
>>>> for testing purposes.
>>> I know that we are talking about synthetic variables where jshell
>>> stores expression values - but you can refer to these variables using
>>> $ID - so people referring to these variables will be able to see some
>>> edges and it would be nice to warn them that jshell picked something
>>> for them.
>>>
>>> Talking heuristics, I believe that, given an intersection like T1 &
>>> T2 ... Tn an acceptable normalization strategy is:
>>>
>>> * compute the minimal set of supertypes S = disjoint(T1, T2 ... Tn),
>>> where the set of disjoint types contains all types in T1 ... Tn for
>>> which there's no subtype in T1 ... Tn
>>> * if S contains just one type, use that type as the inferred type
>>> * if S contains multiple types, pick the first one
>>>
>>> I believe this heuristics should give good results and should also be
>>> deterministic. Of course this normalization should be done both at
>>> the top level (e.g. when the result of inference is an intersection
>>> type) and at the nested level (when the result of inference is some
>>> type like Foo<? extends A & B>).
>>>
>>> Maurizio
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>>
>>>>
>>>> On January 9, 2017 7:30:04 AM Maurizio Cimadamore
>>>> <maurizio.cimadamore at oracle.com
>>>> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>>>
>>>>> Now that I think about it - in case where an intersection type is
>>>>> found,
>>>>> I think it would be great if jshell reported some kind of message like:
>>>>>
>>>>> found possible types: A, B
>>>>> defaulting to: A
>>>>> (please use an explicit type if the default choice is invalid)
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Maurizio
>>>>>
>>>>> On 09/01/17 11:10, Maurizio Cimadamore wrote:
>>>>>> Looks good. As we discussed privately, on lines 177 and 186, I think
>>>>>> we want to use List.map instead of List.stream().map(). Note that
>>>>>> List.map returns the original instance if map() doesn't change any of
>>>>>> the elements, which then enables a simpler == comparison. This seems
>>>>>> like a mistake in the JEP-286 code.
>>>>>>
>>>>>> Maurizio
>>>>>>
>>>>>>
>>>>>> On 08/01/17 20:22, Robert Field wrote:
>>>>>>> Please review....
>>>>>>>
>>>>>>> Bug:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171981
>>>>>>>
>>>>>>> Webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~rfield/8171981v0.webrev/
>>>>>>> <http://cr.openjdk.java.net/%7Erfield/8171981v0.webrev/>
>>>>>>>
>>>>>>> Notes:
>>>>>>>
>>>>>>> There were two different mechanisms for determining type: one used in
>>>>>>> evaluation and one available in the API.  Both had
>>>>>>> limitations/problems.  Both used TypePrinter which was the cause of
>>>>>>> the reported problem.
>>>>>>>
>>>>>>> I've unified handling, discarded both old approaches, using a visitor
>>>>>>> instead.
>>>>>>> I've separated var type name determination (used in code generation
>>>>>>> -- no type variables) from other type printing (used in docs).
>>>>>>> Adopted Maurizo's handling of captured types.
>>>>>>> Added debugging support for wraps.
>>>>>>> Added lots more tests, including tests inspired by JEP-286. All new
>>>>>>> tests, test both entry-points.
>>>>>>> Thanks Maurizio and Dan!
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>