Polygon.fromGeoJSON throws NullPointerException instead of ParseException when coordinates is null or an object

Polygon.fromGeoJSON(String) declares throws ParseException and is backed by the package-private SimpleGeoJSONPolygonParser. The parser checks that "coordinates" is an array, and for a MultiPolygon that each element of it is an array, and otherwise throws ParseException("coordinates should be an array, but got: " + o.getClass()) or "elements of coordinates array should be an array, but got: " + o.getClass(). But it stores a JSON null value, and every nested object it skips, as Java null. So for {"type":"Polygon","coordinates":null}, "coordinates":{} or {"type":"MultiPolygon","coordinates":[{}]}, building the message dereferences null and java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "o" is null escapes instead of the ParseException; a catch (ParseException e) does not see it. A string, number or boolean in the same place gets the intended ParseException, and every other message in the class that reports a parsed value concatenates the value itself (+ o, + point, ...), which is null-safe. (An object whose own members trip one of the parser's checks, such as {"type":null}, gets that check's ParseException first.) The input is malformed and is rejected either way: there is no wrong polygon, hang or index effect, only the wrong exception. The two messages came with the parser in LUCENE-7380 (6.2.0, 2016) and are in every release since, including 10.6.0 and main. A null-safe type name in the two messages fixes it.

• SimpleGeoJSONPolygonParser: the package-private parser behind Polygon.fromGeoJSON (Polygon.java:255-257). It "does minimal parsing of a GeoJSON object, to extract either Polygon or MultiPolygon" (SimpleGeoJSONPolygonParser.java:47-51).
• o: the Java value the parser builds for each JSON member value: a List for an array, String, Double, Boolean, or null.

1. In parseObject, a nested object is parsed recursively and then, if that parse throws nothing, dropped as o = null (:146-154); the literal null also gives o = null (:163-165). In parseArray, an object element is added to the list as null (:310-313).
2. The coordinates check (:205-209) is if (o instanceof List == false) { ... throw newParseException("coordinates should be an array, but got: " + o.getClass()); }. null instanceof List is false, so a null o enters the branch, and o.getClass() (:208) throws before the ParseException is created.
3. The MultiPolygon element check in parse() (:86-91) does the same with "elements of coordinates array should be an array, but got: " + o.getClass() (:90).
4. Every other message that reports a parsed value concatenates the value itself, which prints null safely: + o at :177, :182, :189, :231-232 and :239-240; + point at :256; + pointList and + pointList.get(0|1) at :262, :267 and :272.

Main 645d4fe14a20, Polygon.fromGeoJSON on four inputs (a small probe against the build's classes):

{"type":"Polygon","coordinates":"x"} -> ParseException: coordinates should be an array, but got: class java.lang.String at character offset 32; fragment leading to this:
{"type":"Polygon","coordinates":null} -> java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "o" is null
{"type":"Polygon","coordinates":{}} -> java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "o" is null
{"type":"MultiPolygon","coordinates":[{}]} -> java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "o" is null

The same through a Feature geometry with "coordinates":null and a FeatureCollection feature whose MultiPolygon coordinates is {} (an independent reproducer and a devil's-advocate survey). Not affected: type null or {}, Polygon coordinates [{}], [[{}]] or [null] (a literal null inside an array is rejected earlier by parseArray), MultiPolygon [[{}]], geometry null: all give ParseException. So does an object whose members fail the parser's own checks: "coordinates":{"type":null} gives ParseException: type should be a string, but got: null from the nested parse, while {"a":1} gives the NullPointerException.

• Who is hit. Callers of Polygon.fromGeoJSON (core; Polygon is @lucene.experimental) that handle bad input with catch (ParseException e), the only exception the method declares. Nothing in Lucene calls the parser on its own.
• What it takes. Malformed GeoJSON (RFC 7946 requires coordinates to be an array) whose coordinates member is null or an object the parser skips without error (such as {}). No report to the Lucene project since 6.2.0 (2016); likelihood "rare".
• What happens. The unchecked NullPointerException bypasses the ParseException handler, and its message says nothing about the input; on JDKs without helpful NullPointerException messages (JEP 358, on by default since JDK 15) it has no message at all. The recorded runs with assertions on and off behave the same.
• What does not happen. No polygon is returned for the bad input, so nothing wrong is indexed or queried; no hang, no resource use, no state left behind (one parser object per call). Valid GeoJSON is not affected.
• Related, separate fix sites (not part of this bug). Empty Polygon coordinates [] give IndexOutOfBoundsException in parsePolygon (:228, no check there); a bad \u escape gives NumberFormatException (part of LFV-569); deep nesting gives StackOverflowError (a separate finding).

The first line covers the coordinates message (:208), the second the MultiPolygon element message (:90). On a stock build the first expectThrows already fails, so the second is not reached; a scratch copy holding only the second line fails the same way at :90, and with the fix both pass.

As the regression test: the same test, for example as a new method in TestPolygon next to the testIllegalGeoJSON* tests.

cp TestGeoJSONNullCoordinates.java $LUCENE/lucene/core/src/test/org/apache/lucene/geo/
cd $LUCENE && ./gradlew :lucene:core:test --tests org.apache.lucene.geo.TestGeoJSONNullCoordinates -Ptests.seed=DEADBEEF
# assertions off: add -Ptests.asserts=false (same result)

# gradle, main 645d4fe14a20, seed DEADBEEF (assertions on; the same with -Ptests.asserts=false)
TestGeoJSONNullCoordinates > testNonArrayCoordinates FAILED
    junit.framework.AssertionFailedError: Unexpected exception type, expected ParseException but got java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "o" is null
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:B0DEAA79794FCE0A]:0)
        at app//org.apache.lucene.tests.util.LuceneTestCaseParent.expectThrows(LuceneTestCaseParent.java:1437)
        at app//org.apache.lucene.tests.util.LuceneTestCaseParent.expectThrows(LuceneTestCaseParent.java:1418)
        at app//org.apache.lucene.geo.TestGeoJSONNullCoordinates.testNonArrayCoordinates(TestGeoJSONNullCoordinates.java:26)

        Caused by:
        java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "o" is null
            at org.apache.lucene.geo.SimpleGeoJSONPolygonParser.parseObject(SimpleGeoJSONPolygonParser.java:208)
            at org.apache.lucene.geo.SimpleGeoJSONPolygonParser.parse(SimpleGeoJSONPolygonParser.java:65)
            at org.apache.lucene.geo.Polygon.fromGeoJSON(Polygon.java:256)
            at org.apache.lucene.geo.TestGeoJSONNullCoordinates.lambda$testNonArrayCoordinates$0(TestGeoJSONNullCoordinates.java:28)

# release jars 10.6.0 (assertions on and off): the same failure at SimpleGeoJSONPolygonParser.java:208

• The branch's only job is the ParseException. SimpleGeoJSONPolygonParser.java:205-209 and :86-91 test "value is not a List" and do nothing but throw ParseException. null and objects are two of the five non-array JSON value kinds; for the other three the branch works.
• Sibling messages. :177, :182, :189, :231-232, :239-240, :256, :262, :267 and :272 concatenate the value (o, point or pointList), which is null-safe, and those inputs get ParseException.
• Contract and tests. Polygon.java:255 declares only throws ParseException. TestPolygon.testIllegalGeoJSONExtraCrapAtEnd (:268-281), testIllegalGeoJSONLinkedCRS (:283-302) and testIllegalGeoJSONMultipleFeatures (:305-346) expect ParseException; no test expects a NullPointerException, and none asserts the two messages.
• Intent. LUCENE-7380 (#8433): the parser "throws an exception otherwise" for inputs it cannot handle, and the author wrote before committing "I added class level javadocs, and improved the ParseException throwing". git blame attributes both messages and the o = null branches to that commit (apart from a reformat).

The strongest case for "intended" (an intended-behaviour checker, and a read-only reviewer from another model family, OpenAI GPT-5.6, which said "not real"): the inputs are not standard GeoJSON; the javadoc ("Parses a standard GeoJSON polygon string") has no @throws and promises no exception type for malformed input; Polygon is @lucene.experimental and the parser calls itself minimal; a throws clause never excludes unchecked exceptions; and the parser has other unchecked exits on malformed input, so "always ParseException" was never achieved.

Why it fails: the claim does not rest on an outside contract but on the parser's own check, which detects exactly this input and tries to throw ParseException; a slip in the message expression stops it. The refuting reviewer conceded that null "reaches a NullPointerException instead of the intended local ParseException branch" and agreed with the root cause. The other unchecked exits are places with no check at all. The argument limits severity (low), not validity.

Two options were run through gradle in a scratch worktree of 645d4fe14a20; A is recommended. A fix conflicts textually with open PR #12295, which rewrites the same two checks but keeps getClass().

In SimpleGeoJSONPolygonParser (:90, :208), plus a small helper.

-              "elements of coordinates array should be an array, but got: " + o.getClass());
+              "elements of coordinates array should be an array, but got: " + typeName(o));
 ...
-          throw newParseException("coordinates should be an array, but got: " + o.getClass());
+          throw newParseException("coordinates should be an array, but got: " + typeName(o));
 ...
+  /** Describes a parsed value for an error message; objects and JSON null are parsed as null. */
+  private static String typeName(Object o) {
+    return o == null ? "an object or null" : o.getClass().toString();
+  }

Trade-offs

• Messages for string, number and boolean values stay exactly as they are (class java.lang.String, ...).
• null and objects both read "but got: an object or null": the parser cannot tell them apart after parsing.
• Error path only: no change to the public API signature, to successful parses or to performance; only the two messages change for null and object values.

What the checks validated

Gradle in a scratch worktree of 645d4fe14a20 (removed afterwards), seed DEADBEEF:

• the repro fails on the stock build and passes with the fix, assertions on and off;
• TestPolygon 16 of 16; all 18 classes of org.apache.lucene.geo incl. the repro, 194 tests, 0 failures (7 skipped in TestTessellator);
• :lucene:core:check -x test with the repro in place: BUILD SUCCESSFUL;
• messages: null and {} give ParseException: coordinates should be an array, but got: an object or null at character offset 32; MultiPolygon [{}] gives elements of coordinates array should be an array, but got: an object or null at character offset 42; "x" still gives ... but got: class java.lang.String ....

Replace + o.getClass() by + o at :90 and :208 (two one-token changes).

-          throw newParseException("coordinates should be an array, but got: " + o.getClass());
+          throw newParseException("coordinates should be an array, but got: " + o);

Trade-offs

The smallest diff and consistent with the rest of the class. But {} then reads "but got: null" (misleading for an object), and string, number and boolean messages change from the class name to the value (for example "but got: x"); no test asserts the old text.

What the checks validated

Same scratch worktree: the repro passes (assertions on) and TestPolygon 16 of 16. Messages: "x" gives but got: x; null, {} and MultiPolygon [{}] all give but got: null.

Have parseObject/parseArray keep a marker (for example an empty map) for nested objects so the messages can say "an object".

Trade-offs

Touches the value model that features arrays and parsePolygon rely on: more change than this bug needs. Not tried.

Method: non-formal (randomized differential testing, then code reading and executed tests). On 2026-10-28 the hunt unit for the GeoJSON and WKT parsers (siblings of #16423) was checking its fix for a per-level path-string memory bug in the same parser: a differential test ran random GeoJSON-like documents through the fixed parser and a renamed copy of the stock one. Both threw NullPointerException on documents with "coordinates": {}. That was not a difference between them, but it was a lead: reading SimpleGeoJSONPolygonParser found the two + o.getClass() messages and the o = null value branches. A 4-test public-API JUnit (null, {}, MultiPolygon [{}], a string control) reproduced it on the stock jar; independent checkers then reproduced it with their own tests, and it was cut to the one-test repro. The finder labelled it semi-formal; it is classed as non-formal because no model, proof or bounded-exhaustive check gave the signal.