Gary, you are missing the point. We are not "going" to java 9. We will be providing support for it. There was nothing we had to do to support java 8, but there are changes that must be made, like using StackWalker and being modularized, for Log4J to be usable by everyone who moves to java 9. If we don't make these changes now we are basically saying Log4J cannot be used in java 9. But we don't have to stop supporting java 7 and 8 to do that.
Ralph > On Apr 23, 2017, at 3:47 PM, Gary Gregory <[email protected]> wrote: > > Howdy, > > While this is all possible, I do not like the idea of jumping from Java 7 > to 9. I would rather we go to Java 8 soon and take advantage of the whole > platform cleanly, even if in the case of Instant is a convenience as you > call it. That makes it then less of a difference when we do go to Java 9 > eventually. > > Gary > >> On Apr 21, 2017 8:51 PM, "Matt Sicker" <[email protected]> wrote: >> >> Using java.time is just a convenience compared to our FastDateTime commons >> classes anyways. Lambdas are supportable through regular single-method >> interfaces. As Mikael pointed out, though, default interface methods would >> be tremendously useful for log4j-api. Alternatively, we could create some >> abstract base classes where missing and mark the interfaces as changeable. >> With that pattern, interfaces are for users of the the class, while the >> abstract classes are for implementers of the class. >> >>> On 21 April 2017 at 11:58, Ralph Goers <[email protected]> wrote: >>> >>> How does that benefit a user of Log4j in Java 8. In Java 9 it is >> certainly >>> a benefit if it can provide microsecond granularity. >>> >>> Ralph >>> >>>> On Apr 21, 2017, at 9:21 AM, Gary Gregory <[email protected]> >>> wrote: >>>> >>>> On Apr 21, 2017 7:06 AM, "Ralph Goers" <[email protected]> >>> wrote: >>>> >>>> What features in Java 8 do we need to take advantage of that we haven't >>>> already? >>>> >>>> >>>> How about java.time? Using an Instant instead of a long to timestamp an >>>> event? >>>> >>>> Gary >>>> >>>> >>>> Sent from my iPhone >>>> >>>>> On Apr 21, 2017, at 12:44 AM, Mikael Ståldal < >> [email protected] >>>> >>>> wrote: >>>>> >>>>> I also have a feeling that we focus too much on Java 9 and not enough >> on >>>>> Java 8. >>>>> >>>>>> On Thu, Apr 20, 2017 at 5:08 AM, Remko Popma <[email protected]> >>>> wrote: >>>>>> >>>>>> I agree with Ralph that there are many environments that can't >> upgrade >>>>>> their Java version but still want to use the nice features Log4j2 >>> offers. >>>>>> I've also worked in such environments. I would prefer to support >> older >>>>>> versions as long as possible. (What that means concretely is open for >>>>>> discussion.) :-) >>>>>> >>>>>> Remko >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Apr 20, 2017, at 11:32, Matt Sicker <[email protected]> wrote: >>>>>>> >>>>>>> I just want a plan for when we upgrade. Log4j is such low level code >>>> that >>>>>>> it's not a big deal to me for using Java 8 syntax. I'm mostly >>> interested >>>>>> in >>>>>>> supporting the v8 APIs, and Spring has an interesting way of doing >>> that. >>>>>>> >>>>>>> On Wed, Apr 19, 2017 at 18:01, Ralph Goers < >>> [email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> I can’t agree to that. See >>>>>>>> https://spring.io/blog/2015/04/01/ongoing-support-for- >>>>>> java-7-and-even-java-6 >>>>>>>> < >>>>>>>> https://spring.io/blog/2015/04/01/ongoing-support-for- >>>>>> java-7-and-even-java-6> >>>>>>>> for Spring’s perspective on this. Log4j is such a fundamental >>> framework >>>>>>>> that, while we need to support new features in the latest JDK, we >>> also >>>>>> need >>>>>>>> to continue to support older Java releases for as long as is >>>>>> reasonable. I >>>>>>>> know a few of you would always like to be on more current JDKs, >> but I >>>>>> have >>>>>>>> worked in environments that are very slow to upgrade. In fact, we >>> just >>>>>> got >>>>>>>> a question from someone who is still on 2.2 because they are stuck >> on >>>>>> Java >>>>>>>> 6. >>>>>>>> >>>>>>>> That said, I am all for discussing what a reasonable timeframe is. >> I >>>>>> don’t >>>>>>>> think 2022 makes any more sense than dropping support in July. >>> Whatever >>>>>> we >>>>>>>> decide we should give users at least 6 months notice. >>>>>>>> >>>>>>>> Ralph >>>>>>>> >>>>>>>>> On Apr 19, 2017, at 5:18 PM, Matt Sicker <[email protected]> >> wrote: >>>>>>>>> >>>>>>>>> Roadmap wise, I think dropping support for Java 7 when Java 9 >> comes >>>> out >>>>>>>>> might make sense, though that also depends on where we are >>>> release-wise >>>>>>>> at >>>>>>>>> the time. In the meantime, modularizing the core more and breaking >>>> into >>>>>>>>> more subprojects may help find any desires for a semantically >>> breaking >>>>>>>>> change for version 3. I don't really see that happening with the >>> API, >>>>>> and >>>>>>>>> I'm not so sure how important it'd be in Core, though they could >> be >>>>>>>>> versioned separately in theory. >>>>>>>>> >>>>>>>>>> On 19 April 2017 at 12:59, Gary Gregory <[email protected]> >>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On Wed, Apr 19, 2017 at 10:23 AM, Ralph Goers < >>>>>>>> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I have no idea what your versions are, but 2.9 is going to >> contain >>>>>> the >>>>>>>>>>> first support for Java 9, but it will continue to support Java >>> 7. I >>>>>> am >>>>>>>>>>> assuming your numbering scheme is about what version ONLY >>> supports a >>>>>>>>>>> particular Java release? I am not in favor of that. With >> semantic >>>>>>>>>>> versioning the number should only change when the API changes. >>> Just >>>>>> as >>>>>>>>>> we >>>>>>>>>>> did when we moved from Java 6 to Java 7 we don’t have to >> increment >>>>>> the >>>>>>>>>>> project version number. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Yeah, that's why I said I was not in love with the version >>> proposal. >>>>>>>> What I >>>>>>>>>> am really after is a road-map to give our users an idea of what >> to >>>>>>>> expect. >>>>>>>>>> I suspect a wiki page might be best for that. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I am not worried about hanging on to Java 7 “too long”, so long >> as >>>> we >>>>>>>>>>> continue to find ways to support new Java features. >>>>>>>>>>> >>>>>>>>>>> I suspect you still have not looked at my branch >>>>>>>> “java9NoMultiRelease”. I >>>>>>>>>>> have been planning on merging that to master but just haven’t >> find >>>>>> the >>>>>>>>>>> time. If you want to evaluate it before I merge it I suggest >> again >>>>>> that >>>>>>>>>> you >>>>>>>>>>> have a look. At the moment it only supports StackWalker but it >>>>>> allows >>>>>>>> us >>>>>>>>>>> to start implementing support for Java modules and other Java 9 >>>>>>>> features. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You are correct, I have not looked. >>>>>>>>>> >>>>>>>>>> Gary >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ralph >>>>>>>>>>> >>>>>>>>>>>> On Apr 19, 2017, at 10:12 AM, Gary Gregory < >>> [email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> I like projects that have a road-map page. It can be vague or >>>>>> precise. >>>>>>>>>>> But >>>>>>>>>>>> we should at least discuss it here. I am bringing this up >> partly >>> in >>>>>>>>>> light >>>>>>>>>>>> of https://issues.apache.org/jira/browse/LOG4J2-1883 >>>>>>>>>>>> >>>>>>>>>>>> How about: >>>>>>>>>>>> >>>>>>>>>>>> v 2.x - Java 7 >>>>>>>>>>>> v 3.x - Java 8 >>>>>>>>>>>> v 4.x - Java 9 >>>>>>>>>>>> >>>>>>>>>>>> Is that too weird? I am not in love with it either. >>>>>>>>>>>> >>>>>>>>>>>> I am just concerned that: >>>>>>>>>>>> >>>>>>>>>>>> - We might hang on to Java 7 a little too long. >>>>>>>>>>>> - We are missing on getting into Java 8. I feel like we are. >>>> (Jetty, >>>>>>>>>>>> Hibernate, Teiid, and others are on Java 8, sure they are >> higher >>>>>> level >>>>>>>>>>>> pieces but still, the momentum is there.) >>>>>>>>>>>> - Playing with an unreleased Java 9 might bite us with Ralph's >>>>>> double >>>>>>>>>>>> compile (which I'll admit I have not seen ;-) or really know if >>>>>> Java 9 >>>>>>>>>>>> compiled code would end up in our releases (which could bite us >>> or >>>>>>>>>> not.) >>>>>>>>>>>> >>>>>>>>>>>> Thoughts? >>>>>>>>>>>> >>>>>>>>>>>> Gary >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> E-Mail: [email protected] | [email protected] >>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl? >>>>>>>>>>> ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&link >>>>>>>>>>> Code=as2&tag=garygregory-20&linkId= >> cadb800f39946ec62ea2b1af9fe6a2 >>> b8> >>>>>>>>>>>> >>>>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= >>>>>>>>>>> am2&o=1&a=1617290459> >>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl? >>>>>>>>>>> ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&link >>>>>>>>>>> Code=as2&tag=garygregory-20&linkId= >> 31ecd1f6b6d1eaf8886ac902a24de4 >>>>>> 18%22> >>>>>>>>>>>> >>>>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= >>>>>>>>>>> am2&o=1&a=1935182021> >>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl? >>>>>>>>>>> ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&link >>>>>>>>>>> Code=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Bli >>>>>>>>>>> nk_id%7D%7D%22%3ESpring+Batch+in+Action> >>>>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= >>>>>>>>>>> am2&o=1&a=1935182951> >>>>>>>>>>>> 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 >>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_ >>>>>>>>>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& >>>>>>>>>> linkCode=as2&tag=garygregory-20&linkId= >>> cadb800f39946ec62ea2b1af9fe6a2 >>>>>> b8> >>>>>>>>>> >>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t= >>>>>> garygregory-20&l=am2&o=1&a= >>>>>>>>>> 1617290459> >>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_ >>>>>>>>>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& >>>>>>>>>> >>>>>>>> linkCode=as2&tag=garygregory-20&linkId= >>> 31ecd1f6b6d1eaf8886ac902a24de4 >>>>>> 18%22 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t= >>>>>> garygregory-20&l=am2&o=1&a= >>>>>>>>>> 1935182021> >>>>>>>>>> Spring Batch in Action >>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_ >>>>>>>>>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& >>>>>>>>>> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% >>>>>>>>>> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> >>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t= >>>>>> garygregory-20&l=am2&o=1&a= >>>>>>>>>> 1935182951> >>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Matt Sicker <[email protected]> >>>>>>>> >>>>>>>> -- >>>>>>> Matt Sicker <[email protected]> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> [image: MagineTV] >>>>> >>>>> *Mikael Ståldal* >>>>> Senior software developer >>>>> >>>>> *Magine TV* >>>>> [email protected] >>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>>> >>>>> Privileged and/or Confidential Information may be contained in this >>>>> message. If you are not the addressee indicated in this message >>>>> (or responsible for delivery of the message to such a person), you may >>> not >>>>> copy or deliver this message to anyone. In such case, >>>>> you should destroy this message and kindly notify the sender by reply >>>>> email. >>> >>> >>> >> >> >> -- >> Matt Sicker <[email protected]> >>
