RFR(S) 8226645: [TESTBUG] some AppCDS tests relies on illegal reflective access
David Holmes
david.holmes at oracle.com
Tue Aug 13 01:53:54 UTC 2019
Hi Calvin,
On 13/08/2019 4:11 am, Calvin Cheung wrote:
> On 8/11/19 11:42 PM, Alan Bateman wrote:
>> On 12/08/2019 06:19, David Holmes wrote:
>>>
>>> I don't understand how this works. MethodHandles.lookup() returns a
>>> Lookup for the current/caller class, which in this case is the Utils
>>> test library class. You then use that Lookup instance to try and get
>>> a private Lookup for peerClass, which is an arbitrary test class. But
>>> the Utils Lookup should not have permissions to get a private Lookup
>>> for an arbitrary class! Unless there is some kind of "un-named
>>> module" general access being granted here ??
>> It will only work id peerClass's module opens the packages to all
>> unnamed modules. A saner approach might be for the Util method to take
>> a Lookup object with the right access so that it defines the class in
>> the same run-time package as the lookup object.
> For the tests in questions, both callerModule and targetModule are
> unnamed and both callerClass and lookupClass don't belong to a package.
> So I think the Lookup object was obtained correctly. Let me know if
> there's a better way of obtaining a Lookup object.
You're not supposed to "obtain" a Lookup for another class as such. A
given class is supposed to obtain its own Lookup and then hand that out
to trusted parties. So as Alan suggested you would have:
public static Class<?> defineModifiedClass(Lookup lookup, File clsFile,
String fromString, String toString) ... {
...
Class<?> cls = lookup.defineClass(buff);
}
and the test would do:
Class superClass = Util.defineModifiedClass(MethodHandles.lookup(),
clsFile, from, to);
Cheers,
David
>> In addition, tests such as LoaderSegregation create the ClassLoader so
>> they can define the class (C2 in this case) directly, no need for a
>> dummy class.
>>
> For this test to work, the lookupClass' loader needs to be a
> java.net.URLClassLoader. Only this test requires a dummy class and the
> current fix is fairly simple. I'd like to leave the fix as is for now.
>
> thanks,
>
> Calvin
>
More information about the hotspot-runtime-dev
mailing list