Fix proposal for bug JDK-8221642

[Andreas Rosenberg]

Hi,

this is my first posting regarding to JDK contribution, so this may be the wrong place to ask. 
Please point me in the right direction in this case.

We are using Java rather heavily via JNI on a custom application. For a long time we did stick to JRE 1.8 
for various reasons. My task is to plan an upgrade to a more recent JDK version and while doing some 
test I encountered bugs related to this: JDK-8227491  (JNI - caller sensitive methods).

We are parsing Java class files to auto gen the JNI code for our application, and are also using reflection.
The workaround given is clumsy and needs manual intervention, so I was looking for a more elegant solution.

The problem is: a caller sensitive method wants to determine the caller class for security checks. In case of 
a JNI call no Java stack frame exists, so the JVM function "jclass JVM_GetCallerClass(JNIEnv* env)" answers NULL
which leads to NPEs. 

My idea is this: create an internal proxy class inside "java.base" that reflects this case 
(e.g. "java.lang.NativeCall" or "java.lang.NativeCode").
This class is final and implements nothing.

Then "jclass JVM_GetCallerClass(JNIEnv* env)" (jvm.cpp) could be modified and instead of answering NULL 
in case of a JNI call, it should do this to answer the class proxy: 

return JVM_FindClassFromBootLoader(env, "java/lang/NativeCall");

This would have the following advantages:
- JNI code could again simply call "caller sensitive methods" without the need to make an additional wrapper class
- it would be more a expressive way on the Java side to detect "the callee is native code" than checking for null 
- it would fit better into the framework

I already applied this fix on my own copy of the JDK 17 sources and it works pretty well for us.

As there are probably security considerations involved, advice from experts is required. 
But from my understanding the Java security model is designed for the main app being writing in Java.
In this case there are always Java stacks frames available as parents for caller sensitive methods, so
the proposed fix would not affect the behavior. This assumes that "GetCallerClass" only answers
NULL for the JNI case. This needs verification.

If the main app is native code which uses JNI, the Java security model can only affect the Java part and
as soon as an additional Java stack frame has been generated a regular Java class will be found and
the "standard behavior" should apply again. 

Comments appreciated.

It this fix looks reasonable, what are the steps to get it implemented and integrated into the official 
source tree?

Best regards,
Andy