[PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

[Ralph Goers]

On Sep 18, 2013, at 9:30 AM, Nick Williams wrote:

> 
> On Sep 3, 2013, at 7:02 PM, Mandy Chung wrote:
> 
> 
>> So for log4j to work with security manager installed, it would have torequire the application to grant certain permissions - can you confirm?
> 
> Maybe one of the other Log4j guys listening in can provide input on this. Ralph? I'm relatively new to the Log4j team (just joined in last 6 months). Personally, I've never heard anyone complain about having issues with the SecurityManager. However, Log4j 1 did not use getCallerClass, and many users are still on that version. Log4j 2 started using getCallerClass.

Log4j 2 is relatively new. However, the feature of adding the jar and version when printing the stack trace is copied from Logback, which has been doing this for years and has a fairly large user base at this point.  Only recently was http://jira.qos.ch/browse/LOGBACK-866 created and it still has no comments on the issue, no votes and only 1 watcher (presumably the person who created the issue). http://jira.qos.ch/browse/LOGBACK-472 was also open for this but it was closed as won't fix as it added too much overhead. Again, that issue has no votes and only the single watcher. So almost no one is having problems with this.

Again, the two use cases we are trying to solve for are:
1. Print the stack trace as shown at http://macstrac.blogspot.com/2008/09/better-stack-traces-in-java-with-log4j.html. Both Log4j 2 and Logback are doing this. If the JDK simply had a 
        public void printExtendedStackTrace(OutputStream) 
or 
        public StackTraceFrame[] getStackTraceFrames() 
methods where all the information necessary to format the stack trace as shown in the link is present our needs would be met on this.
2. Determine the ClassLoader associated with the parent of Class somewhere above the current method in the call stack.  Again, something like
        public ClassLoader getParentClassLoader(String className) 
where we provide a fully qualified class name and the ClassLoader of the Class that called that Class would meet our needs. (Note that in this case the FQCN class may call itself so those calls are skipped to find the parent).

Because the JDK doesn't provide these methods we are basically trying to implement them ourselves and thus need the more basic functionality Nick has been proposing.  I can't say how well any of the proposals perform, but I would think encapsulating these in the JDK would alleviate many of the security concerns.

Ralph