[LUCENE-7061] fix remaining api issues with XYZPoint classes

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 6.0
• Lucene Fields: New
• Assignee: Unassigned
• Reporter: Robert Muir
• Created: 02/Mar/16 20:01
• Updated: 28/Aug/22 14:51
• Resolved: 02/Mar/16 22:30

Description

There are still some major problems today:

XYZPoint.newRangeQuery has "brain damage" from variable length terms. nulls for open ranges make no sense: these are fixed-width types and instead you can use things like Integer.maxValue. Removing the nulls is safe, as we can just switch to primitive types instead of boxed types.

XYZPoint.newRangeQuery requires boolean arrays for inclusive/exclusive, but thats just more brain damage. If you want to exclude an integer, you just subtract 1 from it and other simple stuff.

For the apis, this means Instead of:

public static Query newRangeQuery(String field, Long lowerValue, boolean lowerInclusive, Long upperValue, boolean upperInclusive);
  
public static Query newMultiRangeQuery(String field, Long[] lowerValue, boolean lowerInclusive[], Long[] upperValue, boolean upperInclusive[]);

we have:

public static Query newRangeQuery(String field, long lowerValue, long upperValue);
public static Query newRangeQuery(String field, long[] lowerValue, long[] upperValue);

PointRangeQuery is horribly complex due to these nulls and boolean arrays, and need not be. Now it only works "inclusive" and is much simpler.

XYZPoint.newSetQuery throws IOException, just creating the query. This is very confusing and unnecessary (no i/o happens).

LatLonPoint's bounding box query is not inclusive like the other geo. And the test does not fail!

I also found a few missing checks here and there while cleaning up.