Bugs in JShellState#drop

[andrei.eremeev]

On 05/08/2015 09:53 PM, Robert Field wrote:
>
> On 05/08/15 07:07, andrei.eremeev wrote:
>> Hi REPL team,
>>
>> Bugs (see DropTest()):
>> 1. 'x' has outcome 'Added'. In this case 'x' should have id which is 
>> greater than id of 'y'. But 'x' does not.
>> -> int x
>> |  Added variable x of type int
>>
>> -> /- x
>>
>> -> int y
>> |  Added variable y of type int
>>
>> -> int x
>> |  Added variable x of type int
>>
>> -> /l
>>
>>    9 : int x;
>>   10 : int y;
>
> When the key is dropped, it still exists as a key.  So, I think the 
> current behavior is correct.  But, I'm not sure.  I could see that in 
> some cases that would be surprising.
Current behavior violates current specification of Key#id().
"Snippets which replace or redefine existing snippets take on the same 
id as the replaced or redefined snippet."
In this case, 'x' is created again (Outcome.Added), but, according to 
specification, 'x' can have the same id if outcome is either Modified or 
Replaced.
>
>>
>> 2. Commands /var, /classes, /methods and JShellState#vars(), 
>> JShellState#methods(), JShellState#classes return dropped keys.
>
> Yep. Added to TODO (local) will fix soon.
>
>>
>> 3. Class with a broken (dropped) reference can be initiated and used.
>> -> int x
>> |  Added variable x of type int
>>
>> -> class A { int f() { return x; } }
>> |  Added class A
>>
>> -> /- x
>> |  Caused failure of dependent A --
>> |      cannot find symbol
>> |        symbol:   variable x
>> |      class A { int f() { return x; } }
>> |                                 ^
>>
>> -> new A().f()
>> |  Expression value is: 0
>> |    assigned to temporary variable $1 of type int
>
> This is a case of needing class corralling.
>
>>
>>
>> BTW, are we going to implement forward references for classes?
>> Defining classes which refer to classes, methods or variables which 
>> have not defined.
>
> Yes, that needs class corralling too.
>
>> E.g.
>>   class A extends B {}
>>   class B {}
>
> We will not support forward reference of methods or classes where the 
> signature is undefined.  For a class, the signature includes the name, 
> the extends, implements, generic signature, types/names of fields, 
> name/parameter-type of methods/constructors.  What can have forward 
> references is method bodies and field initializers. Note that we will 
> attempt to corral classes whose signatures break after definition, but 
> I'm not sure the level with which that can be achieved.  We the JEP 
> for more detail on this.
>
This is sad. I need to modify JCK-plugin to support this behavior.
>
> -Robert
>
>>
>> Andrei Eremeev
>
Andrei Eremeev