RFR [9]: 8177036: Class.checkMemberAccess throws NPE when calling Class methods via JNI

Alan Bateman Alan.Bateman at oracle.com
Mon Mar 20 11:49:56 UTC 2017

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.


More information about the core-libs-dev mailing list