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