AtomicIntegerArray deserializer crashes on JSON null (IllegalStateException) — symmetric fix to #3038

[greymoth-jp]

Bug

Deserializing a JSON array that contains a null element into an AtomicIntegerArray crashes with an uncaught IllegalStateException:

new Gson().fromJson("[1,null,3]", AtomicIntegerArray.class);
// throws IllegalStateException: Expected an int but was NULL at line 1 column 4 path $[1]

Root cause

In TypeAdapters.java, the ATOMIC_INTEGER_ARRAY adapter's read() method calls in.nextInt() inside a loop that only catches NumberFormatException:

public AtomicIntegerArray read(JsonReader in) throws IOException {
  List<Integer> list = new ArrayList<>();
  in.beginArray();
  while (in.hasNext()) {
    try {
      int integer = in.nextInt();
      list.add(integer);
    } catch (NumberFormatException e) {
      throw new JsonSyntaxException(e);
    }
  }
  in.endArray();
  ...
}

When the JsonReader is positioned at a NULL token, nextInt() throws IllegalStateException — which is not caught here, so it propagates raw instead of being converted to a JsonSyntaxException.

Relationship to #3038

PR #3038 (merged 2026-06-22) fixed the symmetric issue in AtomicLongArray. That adapter delegates to longAdapter.read(in), which returns null for a JSON null; the fix added an explicit null-check:

Number value = longAdapter.read(in);
if (value == null) {
  throw new JsonSyntaxException("null is not a valid AtomicLongArray element");
}
list.add(value.longValue());

AtomicIntegerArray was not updated with the same treatment.

Expected behaviour

A JSON null element inside an AtomicIntegerArray should throw a JsonSyntaxException (same as AtomicLongArray after #3038), not a raw IllegalStateException.

Suggested fix

Mirror the approach used in the AtomicLongArray adapter — either:

Option A — peek before reading:

while (in.hasNext()) {
  try {
    if (in.peek() == com.google.gson.stream.JsonToken.NULL) {
      throw new JsonSyntaxException("null is not a valid AtomicIntegerArray element");
    }
    int integer = in.nextInt();
    list.add(integer);
  } catch (NumberFormatException e) {
    throw new JsonSyntaxException(e);
  }
}

Option B — delegate to INTEGER type adapter (returns null for JSON null, already handles this safely) and add a null-check, consistent with the AtomicLongArray pattern.

A regression test analogous to the one added in #3038 for AtomicLongArray should also be added.

Environment

• Gson latest main branch (after Throw JsonSyntaxException instead of NullPointerException for a null AtomicLongArray element #3038 merge)
• Reproducible with any Gson version where AtomicIntegerArray deserialization is supported

[Marcono1234]

Are you sure that the IllegalStateException propagates as is to the caller? In my testing it looks like it is wrapped in a JsonSyntaxException as desired, here:

gson/gson/src/main/java/com/google/gson/Gson.java

Lines 1123 to 1124 in c9f3fd5

	} catch (IllegalStateException e) {
	throw new JsonSyntaxException(e);

Side notes:

• Your suggested fix checking for JSON null would probably not suffice; the IllegalStateException would also occur for other unexpected JSON value types, e.g. for [1,true,3].
• Is the exception message you pasted even real (or artificially crafted)? JsonReader's error reporting is not exact in all situations, for example for literals such as null it already advances the column, so for me the actual error message is "... at line 1 column 8 path $[1]" (note the 8 instead of the 4).

[amitmishra11]

Confirmed @Marcono1234's suspicion above: I tested this directly against the current main branch (unmodified):

Gson gson = new Gson();
gson.fromJson("[1,null,3]", AtomicIntegerArray.class);

This throws:

com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected an int but was NULL at line 1 column 8 path $[1]

Not a raw, uncaught IllegalStateException — Gson.fromJson(JsonReader, TypeToken) already catches IllegalStateException and wraps it as JsonSyntaxException (Gson.java around line 1123), same as you found. So the crash as described in this issue doesn't reproduce via the standard fromJson API on the current code.

The one real (minor) difference from the AtomicLongArray fix in #3038 is the exception message/path: today it's the generic "Expected an int but was NULL at line 1 column 8 path $[1]" rather than something AtomicIntegerArray-specific like "null is not a valid AtomicIntegerArray element", and as you noted, the same applies to any other unexpected token type (e.g. [1,true,3]), not just null. That's a much smaller, cosmetic-message improvement rather than a crash fix though, so probably not worth a PR on its own — wanted to close the loop on the reproduction question first.