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 <nicho...@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" <nicho...@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 < >> nicho...@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 <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<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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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
