javac 8/9 inconsistency

[Anna Kozlova]

Hi,
 
Ok, the following code compiles with 1.8u40 but fails with java 9
 
abstract class FooBoo {
    {
        map((Class<? extends Annotation> ann) -> getAnnotation(ann)); //error
        map(this::getAnnotation);                                     //error
    }

    abstract <A> A getAnnotation(Class<A> annotationClass);
    abstract <R> void map(Function<Class<? extends Annotation>, ? extends R> mapper);
}
 
Anna
 
From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] 
Sent: Tuesday, February 17, 2015 3:39 PM
To: Anna Kozlova; compiler-dev at openjdk.java.net
Subject: Re: javac 8/9 inconsistency
 
 
On 17/02/15 12:59, Anna Kozlova wrote:
Hi Maurizio,
 
Test::factory is not exact, correct? Then when return type constraint is added, T has only one lower bound, so https://bugs.openjdk.java.net/browse/JDK-8055963  doesn’t apply as is. What can it be then?
This is an issue in javac - while javac does not consider Test::factory pertinent to applicability in the applicability inference step, it goes ahead and type-checks it ahead of the return type during invocation method inference. This means that javac sees two bounds, Test<P> and Test<String> and that's why 8055963 <https://bugs.openjdk.java.net/browse/JDK-8055963>  applies again here. In other words, while performing 18.5.2, javac is adding constraints from an argument that is not pertinent to applicability in the very first section of 18.5.2 which says:

"Let B2 be the bound set produced by reduction in order to demonstrate that m is applicable in §18.5.1 <https://docs.oracle.com/javase/specs/jls/se8/html/jls-18.html#jls-18.5.1> . (While it was necessary in §18.5.1 <https://docs.oracle.com/javase/specs/jls/se8/html/jls-18.html#jls-18.5.1>  to demonstrate that the inference variables in B2 could be resolved, in order to establish applicability, the instantiations produced by this resolution step are not considered part of B2.) "

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. 

Maurizio


 
BTW I found more inconsistencies between 8/9 in our testdata, should I file them?
 
Thanks, 
Anna 
 
From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] 
Sent: Tuesday, February 17, 2015 12:05 PM
To: Anna Kozlova; compiler-dev at openjdk.java.net
Subject: Re: javac 8/9 inconsistency
 
Hi Anna,
I remember now - this is indeed:

https://bugs.openjdk.java.net/browse/JDK-8055963

That problem was ultimately caused by an ambiguity in the spec - which is why the fix was targeted for 9 and hasn't been backported. I would say it's normal for these kind of spec-related fixes to target the next release and not being backported.

Maurizio
On 16/02/15 19:27, Maurizio Cimadamore wrote:
Hi Anna,
it looks like the test should compile - I'm not sure as to which bugs are involved, I'll take a closer look and let you know.

Thanks
Maurizio
On 16/02/15 17:45, Anna Kozlova wrote:
Hi,
 
The following code compiles with java 9 (b. 49) but doesn’t with 8 (1.8u40 b.23)
 
class Test<K> {
 
    public static void foo(Test<String> test) {
        Test<String> e = create(Test::factory, test);
    }
 
    private static <T> T create(Supplier<T> callback, T defaultVal) {
        return null;
    }
 
    static <P> Test<P> factory() {
        return null;
    }
}
 
What is correct? 
 
BTW I’ve found https://bugs.openjdk.java.net/browse/JDK-8055963 which explains to me the situation with  Test<String> e = create(() -> factory(), test); but the fix version is 9. Would it be backported to java 8?
 
Thank you,
Anna
 




!DSPAM:35,54e352b8157502614018010! 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150218/61d73811/attachment-0001.html>