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
