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 > >
