Hi Doron and Otis,
My view is that this bug is a problem in FuzzyQuery, not in PriorityQueue or BooleanQuery. It is the caller's duty to create a priority queue with a sensible size, and it's not BooleanQuery's fault that other classes are using its getMaxClauseCount() wrongly. Moreover, changing PriorityQueue or BooleanQuery in the way Doron did, might potentially have side-effects because they are used in many places in Lucene. How do we know that nowhere in Lucene will we ever need a priority queue with a million elements?
Therefore I suggest a different patch, changing only FuzzyQuery.
he idea in the patch I'm attaching is that while FuzzyQuery is allowed to create BooleanQuery.getMaxClauseCount() clauses, it doesn't have to do so, and doesn't need to create a priority queue of that size when this number is huge. I added to FuzzyQuery its own maxClauseCount (with per-instance getter/setter methods) and FuzzyQuery will never try to create more than this number of clauses, even if Boolean.getMaxClauseCount() is huge.
I set FuzzyQuery's default maxClauseCount to 1024, for backward compatibility (this is what happens today when you use BooleanQuery's defaults). However, it is likely that a user will want to set this number much lower than that. In fact, the whole idea of the priority queue is that it may be enough to take only a small number the most similar terms, so setting a FuzzyQuery's maxClauseCount to 100 or even 10 makes sense to me. This new feature is an added benefit of my patch.
My patch also includes Javadoc changes describing the new feature, and a new test case that failed before the fix, and succeeds after this patch.