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
