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

[Maurizio Cimadamore]

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!
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>