Java 8 compiler bug?

[forax at univ-mlv.fr]

> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Oliver Gierke" <ogierke at pivotal.io>
> Cc: compiler-dev at openjdk.java.net
> Envoyé: Jeudi 17 Novembre 2016 19:16:02
> Objet: Re: Java 8 compiler bug?

> On 17/11/16 17:19, Remi Forax wrote:

>> I think the main issue is that when the inference fails, the compiler instead of
>> reporting an error continue using Object instead.

> Where is inference failing in JDK 8? I think the 'problem' here is that the code
> below:

> import java.util.*;

> class Test {

> void test() {
> Expression<Object> objectExpression = null;
> Expression<Collection<Object>> collectionOfObjectExpression = null;
> m(objectExpression, collectionOfObjectExpression);
> }

> interface Expression<T> {}

> <E, C extends Collection<E>> void m(E elem, Expression<C> collection) { }
> }

> succeeds with -source N where N >= 8 and fails otherwise - which is a
> consequence of Java 8 inference being more powerful. In the original example,
> the fact that there was an overload, combined with the fact that inference used
> to fail for one of the overloaded methods meant that the program passed in
> source N < 8 but fails with ambiguity after 8 because now overload resolution
> can consider both methods as being applicable.

> Maurizio
Sorry, my mail was not specific enough, i agree with you, 
with N < 8, the inference fails -> instead of reporting an error, only one method becomes applicable -> it seems to work. 

I know it's too late but when the inference fails, instead of making a method non-acceptable, and silently choose the other overload, the compiler should have reported an error. 

IDEs/compilers should have a warning for that, because each time we make the inference smarter, diamond in 7, inference inside method call in 8 (auto-wildcard/declaration site variance in 10?), we introduce source incompatibilities. 

regards, 
Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161117/ca1b5d92/attachment.html>