Re: [VOTE] Move trunk to Java 8
On Sep 19, 2014, at 10:23 AM, Yonik Seeley yo...@heliosearch.com wrote: On Fri, Sep 19, 2014 at 7:14 AM, Grant Ingersoll gsing...@apache.org wrote: People will upgrade when the new features they want in the latest release outweigh the mythical pain of upgrading a JDK. Perhaps the technical pain of upgrade is largely mythical, but it's real pain for real users who have no say over what version of Java they can run (or at a minimum have to jump through a lot of hoops to change the java version). Fully well aware of this, but trunk is not, by definition released, so there is nothing for them to upgrade to. There is no right answer... it's a judgement call where we should weigh all the factors each time we require a new Java version. People may weigh factors differently, but no factor should be dismissed out of hand. Of course not, just saying I personally think trunk should move forward as fast as the regular contributors and committers want, which means, we decide/vote and then move on based on the outcome and that the branches (4x or 5x or whatever) should be slower to make any changes. People who take years to upgrade their JDK also likely take years to upgrade Lucene or Solr or whatever. I'm all for keeping and maintaining older branches for those who don't want to upgrade as long as the community is willing to support them. As for Doug's comments, I think they reflect a time when we only maintained one branch and it was more of a forced decision for users. It isn't as cut and dried anymore with multiple branches, services like Solr and ES, etc. I do agree, wholeheartedly however, that we should all be thoughtful and considerate of other's opinions in the process. -Grant - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
+1 for keeping multiple branches for older versions and moving forward to new branch with latest java On Sun, Sep 21, 2014 at 5:40 PM, Grant Ingersoll gsing...@apache.org wrote: On Sep 19, 2014, at 10:23 AM, Yonik Seeley yo...@heliosearch.com wrote: On Fri, Sep 19, 2014 at 7:14 AM, Grant Ingersoll gsing...@apache.org wrote: People will upgrade when the new features they want in the latest release outweigh the mythical pain of upgrading a JDK. Perhaps the technical pain of upgrade is largely mythical, but it's real pain for real users who have no say over what version of Java they can run (or at a minimum have to jump through a lot of hoops to change the java version). Fully well aware of this, but trunk is not, by definition released, so there is nothing for them to upgrade to. There is no right answer... it's a judgement call where we should weigh all the factors each time we require a new Java version. People may weigh factors differently, but no factor should be dismissed out of hand. Of course not, just saying I personally think trunk should move forward as fast as the regular contributors and committers want, which means, we decide/vote and then move on based on the outcome and that the branches (4x or 5x or whatever) should be slower to make any changes. People who take years to upgrade their JDK also likely take years to upgrade Lucene or Solr or whatever. I'm all for keeping and maintaining older branches for those who don't want to upgrade as long as the community is willing to support them. As for Doug's comments, I think they reflect a time when we only maintained one branch and it was more of a forced decision for users. It isn't as cut and dried anymore with multiple branches, services like Solr and ES, etc. I do agree, wholeheartedly however, that we should all be thoughtful and considerate of other's opinions in the process. -Grant - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
I wish that the API improvements Rob Muir and I made to the analysis chain could be released in the foreseeable future, and I wish a little that they could be released in a version that does not require Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
Thats already planned: branch_5x Trunk with Java 8 will be 6.0. Am 21. September 2014 16:58:48 MESZ, schrieb Benson Margulies bimargul...@gmail.com: I wish that the API improvements Rob Muir and I made to the analysis chain could be released in the foreseeable future, and I wish a little that they could be released in a version that does not require Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de
Re: [VOTE] Move trunk to Java 8
Unrelated for the vote, but since it came up: Oracle isn't the only large corporation to employ high calibre skilled committers on the OpenJDK project. Oracle decides support of its own builds on its own terms, but Red Hat for example supports the JVM for much longer to its customers, and being an OSS friendly company any path which might get developed will be included in some publicly available maintenance branch. Disclaimer: I work for Red Hat but I'm just mentioning it as someone passionate for Lucene; so I happen to have an idea of the intention of my colleagues working on the OpenJDK project, but I am not representing my employer on this matter: just wanted to point out that after Oracle will end to support Java7, it's not forcing anyone to move away from it, nor forcing to pay money. In fact in my experience it's very common to find users of older Lucene versions on much older JVMs, often supported JVM builds by other vendors, and I don't expect this to change. HTH -- Sanne On 12 September 2014 20:31, Chris Hostetter hossman_luc...@fucit.org wrote: : That is bogus for an open source project. I won't have such updates, : how can i support such a java version, users that run into trouble? : And this does happen often. : I don't think i should have to pay money and become a paying customer : to Oracle to support lucene. I didn't say you should. I in fact said almost the exact opposite: that we shouldn't let commercial versions of the JDK have any bearing on our decision 1) Benson made a reasonable statement that There are many large organizations of the sort that use Lucene Solr that will not be moving to 8 for years yet 2) you said: I don't buy for years yet. ... impling that such organizations will *have* to upgrade before then because there won't be *free* releases of java. 3) I tried to point out 2 things: a) we shouldn't let the EOL cycle of *one* commercial vendor have any bearing on our policy of support -- particularly since the refrence implementation is an open source source project. 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. -Hoss http://www.lucidworks.com/ - 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
Re: [VOTE] Move trunk to Java 8
A little late to the game, but +1 on Java 8 on trunk. This bikeshed has gone on for countless years (go google moving to Java 5 like 8 years ago for Lucene) and you will never make everyone happy. People will upgrade when the new features they want in the latest release outweigh the mythical pain of upgrading a JDK. On Sep 15, 2014, at 12:44 AM, Shalin Shekhar Mangar shalinman...@gmail.com wrote: +1 If we asked our users we would still be using Java 5. Let's move trunk to Java 8. We'd need to backport stuff to Java 7 based branches for a while because users... but that's okay. On Fri, Sep 12, 2014 at 9:11 PM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Regards, Shalin Shekhar Mangar. Grant Ingersoll | @gsingers http://www.lucidworks.com
Re: [VOTE] Move trunk to Java 8
On Fri, Sep 19, 2014 at 7:14 AM, Grant Ingersoll gsing...@apache.org wrote: People will upgrade when the new features they want in the latest release outweigh the mythical pain of upgrading a JDK. Perhaps the technical pain of upgrade is largely mythical, but it's real pain for real users who have no say over what version of Java they can run (or at a minimum have to jump through a lot of hoops to change the java version). There is no right answer... it's a judgement call where we should weigh all the factors each time we require a new Java version. People may weigh factors differently, but no factor should be dismissed out of hand. As you say, this isn't a new argument... here's what Doug had to say: http://markmail.org/message/7mafuwu5n36u2fva -Yonik http://heliosearch.org - native code faceting, facet functions, sub-facets, off-heap data - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] Move trunk to Java 8
+1 to stay on 1.7, from another small scale committer. I do not see any compelling reason to upgrade to 1.8, except as Benson says for minor programming conveniences. My company would be one of the ones you'd be shutting out if we were on 1.8 now. (Some of our apps upgraded to 1.7 this year.) Of course there is 4.x, but what is 1.8 going to buy 5.x that you're willing to significantly shrink the potential user base? James Dyer Ingram Content Group (615) 213-4311 From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Friday, September 12, 2014 3:45 PM To: dev@lucene.apache.org Subject: Re: [VOTE] Move trunk to Java 8 Corporate overlords isn't helpful. Lucene is what it is because of its wide adoption. That includes big, small, smart, and stupid organizations. I don't think that an infrastructure component like Lucene needs to be 'ahead of the curve'. It should aim to be widely adoptable. To me, that means moving to a new Java requirement after we observe it is semi-ubiquitous. If 1.8 offered some game-changing JVM feature that would allow a giant leap forward in Lucene, then that would be different. So far, all I see are some minor programming conveniences. However, I'm just one very small scale committer, and I've consumed enough oxygen on this topic.
Re: [VOTE] Move trunk to Java 8
The vote passed. https://issues.apache.org/jira/browse/LUCENE-5950 On Fri, Sep 12, 2014 at 8:48 AM, Adrien Grand jpou...@gmail.com wrote: +1 On Fri, Sep 12, 2014 at 5:41 PM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
?? I thought there were two –1 votes. -- Jack Krupansky From: Ryan Ernst Sent: Monday, September 15, 2014 10:19 AM To: dev@lucene.apache.org Subject: Re: [VOTE] Move trunk to Java 8 The vote passed. https://issues.apache.org/jira/browse/LUCENE-5950 On Fri, Sep 12, 2014 at 8:48 AM, Adrien Grand jpou...@gmail.com wrote: +1 On Fri, Sep 12, 2014 at 5:41 PM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
This was a procedural/opinion poll vote: http://www.apache.org/foundation/voting.html Only majority is necessary. On Mon, Sep 15, 2014 at 10:45 AM, Jack Krupansky j...@basetechnology.com wrote: ?? I thought there were two –1 votes. -- Jack Krupansky *From:* Ryan Ernst r...@iernst.net *Sent:* Monday, September 15, 2014 10:19 AM *To:* dev@lucene.apache.org *Subject:* Re: [VOTE] Move trunk to Java 8 The vote passed. https://issues.apache.org/jira/browse/LUCENE-5950 On Fri, Sep 12, 2014 at 8:48 AM, Adrien Grand jpou...@gmail.com wrote: +1 On Fri, Sep 12, 2014 at 5:41 PM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
For the record, I count eleven +1's, and two -1's On Mon, Sep 15, 2014 at 10:56 AM, Ryan Ernst r...@iernst.net wrote: This was a procedural/opinion poll vote: http://www.apache.org/foundation/voting.html Only majority is necessary. On Mon, Sep 15, 2014 at 10:45 AM, Jack Krupansky j...@basetechnology.com wrote: ?? I thought there were two –1 votes. -- Jack Krupansky *From:* Ryan Ernst r...@iernst.net *Sent:* Monday, September 15, 2014 10:19 AM *To:* dev@lucene.apache.org *Subject:* Re: [VOTE] Move trunk to Java 8 The vote passed. https://issues.apache.org/jira/browse/LUCENE-5950 On Fri, Sep 12, 2014 at 8:48 AM, Adrien Grand jpou...@gmail.com wrote: +1 On Fri, Sep 12, 2014 at 5:41 PM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
Ryan, I’m unclear on what makes a “procedural vote” as such. This seems to me to be about code modifications — in a big way as it’s a large change to the codebase. ~ David
Re: [VOTE] Move trunk to Java 8
On Mon, Sep 15, 2014 at 2:45 PM, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: Ryan, I’m unclear on what makes a “procedural vote” as such. This seems to me to be about code modifications — in a big way as it’s a large change to the codebase. David, one way out of this is that a commit is a commit. A sufficiently unhappy PMC member can veto the commit, and thus force more discussion. If no PMC members are sufficiently unhappy, it stands. ~ David
Re: [VOTE] Move trunk to Java 8
Most votes are procedural. There are a couple specific veto votes: 1. You can veto a new committer or PMC member if you are on the PMC. 2. You can veto a specific code commit with a valid technical reason. This cannot be arbitrary or capricious - it has to be a specific technical reason and if that is addressed, things move on. This kind of veto has to be explicit, not just a standard “-1, im against this”. Larger issues - which java versions do we support, what back compat policies, git or svn - these are majority votes. Votes are a failure in a consensus community in general though. It’s best to have a discussion thread and a vote thread becomes a last resort when there is no way consensus will be reached. - Mark http://about.me/markrmiller On Sep 15, 2014, at 2:45 PM, david.w.smi...@gmail.com wrote: Ryan, I’m unclear on what makes a “procedural vote” as such. This seems to me to be about code modifications — in a big way as it’s a large change to the codebase. ~ David - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
David, This thread was about the opinion of whether or not to move trunk to Java 8. There was no actual code change. If anyone has any technical issues with the actual change (LUCENE-5950), please comment there. Thanks Ryan On Mon, Sep 15, 2014 at 11:45 AM, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: Ryan, I’m unclear on what makes a “procedural vote” as such. This seems to me to be about code modifications — in a big way as it’s a large change to the codebase. ~ David
Re: [VOTE] Move trunk to Java 8
I don't have a really strong opinion on 'Should we move to Java 8' but at the same time would not really be happy dealing with 2 continuously diverging branches. I wouldn't want to rewrite the same implementation twice over and get it to work. I am not sure about others but I think it will also make it tougher to attract contributors knowing they might have to deal with 2 divergent branches. At the same time, if there's a reason compelling enough that makes the lives of everyone involved better (read, easier), I'll be in for it. On Fri, Sep 12, 2014 at 8:41 AM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Anshum Gupta http://www.anshumgupta.net
Re: [VOTE] Move trunk to Java 8
Nothing would force you to use java 8 features in anything you worked on. But they would be available. And if the branches are always in sync, what is the point of having 2 branches? There would never be a reason for a major release. On Sep 14, 2014 9:33 AM, Anshum Gupta ans...@anshumgupta.net wrote: I don't have a really strong opinion on 'Should we move to Java 8' but at the same time would not really be happy dealing with 2 continuously diverging branches. I wouldn't want to rewrite the same implementation twice over and get it to work. I am not sure about others but I think it will also make it tougher to attract contributors knowing they might have to deal with 2 divergent branches. At the same time, if there's a reason compelling enough that makes the lives of everyone involved better (read, easier), I'll be in for it. On Fri, Sep 12, 2014 at 8:41 AM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Anshum Gupta http://www.anshumgupta.net
Re: [VOTE] Move trunk to Java 8
(Hmmm... I wonder what Heliosearch’s Java support policy is.) There was a Lucene wiki page for the Java 1.4 to 1.5 transition... is any of that thinking relevant to this 1.7 to 1.8 transition? See: https://wiki.apache.org/lucene-java/Java_1.5_Migration IOW, how much of this issue is specific to Java 8, as opposed to ANY Java migration with trunk and the stable branch? And, to what extent does the issue relate to how imminent a 5.0 release is expected to be, and Java 7 EOL? EOL relates to office Oracle support, but that says nothing about the actual usage at major Lucene user sites. -- Jack Krupansky From: Ryan Ernst Sent: Sunday, September 14, 2014 11:35 AM To: dev@lucene.apache.org Subject: Re: [VOTE] Move trunk to Java 8 Nothing would force you to use java 8 features in anything you worked on. But they would be available. And if the branches are always in sync, what is the point of having 2 branches? There would never be a reason for a major release. On Sep 14, 2014 9:33 AM, Anshum Gupta ans...@anshumgupta.net wrote: I don't have a really strong opinion on 'Should we move to Java 8' but at the same time would not really be happy dealing with 2 continuously diverging branches. I wouldn't want to rewrite the same implementation twice over and get it to work. I am not sure about others but I think it will also make it tougher to attract contributors knowing they might have to deal with 2 divergent branches. At the same time, if there's a reason compelling enough that makes the lives of everyone involved better (read, easier), I'll be in for it. On Fri, Sep 12, 2014 at 8:41 AM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Anshum Gupta http://www.anshumgupta.net
Re: [VOTE] Move trunk to Java 8
On Sun, Sep 14, 2014 at 3:10 PM, Jack Krupansky j...@basetechnology.com wrote: (Hmmm... I wonder what Heliosearch’s Java support policy is.) There was a Lucene wiki page for the Java 1.4 to 1.5 transition... is any of that thinking relevant to this 1.7 to 1.8 transition? See: https://wiki.apache.org/lucene-java/Java_1.5_Migration IOW, how much of this issue is specific to Java 8, as opposed to ANY Java migration with trunk and the stable branch? And, to what extent does the issue relate to how imminent a 5.0 release is expected to be, and Java 7 EOL? EOL relates to office Oracle support, but that says nothing about the actual usage at major Lucene user sites. Another thought: what if there were three branches: -- 'The next generation' -- leading edge, radical, new stuff. Java 8. -- 'The next major release' -- Incompatible API changes, but Java version constrained for now to 1.7. -- the currently-maintained stream of minor releases. -- Jack Krupansky *From:* Ryan Ernst r...@iernst.net *Sent:* Sunday, September 14, 2014 11:35 AM *To:* dev@lucene.apache.org *Subject:* Re: [VOTE] Move trunk to Java 8 Nothing would force you to use java 8 features in anything you worked on. But they would be available. And if the branches are always in sync, what is the point of having 2 branches? There would never be a reason for a major release. On Sep 14, 2014 9:33 AM, Anshum Gupta ans...@anshumgupta.net wrote: I don't have a really strong opinion on 'Should we move to Java 8' but at the same time would not really be happy dealing with 2 continuously diverging branches. I wouldn't want to rewrite the same implementation twice over and get it to work. I am not sure about others but I think it will also make it tougher to attract contributors knowing they might have to deal with 2 divergent branches. At the same time, if there's a reason compelling enough that makes the lives of everyone involved better (read, easier), I'll be in for it. On Fri, Sep 12, 2014 at 8:41 AM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Anshum Gupta http://www.anshumgupta.net
Re: [VOTE] Move trunk to Java 8
On 9/14/2014 10:32 AM, Anshum Gupta wrote: I don't have a really strong opinion on 'Should we move to Java 8' but at the same time would not really be happy dealing with 2 continuously diverging branches. I wouldn't want to rewrite the same implementation twice over and get it to work. I am not sure about others but I think it will also make it tougher to attract contributors knowing they might have to deal with 2 divergent branches. At the same time, if there's a reason compelling enough that makes the lives of everyone involved better (read, easier), I'll be in for it. My vote remains +0. I don't think we're ready quite yet, but I'm not going to be horrendously upset by the move if it happens. I might get really annoyed with complications in backporting, but I'll work through those problems. If anyone cares, my advice is to wait until just before branch_5x is created to require Java 8. Anshum managed to fully articulate what I was trying to say in my message earlier. I absolutely think we do need to make a move to Java 8 as the minimum on trunk, and it likely needs to happen soon. When we do it, we need to be ready to ignore whatever outcry there is from the userbase about how they cannot upgrade Java on their production systems. There will be 4.x versions for those users. They're going to get left in the dust feature-wise, but this is what happens as software projects evolve. I would expect this to not be new information for many of you: I'm in this for Solr. Solr is inherently dependent on Lucene, so I care very much about Lucene, but my focus is Solr. My understanding of Lucene (even the Lucene usage in Solr) is limited. One of our stated goals for Solr 5.0 is to make it a standalone app, possibly with a controlling process. This goal, and the removal of the war target in trunk, mean that Solr 5.0 is not ready for release in its current form. The effort required to build a standalone app looks pretty daunting, although it's possible that embedding Jetty might be really easy. Depending on what we learn regarding converting a servlet to an app, we might need to reinstate the war target in order to make a reasonably quick Solr 5.0 release possible. If that happens, we can migrate to a standalone app in a branch off the new trunk and backport the new build target into branch_5x. Completely switching to a standalone app and eliminating the servlet might need to wait until 6.0 ... and it would be good motivation for 6.0 to follow 5.0 relatively quickly. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
On Sun, Sep 14, 2014 at 3:35 PM, Benson Margulies bimargul...@gmail.com wrote: Another thought: what if there were three branches: -- 'The next generation' -- leading edge, radical, new stuff. Java 8. -- 'The next major release' -- Incompatible API changes, but Java version constrained for now to 1.7. -- the currently-maintained stream of minor releases. Personally I would be happy with this solution. To be specific I would: svn copy branch_4x branch_5x. bump trunk to 6.0 merge back some incompatible changes (example: your simplification to tokenizers, NIO.2, removal of dead codecs such as sep and pulsing) My reasoning: trunk would be both clean from back compat, and on java 8. stable 5.x releases for java 7 could be issued in relatively short order, and we could drop 3.x support there. 4.11 as its named now would be 5.0. It already has some relatively serious changes and with the above it starts to shape up. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
+1 If we asked our users we would still be using Java 5. Let's move trunk to Java 8. We'd need to backport stuff to Java 7 based branches for a while because users... but that's okay. On Fri, Sep 12, 2014 at 9:11 PM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Regards, Shalin Shekhar Mangar.
Re: [VOTE] Move trunk to Java 8
On Sat, Sep 13, 2014 at 1:46 AM, Erick Erickson erickerick...@gmail.com wrote: The point remains that the end user users who are _not_ developers of Lucene/Solr are our customers. Otherwise we're all just playing with ourselves. Not true. Lucene is a library. 100% of its users are developers. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
: : faster. And there are a ton of features that would make our lives as : : developers easier (and that can improve the quality of Lucene 5 when : : it is eventually released). : : Examples please? : The ability to specify default methods on interfaces. So far, that's the only concrete example of seen of the stated motivation for this proposal. It doesn't strike me as a Game Changing langauge feature worthy of making the jump -- Not stacked up against the concerns expressed by several people about alienating existing users. I'm not opposed to moving to Java8, i'm just opposed to doing it w/o more compelling reasons. -1 ... unless/until there are more examples of: a) how moving to java 8 will make our lives easier; b) how java 8 will improve the quality of Lucene. -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
bq: Not true. Lucene is a library. 100% of its users are developers. Well, developers don't operate in a vacuum either. There will be some set of them that cannot use Java 8. It's perfectly reasonable to decide that we can't confine ourselves forever because some people will be inconvenienced and go ahead with it. I'm not at all saying java8 is a bad idea here. I'm with Hoss though, unless and until there are better reasons given I'm -1 Erick On Sat, Sep 13, 2014 at 9:17 AM, Chris Hostetter hossman_luc...@fucit.org wrote: : : faster. And there are a ton of features that would make our lives as : : developers easier (and that can improve the quality of Lucene 5 when : : it is eventually released). : : Examples please? : The ability to specify default methods on interfaces. So far, that's the only concrete example of seen of the stated motivation for this proposal. It doesn't strike me as a Game Changing langauge feature worthy of making the jump -- Not stacked up against the concerns expressed by several people about alienating existing users. I'm not opposed to moving to Java8, i'm just opposed to doing it w/o more compelling reasons. -1 ... unless/until there are more examples of: a) how moving to java 8 will make our lives easier; b) how java 8 will improve the quality of Lucene. -Hoss http://www.lucidworks.com/ - 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
Re: [VOTE] Move trunk to Java 8
On Sat, Sep 13, 2014 at 2:26 AM, Robert Muir rcm...@gmail.com wrote: On Sat, Sep 13, 2014 at 1:46 AM, Erick Erickson erickerick...@gmail.com wrote: The point remains that the end user users who are _not_ developers of Lucene/Solr are our customers. Otherwise we're all just playing with ourselves. Not true. Lucene is a library. 100% of its users are developers. This is the Lucene/Solr project, not just Lucene. This also affects every other project (open source and commercial) that has Lucene or Solr as a dependency. -Yonik http://heliosearch.org - native code faceting, facet functions, sub-facets, off-heap data - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
+1 This is trunk, it doesnt impact anyones users :) On Fri, Sep 12, 2014 at 11:41 AM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - 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
Re: [VOTE] Move trunk to Java 8
I hate to be on the side of either “I always know exactly what should happen, no one else does, I’ll do what I want anyway” or “trunk is just about cutting edge so obviously our java version should also be cutting edge”, because neither are very appealing to me. Sill, I’m +1 moving trunk to Java 8. - Mark http://about.me/markrmiller On Sep 12, 2014, at 11:41 AM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - 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
Re: [VOTE] Move trunk to Java 8
+1 On Fri, Sep 12, 2014 at 5:41 PM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
+1 On 12 September 2014 17:48, Adrien Grand jpou...@gmail.com wrote: +1 On Fri, Sep 12, 2014 at 5:41 PM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Met vriendelijke groet, Martijn van Groningen
Re: [VOTE] Move trunk to Java 8
+8 On Sep 12, 2014, at 11:41 AM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - 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
Re: [VOTE] Move trunk to Java 8
On 9/12/2014 9:41 AM, Ryan Ernst wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. I don't want to stand in the way, so this is not a negative vote. My only concern is causing a large amount of divergence between trunk and the stable branch, which makes it difficult to backport. I'm completely unfamiliar with what Java 8 brings to the table. I'll also confess that I'm still fairly clueless about what Java 7 gives us that's not in Java 6 ... although I think I finally do understand what try-with-resources actually means. If switching to Java 8 is the first step on the road towards a 5.0 release, then I'm all in favor ... although we really need to figure out how we'll achieve a running Solr, now that we don't make a .war. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
: faster. And there are a ton of features that would make our lives as : developers easier (and that can improve the quality of Lucene 5 when : it is eventually released). Examples please? -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
+1 Uwe Am 12. September 2014 17:41:24 MESZ, schrieb Ryan Ernst r...@iernst.net: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de
Re: [VOTE] Move trunk to Java 8
If we release the current contents of trunk first, I'm OK with this, not that i have a veto. There are many large organizations of the sort that use Lucene Solr that will not be moving to 8 for years yet. If the current trunk content is marooned until they move to 8, I will be sad. On Fri, Sep 12, 2014 at 2:39 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : faster. And there are a ton of features that would make our lives as : developers easier (and that can improve the quality of Lucene 5 when : it is eventually released). Examples please? -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
On Fri, Sep 12, 2014 at 2:48 PM, Benson Margulies bimargul...@gmail.com wrote: If we release the current contents of trunk first, I'm OK with this, not that i have a veto. There are many large organizations of the sort that use Lucene Solr that will not be moving to 8 for years yet. If the current trunk content is marooned until they move to 8, I will be sad. I don't buy for years yet. After April 2015, Oracle will no longer post updates of Java SE 7 to its public download sites http://www.oracle.com/technetwork/java/eol-135779.html - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
On Fri, Sep 12, 2014 at 2:39 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : faster. And there are a ton of features that would make our lives as : developers easier (and that can improve the quality of Lucene 5 when : it is eventually released). Examples please? The ability to specify default methods on interfaces. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
2014-09-12 21:11 GMT+02:00 Robert Muir rcm...@gmail.com: On Fri, Sep 12, 2014 at 2:39 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : faster. And there are a ton of features that would make our lives as : developers easier (and that can improve the quality of Lucene 5 when : it is eventually released). Examples please? The ability to specify default methods on interfaces. which I, by the way, find awful ... however +1 Tommaso - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
: After April 2015, Oracle will no longer post updates of Java SE 7 to : its public download sites I'm not sure that's really relevant to the discussion? With Java5 Java6, there was no other large scale JVM distributions then Oracle, so their EOL was extermely pertinant to the question of how long we shoud support it. With Java7, OpenJDK is out there -- as the refrence implemention of Java7 in fact -- and it's seems probable that there will continue to be community support for it long after Oracle stops officialy distributing their commercial version. So I don't think we should not let Oracle's timeframe fro mtheir commercial EOL affect our decision Playing devils advocate http://www.oracle.com/technetwork/java/eol-135779.html That same page that makes it clear there will not longer be *public* (ie: free) updates of Java SE 7 from oracle past that date, it also makes it clear that Oracle will continue to provide bug fix releases of Java7 for paying customers until 2019, and critical bug security fixes until 2022. -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
On Fri, Sep 12, 2014 at 3:13 PM, Tommaso Teofili tommaso.teof...@gmail.com wrote: 2014-09-12 21:11 GMT+02:00 Robert Muir rcm...@gmail.com: On Fri, Sep 12, 2014 at 2:39 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : faster. And there are a ton of features that would make our lives as : developers easier (and that can improve the quality of Lucene 5 when : it is eventually released). Examples please? The ability to specify default methods on interfaces. which I, by the way, find awful ... however +1 I thought it was awful myself too, but sometimes its appropriate. For example, I am currently working on a patch to allow you to gain insight into what is going on with lucene datastructures, how much memory are they using, etc. With java8, i could add a default method to interface Accountable getChildResources that returns the empty list, along with some static sugar methods to e.g. ease implementations and so on. This would be a relatively small patch, wouldn't introduce useless noise anywhere, would be easy for people to use, and it wouldnt break backwards compatibility. With java7, there are less choices. I can introduce a new method to the interface (breaking it, and requiring lots of Collections.emptyList impls everywhere), and a separate Accountables with just static methods, thats one option. Alternatively, i can introduce a new (sub)interface, but that makes the API more complex and much more difficult to use, e.g. instanceof casts and so on, and you still need a separate class for the other stuff. I only use this example because it is something I am currently working on and it frustrates me. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
On Fri, Sep 12, 2014 at 3:19 PM, Chris Hostetter hossman_luc...@fucit.org wrote: Playing devils advocate http://www.oracle.com/technetwork/java/eol-135779.html That same page that makes it clear there will not longer be *public* (ie: free) updates of Java SE 7 from oracle past that date, it also makes it clear that Oracle will continue to provide bug fix releases of Java7 for paying customers until 2019, and critical bug security fixes until 2022. That is bogus for an open source project. I won't have such updates, how can i support such a java version, users that run into trouble? And this does happen often. I don't think i should have to pay money and become a paying customer to Oracle to support lucene. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
+1 Mike McCandless http://blog.mikemccandless.com On Fri, Sep 12, 2014 at 11:41 AM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - 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
Re: [VOTE] Move trunk to Java 8
+1 On Fri, Sep 12, 2014 at 9:26 PM, Michael McCandless luc...@mikemccandless.com wrote: +1 Mike McCandless http://blog.mikemccandless.com On Fri, Sep 12, 2014 at 11:41 AM, Ryan Ernst r...@iernst.net wrote: It has been 6 months since Java 8 was released. It has proven to be both stable (no issues like with the initial release of java 7) and faster. And there are a ton of features that would make our lives as developers easier (and that can improve the quality of Lucene 5 when it is eventually released). We should stay ahead of the curve, and move trunk to Java 8. - 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
: That is bogus for an open source project. I won't have such updates, : how can i support such a java version, users that run into trouble? : And this does happen often. : I don't think i should have to pay money and become a paying customer : to Oracle to support lucene. I didn't say you should. I in fact said almost the exact opposite: that we shouldn't let commercial versions of the JDK have any bearing on our decision 1) Benson made a reasonable statement that There are many large organizations of the sort that use Lucene Solr that will not be moving to 8 for years yet 2) you said: I don't buy for years yet. ... impling that such organizations will *have* to upgrade before then because there won't be *free* releases of java. 3) I tried to point out 2 things: a) we shouldn't let the EOL cycle of *one* commercial vendor have any bearing on our policy of support -- particularly since the refrence implementation is an open source source project. 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. -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
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. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
I'm ok with moving to Java 8, although realistically I don't think it's that much of a gain (yes, there are some syntactic sugars and new APIs, but I remain pretty conservative about using them). D. On Fri, Sep 12, 2014 at 9: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. - 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
Re: [VOTE] Move trunk to Java 8
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
Re: [VOTE] Move trunk to Java 8
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
Re: [VOTE] Move trunk to Java 8
Corporate overlords isn't helpful. Lucene is what it is because of its wide adoption. That includes big, small, smart, and stupid organizations. I don't think that an infrastructure component like Lucene needs to be 'ahead of the curve'. It should aim to be widely adoptable. To me, that means moving to a new Java requirement after we observe it is semi-ubiquitous. If 1.8 offered some game-changing JVM feature that would allow a giant leap forward in Lucene, then that would be different. So far, all I see are some minor programming conveniences. However, I'm just one very small scale committer, and I've consumed enough oxygen on this topic.
Re: [VOTE] Move trunk to Java 8
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
Re: [VOTE] Move trunk to Java 8
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
Re: [VOTE] Move trunk to Java 8
On Fri, Sep 12, 2014 at 7:32 PM, Erick Erickson erickerick...@gmail.com wrote: Users don't care about lambda expressions. You cannot say this. Users of lucene are API users, and supporting these language changes well are important. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
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 am not suggesting moving the stable branch to java 8, only trunk. Your statement implies I am suggesting moving the entire project to java 8. I don't think everyone is understanding that separation. Trunk is *supposed* to be bleeding edge. The stable branch can continue to support java 7, even for some time after EOL (IIRC it was a while after Java 6 EOL that the stable branch moved to java 7). On Fri, Sep 12, 2014 at 4:39 PM, Robert Muir rcm...@gmail.com wrote: On Fri, Sep 12, 2014 at 7:32 PM, Erick Erickson erickerick...@gmail.com wrote: Users don't care about lambda expressions. You cannot say this. Users of lucene are API users, and supporting these language changes well are important. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
There are so many new features in java 8. lambdas etc. If devs start using those features in trunk and the 4x branch sticks to java 7 the codebase can diverge quite a bit. Which means patches won't apply across branches. I'm all for moving to java 8 . but is it not possible to move both? On Sat, Sep 13, 2014 at 5:32 AM, Ryan Ernst r...@iernst.net wrote: 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 am not suggesting moving the stable branch to java 8, only trunk. Your statement implies I am suggesting moving the entire project to java 8. I don't think everyone is understanding that separation. Trunk is *supposed* to be bleeding edge. The stable branch can continue to support java 7, even for some time after EOL (IIRC it was a while after Java 6 EOL that the stable branch moved to java 7). On Fri, Sep 12, 2014 at 4:39 PM, Robert Muir rcm...@gmail.com wrote: On Fri, Sep 12, 2014 at 7:32 PM, Erick Erickson erickerick...@gmail.com wrote: Users don't care about lambda expressions. You cannot say this. Users of lucene are API users, and supporting these language changes well are important. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul
Re: [VOTE] Move trunk to Java 8
On Fri, Sep 12, 2014 at 1:39 PM, Ryan Ernst r...@iernst.net wrote: I think the question here is, should trunk be the blazing forefront of development? Even if the answer is yes, In what dimensions though? Blazing forefront of lucene/solr need not be blazing forefront of Java or of different operating systems, or switching to entirely different languages, etc. The minimum JVM requirement is an orthogonal decision. And I just met with some folks the other day that can't yet upgrade to Java 1.7. The practical considerations of what users can use (say we were to release 5.0 in a few months) and the development pain of further diverging trunk and 4x need to be weighed against the language/library features that a new JVM version bring. -Yonik http://heliosearch.org - native code faceting, facet functions, sub-facets, off-heap data - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
I’ve worked on commercial libraries, and the releases were limited to the oldest JVM that our big customers were using. Some customers were much more conservative (or lazy) than I imagined. I just sent out an e-mail about planning for the JDK 8 upgrade and got some skepticism in reply. In a profit making business, the choice between the latest Java and something that brings in revenue is a pretty easy choice. Sure, take trunk forwards, but if you want Lucene to be widely used, the releases need to be conservative about Java versions. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ On Sep 12, 2014, at 7:23 PM, Yonik Seeley yo...@heliosearch.com wrote: On Fri, Sep 12, 2014 at 1:39 PM, Ryan Ernst r...@iernst.net wrote: I think the question here is, should trunk be the blazing forefront of development? Even if the answer is yes, In what dimensions though? Blazing forefront of lucene/solr need not be blazing forefront of Java or of different operating systems, or switching to entirely different languages, etc. The minimum JVM requirement is an orthogonal decision. And I just met with some folks the other day that can't yet upgrade to Java 1.7. The practical considerations of what users can use (say we were to release 5.0 in a few months) and the development pain of further diverging trunk and 4x need to be weighed against the language/library features that a new JVM version bring. -Yonik http://heliosearch.org - native code faceting, facet functions, sub-facets, off-heap data - 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
Re: [VOTE] Move trunk to Java 8
@Ryan: Yes, I'm clear that you're talking about trunk/5.0 The point remains though that once trunk starts down that path keeping the branches in synch becomes harder. Does the ease in development (alleged) with Java8 balance well against dealing with that divergence? Maybe so, but let's consider it carefully. It may be worth it, I'd just like a better understanding of _why_ it would be worth it. @Robert: bq: You cannot say this. Users of lucene are API users, and supporting these language changes well are important. Why pray tell? I'm quite willing to agree that helping the developers who actually contribute code is important. That said, all I've heard so far is that Java 8 has some stuff that's cool. I'm also perfectly willing to concede that as far as committing is concerned I'm quite light-weight. If you can make an argument that the heavy-weight committer's lives would be made easier by moving to Java 8 I'm all for it. However, that case hasn't been made yet. One example has been The ability to specify default methods on interfaces. Which has already been identified as something that's inconvenient currently, but we can cope. Seems a rather weak reason to move to Java 8. Nit pick all you like, but I'd appreciate it if you'd actually read the whole thing and reply to the overall sentiment as opposed to cherry picking a single statement and use it to obviate the entire thing. In particular I resent you pulling a single statement out of my comments and ignoring the rest. Please stop that crap. Quoting myself: bq: 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. You completely ignored that statement and resorted to cherry-picking without replying to that statement at all. Nobody has enumerated the benefits to our end users. I provided several reasons that would make it an easy sell from my POV, you ignored them all. Do you really have any compelling reasons here? Maybe it would have been clearer to say my users, or perhaps the people I deal with who want a solution, not a playground for developers. The point remains that the end user users who are _not_ developers of Lucene/Solr are our customers. Otherwise we're all just playing with ourselves. I'm perfectly willing to agree that serving the developers with an easier-to-maintain, faster innovation framework is good for my users. I'm not willing to back down without someone enumerating those benefits. Yes, I'm pissed. Credit it to a long week. But please actually respond to what I write rather than make bogus arguments. On Fri, Sep 12, 2014 at 4:39 PM, Robert Muir rcm...@gmail.com wrote: On Fri, Sep 12, 2014 at 7:32 PM, Erick Erickson erickerick...@gmail.com wrote: Users don't care about lambda expressions. You cannot say this. Users of lucene are API users, and supporting these language changes well are important. - 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
