RFR 8203488: Remove error generation from TransTypes

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoyé: Lundi 21 Mai 2018 22:17:24
> Objet: Re: RFR 8203488: Remove error generation from TransTypes

> On 21/05/18 21:09, Maurizio Cimadamore wrote:
>> That's an option too, either error or warning.
> One possibility here would be to force users to use --release when using
> either MethodHandle or VarHandle. E.g. you can either specify no
> -source/-target combo or, if you need to cross-compile, you do so with
> --release. That way you will be prevented from using API points which
> are unsupported at a given source/target level. But maybe that's too harsh.

forcing --release, or deprecating -source/-target if you prefer is something that we should do independently of a particular feature, it will make Java safer.  

> 
> Also, thinking more on VarHandle, I believe what we have in VarHandle is
> different: the behavior that we pushed as part of JDK 9 was a
> generalization of the former behavior; so if you compile VarHandles with
> target 8, I don't think anything bad actually happens - if you use a JDK
> 9/10/11 compiler, the compiler will type-check the polysig correctly.
> Then, in terms of code generation, nothing has changed. In other words,
> javac has no flag to enable varhandles, specifically. But it does have a
> flag to enable polysig. So we do have a problem when compiling polysig
> with no polysig target selected, but we don't have a problem when
> compiling VH with an older target selected.

The semantics of a polysig change between 7 and 9, in 9 you can return a boolean by example, but given that the semantics of 9 is a super-set of the semantics of 7.
So if you use the compiler of a jdk7 or jdk8 with the VarHandle API you will have a surprise but it's just another reason to deprecate -source/-target. 

> 
> Maurizio

Rémi