RFR: CR#8004561 : Additional Functional Interfaces and Updates
Brian Goetz
brian.goetz at oracle.com
Sun Dec 23 18:36:41 UTC 2012
Yes, this is a deliberate u-turn that comes as a result of the
unexpected interactions with the overloading resolution rules.
By having DoubleBlock extending Block<Double>, we created problems for
overloading. For example, consider this expected-to-be-common
overloading in Bunch<T>:
<U> Bunch<U> transform(Function<T,U> transformer)
IntBunch transform(IntFunction<T> transformer)
There are some conflicting rules in overload selection:
- prefer more-specific SAMs to less specific (favors IntFunction)
- prefer less boxing/unboxing
What we'd like is to choose the former when the "natural" type of
transformer is T -> Integer and the latter when the "natural" type is T
-> int. But, because the more specific rule has higher priority, we
would coerce a T -> Integer into a T -> int (with unboxing) all the time.
On 12/20/2012 9:07 PM, Howard Lovatt wrote:
> 1. DoubleBlock doesn't extend Block<Double> and doesn't have a default
> method, similarly int and long
> 2. Similarly all the rest like Function aren't extended
>
> Is this the correct link - it seems to have gone backwards?
>
> -- Howard.
>
>
> On 21 December 2012 12:41, Mike Duigou <mike.duigou at oracle.com> wrote:
>
>> Hello all;
>>
>> Here are some additional functional interfaces for review. The additions
>> fill in holes for primitive types and for two operand "Bi" operations.
>>
>> http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/
>>
>> http://cr.openjdk.java.net/~mduigou/8004561/0/specdiff/java/util/function/package-summary.html
>>
>> Additionally, this patch contains naming updates on the existing
>> functional interfaces following 335 EG review. It does not include the
>> interface specializations and default methods previously proposed in
>> CR#8004015. That proposal has been withdrawn. It turned out that user
>> errors involving unexpected boxing were just too common for the value
>> provided.
>>
>> Mike
>>
>>
>
>
More information about the core-libs-dev
mailing list