I was just trying to run a jtreg test on a new Windows VirtualBox VM. A small
code change is needed but I don't want to do a full build (it also does not
have enough memory). I just copied an existing image, and the modified class
was compiled on the host macOS machine.
So this is not "really a problem", but if --patch-module can be used to patch a
module, I do hope the new classes are treated exactly the same as those
existing classes.
This is similar to the case of exploded build.
--Max
> On Dec 11, 2017, at 3:20 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
>
> On 11/12/2017 01:12, Weijun Wang wrote:
>> I modified a class inside the jdk.crypto.cryptoki module, compiled it with
>> "javac -d /tmp", and then ran a small program with
>>
>> java --patch-module jdk.crypto.cryptoki=/tmp -Djava.security.manager MyProg
>>
>> and it fails with
>>
>> TEST RESULT: Failed. Execution failed: `main' threw exception:
>> java.security.AccessControlException: access denied
>> ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.pkcs11")
>>
>> Looks like the permission granted to "jrt:/jdk.crypto.cryptoki" in
>> lib/security/default.policy are not granted to the new classes inside /tmp.
>> If I duplicate the block for "jrt:/jdk.crypto.cryptoki" to "file:/c:/tmp"
>> the program runs.
>>
>> I thought the /tmp folder should be cascaded into the jrt file system for
>> the module. Can this be enhanced?
>>
> The behavior you see is expected as the classes in /tmp have a different code
> source and so are in a different protection domain. Sure, this could be
> changed so that the classes loaded from the patch path are in the same
> protection domain as the module but that isn't going to work when the patch
> needs different permissions. It also causes problems +TraceClassLoading
> (something we should separate at some point). Is this really a problem or is
> it mostly just tests?
>
> -Alan
