Default methods: Possible problem with JDWP sendMethod resolution semantics

[David Holmes]

Hi Jesper,

This seems more of an issue with the hotspot runtime so cc'd hotspot-dev.

David

On 27/01/2014 11:37 PM, Jesper Steen Møller wrote:
> Hi list
>
> I realize that this is possibly not the right list, but I'm having a lambda-related problem with the JDWP protocol (from the Eclipse Java Debugger)
> The problem is that I cannot invoke the default method of an interface using the equivalent of the superclass invocation syntax. Consider this example:
>
> public interface A {
> 	default int getOne() {
> 		return 1;
> 	}
> }
>
> public interface B {
> 	default int getOne() {
> 		return 2;
> 	}
> }
>
> public class Impl implements A, B {
> 	public int getOne() {
> 		return B.super.getOne() + 3; // stop here and inspect B.super.getOne()
> 	}
> 	public static void main(String[] args) {
> 		Impl i = new Impl();
> 		System.out.println(i.getOne());
> 	}
> }
>
> Now, consider the line with the comment "stop here ...". Assume I have a suspended thread on that line, and I wish to inspect "B.super.getOne()", i.e. invoke the method B.getOne, using the 'this' reference as the receiver. So, I'm sending a "Invoke Method" command under the ObjectReference Command Set, like this:
>
> object	 -  objectID of 'this'
> thread       - threadID of suspended thread
> clazz         - classID of 'B'
> method     - methodID of 'B.getOne'
> arguments - 0
> option      - 3 (this INVOKE_SINGLE_THREADED + INVOKE_NONVIRTUALINVOKE_NONVIRTUAL)
>
> However, the return value is '5' which indicates that the usual virtual call semantics were used on 'this'. Is this supposed to work? Have anyone tried this?
>
> TIA,
> Jesper
>
>