S RFR: 8027304: Lambda: inheriting abstract and default should invoke default, not ICCE

[Karen Kinnear]

David,

I had missed your review - sorry. And you were correct, and Zhengyu's suggestion of a count fixed this problem.
Thank you for catching it - sorry I missed your review.

thanks,
Karen

On Oct 29, 2013, at 11:30 PM, David Holmes wrote:

> Hi Karen,
> 
> On 30/10/2013 12: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.
> 
> I'm not quite sure how to interpret that :) Can you point to the specific resolution rules that are intended to apply here please.
> 
> This code:
> 
> 397     for (int i = 0; i < _members.length(); ++i) {
> 398       Pair<Method*,QualifiedState> entry = _members.at(i);
> 399       if (entry.second == QUALIFIED) {
> 400         qualified_methods.append(entry.first);
> 401         default_index++;
> 402         if (entry.first->is_default_method()) {
> 403           unique_default = (unique_default == false) ? true : false;
> 404         }
> 405       }
> 406     }
> 
> will toggle unique_default depending on the number of default methods found:
> - 1,3,5 ... true
> - 2,4,6 ... false
> 
> is there something that limits the number of potential methods to only two? Otherwise this seems wrong.
> 
> Thanks,
> David
> 
>> 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
>>