So what are we thinking of here for bringing the code up to java 7? One approach would be this massive effort to use, say, diamonds. You know, a checkin of probably all the files in Solr and Lucene. What the heck, let's re-format it all at the same time. And while we're at it....
OK, That's Not Going To Happen. Is the sense here that moving forward with Java 7 idioms will be on an as-needed basis? One refactoring mantra is you should only change stuff you're working on, not unrelated bits of code. On Sat, Mar 8, 2014 at 11:08 AM, Uwe Schindler <u...@thetaphi.de> wrote: > From: Robert Muir [mailto:rcm...@gmail.com] >> On Sat, Mar 8, 2014 at 8:47 AM, Uwe Schindler <u...@thetaphi.de> wrote: >> > And let's also move trunk to Java 8 then. >> > >> > My suggestion is either: >> > - Backport all Java 8 changes from trunk to 4.x (and reassign fix >> > versions to 4.8) >> >> Assuming you mean java7, +1 :) > > Thanks, sorry for the typo. > >> > - Or re-branch trunk to branch_4x, incorporating *all* changes from >> > trunk (so "svn rm branch_4x; svn cp trunk branch_4x") >> > >> >> I don't want this: there are some api problems to be resolved in trunk. I am >> unhappy about StoredDocument/IndexableDocument, which is intended to >> remove the confusion around "not getting your whole document back" >> when things arent stored: because docvalues fields appear in the stored >> document. so this really needs to be sorted out. > > I agree. At the time when we splitted the APIs, DocValues was not yet matured > in 4.x and trunk. I would love to have the StoredIndexableDocument stuff in > Lucene, it is now pending since 1.5 years in trunk (since my GSoC student did > it). I agree, we need to improve the API! But this would not have prevented > me from releasing it. It is not worse than the duplicate Sorter API, you > resolved last week :-) So feel free to improve the API, too! > > Once we agree here (I will add a separate vote now to move to Java 7 in > branch 4.x), I will open a back port issue and try to back port as much stuff > as possible. The first thing would be stuff like reverting commits to work > around missing Long.compare/Integer.compare in Java 6. > > Uwe > > > --------------------------------------------------------------------- > 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
