@michael-ameri This looks like the right approach, although I am a little surprised it works. Will continue reviewing.

very good contribution. I added the missing javadoc and adopted my tests in #938 while keeping your commit in the correct git history attribution making it possible to merge #938 instead of this one. If you prefer to have multiple PRs merge, that would also be fine to me, I can also adopt my tests afer this one is merged.

@stleary (Although it would be a backwards compatibility breaking change) I would strongly suggest to remove the getter and setter for JSONParserConfiguration from JSONTokener with the merge of this PR and quickly release a new version to minimise the (faulty) adoption of these methods. Within the library these methods are no longer required. An external caller should not call these methods, as they bring the potential to change the behaviour within a running parsing process, which should use the same configuration end to end.

@Simulant87

very good contribution. I added the missing javadoc and adopted my tests in #938 while keeping your commit in the correct git history attribution making it possible to merge #938 instead of this one. If you prefer to have multiple PRs merge, that would also be fine to me, I can also adopt my tests afer this one is merged.

thanks for adding the missing parts! I'm totally fine with closing this PR and merging that one.

@stleary (Although it would be a backwards compatibility breaking change) I would strongly suggest to remove the getter and setter for JSONParserConfiguration from JSONTokener

I completely agree with removing the setter (and then making the field final).

Additionally, I think the JSONParserConfiguration shouldn't be passed as an argument in addition to JsonTokener here :

public JSONArray(JSONTokener x, JSONParserConfiguration jsonParserConfiguration)

Instead, the JSONParserConfiguration of x should be used. (Same principle for JSONObject constructor)

e.g., what would be the correct behavior, if x.getJsonParserConfiguration().isStrictMode() != jsonParserConfiguration.isStrictMode() ?

@stleary (Although it would be a backwards compatibility breaking change) I would strongly suggest to remove the getter and setter for JSONParserConfiguration from JSONTokener

I will look into cleaning it up, but since it's already in released code, and not directly causing a problem, removal is probably not on the table.

What problem does this code solve?

• Fixes NullPointerException due to uninitialized JSONParserConfiguration
• Don't store config instance in JSONArray and JSONObject
• Ensures JSONTokener always has a JSONParserConfiguration instance

Does the code still compile with Java6?
Yes

Risks
Low

Changes to the API?
New API methods have been added

Will this require a new release?
No, but the release cadence will be sped up for this commit.

Should the documentation be updated?
No

Does it break the unit tests?
No. The code was tested manually by defaulting strictmode and then running all unit tests. One test fails (the last case in testValid()), but this will be fixed in a follow up commit. Also manually tested with the unit tests in #934 and #936.

Was any code refactored in this commit?
No

Review status
APPROVED

Starting 3-day comment window

Notes:

• The additional required unit tests in New unit tests for Strict mode using JSONTokener and JSONParserConfiguration #934 and Bugfix: NullPointerException thrown for invalid input on JSONTokener without strict mode #936 will be added in a followup commit.
• testValid() last test case will be skipped on default strictmode test runs
• The JSONTokener config setter will be addressed in a followup commit
• Some aspects of this PR may still be under discussion. Fixes can be done in followup commits after consensus is reached.

@michael-ameri Nice work, resolving multiple issues with minimal code changes.