On 03/21/2013 07:11 PM, Mandy Chung wrote:
Hi Peter,
On 3/20/2013 2:33 AM, Peter Levart wrote:
Hi,
If I understand correctly, sun.reflect.Reflection.getCallerClass(int)
will not be usable by non-system code any more. I know it's not a
public API, but it's useful in some situations (not security-related)
and there's no public API for that functionality.
Do you have any example of existing use of Reflection.getCallerClass
to find immediate caller class? or does it need to walk the stack?
That'd be useful.
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...
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?
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?
Regards, Peter
Mandy
Regards, Peter
On 03/15/2013 04:31 AM, Christian Thalinger wrote:
[This is the HotSpot part of JEP 176]
http://cr.openjdk.java.net/~twisti/7198429
7198429: need checked categorization of caller-sensitive methods in
the JDK
Reviewed-by:
More information in JEP 176:
http://openjdk.java.net/jeps/176
src/share/vm/ci/ciMethod.cpp
src/share/vm/ci/ciMethod.hpp
src/share/vm/classfile/classFileParser.cpp
src/share/vm/classfile/classFileParser.hpp
src/share/vm/classfile/javaClasses.hpp
src/share/vm/classfile/systemDictionary.hpp
src/share/vm/classfile/vmSymbols.hpp
src/share/vm/oops/method.cpp
src/share/vm/oops/method.hpp
src/share/vm/opto/library_call.cpp
src/share/vm/prims/jvm.cpp
src/share/vm/prims/methodHandles.cpp
src/share/vm/prims/unsafe.cpp
src/share/vm/runtime/vframe.cpp
src/share/vm/runtime/vframe.hpp
