• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Can a Future<?> be returned from a Consumer?

 
Ranch Hand
Posts: 241
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm confused
 
T Vergilio
Ranch Hand
Posts: 241
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's the same with Callable:
 
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Part of this is the difference between using the lambda syntax short- and long-form. The compiler is giving you the benefit of the doubt, assuming even though submit() returns a Future object, you don't want the expression to return it. Compare it with the long form:

When you explicitly tell the compiler what you want returned, it does a better job of enforcing the rules than the short form.

For your second example, it's because the compiler can't accept a line that is just a declaration. For example, this line will not compile:

Why? Because it's an incomplete statement. Therefore, in the short form the compiler assumes you want to return it since that is the only way it can be used.

For method calls, such as submit() it can be interpreted both as a statement and a return value, so the compiler uses whichever one matches the functional interface.
 
T Vergilio
Ranch Hand
Posts: 241
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply, Scott. I honestly believed that, in the short lambda form, the compiler would ALWAYS interpret what's right of the -> as the return value. I didn't know it was possible for it to sometimes interpret it as a statement.
 
T Vergilio
Ranch Hand
Posts: 241
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I just found it in the documentation:

If the body of a lambda is a statement expression (that is, an expression that would be allowed to stand alone as a statement), it is compatible with a void-producing function type; any result is simply discarded. So, for example, both of the following are legal:



Generally speaking, a lambda of the form () -> expr, where expr is a statement expression, is interpreted as either () -> { return expr; } or () -> { expr; }, depending on the target type.


source: http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.27

Thank you so much for the clarification, Scott!
 
Scott Selikoff
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The key here is that if "() -> { expr; }" does not compile (as in the case of "Consumer badConsumer = c -> result;"), then the compiler automatically assumes it must be "() -> { return expr; }", which also does not compile for this example, but for a different reason.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic