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

Reply via email to