+1 for 4.x on Java7 -0 for rushing trunk to 8 now Rob, in my view, what's best for Lucene as a project is tightly linked to what's best for its users. And the users tend do be corporate. I think users are so important that we should even consider rolling a bugfix-release from the 4.7 branch after 4.8 is released, if there is sufficient user demand for it. I hope we'll see trunk on Java8 before summer, but *today* is a tad too aggressive :)
-- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 10. mars 2014 kl. 12:57 skrev Robert Muir <rcm...@gmail.com>: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
