Skip to content

Throw JsonSyntaxException instead of NullPointerException for a null AtomicLongArray element - #3038

Merged
eamonnmcmanus merged 1 commit into
google:mainfrom
vasiliy-mikhailov:fix/atomiclongarray-null-element
Jun 22, 2026
Merged

eamonnmcmanus merged 1 commit into
google:mainfrom
vasiliy-mikhailov:fix/atomiclongarray-null-element

Conversation

@vasiliy-mikhailov

Copy link
Copy Markdown
Contributor

Deserializing a JSON array that contains a null element into an AtomicLongArray throws a raw NullPointerException:

new Gson().fromJson("[1,null,3]", AtomicLongArray.class); // NullPointerException

The array adapter calls longAdapter.read(in).longValue(), and the element adapter returns null for a JSON null, so longValue() is invoked on null.

This throws a JsonSyntaxException for the null element instead, consistent with how the Long adapter already reports malformed numbers. Includes a regression test.

@google-cla

google-cla Bot commented Jun 21, 2026

Copy link
Copy Markdown

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@Marcono1234 Marcono1234 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot!

This looks reasonable; though the direct project members might have additional comments on this.

Are you able to sign the CLA?

(As side note, while the adapter for AtomicLong has a similar code pattern, that one is most likely not affected because the longAdapter is fully controlled by Gson, so only a JSON null could lead to a Java null but the adapter is nullSafe().)

JsonSyntaxException e =
assertThrows(
JsonSyntaxException.class, () -> gson.fromJson("[1,null,3]", AtomicLongArray.class));
assertThat(e).hasMessageThat().contains("null");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that the message is fully controlled by Gson, maybe it would be better to check the exact message with isEqualTo?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea — switched to isEqualTo("null is not a valid AtomicLongArray element") to assert the exact message. Thanks!

…lement

Deserializing a JSON array with a null element into AtomicLongArray
(e.g. [1,null,3]) called longValue() on the null returned by the element
adapter, throwing a NullPointerException. Throw a JsonSyntaxException for the
null element, consistent with how the Long adapter reports malformed numbers.
Adds a regression test.
@vasiliy-mikhailov
vasiliy-mikhailov force-pushed the fix/atomiclongarray-null-element branch from 9993b74 to a872de0 Compare June 21, 2026 18:20
@vasiliy-mikhailov

Copy link
Copy Markdown
Contributor Author

CLA is signed now. Also agree on AtomicLong — its longAdapter is nullSafe(), so only AtomicLongArray (which reads elements directly) hits the raw NPE, which is why the fix is scoped to just that adapter.

@eamonnmcmanus eamonnmcmanus left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@eamonnmcmanus
eamonnmcmanus merged commit e4f54f7 into google:main Jun 22, 2026
20 checks passed
yusmer96-maker added a commit to yusmer96-maker/gson that referenced this pull request Sep 3, 2026
Gson.fromJson is documented to throw JsonSyntaxException for malformed
input, but four groups of built-in adapters let raw NumberFormatException,
IllegalArgumentException or NullPointerException escape to the caller.
Callers that guard with catch (JsonParseException) do not catch these.

This is the same defect class already fixed for AtomicLongArray in google#3038
and currently open for AtomicIntegerArray in google#3047 / google#3095. In each case
the neighbouring target type already behaves correctly.

- BitSet with a malformed number
- null elements in primitive arrays (int[], double[], char[], ...)
- double/float with a malformed number
- null elements in collections that reject them (TreeSet, ArrayDeque,
  PriorityQueue, EnumSet)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants