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