Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces

Stephen Colebourne scolebourne at
Wed Nov 14 10:48:24 UTC 2012

On 13 November 2012 19:05, Mike Duigou <mike.duigou at> wrote:
> - becomes Function.apply
> - Factory.make becomes Supplier.get
> - Specializations of Supplier for int, long, double
> - Reorder type variables to put result last
> - Fixes many javadoc and stylistic comments.
> What didn't change:
> - Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform?
> - Combiner will be part of the full API but it's only present in this patch as a comment.
> - No default methods.
> Unless there are sustained and persuasive objections this will be committed to the jdk8/tl workspace at the end of this week or early next week. (Hence "core-libs-dev" being the primary review list)

The interface definitions say nothing about null. I'd like to see
something in there, even if it is to say "null handling behaviour is
defined by the implementation".

I still find Block confusing. A code block is a block of code
delimited by { }. It takes no arguments and returns nothing.
"Receiver" was suggested as the interface name to match Supplier, and
that made sense to me (and is better than Sink, which is very IO).

I also find Predicate.test to be a non-optimal method name. "test" is
a method name I only see in test cases. Commons collections used
"evaluate". "is" would be a possible short option. I'm sure the EG can
think of others.


More information about the core-libs-dev mailing list