Issues with generic type detection of SAM types implemented using lambdas

[elias vasylenko]

I don't think you are discussing different things at all, Oliver.

You have presented your argument from two points of view:

- Users can't pass lambdas to methods unless they know for sure that the
implementation isn't relying on being able to reflect over generic type
parameters.

- As a result, library implementors / API designers can't rely on generic
type information being available.

David's point is that *both of these statements were already true* for
regular classes before lambdas came along.

What difference does it make if you have one more special case you need
your users to avoid? Either you already properly document these awkward
restrictions of argument types where it is not obvious and deem it an
acceptable risk, in which case you only need to make a minor change to this
documentation, or your API was already broken.

On Thu, 11 Jan 2018 at 15:34 Oliver Gierke <ogierke at pivotal.io> wrote:

> Again, I think we're discussing different things here. You refer to the
> fact that from an instance of a generic class, without creating an
> anonymous subtype, there's no way to find out about the generic type
> they've been bound to. That's fine and - I guess - common knowledge amongst
> Java developers.
>
> I am looking a different case and thus a different problem: Lambdas have
> been advertised as a direct alternative to anonymous classes (see [0], esp.
> section 12), and that's the reason IDEs unconditionally recommend to
> convert the latter into the former. However, for a given generic interface,
> reflecting over the declared generics in the Lambda variant behaves
> fundamentally different compared to an anonymous implementation.
>
> So I am pretty passionless on whether that's "trying to be clever" or
> "bad". I was merely pointing out an inconsistency.
>
> Cheers,
> Ollie
>
> [0] http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-final.html
>
> > Am 11.01.2018 um 15:20 schrieb David Lloyd <david.lloyd at redhat.com>:
> >
> > On Thu, Jan 11, 2018 at 8:03 AM, Oliver Gierke <ogierke at pivotal.io>
> wrote:
> >>> Am 11.01.2018 um 14:56 schrieb David Lloyd <david.lloyd at redhat.com>:
> >>>
> >>> On Thu, Jan 11, 2018 at 3:10 AM, Oliver Gierke <ogierke at pivotal.io>
> wrote:
> >>>> Lambda based implementations of SAM types currently don't support
> inspecting the type for generic type parameters. This can cause unexpected
> surprise...
> >>>
> >>> Here's a non-lambda example that demonstrates that inspecting *any*
> >>> class for generic type parameters is fragile and not a good idea:
> >>>
> >>> public final class Hasher<T> implements ToIntFunction<T> {
> >>>   int applyAsInt(T value) { return value.hashCode(); }
> >>> }
> >>>
> >>> Oops, now all my concrete implementations have generic parameters.
> >>
> >> I'm afraid I can't follow.
> >
> > Your example code which prints the actual type arguments will fail
> > because there is no actual type argument declared on the generic
> > *type*, only the *instance*.  If you create an API which relies on
> > getting actual types off of an object instance's class, you've made a
> > usability mistake.
> >
> >>> Telling users they cannot have generic parameters on their
> >>> implementation classes is poor API design.
> >>
> >> Who is actually doing that?
> >
> > "I just wanted to point out that an ordinary user -- in general client
> > code that uses APIs with SAM types -- *has to implicitly know* whether
> > *any code* (potentially Java 6 based) downstream might attempt
> > generics resolution before she can decide whether to use a Lambda with
> > this SAM type."
> >
> > Anyone who wrote one of these APIs is actually doing that.  It has
> > nothing to do with lambdas, and everything to do with APIs relying on
> > the assumption that implementation classes will have actual values for
> > every type parameter that it may inherit.  This assumption is flawed
> > because it's completely normal for a user to have a single function
> > implementation that works for many types; this is a solid
> > memory-conserving technique.  The only thing broken by this are
> > "clever" APIs that require usage of getActualTypeArguments() to get
> > necessary information from the user.
> >
> > --
> > - DML
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180111/0acbfc5b/attachment.html>