Perhaps it's time to release a beta or milestone or something? That way we can get some extra testing while we polish for 2.1 and hopefully get a release candidate out within, oh, let's say early October? Try to release 2.1 around the end of October/early November at the latest? I think we can probably do it, and I can RM again.
On 16 September 2014 01:15, Remko Popma <[email protected]> wrote: > 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 >>>>>> <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 >>>>>> >>>>>> >>>>>> -- >>>>>> Rgds,Rory O'Donnell >>>>>> Quality Engineering Manager >>>>>> Oracle EMEA , Dublin, Ireland >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> E-Mail: [email protected] | [email protected] >>>>> 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: [email protected] | [email protected] >>>> 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: [email protected] | [email protected] >> 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: [email protected] | [email protected] > 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 > > -- Matt Sicker <[email protected]>
