JDK-8042123 : Support default and static interface methods in JDI, JDWP and JDB
  • Type: Enhancement
  • Component: core-svc
  • Affected Version: 1.8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-04-29
  • Updated: 2017-05-17
  • Resolved: 2014-10-03
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.
8u40 b10Fixed 9Fixed
Related Reports
Cloners :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Since JDK 8 it is possible to have static methods in interfaces. However, there is no way to execute them from debugger.
Static method in classes can be run by com.sun.jdi.ClassType.invokeMethod(). But there is missing corresponding com.sun.jdi.InterfaceType.invokeMethod().

In addition, when an invocation of a default method is attempted it results in error.
On further reflection and examination of what is allowed at the Java language level I think the intent was that static interface methods can not be invoked via ObjectReference.invokeMethod, but the changes to the spec and the implementation were not consistent with that. I believe this bug should have: a) Changed the initial part of the invokeMethod spec from: "The method may be a static method or an instance method, but not a static initializer or constructor." to read something like: "The method may be a static class method or an instance method, but not a static initializer, static interface method or constructor." and b) Actually implemented the logic to throw IllegalArgumentException when called for a static interface method whether virtual or non-virtual Then the logic that dispatches to InterfaceType.invokeMethod is not needed and should be removed. Rather than try to address this as part of JDK-8165827 I will file a new bug.

The specification change for ObjectReference.invokeMethod was not correct. It states: * @throws java.lang.IllegalArgumentException if the method is not * a member of this object's class, if the size of the argument list * does not match the number of declared arguments for the method, * if the method is a constructor or static intializer, or * if {@link #INVOKE_NONVIRTUAL} is specified and the method is * either abstract or a non-default interface member. The last clause prohibits nonvirtual invocation of a static interface method, but it should be allowed: /** * Invokes the specified {@link Method} on this object in the * target VM. The * specified method can be defined in this object's class, * in a superclass of this object's class, or in an interface * implemented by this object. The method may be a static method * or an instance method, but not a static initializer or constructor. The implementation delegates static method invocations to Interfacetype.invokeMethod or ClassType.invokeMethod as appropriate. This will be fixed as part of the update for JDK-8165827.

For the JDK 8u40 release notes: Scope: Java SE Synopsis: Invoking default and static interface methods via JDI Description: Java SE 8 Language Specification has introduced static and default methods for interfaces. JDI specification didn't account for this in Java SE 8. JDI and JDWP have now been updated to allow such invocations. In JDI the "com.sun.jdi.InterfaceType" class now contains an additional method "Value invokeMethod(ThreadReference thread, Method method, List<? extends Value> arguments, int options)". In JDWP a new comand "InvokeMethod" is added to the "InterfaceType" command set. The JDWP version was increased to 8. Incompatibility: Source

Suggested relese-note text: "Since JDK 8 it is possible to have directly executable static and default methods in interfaces. These methods are not executable via JDWP or JDI and therefore can not be properly debugged."

8u20-deferal-reqest-justification: It turns out that the CCC is not enough. Changing the JDWP spec and parts of the JDI API would require a MR to JDK8 which is a lengthy process and not guaranteed to happen. What is sure now is that In the timeframe of 8u20 no MR will happen. Therefore asking for deferral.