S RFR: 8027304: Lambda: inheriting abstract and default should invoke default, not ICCE
David Holmes
david.holmes at oracle.com
Tue Oct 29 20:30:05 PDT 2013
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
>
More information about the hotspot-runtime-dev
mailing list