I'm highly concerned about speed. The workaround in the logback pull-request has some benchmarks regarding alternative ways to get the required info and those are quite shocking:
> This solution was found from > http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflection > and 1,000,000 calls of all alternatives were measured as follows : > Reflection: 10.195 ms. > Current Thread StackTrace: 5886.964 ms. > Throwable StackTrace: 4700.073 ms. > SecurityManager: 1046.804 ms. The "best" solution using SecurityManager is still 100x slower than the original Reflection call while the Throwable solution is about 470x slower. D: This is a disaster, especially for our logging use-case with lots and lots of calls. This is also causing issues for Groovy http://jira.codehaus.org/browse/GROOVY-6279 but it's a lot less severe since the code won't get executed nearly as often as in our case. My hope was that, together, we could probably make a difference. I also thought that a bigger "audience" would increase the likeliness that some of us knows one of the responsible persons personally - which would probably have more impact than just a message on a mailing list. Anyway, I just subscribed to the core-list. Didn't even know about it. I hope that "open" in open-jdk isn't just PR… *sigh* Cheers, Jörn. On 27. Juli 2013 at 17:53:19, Ralph Goers (ralph.go...@dslextreme.com) wrote: Thanks Jörn, This was first reported to us in May in LOG4J2-245. Nick sent a message to the openjdk list at that time [1] but it seemed to be ignored. How would you propose we convince Oracle? To be honest, I would much prefer that I be able to get a stack trace from a Throwable that has the Class objects in it, instead of just the class names. Ralph [1] http://mail.openjdk.java.net/pipermail/java-se-8-spec-comments/2013-May/000014.html On Jul 26, 2013, at 2:43 AM, Jörn Huxhorn wrote: Hi everyone. I wanted to inform you about the following Logback issues since their root causes will also impact log4j: http://jira.qos.ch/browse/LOGBACK-885 https://github.com/qos-ch/logback/pull/136 In short: sun.reflect.Reflection.getCallerClass - changed behavior in Java7u25 since the stack frames have changed. http://bugs.sun.com/view_bug.do?bug_id=8016814 - will throw an UnsupportedOperationException in upcoming Java7u40. http://bugs.sun.com/view_bug.do?bug_id=8014925 - will be removed in Java8 with no replacement. http://bugs.sun.com/view_bug.do?bug_id=8020785 https://github.com/qos-ch/logback/pull/136 contains a way to get similar informations but, unfortunately, it is 100x slower than sun.reflect.Reflection.getCallerClass. http://bugs.sun.com/view_bug.do?bug_id=8014925 contains the following text: "JEP-176 proposes to remove sun.reflect.Reflection.getCallerClass(int) that has incompatibility concern since there are existing applications depending on this private API such as Oracle Diagnostic Logging and jidesoft library that breaks Oracle Primavera. The jdk part of JEP-176 has been backported to 7u25 but keep sun.reflect.Reflection.getCallerClass(int) as the mitigration plan (JDK-8014745) in 7u25. The following describes the transition plan to allow customers to migrate their applications away from this private API: 1. Disable sun.reflect.Reflection.getCallerClass(int) in 7u40 and provide a flag to re-enable it 2. Determine how this private API is being used and the use cases 3. Remove this private API if there is no valid use case or there is a proper replacement for it. Allow at least 2 CPU releases to allow customers to make appropriate change. So the earliest for the removal is 7u55. If there are valid use cases but no proper replacement, we may keep this private API in jdk7u for longer." I consider the use of this API in logging frameworks a very valid use case, especially since the only replacements available would have severe impact on the performance (other techniques like generating a Stacktrace via Throwable are even slower than the SecurityManager workaround in the pull request) - so we should probably all try to convince Oracle that a proper replacement, ideally in a public API, is needed. Cheers, Jörn. --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
