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 <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 >>>>>>> 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 >>>> >>> >>
smime.p7s
Description: S/MIME cryptographic signature
