S RFR: 8027304: Lambda: inheriting abstract and default should invoke default, not ICCE
Karen Kinnear
karen.kinnear at oracle.com
Wed Oct 30 07:23:53 PDT 2013
updated webrev with Zhengyu's suggestion - which just makes the unique requirement much clearer - thanks Zhengyu!
http://cr.openjdk.java.net/~acorn/8027304.2/webrev/
thanks,
Karen
On Oct 30, 2013, at 10:06 AM, Karen Kinnear wrote:
> Zhengyu,
>
> Good catch. I don't want a toggle. I want to find out if there is only 1 answer. A counter would
> be totally clear.
>
> thanks - I needed that,
> Karen
>
> On Oct 30, 2013, at 9:31 AM, Zhengyu Gu wrote:
>
>>
>> On 10/30/2013 8:37 AM, harold seigel wrote:
>>> Hi Karen,
>>>
>>> Instead of:
>>> unique_default = (unique_default == false) ? true : false;
>>> why not just:
>>> unique_default = !unique_default;
>> Does not seem right. This one toggles the value, and original one when unique_default = false, it will always be false.
>>
>> Why not uses counter, and check counter == 1?
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>> Thanks, Harold
>>>
>>> On 10/29/2013 10:55 PM, Karen Kinnear wrote:
>>>> webrev: http://cr.openjdk.java.net/~acorn/8027304/webrev/
>>>> bug: http://bugs.openjdk.java.net/browse/JDK-8027304
>>>>
>>>> Bug in default method handling due to specification misinterpretation if there is one maximally-specific default method,
>>>> but no one maximally specific method based on default method inheritance rules.
>>>> Inheritiing abstract and default should invoke default, rather than IncompatibleClassChangeError.
>>>>
>>>> Tested:
>>>> Fixed vm defmeth ConflictingDefaultsTest testAmbiguousReabstract (renamed to testMaximallySpecificDefault)
>>>> jdk DefaultMethodsTest, FDSeparateCompilationTest
>>>> jck lang, vm
>>>> jtreg java.util, java.lang
>>>> vm.quick.testlist
>>>>
>>>> thanks,
>>>> Karen
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20131030/185aedfc/attachment.html
More information about the hotspot-runtime-dev
mailing list