Hi Luc, I'm OK with you backporting this to 6.0. I think its important for shoring up the API.

On Thu, Mar 3, 2016 at 8:24 AM, Adrien Grand <jpountz@gmail.com> wrote:

Le jeu. 3 mars 2016 à 15:13, Vanlerberghe, Luc <Luc.Vanlerberghe@bvdinfo.com> a écrit :
-          I didn’t leave any public MultiPhraseQuery constructors like you did for PhraseQuery.  Adding a few afterwards shouldn’t break anything though.

I think it's good this way: I added them for PhraseQuer because I thought it should be easy to create simple phrase queries but maybe it was a mistake. MultiPhraseQuery on the other hand is an expert query so I'm totally fine with not having convenience constructors.

-          The private termArrays and positions members could become fixed arrays like you did for PhraseQuery.  This would change the signature of getTermArrays() and getPositions(), so perhaps it should happen now…

Actually I think returning a list is better: with arrays you need to perform a deep copy if you want to make sure that the user cannot change the internal state of the query. We could keep arrays internally and call Collections.unmodifiableList(Arrays.asList(termArrays)) when returning the terms to the user?