hg: lambda/lambda/langtools: Enhancement: more stable serialized lambda names

[Peter Levart]

On 02/09/2013 06:05 PM, Peter Levart wrote:
>
> On 02/07/2013 08:30 PM, maurizio.cimadamore at oracle.com wrote:
>> Changeset: 7bffb45844fb
>> Author:    mcimadamore
>> Date:      2013-02-07 19:30 +0000
>> URL:http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7bffb45844fb
>>
>> Enhancement: more stable serialized lambda names
>>
>> Serializable lambdas are desugared to methods where name follows following pattern:
>>
>>    lambda$mmm$kkkk$nnn
>>
>> where mmm is the method name and kkk is the hashcode of the method signature, and nnn is a sequentially assigned number.  That way, dependencies on lambdas from other methods will be minimized.
>
> Hi Maurizio,
>
> Could the hashCodes of the signatures of two overloaded methods clash? 
> For example, these two methods:
>
>     void m(Aa a) { }
>
>     void m(BB b) { }
>
> have method descriptor signatures with same hashCodes.
>
> One way to avoid generating name clashes in such contrived examples is 
> to have 'serializableLambdaCounts' Map being keyed by method's 
> declaring class + hashCode of method's signature. 

Or better, being keyed by "lambda$mmm$kkkk" prefix of generated method 
name, whatever it is...

> String.hash32() could also help avoid clashes.
>
> Otherwise, is there some rule that disallows synthetic method names 
> using full ASCII set of chars? Why couldn't the generated method name 
> be composed of the unchanged method signature?
>
> Regards, Peter
>
>> ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
>> ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
>>
>>
>