Perhaps the label "Experimental" caused a misunderstanding. I fully intend to do my due diligence and ensure this is properly documented and has JUnit tests that all pass on Windows, Solaris and Linux. So this appender is no more and no less experimental than our new JUL bridge or the new GELF layout.
You'll remember that I initially marked the RandomAccessFile appenders as "Experimental" in the documentation. This is not because they were of lesser quality in any way, it was just an indication to users that these appenders did not have the same track record that the File appenders had. We removed that label after a number of releases when we felt that they had built enough of a track record and the "Experimental" label was no longer useful or correct. My intention is to do the same with the MemoryMappedFile appender. On the one hand this appender promises better performance, but users should be aware that they are a new addition and they should do their own due diligence. I expect to finish the work for MemoryMappedFileAppender by the end of next week. I hope that is soon enough to be able to include it in 2.1. Speaking of JUL, we should update this image: http://logging.apache.org/log4j/2.x/faq.html#which_jars Regards, -Remko Sent from my iPhone > On 2014/09/16, at 11:26, Gary Gregory <[email protected]> wrote: > > I do not think we can or should include "experimental code" unless it is in a > separate module with flashing red lights. At that point, we might as well > leave it in git, with a pointer from our docs. But even experimental code > needs proper documentation and I personally barely have time to do what I am > doing... > > 2.1 has a good chunk of new features already, let's not try and stuff more in > there. I'd like to stabilize what we have now, release 2.1, and continue on > to 2.2 and beyond. If we RERO, there is no need to try to stuff features > under the wire. > > I think that if we focus on 2.1 now, then you can ask the ML to pitch in this > new feature for 2.2. This would let more focus be on the new code and another > feature to look forward to in 2.2. I think we are doing well now and there is > no reason we cannot keep on RERO. > > Are we done with the clock business? I think someone wanted to run some > benchmarks and possibly deprecate some code. Once that is done, I think we > can start 2.1. > > Gary > >> On Mon, Sep 15, 2014 at 9:55 PM, Remko Popma <[email protected]> wrote: >> I'd like to include it in 2.1 as an experimental feature to get some early >> user feedback. But I don't want to hold everyone up either. >> Do we have a release date in mind? >> >> Remko >> >> Sent from my iPhone >> >>> On 2014/09/16, at 9:07, Gary Gregory <[email protected]> wrote: >>> >>> On deck for 2.2 perhaps? >>> >>> Gary >>> >>> >>> -------- Original message -------- >>> From: Remko Popma >>> Date:09/15/2014 19:28 (GMT-05:00) >>> To: Log4J Developers List >>> Subject: Re: Analysis of apache-maven-3.2.3's dependency on JDK-Internal >>> APIs >>> >>> (Dropped Oracle people from recipients) >>> >>> MemoryMappedFileAppender is still in progress in a local branch. I haven't >>> been able to spend much time on it yet. I'll push the branch when I get >>> some unit tests working. >>> >>> Sent from my iPhone >>> >>>> On 2014/09/15, at 23:47, Gary Gregory <[email protected]> wrote: >>>> >>>>> On Mon, Sep 15, 2014 at 10:35 AM, Remko Popma <[email protected]> >>>>> wrote: >>>>> One more: the lack of a public API to unmap a memory mapped file means we >>>>> may need to use sun.misc.Cleaner to implement rollover for the upcoming >>>>> MemoryMappedFileAppender. Still investigating this... >>>> >>>> Is the MemoryMappedFileAppender on a branch? I do not see it in master... >>>> >>>> Gary >>>> >>>>> >>>>> >>>>>> On Monday, September 15, 2014, Remko Popma <[email protected]> wrote: >>>>>> And separately from the caller class issue, log4j2 async loggers depend >>>>>> on the LMAX Disruptor, which makes heavy use of sun.misc.Unsafe, I think >>>>>> mostly for concurrency primitives. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On 2014/09/15, at 22:59, Gary Gregory <[email protected]> wrote: >>>>>>> >>>>>>> If you download the source zip or git clone, please see the class >>>>>>> org.apache.logging.log4j.core.impl.ReflectiveCallerClassUtility. >>>>>>> >>>>>>> Gary >>>>>>> >>>>>>>> On Mon, Sep 15, 2014 at 9:56 AM, Gary Gregory <[email protected]> >>>>>>>> wrote: >>>>>>>> Ah, let's see... >>>>>>>> >>>>>>>> These links discuss our problems: >>>>>>>> >>>>>>>> - https://issues.apache.org/jira/browse/LOG4J2-245 >>>>>>>> - https://issues.apache.org/jira/browse/LOG4J2-809 >>>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>>> On Mon, Sep 15, 2014 at 8:54 AM, Rory O'Donnell Oracle, Dublin >>>>>>>>> Ireland <[email protected]> wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Can I point you to the following paragraphs below. >>>>>>>>> >>>>>>>>> "For anything where your migration path is unclear, I would >>>>>>>>> appreciate comments on the JDK-internal API usage patterns in the >>>>>>>>> attached jdeps report, in particular comments elaborating on the >>>>>>>>> rationale for them either to me or on this list. >>>>>>>>> >>>>>>>>> Finding suitable replacements for unsupported interfaces is not >>>>>>>>> always straightforward, which is why I am reaching out to you early >>>>>>>>> in the JDK 9 development cycle so you can give feedback about new >>>>>>>>> APIs that may be needed to facilitate this exercise." >>>>>>>>> >>>>>>>>> Please feel free to send me your comments, explanations etc on why >>>>>>>>> you are using JDK-internal APIs ? >>>>>>>>> >>>>>>>>> Rgds,Rory >>>>>>>>> >>>>>>>>> P.S. I haven't gotten round to running the tool on log4j yet. >>>>>>>>> >>>>>>>>>> On 15/09/2014 12:52, Gary Gregory wrote: >>>>>>>>>> Sad, isn't it? Like going to the Dr. and he tells you you've got >>>>>>>>>> something he can't help you with! >>>>>>>>>> >>>>>>>>>> Gary >>>>>>>>>> >>>>>>>>>>> On Mon, Sep 15, 2014 at 7:33 AM, Ralph Goers <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> Yes, but if you follow the link you will notice that there is still >>>>>>>>>>> no replacement. >>>>>>>>>>> >>>>>>>>>>> Sent from my iPad >>>>>>>>>>> >>>>>>>>>>> > On Sep 15, 2014, at 3:55 AM, Gary Gregory >>>>>>>>>>> > <[email protected]> wrote: >>>>>>>>>>> > >>>>>>>>>>> > This is of interest to use and our call stack query hacks, isn't >>>>>>>>>>> > kt? >>>>>>>>>>> > >>>>>>>>>>> > Gary >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > -------- Original message -------- >>>>>>>>>>> > From: "Rory O'Donnell Oracle, Dublin Ireland" >>>>>>>>>>> > Date:09/15/2014 06:17 (GMT-05:00) >>>>>>>>>>> > To: [email protected] >>>>>>>>>>> > Cc: Maven Developers List ,Balchandra Vaidya ,Dalibor Topic >>>>>>>>>>> > Subject: Re: Analysis of apache-maven-3.2.3's dependency on >>>>>>>>>>> > JDK-Internal APIs >>>>>>>>>>> > >>>>>>>>>>> > Hi Stephen, >>>>>>>>>>> > >>>>>>>>>>> > One more time, hope this is ok. >>>>>>>>>>> > >>>>>>>>>>> > Rgds,Rory >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >Â Â JDK Internal API Usage Report for apache-maven-3.2.3 >>>>>>>>>>> > >>>>>>>>>>> > The OpenJDK Quality Outreach campaign has run a compatibility >>>>>>>>>>> > report to >>>>>>>>>>> > identify usage of JDK-internal APIs. Usage of these JDK-internal >>>>>>>>>>> > APIs >>>>>>>>>>> > could pose compatibility issues, as the Java team explained in >>>>>>>>>>> > 1996 >>>>>>>>>>> > <http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html>. >>>>>>>>>>> > We have created this report to help you identify which >>>>>>>>>>> > JDK-internal APIs >>>>>>>>>>> > your project uses, what to use instead, and where those changes >>>>>>>>>>> > should >>>>>>>>>>> > go. Making these changes will improve your compatibility, and in >>>>>>>>>>> > some >>>>>>>>>>> > cases give better performance. >>>>>>>>>>> > >>>>>>>>>>> > Migrating away from the JDK-internal APIs now will give your team >>>>>>>>>>> > adequate time for testing before the release of JDK 9. If you are >>>>>>>>>>> > unable >>>>>>>>>>> > to migrate away from an internal API, please provide us with an >>>>>>>>>>> > explanation below to help us understand it better. >>>>>>>>>>> > As a reminder, >>>>>>>>>>> > supported APIs are determined by the OpenJDK's Java >>>>>>>>>>> > Community Process >>>>>>>>>>> > and not by Oracle. >>>>>>>>>>> > >>>>>>>>>>> > This report was generated by jdeps >>>>>>>>>>> > <http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html> >>>>>>>>>>> > through static analysis of artifacts: it does not identify any >>>>>>>>>>> > usage of >>>>>>>>>>> > those APIs through reflection or dynamic bytecode. You may also >>>>>>>>>>> > run >>>>>>>>>>> > jdeps on your own >>>>>>>>>>> > <https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool> >>>>>>>>>>> > if you would prefer. >>>>>>>>>>> > >>>>>>>>>>> > Summary of the analysis of the jar files within >>>>>>>>>>> > apache-maven-3.2.3: >>>>>>>>>>> > >>>>>>>>>>> >Â Â * Numer of jar files depending on JDK-internal APIs: 1 >>>>>>>>>>> >Â Â * Internal APIs that have known replacements: 0 >>>>>>>>>>> >Â Â * Internal APIs that your team should migrate away: 1 >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >Â Â Â Â APIs that have known replacements >>>>>>>>>>> >Â Â Â Â >>>>>>>>>>> ><https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool>: >>>>>>>>>>> > >>>>>>>>>>> > ID Replace Usage of With Inside >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >Â Â Â Â JDK-internal APIs without supported replacements: >>>>>>>>>>> > >>>>>>>>>>> > ID Internal APIs (do not use) Used by >>>>>>>>>>> > 1 sun.misc.Unsafe >>>>>>>>>>> > >>>>>>>>>>> >Â Â * lib/guava-14.0.1.jar >>>>>>>>>>> > >>>>>>>>>>> > Explanation... >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >Â Â Â Â Identify External Replacements >>>>>>>>>>> > >>>>>>>>>>> > You should use a separate third-party library that performs this >>>>>>>>>>> > functionality. >>>>>>>>>>> > >>>>>>>>>>> > ID Internal API (grouped by package) Used By Identify External >>>>>>>>>>> > Replacement >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > On 15/09/2014 10:22, Stephen Connolly wrote: >>>>>>>>>>> > > I think the mailing list stripped the attachment >>>>>>>>>>> > > >>>>>>>>>>> > > On Monday, 15 September 2014, Rory O'Donnell Oracle, Dublin >>>>>>>>>>> > > Ireland < >>>>>>>>>>> > > [email protected]> wrote: >>>>>>>>>>> > > >>>>>>>>>>> > >> Hi Robert,Kristian, >>>>>>>>>>> > >> >>>>>>>>>>> > >> As part of the preparations for JDK 9, Oracle's engineers have >>>>>>>>>>> > >> been >>>>>>>>>>> > >> analyzing open source projects like yours to understand usage. >>>>>>>>>>> > >> One area of concern involves identifying compatibility >>>>>>>>>>> > >> problems, such as >>>>>>>>>>> > >> reliance on JDK-internal APIs. >>>>>>>>>>> > >> >>>>>>>>>>> > >> Our engineers have already prepared guidance on migrating some >>>>>>>>>>> > >> of the more >>>>>>>>>>> > >> common usage patterns of JDK-internal APIs to supported public >>>>>>>>>>> > >> interfaces. >>>>>>>>>>> > >> The list is on the OpenJDK wiki [0], along with instructions >>>>>>>>>>> > >> on how to run >>>>>>>>>>> > >> the jdeps analysis tool yourself . >>>>>>>>>>> > >> >>>>>>>>>>> > >> As part of the ongoing development of JDK 9, I >>>>>>>>>>> > >> would like to encourage >>>>>>>>>>> > >> migration from JDK-internal APIs towards the supported Java >>>>>>>>>>> > >> APIs. I have >>>>>>>>>>> > >> prepared a report for your project release apache-maven-3.2.3 >>>>>>>>>>> > >> based on the >>>>>>>>>>> > >> jdeps output. >>>>>>>>>>> > >> >>>>>>>>>>> > >> The report is attached to this e-mail. >>>>>>>>>>> > >> >>>>>>>>>>> > >> For anything where your migration path is unclear, I would >>>>>>>>>>> > >> appreciate >>>>>>>>>>> > >> comments on the JDK-internal API usage patterns in the >>>>>>>>>>> > >> attached jdeps >>>>>>>>>>> > >> report - in particular comments elaborating on the rationale >>>>>>>>>>> > >> for them - >>>>>>>>>>> > >> either to me or on this list. >>>>>>>>>>> > >> >>>>>>>>>>> > >> Finding suitable replacements for unsupported interfaces is >>>>>>>>>>> > >> not always >>>>>>>>>>> > >> straightforward, which is why I am reaching out to you early >>>>>>>>>>> > >> in the JDK 9 >>>>>>>>>>> > >> development cycle so you can give feedback about new APIs that >>>>>>>>>>> > >> may be >>>>>>>>>>> > >> needed to facilitate this exercise. >>>>>>>>>>> > >> >>>>>>>>>>> > >> Thank you in advance for any efforts and feedback helping us >>>>>>>>>>> > >> make JDK 9 >>>>>>>>>>> > >> better. >>>>>>>>>>> > >> >>>>>>>>>>> > >> Rgds,Rory >>>>>>>>>>> > >> >>>>>>>>>>> > >> [0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+ >>>>>>>>>>> > >> Analysis+Tool >>>>>>>>>>> > >> >>>>>>>>>>> > >> -- >>>>>>>>>>> > >> Rgds,Rory O'Donnell >>>>>>>>>>> > >> Quality Engineering Manager >>>>>>>>>>> > >> Oracle EMEA , Dublin, Ireland >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >>>>>>>>>>> > -- >>>>>>>>>>> > Rgds,Rory O'Donnell >>>>>>>>>>> > Quality Engineering Manager >>>>>>>>>>> > Oracle EMEA , Dublin, Ireland >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> E-Mail: [email protected] | [email protected] >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Rgds,Rory O'Donnell >>>>>>>>> Quality Engineering Manager >>>>>>>>> Oracle EMEA , Dublin, Ireland >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> E-Mail: [email protected] | [email protected] >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> E-Mail: [email protected] | [email protected] >>>>>>> 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 >>>> >>>> >>>> >>>> -- >>>> E-Mail: [email protected] | [email protected] >>>> 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 > > > > -- > E-Mail: [email protected] | [email protected] > 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
