RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB
Daniel D. Daugherty
daniel.daugherty at oracle.com
Mon Apr 28 17:45:54 UTC 2014
On 4/28/14 3:59 AM, Jaroslav Bachorik wrote:
> Thanks Dan!
>
>
> On 25.4.2014 20:08, Daniel D. Daugherty wrote:
>> On 4/24/14 6:52 AM, Jaroslav Bachorik wrote:
>>> Please, review the following patch:
>>>
>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04
>>
>> make/data/jdwp/jdwp.spec
>> line 1256: "<p>Since JDWP version 1.8
>> Missing the ending double quote.
>
> Fixed.
>
>>
>> line 1281: "suspended by an event or by command. "
>> "by command" isn't clear. "by this command", "by a command"
>> or something else more specific would be good.
You didn't say anything about this one...
>>
>> line 1322: (Error INVALID_METHODID "methodID is not the ID of a
>> method.")
>> The above description permits a 'methodID' value that
>> is not for a method in the 'clazz' interface. Perhaps
>> add "in the interface specified by clazz" at the end
>> of the description?
>
> This text is copied over from the ClassType#InvokeMethod. Should I
> change it there too?
Probably. Check with Staffan L for another set of eyes...
>
>>
>> src/share/back/VirtualMachineImpl.c
>> No comments.
>>
>> src/share/back/debugDispatch.c
>> No comments.
>>
>> src/share/back/util.c
>> No comments.
>>
>> src/share/classes/com/sun/jdi/ClassType.java
>> No comments.
>>
>> src/share/classes/com/sun/jdi/InterfaceType.java
>> line 88: * but not a static initializer.
>> The 'jdwp.spec' wording does not mention this restriction.
>
> Mentioned this restriction in jdwp.spec
>
>>
>> typo line 107: * enclosing class's class loader).
>> typo line 184: * loaded through the enclosing class's class
>> loader.
>> -> enclosing class' class loader
>
> Fixed. Also in ClassType (the comments were copied over from there
> with typos ...)
>
>>
>> line 189: * @throws VMCannotBeModifiedException ...
>> Please add the following after line 189:
>>
>> *
>> * @since 1.8
>>
>
> Done.
>
>> line 193-196: These exception are not named in the throws clause:
>> IllegalArgumentException, VMCannotBeModifiedException
>
> They are runtime exceptions. Should I list them in the throws clause
> regardless of that?
I should have checked for that. I'm pretty sure we don't put
runtime exceptions in the 'throws' clause... Of course, I'm
not enough of a Java programmer to know why putting them there
would be a bad idea or bad style or...
>
>>
>>
>> src/share/classes/com/sun/jdi/Method.java
>> line 144: * false otherwise
>> Please add the following after line 144:
>>
>> *
>> * @since 1.8
>
> Done.
>
>>
>> src/share/classes/com/sun/jdi/ObjectReference.java
>> No comments.
>>
>> src/share/classes/com/sun/tools/example/debug/expr/LValue.java
>> No comments.
>>
>> src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java
>> line 32: final public class ClassTypeImpl extends InvokableTypeImpl
>> The switch to "final" caught my eye. I presume that
>> SA-JDI does not extend this implementation class.
>
> To my best knowledge it does not.
>
>>
>> Most of these changes appear to be due to refactoring with
>> the new InvokableTypeImpl.java. Tried to do a visual diff
>> between the common parts of this file and InvokableTypeImpl.java.
>> Didn't see anything obviously wrong.
>>
>> src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java
>> Most of these changes appear to be due to refactoring with
>> the new InvokableTypeImpl.java. Tried to do a visual diff
>> between the common parts of this file and InvokableTypeImpl.java.
>> Didn't see anything obviously wrong.
>>
>> src/share/classes/com/sun/tools/jdi/MethodImpl.java
>> No comments.
>>
>> src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java
>> No comments.
>>
>> src/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java
>> No comments.
>>
>> src/share/back/InterfaceTypeImpl.c src/share/back/ClassTypeImpl.c
>> No comments.
>>
>> src/share/back/InterfaceTypeImpl.h src/share/back/ClassTypeImpl.h
>> No comments.
>>
>> src/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java
>> Most of this code came from refactoring ClassTypeImpl.java or
>> InterfaceTypeImpl.java.
>>
>> line 98: throws clause does not mention:
>> IllegalArgumentException or VMCannotBeModifiedException
>
> This is a runtime exception. It hasn't been mentioned in the
> ClassType#invokeMethod() throws clause too.
Same as above.
>
>>
>> But I also have to wonder why this JavaDoc is here since
>> this is an impl class...
>
> Just to add expressiveness. This method is actually declared by the
> both interfaces, ClassType and InterfaceType and it kind of made sense
> to have the shared implementation documented. The cleaner solution
> would probably be to factor out a shared superinterface for ClassType
> and InterfaceType and declare invokeMethod() there. But that would be
> more disruptive than playing just with the implementations.
>
>>
>> test/com/sun/jdi/EvalInterfaceStatic.sh
>> line 35: # the above error occurs. jdb doesnt notice that this is
>> Not sure what "the above error" is. I don't see an error
>> example above this line.
>>
>> typo: "doesnt" -> "doesn't"
>
> This code comment is completely wrong - a remnant of copy-paste :/ I
> forgot to clean it up. Sorry.
No problem.
>
>>
>> test/com/sun/jdi/InterfaceMethodsTest.java
>> Very nice test!
>>
>> Dan
>
> The updated webrev -
> http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/
Sounds good. Don't know when I'll get a chance for a re-review so
please don't wait for me.
Dan
>
> -JB-
>
>>
>>
>>>
>>> With JDK8 it became possible to have methods with implementation in
>>> interfaces - static and default interface methods. However the JDI and
>>> JDWP were not updated to reflect these capabilities so it is not
>>> currently possible to invoke a static or default interface method
>>> programatically from the debugger.
>>>
>>> This patch adds support for static and default interface methods to
>>> JDI, JDWP and JDB.
>>>
>>> Thanks,
>>>
>>> -JB-
>>
>
More information about the serviceability-dev
mailing list