hg: valhalla/valhalla: 8222784: [lworld] Remove stale compiler options: -XDallowGenericsOverValues and -XDdisallowValueConstructors

[forax at univ-mlv.fr]

> De: "Srikanth" <srikanth.adayapalam at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Samedi 20 Avril 2019 14:54:26
> Objet: Re: hg: valhalla/valhalla: 8222784: [lworld] Remove stale compiler
> options: -XDallowGenericsOverValues and -XDdisallowValueConstructors

> On 20/04/19 3:53 PM, Remi Forax wrote:

>> - .class notation is not supported
>>   public class DotClass {
>>     final int value;

>>     public DotClass(int value) {
>>       this.value = value;
>>     }

>>     private static <T> T foo(Class<T> type) {
>>       return null;
>>     }

>>     public static void main(String[] args) {
>>       foo(DotClass?.class);
>>     }
>>   }

> For .class notation, see [ https://bugs.openjdk.java.net/browse/JDK-8221323 |
> https://bugs.openjdk.java.net/browse/JDK-8221323 ]
> where there is an express request not to support these:

> " Moving forward it looks like we want to say "Foo.class" for class constant
> (ldc Class) in source code. If you want the boxed/value class mirror, you need
> to use Class.asBoxType()/asValueType() methods. "

> Any difference of opinion ??
yes, 
there are two side of the support of Foo?.class, one is how to get the reference to the inline class at runtime, the methods asXXXType covers this, but there is also a typing part, as in the example, the resulting type should be a Class<Foo?> and not a Class<Foo>. 

So i agree that we do not need to support the special syntax Foo?.class but in that case the methods asXXXType have to be recognized by the compiler the same way Object.getClass() has a special typing rule in the compiler. 

regards, 
Rémi 

> Srikanth