javac 8/9 inconsistency

[Maurizio Cimadamore]

On 17/02/15 14:39, Maurizio Cimadamore wrote:
> This is a bug - if the argument has been considered not pertinent to 
> applicability - it should simply be left alone here (and then 
> considered back after target-type is thrown into the mix). I will file 
> a bug. Please keep such issues coming - it's probably useful for both 
> parties to look at them. 
Expanding a bit on this - I believe the spec is saying that the 
following should result in error:

import java.util.function.*;

class Sup { }

class Sub1 extends Sup { }
class Sub2 extends Sup { }

class Test<K> {

     public static void foo(Test<Sub1> test) {
         Test<? extends Sup> e1 = create(Test::factory, test); //error
         Test<? extends Sup> e2 = create(s -> new Test<Sub2>(), test); 
//error
     }

     private static <A, T> T create(Function<String, T> callback, T 
defaultVal) {
         return null;
     }

     static Test<Sub2> factory(String s) {
         return null;
     }
}

While javac correctly compiles as it's getting two lower bounds and then 
doing eager instantiation with the lub of such bound parameterizations.

Dan, do you agree? Honestly, it seems a bit gratuitous to reject such 
code - is there any fundamental reason as to why we cannot go ahead and 
type-check those arguments (even if they are not pertinent to 
applicability) that are not stuck on any input type-variable? Could this 
warrant some spec enhancement?

Maurizio