Hi, Joel
This bug is a SQE testing bug, see
https://bugs.openjdk.java.net/browse/JDK-8027734
<https://bugs.openjdk.java.net/browse/JDK-8027734>
I have commented with the exception stacktrace.
It only fails when defmeth set call through reflection and passed
with other two modes: -mode invoke and -mode direct
The problem I got is from this part: Reflection.java:118
(verifyMemberAccess)
if (!Modifier.isPublic(getClassAccessFlags(memberClass)))
{ // here memberClass is p1.I which is
not a public
isSameClassPackage = isSameClassPackage(currentClass,
memberClass); // Not in same class
gotIsSameClassPackage = true;
if (!isSameClassPackage) {
return false; // so we return false.
}
}
// At this point we know that currentClass can access memberClass.
if (Modifier.isPublic(modifiers)) {
return true;
}
memberClass is p1.I is a private interface, but its sub p1.J is a public
interface. The default method is in I:
/* In package1:
* package p1;
* interface I {
* default int m() { return 10; };
* }
* public interface J extends I {};
*
* In package2:
* class A implements p1.J {}
* A myA = new A;
* myA.m(); // should return 10, not throw IllegalAccessError
* B myB = new B; // not related
*/
Now defmeth caller is TestContext, which is not in same package with
interface I, this leads verify failed.
'modifiers' is public, but we check if the caller class and calee class
in same package first and returned false, since they do not exist in
same package. If we check the following statement first, we will return
true. I am not familiar with this code, can you or some other people on
the list give comments?
Thanks
Yumin
On 10/10/2013 6:02 AM, Joel Borggren-Franck wrote:
Hi Karen,
I agree with the others, the code looks good though I like Paul's
suggestion.
Silly question perhaps, do you know if we have good test coverage on
actually reflectively invoking a Method more than 15 times?
cheers
/Joel
On 2013-10-09, Karen Kinnear wrote:
Please review:
webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/
bug: https://bugs.openjdk.java.net/browse/JDK-8026213
Summary:
Reflection generates code dynamically to speed up reflection processing after
startup. The first
15 runs of a reflection call use the vm code path, after that we use the
generated code path, which
needs to use invokespecial on private methods in interfaces.
Tested:
Test attached to the bug
Also - all the 8011311 private method testing was run with this in the build:
Robert Field's TypeTest
8025475 test
defmeth privatemethodstest with reflection
John Rose's intfbug
jtreg: java.util, java.lang
jck vm, lang
thanks,
Karen
