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" <boa...@gmail.com> 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 <ralph.go...@dslextreme.com> 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 <garydgreg...@gmail.com> > > wrote: > > > > > > On Apr 21, 2017 7:06 AM, "Ralph Goers" <ralph.go...@dslextreme.com> > > 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 < > mikael.stal...@magine.com > > > > > > 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 <remko.po...@gmail.com> > > > 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 <boa...@gmail.com> 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 < > > ralph.go...@dslextreme.com> > > >>>> 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 <boa...@gmail.com> > 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 <garydgreg...@gmail.com> > > >>> wrote: > > >>>>>>> > > >>>>>>> On Wed, Apr 19, 2017 at 10:23 AM, Ralph Goers < > > >>>>> ralph.go...@dslextreme.com> > > >>>>>>> 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 < > > garydgreg...@gmail.com> > > >>>>>>>> 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: garydgreg...@gmail.com | ggreg...@apache.org > > >>>>>>>>> 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: garydgreg...@gmail.com | ggreg...@apache.org > > >>>>>>> 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 <boa...@gmail.com> > > >>>>> > > >>>>> -- > > >>>> Matt Sicker <boa...@gmail.com> > > >>> > > >> > > >> > > >> > > >> -- > > >> [image: MagineTV] > > >> > > >> *Mikael Ståldal* > > >> Senior software developer > > >> > > >> *Magine TV* > > >> mikael.stal...@magine.com > > >> 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 <boa...@gmail.com> >
