JDK-8071657 : JDI ObjectReferenceImpl.invokeMethod() validation fails for virtual invocations of method with declaring type being an interface
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 8u40
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-01-27
  • Updated: 2015-09-29
  • Resolved: 2015-03-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8u60 b08Fixed
Related Reports
Duplicate :  
Description
Bug came in through another system. Bug Description:

I'm seeing a regression moving from JDK7 to JDK8u40 with the invocation of a method in an annotation from a debugger.

I have a simple annotation class with two methods.   There is a unit test that retrieves the annotations (getDeclaredAnnotations()).
After retrieving the annotations,  I try to call ObjectReference.invokeMethod() to invoke each of the annotation's methods. In JDK7 this worked; in JDK8 it fails with an IllegalAccessException: "Not a default method".

I've looked at the source for com.sun.tools.jdi.ObjectReferenceImpl and see significant changes between JDK7 and JDK8 due to the introduction of interface methods in JDK8.

In JDK7, all methods were class (as opposed to interface) methods and the validation of the annotation methods was successful.

In JDK8, validateMethodInvocation has been rewritten to be a small method that forwards the validation to one of two new methods,
validateClassMethodInvocation or validateIFaceMethodInvocation. The implementation of validateClassMethodInvocation appears to be the same as the pre-JDK8 validateMethodInvocation -- validation that the annotation method would pass.   However, the annotation method is being treated as an interface method (because method.declaringType() instanceof InterfaceTypeImpl is true) and going through validateIFaceMethodInvocation.   The test there is that method.isDefault() -- and the annotation method returns false, thus the exception is thrown.

I'm not sure what the correct behavior is here, but there are a couple of possibilities:
- If annotation classes were treated as classes, rather than interfaces, then we'd go through the same validation as before and this would work.
- Alternately. if methods on annotations were considered default methods, then we'd pass the new validation. (The annotations do have a "default" value specified, but not all annotation methods will, so this seems a less satisfactory solution)
- Or, the validateIFaceMethodInvocation may need a special test for annotation methods and validate them differently than interface methods. 
Comments
Verified in JDK 1.8.0_60b09 using reproducer from a duplicate issue.
03-04-2015

URL: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/aa2770d3ff19 User: lana Date: 2015-03-23 21:16:45 +0000
23-03-2015

URL: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/aa2770d3ff19 User: jbachorik Date: 2015-03-12 02:34:00 +0000
12-03-2015

URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9c769c3a2c60 User: lana Date: 2015-03-11 02:21:44 +0000
11-03-2015

URL: http://hg.openjdk.java.net/jdk9/hs/jdk/rev/9c769c3a2c60 User: ctornqvi Date: 2015-02-26 04:39:55 +0000
26-02-2015

It all boils down to how one actually obtains the JDI Method instance. When going through the actual object instance everything works fine. But when getting the class first and retrieving the method from the class the invocation will fail for interfaces even when not using NON_VIRTUAL flag for the invocation.
06-02-2015

Deferral justification: I was not able to reproduce the problem using the standard JDI APIs. The issue seems to be related to a very specific usage of the APIs. Currently we are waiting for the reporter to provide us with a code examples to allow us to investigate further.
29-01-2015

Looks related to JDK-8042123 which was fixed in 8u40.
27-01-2015