Javac Bug?

[David Holmes]

On 16/11/2013 1:36 AM, Zhong Yu wrote:
> On Fri, Nov 15, 2013 at 9:15 AM, Vicente-Arturo Romero-Zaldivar
> <vicente.romero at oracle.com> wrote:
>> On 15/11/13 14:51, Zhong Yu wrote:
>>>
>>> The return type seems also play a role here, see
>>> http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/F.html
>>>
>>> ""
>>> A lambda expression (15.27) is potentially compatible with a
>>> functional interface type (9.8) if all of the following are true:
>>>
>>> The arity of the targeted type's function type is the same as the
>>> arity of the lambda expression.
>>> If the targeted type's function type has a void return, then the
>>> lambda body is either a statement expression (14.8) or a
>>> void-compatible block (15.27.2).
>>> If the targeted type's function type has a (non-void) return type,
>>> then the lambda body is either an expression or a value-compatible
>>> block (15.27.2).
>>> ""
>>>
>>> Therefore, method
>>>       public void forEach(Consumer<? super T> consumer)
>>> is not potentially applicable to invocation
>>>       forEach(v -> { return biPredicate.test(1, v); } );
>>> because the function type of Consumer has a void return, yet the
>>> lambda body is a value-compatible block.
>>
>>
>> The compiler analyze lambda expressions in several phases:
>>
>> first analysis is by arity, if there are two possible applicable methods by
>> arity the compiler issues an error. If a method pass to the next phase, then
>> the rest of the information is taken into account.
>
> But the spec text I quoted mentions both arity and return type in the
> phase of identifying potentially applicable methods (15.12.2.1)

I have to agree - the compiler needs to consider all of the conditions 
combined as is written in the spec. It should not declare ambiguity 
based on arity alone when the return type would have reduced things to a 
single applicable method.

David
-----

>
>>
>>
>>>
>>>
>>> On Fri, Nov 15, 2013 at 7:57 AM, Vicente-Arturo Romero-Zaldivar
>>> <vicente.romero at oracle.com> wrote:
>>>>
>>>> On 13/11/13 19:04, Zhong Yu wrote:
>>>>>
>>>>> This program does not compile in javac8 build 115. I think it should
>>>>> compile (but who knows really:)
>>>>>
>>>>> public class Bug<T> {
>>>>>        public void forEach(Consumer<? super T> consumer) {
>>>>>            // ...
>>>>>        }
>>>>>        public void forEach(Predicate<? super T> predicate) {
>>>>>            // ...
>>>>>        }
>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
>>>>> biConsumer) {
>>>>>            forEach((v) -> { biConsumer.accept(1, v); });
>>>>>        }
>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
>>>>> biPredicate) {
>>>>>            forEach(v -> { return biPredicate.test(1, v); } );
>>>>>        }
>>>>> }
>>>>
>>>> Hi Zhong Yu,
>>>>
>>>> No the compiler is right functional descriptors of Consumer and Predicate
>>>> have the same arity, so the compiler determines that there is an
>>>> ambiguity
>>>> error.
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>>>
>>>>>
>>>>> On Wed, Nov 13, 2013 at 12:59 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>>>>>
>>>>>> Here's my understanding how the process works.
>>>>>>
>>>>>> When javac sees
>>>>>>
>>>>>>        forEach( v->... )
>>>>>>
>>>>>> two pieces of information of the implicit lambda are used to prune
>>>>>> overloading methods:
>>>>>> 1. the arity. therefore BiConsumer/BiPredicate are excluded
>>>>>> 2. whether the lambda body returns void or a real type.
>>>>>>
>>>>>> If the lambda body is a block, it's quite clear whether it's void or
>>>>>> not. It seems to me that this would work:
>>>>>>
>>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>> biConsumer) {
>>>>>>            forEach((v) -> { biConsumer.accept(1, v); });
>>>>>>        }
>>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>> biPredicate) {
>>>>>>            forEach(v -> { return biPredicate.test(1, v); } );
>>>>>>        }
>>>>>>
>>>>>> ( ... But it fails in javac build 115. javac bug?)
>>>>>>
>>>>>> If the lambda body is a "statement expression", like in your original
>>>>>> example
>>>>>>
>>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>> biConsumer) {
>>>>>>            forEach((v) -> biConsumer.accept(1, v) );
>>>>>>        }
>>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>> biPredicate) {
>>>>>>            forEach(v -> biPredicate.test(1, v) );
>>>>>>        }
>>>>>>
>>>>>> It's unclear what the return type is, so javac cannot use the return
>>>>>> type to prune. Note that even though `biConsumer.accept(1, v)`
>>>>>> obviously returns void, javac does not know that, because the type of
>>>>>> `v` is not known yet. And even though `biPredicate.test(1, v)`
>>>>>> obviously returns boolean, it is compatible to a function type that
>>>>>> expects void return.
>>>>>>
>>>>>> Now, for each invocation, we have two potentially applicable methods.
>>>>>>
>>>>>> The next step tries to prune methods by checking argument types
>>>>>> against method parameter types. Unfortunately, implicit lambda
>>>>>> expressions are too vague, so they are simply ignored in this step.
>>>>>>
>>>>>> Therefore both methods are considered applicable methods. The most
>>>>>> specific method is sought after. However neither method is more
>>>>>> specific than the other, therefore we see the error message of
>>>>>> ambiguity.
>>>>>>
>>>>>> If you use explicit lambda expressions, javac is able to do more
>>>>>> pruning, so this works:
>>>>>>
>>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>> biConsumer) {
>>>>>>            forEach((T v) -> biConsumer.accept(1, v) );
>>>>>>        }
>>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>> biPredicate) {
>>>>>>            forEach( (T v) -> biPredicate.test(1, v) );
>>>>>>        }
>>>>>>
>>>>>> So if you have overloading methods like this
>>>>>>
>>>>>>        public void forEach(Consumer<? super T> consumer) {
>>>>>>            // ...
>>>>>>        }
>>>>>>        public void forEach(Predicate<? super T> predicate) {
>>>>>>            // ...
>>>>>>        }
>>>>>>
>>>>>> client code often cannot use implicit lambda expressions as arguments;
>>>>>> and experts have advised against this kind of overloading scheme (two
>>>>>> functional interfaces with the same arity)
>>>>>>
>>>>>>
>>>>>> Zhong Yu
>>>>>>
>>>>>> On Wed, Nov 13, 2013 at 8:01 AM, Dávid Karnok <akarnokd at gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm rewriting a library and run into a strange ambiguity error
>>>>>>> reported
>>>>>>> by
>>>>>>> javac in JDK 8 b115, Windows 7 x86:
>>>>>>>
>>>>>>> public class Bug<T> {
>>>>>>>        public void forEach(Consumer<? super T> consumer) {
>>>>>>>            // ...
>>>>>>>        }
>>>>>>>        public void forEach(BiConsumer<? super Integer, ? super T>
>>>>>>> consumer) {
>>>>>>>            forEach((v) -> consumer.accept(1, v));
>>>>>>>        }
>>>>>>>        public void forEach(Predicate<? super T> stoppableConsumer) {
>>>>>>>            // ...
>>>>>>>        }
>>>>>>>        public void forEach(BiPredicate<? super Integer, ? super T>
>>>>>>> stoppableConsumer) {
>>>>>>>            forEach(v -> stoppableConsumer.test(1, v));
>>>>>>>        }
>>>>>>> }
>>>>>>>
>>>>>>> error: reference to forEach is ambiguous
>>>>>>>            forEach((v) -> consumer.accept(1, v));
>>>>>>>      both method forEach(Consumer<? super T>) in Bug and method
>>>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>>>      where T is a type-variable:
>>>>>>>        T extends Object declared in class Bug
>>>>>>>
>>>>>>> error: reference to forEach is ambiguous
>>>>>>>            forEach(v -> stoppableConsumer.test(1, v));
>>>>>>>      both method forEach(Consumer<? super T>) in Bug and method
>>>>>>> forEach(Predicate<? super T>) in Bug match
>>>>>>>      where T is a type-variable:
>>>>>>>        T extends Object declared in class Bug
>>>>>>>
>>>>>>> I'm using NetBeans 7.4 (Build 201310111528) which doesn't report this
>>>>>>> ambiguity in the editor, and the "highlight occurrences" correctly
>>>>>>> selects
>>>>>>> the 3rd method when I select the forEach in the 4th method. However,
>>>>>>> the
>>>>>>> clean and build fails with the errors above. I have to add explicit
>>>>>>> cast
>>>>>>> to
>>>>>>> the problematic places.
>>>>>>>
>>>>>>> So I'm a bit confused right now. Is it a bug with NetBeans' editor,
>>>>>>> with
>>>>>>> javac or simply the artifact of how overload resolution works?
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> David Karnok
>>>>>>>
>>
>