You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Inconsistent null Handling Across JSONObject Construction Paths #1049
The codebase I'm working on uses this library extensively—across about 22,000 files. Is there a way to enable a system-wide configuration to allow NativeNull and overrideDuplicateKey?
To solve this, we could introduce a global, system-wide configuration state while keeping the individual JSONParserConfiguration objects immutable.
We could add a thread-safe static reference (like an AtomicReference) to hold a default global configuration. It would look something like this for the user:
Java
// 1. Define your custom configuration
JSONParserConfiguration myConfig = new JSONParserConfiguration()
.withUseNativeNulls(true)
.withOverwriteDuplicateKey(true);
// 2. Set it globally (do this once during application startup)
JSONParserConfiguration.setGlobalConfiguration(myConfig);
This approach maintains backward compatibility but gives users a simple "set-and-forget" option so they don't have to pass the config object into every single JSONObject or JSONArray constructor.
Let me know if you think this is a good direction, and I'd be happy to put together a PR!
Activity
stleary commentedon Apr 4, 2026
@venkat-cheenu Thanks for bringing this up. This is a known problem for map parsing. For example, see #296.
For now, you can use these workarounds:
Output:
However, it might be reasonable to update the code to accept nulls in maps by default when running in strict mode. Would this work for you?
venkat-cheenu commentedon Apr 4, 2026
Thanks for the detailed comment. @stleary
The codebase I'm working on uses this library extensively—across about 22,000 files. Is there a way to enable a system-wide configuration to allow NativeNull and overrideDuplicateKey?
stleary commentedon Apr 4, 2026
@venkat-cheenu Do you have any suggestions on how to do this?
venkat-cheenu commentedon Apr 5, 2026
Hi @stleary,
To solve this, we could introduce a global, system-wide configuration state while keeping the individual JSONParserConfiguration objects immutable.
We could add a thread-safe static reference (like an AtomicReference) to hold a default global configuration. It would look something like this for the user:
Java
This approach maintains backward compatibility but gives users a simple "set-and-forget" option so they don't have to pass the config object into every single JSONObject or JSONArray constructor.
Let me know if you think this is a good direction, and I'd be happy to put together a PR!
venkat-cheenu commentedon Apr 5, 2026
Draft PR : #1050