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 >>> 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 >> >> >> > > > > > -- > 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
