Interesting inference case

Sam Pullara spullara at gmail.com
Mon Sep 2 12:15:35 PDT 2013


The funny thing is, call(int i) is not a valid match for either Runnable or Callable. You're thinking "int call()" which would match Callable.

Sam

On Sep 2, 2013, at 11:13 AM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> Suppose you comment out call() instead, then does it also not complain?
> 
> Without call(i), this resolves to ES.submit(Runnable) ?
> 
> But with call(i) it could also resolve to ES.submit(Callable) ?
> 
> Intuitively, I would expect it to prefer a Callable to a Runnable given the match in method name...
> 
> 
> 
> 
> On Mon, Sep 2, 2013 at 10:19 AM, Sam Pullara <spullara at gmail.com> wrote:
> I was trying to pass Semaphore::release to ExecutorService.submit and ran into a puzzling compile error. Here is a reproduction case:
> 
> public class InferTest {
>     void call() {}
> //    void call(int i) {}
> 
>     @Test
>     public void test() {
>         ExecutorService es = Executors.newCachedThreadPool();
>         es.submit(this::call);
>     }
> }
> 
> With the comment, this compiles fine. If you uncomment the second call() method it fails with:
> 
> java: reference to submit is ambiguous
>   both method <T>submit(java.util.concurrent.Callable<T>) in java.util.concurrent.ExecutorService and method submit(java.lang.Runnable) in java.util.concurrent.ExecutorService match
> java: incompatible types: cannot infer type-variable(s) T
>     (argument mismatch; bad return type in method reference
>       void cannot be converted to T)
> 
> I'm not sure why the overload on call() would cause the ambiguity.
> 
> Sam
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130902/ea2152d7/attachment.html 


More information about the lambda-libs-spec-experts mailing list