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

[Robert Field]

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.

Thanks,
Robert



On January 9, 2017 7:30:04 AM Maurizio Cimadamore 
<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/
>>>
>>> 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!
>>>
>>
>