RFR 8203488: Remove error generation from TransTypes (original) (raw)

forax at univ-mlv.fr forax at univ-mlv.fr
Mon May 21 21:48:27 UTC 2018

----- 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

More information about the compiler-dev mailing list