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

[Maurizio Cimadamore]

I agree this is something we should fix, either by taking absolute value 
of the hash, or by emitting the HEX representation.

Maurizio

On 04/03/13 08:42, Peter Levart wrote:
> Hi Brian, Maurizio,
>
> The generated method name is ok. It could even be compliant with Java 
> syntax if the "kkkk" part was taken to be a HEX representation of the 
> hashCode(). Currently the decimal representation can be negative and 
> '-' character stands-out. I believe all other synthetically generated 
> methods comply with Java syntax, don't they?
>
> Regards, Peter
>
> On 02/09/2013 07:09 PM, Brian Goetz wrote:
>> 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
>>>>
>>>>
>>>
>>>
>