On 20/03/2017 11:42, Peter Levart wrote:
I guess that when only the ClassLoader of the caller is checked in
logic of @CS method, such calls should behave as though the caller was
some class loaded by bootstrap ClassLoader. But what about @CS methods
that inspect the caller class more deeply (such as reflection API)
where the identity of the caller, its package and module play role in
decisions? What behavior is expected in such cases? Should core
reflection always allow access when invoked from "null" caller?
Currently core reflection throws InternalError (because of the check
in Reflection::ensureMemberAccess). But jake repo already contains
changes that remove this check and NPE is thrown later on in
verifyModuleAccess...
I think we'll need to create some tests to catch all the cases where @CS
methods are involved from thread attached via JNI and without any caller
frames. In some cases then IllegalCallerException might be best, in
other cases then it may be okay to assume the caller is java.base.
-Alan.
