I can confirm that the JDK team /has/ committed the change to restore 
Reflection.getCallerClass() in Java 7u40:

http://hg.openjdk.java.net/jdk7u/jdk7u40-dev/jdk/rev/244dbaeab45e

So, hurray! Lol.

Nick

On Aug 1, 2013, at 9:48 AM, Remko Popma wrote:

> O(n log n) would not be too bad, but what you're describing sounds more like 
> quadratic time!
> That's huge, Nick, congrats! That would mean a big speed improvement for the 
> location-based layout patterns in Log4j, they use 
> Thread.currentThread().getStackTrace() under the hood. Nice!
> 
> -Remko
> 
> From: Nick Williams <nicho...@nicholaswilliams.net>
> To: Log4J Developers List <log4j-dev@logging.apache.org> 
> Sent: Thursday, August 1, 2013 10:11 PM
> Subject: Re: Relfection.getCallerClass
> 
> Here's something interesting.
> 
> So the last method I had to write, StackTraceFrame.getStackTrace(Throwable), 
> I finished last night. It's the alternative to Throwable.getStackTrace(). 
> Instead of returning StackTraceElement[] (String for declaring class name), 
> it returns StackTraceFrame[] (Class<?> for declaring class). I expected this 
> to perform about the same or possibly even worse--boy was I wrong.
> 
> StackTraceFrame.getStackTrace(Throwable) consistently returns in half the 
> time that Throwable.getStackTrace() does. Looking at why that is, I found a 
> HUGE inefficiency in Throwable.getStackTrace(). 
> StackTraceFrame.getStackTrace(Throwable) walks the backtrace 1 time and runs 
> O(n), where n is the number of elements in the stack trace. 
> Throwable.getStackTrace() walks the back trace 1+(n/2) times (first it 
> measures the depth of the back trace in one native method call, then it gets 
> the elements by index in a native method call for each, looping up to that 
> index each time), for an O(nlogn) (I think) running time. Much worse.
> 
> So ... I improved Throwable.getStackTrace() and cut its running time in half 
> while I was at it. This also resulted in cutting 
> Thread.currentThread().getStackTrace()'s runtime in half. Think they'll 
> appreciate it? :-/
> 
> N
> 
> On Jul 31, 2013, at 4:42 PM, Paul Benedict wrote:
> 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019486.html
>> 
>> 
>> On Wed, Jul 31, 2013 at 4:40 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
>> Hm... do you have a URL for this ray of hope?
>> 
>> Gary
>> 
>> 
>> On Wed, Jul 31, 2013 at 5:34 PM, Paul Benedict <pbened...@apache.org> wrote:
>> Nevermind. I just found it. Lousy browser caching!
>> 
>> 
>> On Wed, Jul 31, 2013 at 4:33 PM, Paul Benedict <pbened...@apache.org> wrote:
>> Did you find this out on the OpenJDK mailing list? I can't find the 
>> information; I may have missed it.
>> 
>> 
>> On Wed, Jul 31, 2013 at 4:22 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
>> KA-POW! Well done, sir. How about we use your mug as the new logo? ;)
>> 
>> Gary
>> 
>> 
>> On Wed, Jul 31, 2013 at 4:47 PM, Nick Williams 
>> <nicho...@nicholaswilliams.net> wrote:
>> A PARTIAL VICTORY!
>> 
>> They've decide to revert the change to Reflection.getCallerClass for 7u40 
>> and the rest of 7. Woohoo!
>> 
>> "What will happen to this method in JDK 8 requires further thought."
>> 
>> Meanwhile, about 300 lines of Java and 1,000 lines of native code later, I'm 
>> about ready to submit my patch for a public API replacement in Java 8.
>> 
>> N
>> 
>> On Jul 29, 2013, at 8:39 AM, Gary Gregory wrote:
>> 
>>> What a mess :( it seem unlikely new APIs will be added to Java 8 to help 
>>> us, at least based on comments like 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019110.html
>>> 
>>> We might be left with documenting our side with "if you use features x and 
>>> y in this context then the speed will degrade to so and so, here is where 
>>> to ask Oracle to fix it: http:..."
>>> 
>>> Gary
>>> 
>>> On Jul 29, 2013, at 9:06, Nick Williams <nicho...@nicholaswilliams.net> 
>>> wrote:
>>> 
>>>> core-libs-dev
>> 
>> 
>> 
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>> 
>> 
>> 
>> -- 
>> Cheers,
>> Paul
>> 
>> 
>> 
>> -- 
>> Cheers,
>> Paul
>> 
>> 
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>> 
>> 
>> 
>> -- 
>> Cheers,
>> Paul
> 
> 
> 

Reply via email to