In the Cursor based refactoring I've noticed some inefficiencies with the way we deal with Evaluators. For more information about what these are please see the developer documentation on the default partition implementation and how search is conducted on it here .
The Evaluator interface is used to determine whether or not a filter expression accepts a candidate entry. Evaluators have an AST representation of the expression or subexpression they use to determine if the candidate matches the expression filter. Right now we use evaluate( IndexEntry ) which contains the id and value along with the entry if it is pulled from the master table. This is to temporarily store the entry so subsequent evaluation attempts do not have to access the master table again to get the entry. It makes search a lot faster.
I was seeing some use cases in unit tests and Cursor implementations that use evaluators which don't necessarily need to pass in an IndexEntry. Instead they need to pass in a ServerEntry or a Long id for the candidate. In some cases a new IndexEntry object is created just to be able to utilize the Evaluator. So I'm going to change this interface so it adds these additional overloads:
boolean evaluate( IndexEntry<?,E> entry ) throws Exception;
boolean evaluate( Long id ) throws Exception;
boolean evaluate( E entry ) throws Exception;
 - http://cwiki.apache.org/confluence/display/DIRxSRVx11/SearchEngine+and+Optimizer