RFR: 8165827: Support private interface methods in JNI, JDWP, JDI and JDB
Daniel D. Daugherty
daniel.daugherty at oracle.com
Tue Oct 11 17:30:05 UTC 2016
On 10/10/16 7:55 PM, David Holmes wrote:
> Turns out the only place changes were needed were in JDI.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165827
>
> webrev: http://cr.openjdk.java.net/~dholmes/8165827/webrev/
src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java
No comments. (Thanks for also fixing the typo.)
src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java
L352: if (isNonVirtual(options)) {
L353: if (method.isAbstract()) {
L354: throw new IllegalArgumentException("Abstract
method");
L355: }
Any particular reason for breaking the logic into two
distinct if-statements?
Perhaps:
if (isNonVirtual(options) && method.isAbstract()) {
throw new IllegalArgumentException("Abstract
method");
}
Also, perhaps "unexpected Abstract method" is more clear?
test/com/sun/jdi/InterfaceMethodsTest.java
L526: if (t.getClass() != expectedException) {
L527: System.err.println("--- FAILED");
L528: failure("FAILED: " + t);
L529: return null;
L530: }
You should also report the expectedException value here to
aid in failure analysis.
Thumbs up! I don't need to see another webrev if you decide to
make the above small tweaks.
Dan
>
> The spec change in ObjectReference is very simple and there is a CCC
> request in progress to ratify that change.
>
> The implementation change in ObjectReferenceImpl mirrors the updated
> spec and use the same format as already present in the class version
> of the check method.
>
> The test is a little more complex. This is obviously an extension to
> what is already tested in InterfaceMethodsTest. However IMT has a
> number of problem with the way it is currently written [1] -
> specifically it doesn't properly separate method lookup from method
> invocation. So I've added the capability to separate lookup and
> invocation for use with the private interface methods - I have not
> tried to address shortcomings of the existing tests. Though I did fix
> the return value checking logic! And did some clarifying comments and
> renaming in a couple of place.
>
> Still on the test I can't add the negative tests I would like to add
> because they actually pass due to a different long standing bug in JDI
> - [2]. So the actual private interface method testing is very simple:
> can I get the Method from the InterfaceType for the interface
> declaring the method? Can I then invoke that method on an instance of
> a class that implements the interface.
>
> Thanks,
> David
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8166453
> [2] https://bugs.openjdk.java.net/browse/JDK-8167416
More information about the hotspot-runtime-dev
mailing list