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