Bug when lowering a method ref (concise method)

forax at univ-mlv.fr forax at univ-mlv.fr
Mon Oct 1 21:59:49 UTC 2018

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Vicente Romero" <vicente.romero at oracle.com>, "amber-dev"
> <amber-dev at openjdk.java.net>
> Envoyé: Lundi 1 Octobre 2018 20:06:31
> Objet: Re: Bug when lowering a method ref (concise method)

> On Sep 30, 2018, at 6:11 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> public void run() -> null;

> Random thoughts on null for void, and returning a "safe default"…

> When we get to reified generics, there will be this:

> interface HasM<any T> { default T m() -> T.default; }

> There's also the usual question of "why isn't void a type"?

> And if void were a type, and still more a nullable type,
> then the "-> null" would be valid.

> But if void were a primitive type, and Void were its wrapper.
> In that case passing (Void)null up to void deserves NPE,
> just as passing (Integer)null up to int gets NPE. Unless
> declaring void as nullable allowed it to avoid that fate.

as we said in another discussion, void can be retconed (in the additive way) to be an empty value type, 
in that case the only possible value of void is void.default. 

> — John


More information about the amber-dev mailing list