[labkey-jeckels]

Fixes #1091.

When a document repeats the same keys across many objects, such as an array of rows, each parsed JSONObject holds its own copy of every key String. With this change, JSONObject reuses the first instance of each key read by the same JSONTokener. As discussed in the issue, it is on by default and controlled by a new JSONParserConfiguration.withMaxSharedKeys(int):

• 1000 (default): share up to the first 1000 distinct keys per parse
• 0: no sharing, the behavior before this change
• -1 (UNLIMITED_SHARED_KEYS): no limit

The limit bounds the extra memory for input with many unique keys. The map is held by the tokener and released with it.

Why the first N keys

Once the limit is reached, new keys are not added, and keys already in the map stay shared. I considered two alternatives:

• LRU eviction would recover when a document begins with many unique keys, such as an object keyed by IDs, before the repeated rows. But if rows have more distinct keys than the limit, they are always read in the same order, so each key is evicted just before it repeats and nothing is shared. Rows are the case this change targets. LRU also updates its access order on every lookup and uses more memory per entry.
• Clearing the map at the limit also recovers from unique keys at the start, at no cost per lookup, but it shares little when rows have more keys than the limit, and its behavior is harder to explain.

Keeping the first N shares the most in the row case and is the simplest to reason about. Input that starts with many unique keys can raise the limit or use -1.

Inputs that behave differently

None. With any setting, every input parses to the same values, types, and toString() output as before. The only observable difference is String identity: with sharing on, equal keys in different objects from the same parse are the same instance. Values are never shared.

Measurements (JDK 17, retained heap after GC)

Payload	withMaxSharedKeys(0)	Default (1000)
10,000 rows × 30 keys	39.5 MB, 84.5 ms	23.4 MB (−40.6%), 84.8 ms
100,000 unique keys in one object	11.4 MB, 26.1 ms	11.4 MB, 26.7 ms

New tests in JSONParserConfigurationTest cover the setting; sharing across rows, nested objects, and arrays; values staying unshared; the limit; unlimited; separate parses; unchanged output; and strict and lenient syntax. All tests pass, including with the test-strict-mode profile.

I dedicate this contribution to the public domain, consistent with the project's license.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[stleary]

What problem does this code solve?
Fixes an issue where a JSON doc with many repeated key strings consumes much heap space

Risks
Low:

• The Javadocs refer to 'one parse', but the actual lifetime is 'one tokener'.
• Users with many small JSON docs could allocate many hashtables unless they use the workaround of disabling the shareKeys map.

Neither of these are dealbreakers

Changes to the Existing Behavior
Tokener now allocates and uses a hashmap of shared keys.

Changes to the API
New option in JSONParserConfiguration

Will this require a new release?
No

Should the documentation be updated?
No

Unit Tests
New unit tests were added

Refactoring
No

Review status
APPROVED

Starting 3-day comment window