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

Robert Field robert.field at oracle.com
Mon Jan 9 21:44:03 UTC 2017


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 <https://bugs.openjdk.java.net/browse/JDK-8172453>

-Robert

> On Jan 9, 2017, at 9:35 AM, Maurizio Cimadamore <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> 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!
>>>>> 
>>>> 
>>> 
>> 
>> 
> 



More information about the kulla-dev mailing list