Jörn, Thanks for chiming in with that very useful information. I have passed it on to the core-libs-dev list.
I am doing my best to stay on top of these guys and try to get a solution agreed upon. The thing that concerns me is that we have already passed "Feature Complete" (which, of course, has different meanings to different people--features are still being developed, IMO), "Rampdown" has started, and the "Developer Preview" comes out September 5. That gives us 38 days to make this happen--not a lot of time in JDK land. The more people that subscribe to the list and vocalize about this issue (and, frankly, support the proposal I made Saturday), the more likely it is to happen. Nick On Jul 29, 2013, at 4:47 AM, Jörn Huxhorn wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
