RFR (M) JDK-8033150: invokestatic: IncompatibleClassChangeError trying to invoke static method from a parent in presence of conflicting defaults

Lois Foltan lois.foltan at oracle.com
Mon Mar 31 19:51:06 UTC 2014

On 3/31/2014 2:08 PM, Keith McGuigan wrote:
> Hi Lois,
> I think that looks good.  I like it much better than doing the static 
> method check in the default method processing.
> My only suggestion is that it would be nice to encode new parameter to 
> uncached_lookup_method to be some sort of enum instead of a boolean, 
> so that it is obvious from the call-site what the behavior should be 
> (having just "false" in the parameter list requires you to reference 
> back to the declaration to figure out what that "false" means).
> So instead of:
>    uncached_lookup_method(field_name, field_sig, false);
> It'd be:
>   uncached_lookup_method(field_name, field_sig, NORMAL); or
>   uncached_lookup_method(field_name, field_sig, IGNORE_OVERPASS);
> (or something like that -- I'm no good at names).

Thank you Keith.  Good suggestion.  I will implement and repost an 
updated webrev for review.

> --
> - Keith
> On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan <lois.foltan at oracle.com 
> <mailto:lois.foltan at oracle.com>> wrote:
>     Hi,
>     Please review the following fix:
>     Webrev:
>     http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/
>     <http://cr.openjdk.java.net/%7Elfoltan/bug_jdk8033150/>
>     Bug: invokestatic: IncompatibleClassChangeError trying to invoke
>     static method from a parent in presence of conflicting defaults
>     https://bugs.openjdk.java.net/browse/JDK-8033150
>     Summary of fix:
>     During default method processing, determine_target(), is
>     responsible for making decisions on whether
>     to create and add an overpass method to the current class for
>     issues that have been encountered during the walk
>     of the default methods.  The routine
>     defaultMethods.cpp/has_matching_static() helped determine this
>     decision by looking within the current class for a static method
>     that should be preferred during method
>     resolution over an overpass method being created.  However,
>     has_matching_static() did not continue to
>     look for a static method in current class' superclasses which
>     JDK-8033150 exposed.
>     After looking at the code more closely, the has _matching_static()
>     concept is being moved out out of default
>     method processing and into method resolution processing.  The
>     primary reason for this is to allow
>     default method processing to match method selection where statics
>     are and should be ignored.   According
>     to JVMS, static methods should only be preferred over an overpass
>     method at method and interface
>     method resolution time.  To enable method resolution to
>     potentially find a static method over an overpass
>     method, a new parameter "ignore_overpass" was added to
>     InstanceKlass::uncached_lookup_method().
>     It has the affect of indicating to find_method_index() to ignore
>     overpass methods and continue the search
>     in case a static method of the same name and signature is present
>     in the current class or its superclasses.
>     Tests:
>         - jtreg hotspot/test/*, JDK java.lang & java.util,
>     vm.quick.testlist, JCK lang & vm, defmeth tests
>     - Test will be added to the defmeth test system
>     Thank you,
>     Lois

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140331/be1be445/attachment.html>

More information about the hotspot-runtime-dev mailing list