S RFR: Lambda: no superclass methods in defaults

Karen Kinnear karen.kinnear at oracle.com
Mon Sep 16 14:27:30 PDT 2013


Yumin,

My apologies. I will put back the // ndef PRODUCT to match the other 15 lines.
This is a style issue and is quite prevalent in a lot of code in the code base. I actually prefer it,
but we can have that discussion when we review detailed style preferences.

So I will put this one line back and let that be a future discussion.

thanks,
Karen

On Sep 16, 2013, at 5:14 PM, Yumin Qi wrote:

> Hi, Karen
> 
>  Could you can change all the
> 
> 259:#endif // ndef PRODUCT
> 461:#endif // ndef PRODUCT
> 585:#endif // ndef PRODUCT
> 631:#endif // ndef PRODUCT
> 748:#endif // ndef PRODUCT
> 762:#endif // ndef PRODUCT
> 770:#endif // ndef PRODUCT
> 778:#endif // ndef PRODUCT
> 904:#endif // ndef PRODUCT
> 912:#endif // ndef PRODUCT
> 956:#endif // ndef PRODUCT
> 972:#endif // ndef PRODUCT
> 987:#endif // ndef PRODUCT
> 1141:#endif // ndef PRODUCT
> 1165:#endif // ndef PRODUCT
> 
> in this file?
> 
> There was total 16, and now 15 after you changed one.
> (The line number based on my workspace, not accurate).
> 
> Thanks
> Yumin
> 
> On 9/16/2013 2:03 PM, Karen Kinnear wrote:
>> Updated webrev
>> 
>> http://cr.openjdk.java.net/~acorn/8024647.02/webrev/
>> 
>> Incorporating comments from Yumin and Keith. I would appreciate formal approval from Keith :-)
>> 
>> Here is an example of what TraceMethodDefaults prints for this case:
>> 
>> Class B requires default method processing
>> B
>>   A
>>     java/lang/Object
>>   I
>> Slots that need filling:
>>   m()V
>>   Looking for default methods for slot m()V
>> Creating overpasses...
>> for slot: m()V
>>   Selected method: A.m()V : in superclass
>> Created 0 overpass methods
>> Default method processing complete
>> 
>> thanks,
>> Karen
>> 
>> On Sep 13, 2013, at 11:24 PM, Karen Kinnear wrote:
>> 
>>> Please review
>>> 
>>> webrev: http://cr.openjdk.java.net/~acorn/8024647.01/webrev/
>>> https://bugs.openjdk.java.net/browse/JDK-8024647
>>> 
>>> Bug: Default method resolution incorrectly handles private superclass methods.
>>> Problem was that during default method resolution, we are creating overpasses for
>>> superclass target methods. We only need to create these for superinterface target methods.
>>> 
>>> Testing:
>>> test cases in the bug
>>> defmeth tests - no additional failures
>>>  (these test cases should be added to the vm sqe defmeth tests)
>>> 
>>> regression tests:
>>> java.util.streams - in progress
>>> jprt - in progress
>>> vm.quick.testlist - in progress
>>> 
>>> thanks,
>>> Karen
>>> 
>>> 
> 



More information about the hotspot-runtime-dev mailing list