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

Joe Bowbeer joe.bowbeer at gmail.com
Tue Nov 13 15:26:33 PST 2012

Hey Brian,

Judging from Mike's email, I gather that these "apply" method names do need to be unique?

Just hoping you can clarify...

On Tue, Nov 13, 2012 at 12:14 PM, Brian Goetz <brian.goetz at oracle.com>wrote:

I've updated the webrev for the first set of lambda functional interfaces

(JSR-335) with the feedback from the first review round. The updated webrev is:

http://cr.openjdk.java.net/**mduigou/8001634/3/webrev/<http://cr.openjdk.java.net/mduigou/8001634/3/webrev/> This update includes: - Mapper.map 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? Block.accept. Also, to allow IntFunction to implement Function<T,Integer>, need to adjust the method names. Propose applyAs{Int,Long,Double} for specializations. Similarly, need to do the same for Supplier: getAs{Int,Long,Double} with appropriate defaults for the specialized versions.

More information about the lambda-libs-spec-observers mailing list