S RFR: Lambda: no superclass methods in defaults

[Karen Kinnear]

Thanks Yumin for understanding and for the quick review.

thanks,
Karen

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

> Karen,
> 
>  That is OK roll back the one change. In future,  we may need to make all the 'defs' consistent.
> 
> #ifdef _WINDOWS
> .....
> #else
> 
> #endif // _WINDOWS
> 
> Some time confusing, which part is for WINDOWS? Your style is better to pick up code though most of the 'defs' not in your style.
> 
> Others look good.
> Please go ahead for integration.
> 
> Thanks
> Yumin
> 
> On 9/16/2013 2:27 PM, Karen Kinnear wrote:
>> 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
>>>>> 
>>>>> 
>