We considered that option (i.e. default JNI code with no caller frame to the unnamed module of the system loader).   It should be very rare for such use case.   It's the simplest to keep the same access to public members of public classes in packages that are exported unconditionally as method invocation and field access as well as java.lang.invoke public Lookup.

If a native thread attaching to the VM with no caller wants to break encapsulation, it will have to workaround it by calling through a Java class.

Mandy

On 1/31/22 9:35 PM, Johannes Kuhn wrote:
Might be a bit late, but wouldn't it be better to check if the package is exported to at least the unnamed module of the system class loader?

It is currently not possible to add unconditional exports on the command line, but it is possible to add `--add-exports=some.module/some.pkg=ALL-UNNAMED` to the command line.

- Johannes

On 01-Feb-22 1:13, Mandy Chung wrote:
On Fri, 28 Jan 2022 17:50:19 GMT, Mandy Chung <mch...@openjdk.org> wrote:

`AccessibleObject::setAccessible` and `trySetAccessible` methods should only allow access to public member of a public type that is unconditionally exported consistent with the access check as described in the class specification, when invoked by JNI code with no Java class on the stack.   The current implementation throws NPE when finding the module of the caller class as the caller class is null.

The specification of `canAccess`, `setAccessible` and `trySetAccessible` are updated to specify the behavior when the caller class is null.   I consider this spec update as a clarification as the class specification covers this case.

This pull request has now been integrated.

Changeset: 9c0104b9
Author:    Mandy Chung <mch...@openjdk.org>
URL: https://git.openjdk.java.net/jdk/commit/9c0104b9c96f012da1602f503f641824d78f4260
Stats:     193 lines in 3 files changed: 166 ins; 19 del; 8 mod

8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack

Reviewed-by: alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7271

Reply via email to