I tend to think Java 8 still requires a fair share of testing before it'll make it to production... Check out this recent marvel :)
http://marc.info/?l=openjdk-compiler-dev&m=139410546908373&w=2 On Mon, Mar 10, 2014 at 1:37 PM, Jan Høydahl <jan....@cominvent.com> wrote: > +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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
