Bug 8027734

[Yumin Qi]

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
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20131111/d6fa95c6/attachment.html