Fun with method references

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Mon Aug 9 08:40:25 PDT 2010


On 09/08/10 16:26, tom.hawtin at oracle.com wrote:
> On 09/08/2010 01:37, Howard Lovatt wrote:
>
>    
>> The problem is that both foo(Handler<String>) and foo(Handler<Bar>)
>> get erased to foo(Handler) and therefore they both can't exist in the
>> same class (they have the same signature in the class file). If
>> generics ere reified then you could have both methods in the same
>> class since they would have different signatures. The same goes for
>> any other feature, including function types, that is implemented via
>> erasure.
>>      
> The generics information is still in the class file format and is
> available at link-time (and also through the reflection APIs). A
> necessary change would be for Java SE 7 to allow class files with
> methods that vary only in generics. As the method resolution magic
> happens at link-time, there is no need for objects to contain generic
> information at run-time.
>    
True - however we ought not to forget about 1.4 clients who see no 
generics at all and, as a result, will not be able to choose between two 
methods with the same erased signature.

Maurizio
> OTOH, I'm not a big fan of overloading. Keep it explicit.
>
> Tom
>
>    



More information about the lambda-dev mailing list