JSONTestSuite has 2 failures out of 318 tests - is this a back port regression?

[simbo1905]

On branch json-test-suite running:

mvn test -pl json-compatibility-suite

gives:

[ERROR]   Run 256: JsonTestSuiteTest.lambda$createTest$0:49 [File y_object_duplicated_key.json should parse successfully] 
Expecting code not to raise a throwable but caught
  "jdk.sandbox.java.util.json.JsonParseException: The duplicate member name: "a" was already parsed. Location: row 0, col 12.
...
[ERROR]   Run 257: JsonTestSuiteTest.lambda$createTest$0:49 [File y_object_duplicated_key_and_value.json should parse successfully] 
Expecting code not to raise a throwable but caught
  "jdk.sandbox.java.util.json.JsonParseException: The duplicate member name: "a" was already parsed. Location: row 0, col 12.

The other tests pass. Not sure if this is a back port but or expected of upstream.

[simbo1905]

There are specific stress test files in the JSON Test Suite:

1. n_structure_100000_opening_arrays.json - 100KB of opening brackets [[[[...
2. n_structure_open_array_object.json - 250KB of alternating [{[{...

These are intentional stress tests designed to test parser limits, not normal JSON. The StackOverflowError is happening because the Java parser is using recursive descent parsing without depth limits.

This is likely a real matter. Given that if the API ever goes live people will DDoS the parser all the time in the wild this is likely an issue that will have to be addressed before the proposed API ever goes life. There should be a warning about this on the homepage.

[simbo1905]

okay seems that the official suite has some malformed strings that are not UTF8. if the sandbox java API only had a String public method then there would be no way to make a bad string. yet the API also has char[] so someone could incorrectly parse the input to get a string that isn't legal UTF8. malformed data attacks are going to happen in the wild also. so the logic in this repo should attempt to force feed the data to the parser.