RFR 8144903: JShell: determine incorrectly the type of the expression which is array type of captured type

[Maurizio Cimadamore]

On 10/12/15 03:07, Robert Field wrote:
> Important note: the result of this call is used as the type in a 
> generated variable declaration.  So, building a representation of 
> compound type does not work.
I'm totally aware of this; I didn't suggest to have a representation for 
intersection types, but to handle them better instead of always flat 
them out as Object. For example, you can flatter the intersection type 
by picking the first non-Object bound.

But ultimately, in response to Shinya, given that the behavior of jshell 
is already an approximation, I think the fact that the particular 
regression test used to work is more an accident than a feature. We can 
write several other tests in which using the bound doesn't work. And, 
worse, we can write examples in which the 'Right' behavior (from a user 
perspective) can be one or the other depending on their needs. So, this 
seems to me like a battle not worth to fight: if you are dissatisfied 
with the type jshell comes up with in these corner cases, just add a 
declaration manually.

To model fully what's going on in the type-system you would have to add 
a notion of a 'generic snippet' i.e. a snippet with its own 
type-variables, which you can probably translate as a generic method. 
That snippet would then be able to retain precise type info as 
type-variable bounds (so you can retain all the bounds of the 
intersection and still have a legitimate declared type to use - a 
tyoe-variable). But it feels like a lot of work and I'm not sure of the 
payout.

Maurizio