Hi Peter,
On 3/21/2013 11:47 AM, Peter Levart wrote:
...
I have seen a utility that uses it to establish the context (package
and ClassLoader) of where to start searching for resources for GUI
components construction. And a utility that wraps
Class.forName(String) - specifying Class.forName(name, true,
Reflection.getCallerClass(2).getClassLoader()) instead to use the
caller's class loader to load the class...
This seems to me that this case is more of visibility issue rather than
caller-sensitivity.
Usually it is only necessary to get the immediate caller.
Is there a reason to not "unofficially" support also classes with
@CS annotated methods and which are not loaded by bootstrap or
extension class-loader ?
We expect that most of the caller-sensitive cases are in the JDK and
should be rare for non-system libraries to have caller-sensitive
code. It'd be good to understand the use cases and the requirements
to determine the appropriate support for it.
Ok, but why limit? Is it an optimization?
Just out of scope and there will be much more consideration to expand
the scope to cover the user caller-sensitive methods (e.g. SE API and
implementable by different JDK vendors).
The scope of JEP 176 is target for the system code where it has all
permissions that we expect majority of the caller-sensitive cases are in.
Is it for security? For example: one might think that creating an
anonymous class and holding a j.l.Class reference somewhere safe is
enough for safety, so the class itself could have public API. Now if
an untrusted callback object is passed to the code of such class and
it is invoked from within that code, the anonymous class can get
"revealed" to the untrusted code which can use it's public API to
invoke it. Are there any other implications of allowing non-system
code to get the caller?
It'd help if you can have a test case showing this to help the
discussion. However, restricting Reflection.getCallerClass be called by
the system code is no difference than defining a module-private class.
sun.reflect.* classes are private to the JDK implementation that are not
supported. If there were modules, applications would not have been able
to call it since sun.reflect would not be exported.
I would recommend to file a RFE and describe the use cases that require
an API to get the caller class or find caller's context so that we can
address it properly.
With this fix, the only way to call Reflection.getCallerClass must be
system code (in bootclasspath or extension library). As a workaround,
can you put it on the bootclasspath?
Mandy
