@Furkan, thanks for sharing your thoughts and giving insights. I am happy that you agree that we should move to Java 1.7 even if you had the trouble with your legacy code. That is the right way to go here!
Regarding the vote: +1 for moving to Java 1.7 on 4.x -1 for moving to Java 8 on trunk I think it's too early and we should make the decision once we are closer to a release and then features might be more important than lambda functions so lets move the decision to later! simon On Sun, Mar 9, 2014 at 3:49 PM, Furkan KAMACI <furkankam...@gmail.com> wrote: > Hi All; > > I am not a committer yet but I want share my thoughts as a contributor and a > Solr user to give an example from real life. I use SolrCloud for one year > (our product is at pre-prod step) and I have hundreds of servers at my > company and nearly half of them are SolrCloud. We also have an Hadoop > cluster which runs Map/Reduce jobs. We also use and test Ambari and > Hortonworks and we also use Giraph at our Hadoop side. Just a few weeks ago > we've faced with an issue that some of projects that we use was not > compatible with Java 7 (yes its weird.) So we had to change the Java version > of our servers until we maintain it (I've updated a project from Java 7 to > Java 6 just because of that.) > > I've separated the SolrCloud nodes from other parts of our ecosystem as > usual and I've never faced with a problem as like that with my management. I > use Java 1.7 u25 as recommended and because of it is stable. However I see > that even it is more logical to upgrade to new versions of Java (if it is > stable) sometimes there maybe some limitations for companies. If I could > generate Solr indexes via Map/Reduce at my current architecture I was not > able to use it because of that Java 6 problem. > > I'm currently reviewing Java 8 book of Manning and I know that Java 8 has > great features. However my thought is that: Java 6 might be considered as > outdated and it is applicable that if we don't support it. However I think > that Java 7 will be used for a long time within companies and trunk should > support Java 7 too at least until Java 8 has a common usage or until the end > of life of Java 7 support (it seems that it will be supported at least until > March 2015). > > Thanks; > Furkan KAMACI > > > 2014-03-09 16:07 GMT+02:00 Erick Erickson <erickerick...@gmail.com>: > >> Solr/Lucene 4.8 -> Java 7 >> +1 >> >> Solr/Lucene 5.0 -> Java8 >> >> -1 for now. +1 as we get closer to releasing 5.0. There's still plenty >> of cruft in trunk that's there only because of needing to support >> Java6 in the 4.x code line, I think having a period when we can freely >> clean up some of the Java 6 leftovers in trunk and 4.8+ without having >> to _additionally_ deal with Java 8 changes that only apply to trunk >> would be useful. Wouldn't it be nice to have just a few months where >> one didn't have to even think about it ;) >> >> As far as 5.0 is concerned... The point that organizations move much >> more slowly than we do in terms of adopting new Java releases is well >> taken. I suspect that, no matter what, if we move 5.0 to Java 8, we'll >> have quite a long period (3 years as a wild guess) where some people >> will be unable to use 5.x because of organizational (not technical) >> issues. >> >> IMO, it's perfectly legitimate to say that Solr development shouldn't >> be held up because organization X is unwilling to use Java8 thus I >> think we should go forward with 5x and Java8, just not quite yet. >> >> Just don't be surprised by people saying that they can't use Java8 in >> 2016 and would someone backport fix/improvements X, Y, and Z :)... >> >> >> >> On Sun, Mar 9, 2014 at 9:31 AM, Tommaso Teofili >> <tommaso.teof...@gmail.com> wrote: >> > >> > >> > >> > 2014-03-08 17:17 GMT+01:00 Uwe Schindler <u...@thetaphi.de>: >> > >> >> Hi all, >> >> >> >> Java 8 will get released (hopefully, but I trust the release plan!) on >> >> March 18, 2014. Because of this, lots of developers will move to Java >> >> 8, >> >> too. This makes maintaining 3 versions for developing Lucene 4.x not >> >> easy >> >> anymore (unless you have cool JAVA_HOME "cmd" launcher scripts using >> >> StExBar >> >> available for your Windows Explorer - or similar stuff in Linux/Mäc). >> >> >> >> We already discussed in another thread about moving to release trunk as >> >> 5.0, but people disagreed and preferred to release 4.8 with a minimum >> >> of >> >> Java 7. This is perfectly fine, as nobody should run Lucene or Solr on >> >> an >> >> unsupported platform anymore. If they upgrade to 4.8, they should also >> >> upgrade their infrastructure - this is a no-brainer. In Lucene trunk we >> >> switch to Java 8 as soon as it is released (in 10 days). >> >> >> >> Now the good things: We don't need to support JRockit anymore, no need >> >> to >> >> support IBM J9 in trunk (unless they release a new version based on >> >> Java 8). >> >> >> >> So the vote here is about: >> >> >> >> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all >> >> Java >> >> 7-related issues (FileChannel improvements, diamond operator,...). >> > >> > >> > +1 >> > >> >> >> >> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. >> >> This would make some APIs much nicer. Our infrastructure mostly >> >> supports >> >> this, only ECJ Javadoc linting is not yet possible, but forbidden-apis >> >> supports Java 8 with all its crazy new stuff. >> > >> > >> > -1 I think a move to Java 8 is worth only if and when Java 8 has proven >> > to >> > be stable, also I don't think (that's another thread though) we're (and >> > should be) moving fast towards release 5, so there's likely plenty of >> > time >> > for having Java 8 out for some time before we have 5.0 out. >> > >> > Tommaso >> > >> >> >> >> >> >> You can vote separately for both items! >> >> >> >> Uwe >> >> >> >> ----- >> >> Uwe Schindler >> >> H.-H.-Meier-Allee 63, D-28213 Bremen >> >> http://www.thetaphi.de >> >> eMail: u...@thetaphi.de >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> 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
