It was later pointed out to me that I was emailing the wrong list for this kind of discussion. I've emailed the core libraries mailing list and several thorough discussions have resulted. I made just the suggestion you point out (get a stack trace from a Throwable that has Class objects in it) [1] [2] [3]. Discussions are still ongoing and hopefully we can convince them to do something. The more people we can have chiming in on these threads, the better.
Nick [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html, http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html On Jul 27, 2013, at 10:52 AM, Ralph Goers 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: [email protected] >> For additional commands, e-mail: [email protected] >> >
