Review Request: CR#8001634 : Initial set of lambda functional interfaces

[Remi Forax]

On 11/01/2012 10:43 AM, David Holmes wrote:

[...]

> package-info.java
>
> * <em>Functional interfaces</em> provide typing for lambda methods.
>
> lambda methods? Do you mean lambda expressions?
>
> "non-defaulted" is a horrible term. Isn't it simply abstract? Seems to 
> me that "abstract default" should not be permitted and that default 
> wipes out any implicit abstract. That way a default method is not an 
> abstract method, while an abstract method is what it always has been: 
> a method signature with no implementation.

I agree that a single abstract method is a better term here.
Nitpicking, Java 8 allows static methods in interface so non-default 
doesn't mean abstract but abstract or static methods.

>
> Cheers,
> David

Cheers,
Rémi

>
> On 1/11/2012 6:16 AM, Mike Duigou wrote:
>> There's a large set of library changes that will be coming with 
>> Lambda. We're getting near the end of the runway and there's lots 
>> left to do so we want to start the process of getting some of the 
>> more stable pieces put back to the JDK8 repositories.  We've spent a 
>> some time slicing things into manageable chunks. This is the first 
>> bunch. We'd like to time-box this review at one week, since there are 
>> many more pieces to follow.
>>
>> The first chunk is the basic set of functional interface types. While 
>> this set is not complete, it is enough to be able to proceed on some 
>> other pieces.  This set contains no extension methods (we'll do those 
>> separately) and does not contain all the specializations we may 
>> eventually need.
>>
>> The specification is limited; most of the interesting restrictions 
>> (side-effect-freedom, idempotency, stability) would really be imposed 
>> not by the SAM itself by by how the SAM is used in a calculation. 
>> However, some common doc for "how to write good SAMs" that we can 
>> stick in the package doc would be helpful. Suggestions welcome.
>>
>> Elements of this naming scheme include:
>> - Each SAM type has a unique (arity, method name) pair.  This allows 
>> SAMs to implement other SAMs without collision.
>> - The argument lists are structured so that specializations act on 
>> the first argument(s), so IntMapper<T>  is a specialization of 
>> Mapper<R,T>, and IntBinaryOperator is a specialization of 
>> BinaryOperator<T>.
>>
>> In order to get the most useful feedback out of this review, we'd 
>> like to ask you follow the following guidelines for the review:
>>
>> - We are time-boxed at one week. (until Nov. 7th)
>>
>> - Please review the whole bunch in a single message if possible, 
>> rather than in bits and pieces.  It is far easier to extract useful 
>> feedback from one complete review than from a dozen partial ones.
>>
>> - Please wait a few days before replying to other people's reviews! 
>> We want to keep the discussion on-topic to maximize the useful review 
>> content.  It is far too easy for the discussion to spiral off into 
>> minutia and lose sight of the goal -- which is to provide useful 
>> feedback on the API we're asking for feedback on.
>>
>> http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/