[NUAAwqy]

Problem

RuntimeTypeAdapterFactory's read path calls labelJsonElement.getAsString() without checking the element's shape. When the JSON's type field is null or a nested object/array, JsonElement.getAsString() throws a bare UnsupportedOperationException ("JsonNull" / "JsonObject"), which escapes the JsonParseException contract the adapter already uses for a missing type field (and which Gson.fromJson does not wrap).

Repro:

RuntimeTypeAdapterFactory<BillingInstrument> rta =
    RuntimeTypeAdapterFactory.of(BillingInstrument.class).registerSubtype(CreditCard.class);
Gson gson = new GsonBuilder().registerTypeAdapterFactory(rta).create();
gson.fromJson("{\"type\":null}", BillingInstrument.class);
// actual: java.lang.UnsupportedOperationException: JsonNull
// expected: com.google.gson.JsonParseException

Fix

Reject non-primitive label values with a JsonParseException before calling getAsString(), mirroring the existing missing-field error. Only the exception type and message change for these inputs; primitive labels (strings, and numbers/booleans via their existing getAsString() behavior) are untouched, so no previously working input changes result. Both read paths are covered (maintainType on and off).

Tests

Added testDeserializeNullTypeField, testDeserializeNullTypeFieldWithMaintainType and testDeserializeObjectAsTypeField to RuntimeTypeAdapterFactoryTest.

Before the fix (RED), mvn -pl extras test -Dtest=RuntimeTypeAdapterFactoryTest:

[ERROR] Tests run: 17, Failures: 3, Errors: 0, Skipped: 0
  testDeserializeNullTypeField:151 unexpected exception type thrown; expected:<com.google.gson.JsonParseException> but was:<java.lang.UnsupportedOperationException>
  testDeserializeNullTypeFieldWithMaintainType:169 unexpected exception type thrown; expected:<com.google.gson.JsonParseException> but was:<java.lang.UnsupportedOperationException>
  testDeserializeObjectAsTypeField:186 unexpected exception type thrown; expected:<com.google.gson.JsonParseException> but was:<java.lang.UnsupportedOperationException>
Caused by: java.lang.UnsupportedOperationException: JsonNull
Caused by: java.lang.UnsupportedOperationException: JsonObject

After the fix (GREEN), same command:

[INFO] Tests run: 17, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS

Full extras module suite (mvn -pl extras test, JDK 17):

[INFO] Tests run: 33, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS

AI assistance used for discovery; changes were verified by running the test suite locally.

[Marcono1234]

Just as side note: JsonArray also supports getAsString, but only if the array contains a single element.

Not sure if it is worth to keep supporting that. It seems rather unlikely to me that users rely on this (?).

[NUAAwqy]

Good point — thanks for the side note. The current change keeps the existing behavior for single-element JsonArray inputs untouched (the value still goes through nextElement.getAsString()), so this PR does not regress it. Tightening to isJsonPrimitive() would be a separate behavioral change, so I would prefer to keep this PR scoped to the null / wrong-type case unless you feel otherwise.

[Marcono1234]

The current change keeps the existing behavior for single-element JsonArray inputs untouched (the value still goes through nextElement.getAsString()), so this PR does not regress it.

Are you sure? The isJsonPrimitive() check you added comes before the getAsString() call. So I think it would reject for example {"type": ["CreditCard"], ...}.

Or maybe there was a misunderstanding; I am talking about labelJsonElement being a JSON array with a single element.

---

Tightening to isJsonPrimitive() would be a separate behavioral change

But isn't that exactly what your PR already does? Adding a isJsonPrimitive() check?

I am not saying that this is necessarily problematic, as mentioned in my original comment. It seems unlikely that users rely on the previous JsonArray handling.

[NUAAwqy]

You are right, and thanks for pushing back — I had misread the order of the checks. The isJsonPrimitive() guard runs before getAsString(), so a single-element array label such as {"type": ["CreditCard"]} is now rejected, whereas previously it went through JsonArray.getAsString() and deserialized fine. That is a real behavior change, not a no-op.

Given your note that relying on this lenient path seems unlikely, I kept the strict behavior and pinned it with a regression test (testDeserializeSingleElementArrayAsTypeField) so the decision is explicit. If you would rather preserve the old lenient single-element-array path, I'm happy to special-case it instead.