You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Nick Williams <ni...@nicholaswilliams.net> on 2013/09/01 10:18:54 UTC

Re: Relfection.getCallerClass

I have submitted my patch to add a public API for getCallerClass to the JDK mailing list:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020477.html

I appreciate anyone who can support it verbally on the list, but of course the most critical test is whether I can get a committer to sponsor my change.

Nick

On Aug 2, 2013, at 7:59 PM, Paul Benedict wrote:

> Wow! I totally forgot about their insane numbering system. All this time, I thought version 40 was  many months in the future.
> 
> On Aug 2, 2013 6:34 PM, "Nick Williams" <ni...@nicholaswilliams.net> wrote:
> I HATE their new numbering system. HATE.
> 
> ABHOR.
> 
> 7u40 comes after 7u25. So, yes, it's the next one. Set to release mid-September.
> 
> Nick
> 
> On Aug 2, 2013, at 4:59 PM, Gary Gregory wrote:
> 
>> On Thu, Aug 1, 2013 at 10:01 PM, Nick Williams <ni...@nicholaswilliams.net> wrote:
>> 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.
>> 
>> With Oracle's new demented numbering scheme, how can you tell when this version is coming? ;) Is that the next Java 7 or the one after that?
>> 
>> Gary
>> 
>> 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 <ni...@nicholaswilliams.net>
>>> To: Log4J Developers List <lo...@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 <ga...@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 <pb...@apache.org> wrote:
>>>> Nevermind. I just found it. Lousy browser caching!
>>>> 
>>>> 
>>>> On Wed, Jul 31, 2013 at 4:33 PM, Paul Benedict <pb...@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 <ga...@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 <ni...@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 <ni...@nicholaswilliams.net> wrote:
>>>>> 
>>>>>> core-libs-dev
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
>> -- 
>> E-Mail: garydgregory@gmail.com | ggregory@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
> 


Re: Relfection.getCallerClass

Posted by Nick Williams <ni...@nicholaswilliams.net>.
Guys the discussion is _not_ going well on the mailing list. They have designed a bloody horrible API that reeks of poor performance and near-impossibility to use if your code isn't compiled with Java 8. We need some devs to get over there and comment.

Nick

On Sep 3, 2013, at 9:45 PM, Ralph Goers wrote:

> From my reading it sounds like they will definitely support the usage for formatting Throwables but may not for what ClassLoaderContextSelector requires. 
> 
> Ralph
> 
> Sent from my iPad
> 
> On Sep 3, 2013, at 6:40 PM, Nick Williams <ni...@nicholaswilliams.net> wrote:
> 
>> Good news! A Java committer has agreed to take on the commit and sponsor a public API replacement for getCallerClass. It sounds like there will be significant (even drastic) changes from my patch, but there's going to be /something/. *sigh*
>> 
>> So. Much. Work...
>> 
>> Nick
>> 
>> On Sep 1, 2013, at 3:18 AM, Nick Williams wrote:
>> 
>>> I have submitted my patch to add a public API for getCallerClass to the JDK mailing list:
>>> 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020477.html
>>> 
>>> I appreciate anyone who can support it verbally on the list, but of course the most critical test is whether I can get a committer to sponsor my change.
>>> 
>>> Nick
>>> 
>>> On Aug 2, 2013, at 7:59 PM, Paul Benedict wrote:
>>> 
>>>> Wow! I totally forgot about their insane numbering system. All this time, I thought version 40 was  many months in the future.
>>>> 
>>>> On Aug 2, 2013 6:34 PM, "Nick Williams" <ni...@nicholaswilliams.net> wrote:
>>>> I HATE their new numbering system. HATE.
>>>> 
>>>> ABHOR.
>>>> 
>>>> 7u40 comes after 7u25. So, yes, it's the next one. Set to release mid-September.
>>>> 
>>>> Nick
>>>> 
>>>> On Aug 2, 2013, at 4:59 PM, Gary Gregory wrote:
>>>> 
>>>>> On Thu, Aug 1, 2013 at 10:01 PM, Nick Williams <ni...@nicholaswilliams.net> wrote:
>>>>> 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.
>>>>> 
>>>>> With Oracle's new demented numbering scheme, how can you tell when this version is coming? ;) Is that the next Java 7 or the one after that?
>>>>> 
>>>>> Gary
>>>>> 
>>>>> 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 <ni...@nicholaswilliams.net>
>>>>>> To: Log4J Developers List <lo...@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 <ga...@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 <pb...@apache.org> wrote:
>>>>>>> Nevermind. I just found it. Lousy browser caching!
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Jul 31, 2013 at 4:33 PM, Paul Benedict <pb...@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 <ga...@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 <ni...@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 <ni...@nicholaswilliams.net> wrote:
>>>>>>>> 
>>>>>>>>> core-libs-dev
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> E-Mail: garydgregory@gmail.com | ggregory@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
>>>> 
>>> 
>> 


Re: Relfection.getCallerClass

Posted by Ralph Goers <rg...@apache.org>.
From my reading it sounds like they will definitely support the usage for formatting Throwables but may not for what ClassLoaderContextSelector requires. 

Ralph

Sent from my iPad

On Sep 3, 2013, at 6:40 PM, Nick Williams <ni...@nicholaswilliams.net> wrote:

> Good news! A Java committer has agreed to take on the commit and sponsor a public API replacement for getCallerClass. It sounds like there will be significant (even drastic) changes from my patch, but there's going to be /something/. *sigh*
> 
> So. Much. Work...
> 
> Nick
> 
> On Sep 1, 2013, at 3:18 AM, Nick Williams wrote:
> 
>> I have submitted my patch to add a public API for getCallerClass to the JDK mailing list:
>> 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020477.html
>> 
>> I appreciate anyone who can support it verbally on the list, but of course the most critical test is whether I can get a committer to sponsor my change.
>> 
>> Nick
>> 
>> On Aug 2, 2013, at 7:59 PM, Paul Benedict wrote:
>> 
>>> Wow! I totally forgot about their insane numbering system. All this time, I thought version 40 was  many months in the future.
>>> 
>>> On Aug 2, 2013 6:34 PM, "Nick Williams" <ni...@nicholaswilliams.net> wrote:
>>>> I HATE their new numbering system. HATE.
>>>> 
>>>> ABHOR.
>>>> 
>>>> 7u40 comes after 7u25. So, yes, it's the next one. Set to release mid-September.
>>>> 
>>>> Nick
>>>> 
>>>> On Aug 2, 2013, at 4:59 PM, Gary Gregory wrote:
>>>> 
>>>>> On Thu, Aug 1, 2013 at 10:01 PM, Nick Williams <ni...@nicholaswilliams.net> wrote:
>>>>>> 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.
>>>>> 
>>>>> With Oracle's new demented numbering scheme, how can you tell when this version is coming? ;) Is that the next Java 7 or the one after that?
>>>>> 
>>>>> Gary
>>>>>> 
>>>>>> 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 <ni...@nicholaswilliams.net>
>>>>>>> To: Log4J Developers List <lo...@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 <ga...@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 <pb...@apache.org> wrote:
>>>>>>>> Nevermind. I just found it. Lousy browser caching!
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Wed, Jul 31, 2013 at 4:33 PM, Paul Benedict <pb...@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 <ga...@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 <ni...@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 <ni...@nicholaswilliams.net> wrote:
>>>>>>>>> 
>>>>>>>>>> core-libs-dev
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> E-Mail: garydgregory@gmail.com | ggregory@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
> 

Re: Relfection.getCallerClass

Posted by Gary Gregory <ga...@gmail.com>.
Nice push Nick! Did you get any details on what the security issues are? I
do recall reading about that on the ML thread you referred.

Gary


On Tue, Sep 3, 2013 at 8:40 PM, Nick Williams <nicholas@nicholaswilliams.net
> wrote:

> Good news! A Java committer has agreed to take on the commit and sponsor a
> public API replacement for getCallerClass. It sounds like there will be
> significant (even drastic) changes from my patch, but there's going to be
> /something/. *sigh*
>
> So. Much. Work...
>
> Nick
>
>
> On Sep 1, 2013, at 3:18 AM, Nick Williams wrote:
>
> I have submitted my patch to add a public API for getCallerClass to the
> JDK mailing list:
>
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020477.html
>
> I appreciate anyone who can support it verbally on the list, but of course
> the most critical test is whether I can get a committer to sponsor my
> change.
>
> Nick
>
> On Aug 2, 2013, at 7:59 PM, Paul Benedict wrote:
>
> Wow! I totally forgot about their insane numbering system. All this time,
> I thought version 40 was  many months in the future.
> On Aug 2, 2013 6:34 PM, "Nick Williams" <ni...@nicholaswilliams.net>
> wrote:
>
>> I HATE their new numbering system. HATE.
>>
>> ABHOR.
>>
>> 7u40 comes after 7u25. So, yes, it's the next one. Set to release
>> mid-September.
>>
>> Nick
>>
>> On Aug 2, 2013, at 4:59 PM, Gary Gregory wrote:
>>
>> On Thu, Aug 1, 2013 at 10:01 PM, Nick Williams <
>> nicholas@nicholaswilliams.net> wrote:
>>
>>> 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.
>>>
>>
>> With Oracle's new demented numbering scheme, how can you tell when this
>> version is coming? ;) Is that the next Java 7 or the one after that?
>>
>> Gary
>>
>>>
>>> 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 <ni...@nicholaswilliams.net>
>>> *To:* Log4J Developers List <lo...@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 <ga...@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 <pb...@apache.org>wrote:
>>>
>>> Nevermind. I just found it. Lousy browser caching!
>>>
>>>
>>> On Wed, Jul 31, 2013 at 4:33 PM, Paul Benedict <pb...@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 <ga...@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 <
>>> nicholas@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 <ni...@nicholaswilliams.net>
>>> wrote:
>>>
>>> core-libs-dev
>>>
>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Paul
>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Paul
>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Paul
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Relfection.getCallerClass

Posted by Nick Williams <ni...@nicholaswilliams.net>.
Good news! A Java committer has agreed to take on the commit and sponsor a public API replacement for getCallerClass. It sounds like there will be significant (even drastic) changes from my patch, but there's going to be /something/. *sigh*

So. Much. Work...

Nick

On Sep 1, 2013, at 3:18 AM, Nick Williams wrote:

> I have submitted my patch to add a public API for getCallerClass to the JDK mailing list:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020477.html
> 
> I appreciate anyone who can support it verbally on the list, but of course the most critical test is whether I can get a committer to sponsor my change.
> 
> Nick
> 
> On Aug 2, 2013, at 7:59 PM, Paul Benedict wrote:
> 
>> Wow! I totally forgot about their insane numbering system. All this time, I thought version 40 was  many months in the future.
>> 
>> On Aug 2, 2013 6:34 PM, "Nick Williams" <ni...@nicholaswilliams.net> wrote:
>> I HATE their new numbering system. HATE.
>> 
>> ABHOR.
>> 
>> 7u40 comes after 7u25. So, yes, it's the next one. Set to release mid-September.
>> 
>> Nick
>> 
>> On Aug 2, 2013, at 4:59 PM, Gary Gregory wrote:
>> 
>>> On Thu, Aug 1, 2013 at 10:01 PM, Nick Williams <ni...@nicholaswilliams.net> wrote:
>>> 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.
>>> 
>>> With Oracle's new demented numbering scheme, how can you tell when this version is coming? ;) Is that the next Java 7 or the one after that?
>>> 
>>> Gary
>>> 
>>> 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 <ni...@nicholaswilliams.net>
>>>> To: Log4J Developers List <lo...@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 <ga...@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 <pb...@apache.org> wrote:
>>>>> Nevermind. I just found it. Lousy browser caching!
>>>>> 
>>>>> 
>>>>> On Wed, Jul 31, 2013 at 4:33 PM, Paul Benedict <pb...@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 <ga...@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 <ni...@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 <ni...@nicholaswilliams.net> wrote:
>>>>>> 
>>>>>>> core-libs-dev
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> E-Mail: garydgregory@gmail.com | ggregory@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
>> 
>