title: Lambda expression and method overloading doubts
body: <p>OK, so method overloading is-a-bad-thing™. Now that this has been settled, let's assume I actually <em>want</em> to overload a method like this:</p>
  <pre><code>static void run(Consumer&lt;Integer&gt; consumer) {
      System.out.println(&quot;consumer&quot;);
  }
  
  static void run(Function&lt;Integer, Integer&gt; function) {
      System.out.println(&quot;function&quot;);
  }
  </code></pre>
  <p>In Java 7, I could call them easily with non-ambiguous anonymous classes as arguments:</p>
  <pre><code>run(new Consumer&lt;Integer&gt;() {
      public void accept(Integer integer) {}
  });
  
  run(new Function&lt;Integer, Integer&gt;() {
      public Integer apply(Integer o) { return 1; }
  });
  </code></pre>
  <p>Now in Java 8, I'd like to call those methods with lambda expressions of course, and I can!</p>
  <pre><code>// Consumer
  run((Integer i) -&gt; {});
  
  // Function
  run((Integer i) -&gt; 1);
  </code></pre>
  <p>Since the compiler <em>should</em> be able to infer <code>Integer</code>, why don't I leave <code>Integer</code> away, then?</p>
  <pre><code>// Consumer
  run(i -&gt; {});
  
  // Function
  run(i -&gt; 1);
  </code></pre>
  <p>But this doesn't compile. The compiler (javac, jdk1.8.0_05) doesn't like that:</p>
  <pre class="lang-none prettyprint-override"><code>Test.java:63: error: reference to run is ambiguous
          run(i -&gt; {});
          ^
    both method run(Consumer&lt;Integer&gt;) in Test and 
         method run(Function&lt;Integer,Integer&gt;) in Test match
  </code></pre>
  <p>To me, intuitively, this doesn't make sense. There is absolutely no ambiguity between a lambda expression that yields a return value (&quot;value-compatible&quot;) and a lambda expression that yields <code>void</code> (&quot;void-compatible&quot;), as set out in the <a href="http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.27" rel="noreferrer">JLS §15.27</a>.</p>
  <p>But of course, the JLS is deep and complex and we inherit 20 years of backwards compatibility history, and there are new things like:</p>
  <blockquote>
  <p>Certain argument expressions that contain <em><strong>implicitly typed lambda expressions</strong></em> (<a href="http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.27.1" rel="noreferrer">§15.27.1</a>) or inexact method references (<a href="http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.13.1" rel="noreferrer">§15.13.1</a>) are ignored by the applicability tests, because their meaning cannot be determined until a target type is selected.</p>
  <p><em><a href="http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2" rel="noreferrer">from JLS §15.12.2</a></em></p>
  </blockquote>
  <p>The above limitation is probably related to the fact that <a href="http://openjdk.java.net/jeps/101" rel="noreferrer">JEP 101</a> wasn't implemented all the way, as can be seen <a href="http://blog.jooq.org/2013/11/25/a-lesser-known-java-8-feature-generalized-target-type-inference/" rel="noreferrer">here</a> and <a href="http://mail.openjdk.java.net/pipermail/lambda-dev/2013-July/010531.html" rel="noreferrer">here</a>.</p>
  <h3>Question:</h3>
  <p>Who can tell me exactly what parts of the JLS specifies this compile-time ambiguity (or is it a compiler bug)?</p>
  <p>Bonus: Why were things decided this way?</p>
  <h3>Update:</h3>
  <p>With jdk1.8.0_40, the above compiles and works fine</p>