Multiple SAMs for same concept

Pavel Minaev int19h at
Thu Jul 15 16:49:30 PDT 2010

On Thu, Jul 15, 2010 at 4:34 PM, Stephen Colebourne
<scolebourne at> wrote:
> One problem noted with the removal of function types is that multiple
> SAMs with the same signature are not compatible. For example:
> Having these different incompatible definitions is problematic, for
> example when the developer has created a library of reusable
> implementations implementing one SAM, and then wants to use them using
> another (eg. a newly added JDK SAM).
> Given the method:
>  private void process(Generator<String> gen) { ... }
> the most recent draft SotL would allow the following two choices for conversion:
>  Supplier<String> supplier = ...
>  process( {->} );  // manual conversion to a Generator
>  process( supplier#supply() );  // using method ref to manually
> convert to Generator
> While the two solutions are not terrible, they are less than ideal. I
> would argue that the ideal would be:
>  process(supplier);  // auto-boxed from Supplier to Generator

Such "autoboxing" (since no boxing happens here, I'd rather call it
"autowrapping") wouldn't preserve object identity. I think it would be
very confusing to pass a reference to object, only to receive a
reference to a completely different (as in, r1 != r2) object on the
other side - especially without any explicit casts or other indication
that something unusual is going on.

This wasn't a problem with primitives because they don't have their
own object identity

> One compromise option I came up with was:
> process( supplier# );

This looks more reasonable.

More information about the lambda-dev mailing list