A beta sounds reasonable. Gary
On Tue, Sep 16, 2014 at 9:33 PM, Matt Sicker <[email protected]> wrote: > 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]> > -- 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
