Its too sad this decision isn't about what is best for attracting new developers, but instead corrupted by corporate policies around JVM versions and the like.
what a shame, open source isn't supposed to be like that. On Mon, Mar 10, 2014 at 5:46 AM, Uwe Schindler <u...@thetaphi.de> wrote: > Hi, > > it looks like we all agree on the same: > > +1 for Lucene 4.x requirement on Java 7. > -1 to not change trunk (keep it on Java 7,too). > > I will keep this vote open until this evening, but I don't expect any other > change. Indeed, there are no real technical reasons to not move. > > I was expecting the fact that the majority -1 on trunk with Java 8. Simon > said, that we may provide closures in the API in the future, but for our > public API that’s still not a must to actually be on Java 8: If we define our > interfaces nicely (using 1-method functional *interface*, no abstract > classes, only interfaces!), everybody on Java 8 can use closures although > Lucene is on Java 7. Maybe in the future we can have a TokenStream variant > with push-semantics using closures! > > I opened https://issues.apache.org/jira/browse/LUCENE-5514 to manage the > backport. The initial patch covering many commits is already ready to commit. > I just have to take the time until this vote finishes, to check that all > stuff like smoke tester, javadocs linting,... work as expected. > > Theoretically, we might also only change Lucene 4.x's build to Java 7 without > any code change, but we should also provide some real reason for the move! > Otherwise people will start to complain and "patch" Lucene 4.8 to still > support Java 6 and Android mobile phones :-) > > The backported issues bring real improvements to the user and make usage with > Java 6 impossible: > - Use of FileChannel's new open method (this allows deleting files while open > on Windows) > - Use of Long.compare(long,long) and Integer.compare(int,int) instead of the > hacks with Long.signum() or 3 way branches. Hotspot aggressively handles > those methods and they may get intrinsics in the future. So we should really > use them. > The above issue has primarily focused on backporting these changes and > reverting "quick fix commits in 4.x" (after failed Jenkins builds). > > In the future we have now only one supported Java version, so backports are > very easy. Also releasing 4.x is much easier now, because Javadocs look fine > now by default. We can now also proceed with using diamond operator and > try-with-resources (much more important than diamond), without the need for > backports being hard. So feel free to commit any Java 7 syntax once > LUCENE-5514 is resolved! > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > >> -----Original Message----- >> From: Uwe Schindler [mailto:u...@thetaphi.de] >> Sent: Saturday, March 08, 2014 5:17 PM >> To: dev@lucene.apache.org >> Subject: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once >> officially released) >> >> 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,...). >> [.] 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. >> >> 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
