title: How Java 8 is able to infer lambdas argument type
body: <p>I'm currently playing with Vert.x in Java and noticed that the examples in the documentation use lambdas extensively as callback parameters. For example:</p>
  
  <pre><code>NetServer server = vertx.createNetServer();
  server.listen(1234, "localhost", res -&gt; {
    if (res.succeeded()) {
      System.out.println("Server is now listening!");
    } else {
      System.out.println("Failed to bind!");
    }
  });
  </code></pre>
  
  <p>Looking into the documentation of <code>listen</code> functions shows the following:</p>
  
  <pre><code>NetServer listen(int port,
                   String host,
                   Handler&lt;AsyncResult&lt;NetServer&gt;&gt; listenHandler)
  </code></pre>
  
  <p>My question is how does the JVM have a chance to deduce generic data types such as <code>Handler&lt;AsyncResult&lt;NetServer&gt;&gt;</code> out of such non-informative objects such as <code>res</code>? This seems fine for languages like JavaScript that do duck-typing, but for languages like Java that do strong typing, it's not as obvious for me. If we use an anonymous class instead of a lambda, all data types would be on the plate.</p>
  
  <p>--EDIT--
  As already explained by @Zircon, probably better example from Vert.x documentation would be following declaration:</p>
  
  <pre><code>&lt;T&gt; void executeBlocking(Handler&lt;Future&lt;T&gt;&gt; blockingCodeHandler,
                           Handler&lt;AsyncResult&lt;T&gt;&gt; resultHandler)
  </code></pre>
  
  <p>with example of usage from docs:</p>
  
  <pre><code>vertx.executeBlocking(future -&gt; {
    // Call some blocking API that takes a significant amount of time to return
    String result = someAPI.blockingMethod("hello");
    future.complete(result);
  }, res -&gt; {
    System.out.println("The result is: " + res.result());
  });
  </code></pre>
  
  <p>Where type of  is not available, thus only methods available on <code>Future</code> and <code>AsyncResults</code> can be used.</p>