JDK-8020968 : Provide a replacement for sun.reflect.Reflection.getCallerClass
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 8
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2013-07-20
  • Updated: 2015-11-24
  • Resolved: 2015-11-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Duplicate :  
JDK-8140450 - Implement JEP 259: Stack-Walking API
Relates :  
JDK-4851444 - (reflect) equivalent of sun.reflect.Reflection.getCallerClass should be exposed
Relates :  
JDK-8025799 - Restore sun.reflect.Reflection.getCallerClass(int) until a replacement API is provided
Relates :  
JDK-8043814 - JEP 259: Stack-Walking API
Relates :  
JDK-8020785 - caller-sensitive methods to skip dynamic generated frames and look up the true caller
Description
Class.getResource and ClassLoader.getResource are the APIs to obtain resource files associated with the class and/or classloader.  An example in the JDK: ResourceBundle.getBundle finds the caller's class and uses the caller class loader to load a resource bundle.  Libraries and frameworks such as Groovy, Log4j  need similar capability and also need the ability to filter their implementation classes.   Existing code has been using sun.reflect.Reflection.getCallerClass(int depth). 

There is no current way for libraries to support loading resource files on behalf of its immediate caller without explicitly passing the calling Class (for example localization data in GUI applications).  See discussion in [1].

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018353.html
Comments
As specified in JEP 259 [1], StackWalker::getCallerClass and StackWalker::walk provide the replacement for sun.reflect.Reflection.getCallerClass. This issue is closed as a duplicate of JDK-8140450 (the implementation for JEP 259). [1] http://openjdk.java.net/jeps/259
24-11-2015
There are some caller-sensitive methods that only call Reflection.getCallerClass under certain conditions (ex: if a SecurityManager is enabled). Could we somehow distinguish those cases or do you think always attaching the caller class would not affect performance too much?
25-02-2015
The best way to replace getCallerClass, in my opinion, would be to link caller-sensitive methods in such a way that the JVM adds the caller class as an extra argument: Foo { void bar() { Class.forName("Baz"); // links as Class.forName(_, Foo.class) } } class Class { static native @CallerSensitive Class forName(String x); // stub private static Class forName(String x, @CallerSensitive Class caller) { // target used by JVM ...do privileged stuff here... } } Note that the "real" entry point is private, so there is no way to spoof the API. The VM's link resolver is responsible for appending the extra argument. The existing "appendix" mechanism in the HotSpot JVM could be repurposed to perform this on-the-fly transformation.
22-02-2015
Tail call elimination requires a special kind of stack frame that saves stack-walk information that would otherwise be lost. Java's security model requires this. See discussion of "continuation marks" in http://mail.openjdk.java.net/pipermail/mlvm-dev/2013-July/005417.html and https://wiki.openjdk.java.net/display/mlvm/TailCalls#TailCalls-Stackwalkingandframeelision .
14-05-2014
Here's a JDK 8 motivation for doing a better job of filtering and controlling backtrace displays: http://www.takipiblog.com/2014/03/25/the-dark-side-of-lambda-expressions-in-java-8/ The gist of it is as we add more fancy language features on top of the JVM, there are more noisy internal frames in backtraces. This information is sometimes necessary, but it usually complicates the diagnosis of errors in the field.
26-03-2014
Existing frameworks have been using sun.reflect.Reflection.getCallerClass(int depth) to find the caller's class but it has been removed in jdk8 for JEP-176. JDK8 has to provide a replacement to support the use cases.
27-09-2013