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

[Brian Goetz]

Yes, they could, but this patch addresses that.  It keeps the numbering 
going in that case.

More generally, the goal here is not any sort of "absolute stability"; 
but instead to avoid gratuitous instability.



On 2/9/2013 12: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. 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
>>
>>
>
>