RFR : CR8004015 : Add parent interfaces and default methods to basic functional interfaces

David Holmes david.holmes at oracle.com
Fri Dec 14 06:28:41 UTC 2012

HI Mike,

On 14/12/2012 3:24 PM, Mike Duigou wrote:
> Hello all;
> I have updated the webrev again for hopefully the last time:
> http://cr.openjdk.java.net/~mduigou/8004015/3/webrev/
> http://cr.openjdk.java.net/~mduigou/8004015/3/specdiff/overview-summary.html
> The implementation now uses Primitive.primitiveValue() ie. Integer.integerValue() rather than a cast. Same bytecode but using the intrinsic function makes it more clear that result is either primitive or NPE and that CCE is not possible.
> I have added @throws NPE for a number of the default methods. We won't be including @throws NPE in all cases where null is disallowed because when the @throws NPE is declared the API is required to throw NPE in that circumstance. So for cases where the NPE is "naturally" thrown or that aren't performance sensitive we will likely add @throws NPE declarations but for performance sensitive methods we won't be adding explicit null checks to match a @throws NPE specification. There's a tradeoff here in some cases. Please feel free to quibble about specific cases as they occur. :-)

That doesn't make sense to me. The throwing of the NPE is intended to be 
part of the specification not an implementation choice. Further @param 
foo non-null, is just as binding on implementations as @throws NPE if 
foo is null. ???

I think defining the NPE via the @param and @throws is a lose-lose 

!      * @param left {@inheritDoc}, must be non-null
!      * @param right {@inheritDoc}, must be non-null
!      * @return {@inheritDoc}, always non-null
!      * @throws NullPointerException if {@code left} or {@code right} 
is null

You only need one convention.


> Mike

More information about the core-libs-dev mailing list