I'd like to avoid the distraction of speculating about the reasons organizations will or won't upgrade to Java 8 as I don't think it's helpful.
What's important to me is whether Java 8 offers me, in my role of supporting real-live users, benefit. And here I don't care about lambda expressions. Users don't care about lambda expressions. Users don't care about anything except whether Solr/Lucene solves their problem and keeps running. So, things I desperately care about are things like whether Java 8: 1> Avoids stop-the-world GC pauses that handicap Solr/Lucene when it comes to making use of all the memory we have available. I do note that PermGen is removed, don't quite know how/whether that'll help here... 2> Makes Lucene/Solr run twice as fast. 3> Makes it harder to screw up in general, and file operations in particular (heck, I committed a screw-up on this recently), leading to more functionality faster. 4> Anything else I can point to when answering the question "why is Java 8 required?". But that "anything else" needs to be more specific than "it's modern". IOW, if I put myself in an operations person's shoes, I'd have to ask "what makes going to Java 8 worth the headache? Gimme something to take to my manager please!" All _that_ said, I agree we have to move forward at some point. I'm not convinced now's the time as far as Java 8 is concerned though. I could get convinced if there were benefits like the above. But so far nobody has presented anything that really lights my fire. Erick On Fri, Sep 12, 2014 at 1:45 PM, david.w.smi...@gmail.com <david.w.smi...@gmail.com> wrote: > Your arguments really resonate with me, Ryan… > +1 to Java 8 > > (FWIW I’m using coding in Java 8 these days already) > > ~ David Smiley > Freelance Apache Lucene/Solr Search Consultant/Developer > http://www.linkedin.com/in/davidwsmiley > > On Fri, Sep 12, 2014 at 1:39 PM, Ryan Ernst <r...@iernst.net> wrote: >>> >>> One that is on my mind right now may just barely make it to 1.7 this >>> year. >> >> >>> >>> Thus my desire to see a way to get the pending trunk work to people who >>> are not moving to 1.8 any time soon. >> >> >> We should not hold Lucene back because some companies have arcane upgrade >> policies. Part of what allows policies like this to continue is the >> slowness of the ecosystem to update, both support (we already have this) and >> requirement (what is being proposed). As I said in the original message, we >> should be ahead of the curve, not the project that is dragging behind. >> >>> I thought I saw a message go by about a 5x branch the other day, so >>> perhaps things are already exactly what I am asking for >> >> >> This is one proposed alternative to "solve all the trunk problems" (bwc >> and java8). I think it is a copout (no offense Robert) to avoid forcing an >> agreement by the community to move forward. >> >>> Given how long it is likely to be until 6.0, I am not here to argue that >>> 6.0 should not require 1.8 >> >> >> But no one knows how long it will be until 5.0 either. Even after 5.0 is >> released, whenever that may be, if there are those in the community that >> want to stretch life out of the 4x branch on java 7, that is their >> prerogative. >> >> I think the question here is, should trunk be the "blazing forefront of >> development?" I think it should be, and it seems like many others agree. >> We should not limit what is possible in trunk because corporate overlords >> are afraid of change. >> >> On Fri, Sep 12, 2014 at 1:24 PM, Benson Margulies <bimargul...@gmail.com> >> wrote: >>> >>> >>> >>> On Fri, Sep 12, 2014 at 3:35 PM, Robert Muir <rcm...@gmail.com> wrote: >>>> >>>> On Fri, Sep 12, 2014 at 3:31 PM, Chris Hostetter >>>> <hossman_luc...@fucit.org> wrote: >>>> > >>>> > b) that your argument against benson's claims seemed missleading: just >>>> > because Oracle is EOLing doesn't mean people won't be using OpenJDK; >>>> > even >>>> > if they are using Oracle's JDK, if they are large comercial >>>> > organizations >>>> > they might pay oracle to keep using it for a long time. >>>> > >>>> >>>> Its not misleading at all, its being practical. If people want to use >>>> old jvm versions, good for them. But if they open a corruption bug >>>> with one of these "commercial" versions, then my only choice is to >>>> close as "wont fix". So they might as well just use an old lucene >>>> version, too. >>> >>> >>> Here's what I know. Over the last few years, the large entities my >>> employer sells to have been very slow to move to new Java versions. Why? I >>> dunno, maybe all of them have Mordac working there. Do they pay for security >>> fixes from Oracle? Or do they just stick their heads in the sand? I can't >>> tell you. One that is on my mind right now may just barely make it to 1.7 >>> this year. >>> >>> We (meaning this project, not my employer) generally require that >>> 'significant' changes go into major releases. So, that ties together the JVM >>> version and these changes. Thus my desire to see a way to get the pending >>> trunk work to people who are not moving to 1.8 any time soon. An alternative >>> would be to have a different policy for what can go into a 4.x. I thought I >>> saw a message go by about a 5x branch the other day, so perhaps things are >>> already exactly what I am asking for, and I apologize for the noise. Given >>> how long it is likely to be until 6.0, I am not here to argue that 6.0 >>> should not require 1.8. I like a nice lambda expression as well as the next >>> guy. >>> >>> >>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
