Lambda proxy class doesn't carry generics information

[Brian Goetz]

In the first example, there exists a statically defined class.  In the second, there is not.  Currently we are generating one class per lambda capture site, but we view that as a temporary implementation.  So while we *could* "fix" this with the current translation strategy, it would just break when we tried to go to, say, the one-class-per-SAM strategy anyway.  

(I am sure the strategy he is using fails anyway when you are more than one hop away from the instantiation site.  For example, if you create a combinator for "compose comparators"; the inner class in compose(c1, c2) will not know that its a Comparator<String> since compose will be a generic method anyway.)



On Oct 5, 2013, at 12:49 PM, Remi Forax wrote:

> David Gageot [1] talk to me about this issue after my presentation at ParisJUG and
> I totally forgot to report it.
> He said that he is using a framework that uses the generic information inserted by javac
> (and available by reflection) so he can not retrofit its code that uses inner classes to
> use lambdas because the generated lambda proxy doesn't carry this information.
> 
> Here is a small test to see the issue:
> public static void main(String[] args) {
>    Comparator<String> c = new Comparator<String>() {
>      @Override
>      public int compare(String s1, String s2) {
>        return s1.compareTo(s2);
>      }
>    };
>    Comparator<String> c2 = (s1, s2) -> s1.compareTo(s2);
> 
> System.out.println(Arrays.toString(c.getClass().getGenericInterfaces())); // [java.util.Comparator<java.lang.String>]
> System.out.println(Arrays.toString(c2.getClass().getGenericInterfaces())); // [interface java.util.Comparator]
>  }
> 
> I said to him that it was not a bug, but it's less clear to me now :(
> 
> cheers,
> Rémi
>