JSONObject parsing for self-referencing maps

[ZachsCoffee]

Fix for #701

Edit: without the AbstractConfiguration class

A new configuration class was added for the JSON parser.

• The configuration class can easily accept future additions at configuration without any change at the JSONObject class.
• The default functionality of the JSONObject class is controlled from the JSONParserConfiguration class. This way we can give the possibility for someone to enable the circular dependency check or if we change mid we can make the default functionality to be the check to be one. This change will not affect any other class other than JSONParserConfiguration.
• An already existing case using the circular dependency functionality (not for the Map) here: org.json.JSONObject#populateMap so I left it as is. If we want to change it and respect the new configuration for the check I can make it easily.

[stleary]

@ZachsCoffee BiConsumer is Java 8 feature. Can you find an alternate implementation that only requires Java 7? Sorry, this is a recent decision (see comments in #789 and issue #799) and has not been communicated to the team yet.

[ZachsCoffee]

Yes @stleary I will find an alternative, but I don't have the time today make the change. Probably tomorrow.

[johnjaylward]

@stleary is an alternative still needed if we do the point release off of the 20230618 tag?

[stleary]

@stleary is an alternative still needed if we do the point release off of the 20230618 tag?

@johnjaylward Good point. Here is my take on it:
We have changed the minimum required Java build version in the past, and it has not been a major issue, but there was always a concern that at some point Android developers might get left behind. This was discussed in #614, which really belongs on its own Wiki page. Since requiring Java 8 in 20231018 there have been less than 20 Maven usages, but already one Android developer stuck on Java 7 has come forward. As more people adopt the version due to the CVE, we could have more users reporting problems. What can we offer those users? Well, at least we can tell them that they can compile the jar themselves since it can still be manually built with Java 6. As soon as we start allowing Java 8 features, that will be lost. What should we replace it with? I have not come up with a good answer yet. So, for now, and until we have more clarity on users' limitations, I think it is prudent to require Java 6 compatibility in the code.

[johnjaylward]

I think it is prudent to require Java 6 compatibility in the code.

Would you like a PR to set the current compatible JVM to 1.6, or do you prefer to do the point releases on the older tag though?

If we downgrade the master branch back to 1.6, I think more than a few people will be disappointed.

Doing the point releases on 20230618 (like a 20230618.001) which only has the security updates would be simple enough and still give a path forward for java8 in master.

[stleary]

Would you like a PR to set the current compatible JVM to 1.6, or do you prefer to do the point releases on the older tag though?
If we downgrade the master branch back to 1.6, I think more than a few people will be disappointed.

I don't think any version-specific changes are needed now, and hopefully, will never be needed. This is just a developer restriction to ensure the source code is compatible with java6 (or possibly 7?). If a user is stuck on an earlier Java version, they will just have to build manually, and won't benefit from the unit tests.

Doing the point releases on 20230618 (like a 20230618.001) which only has the security updates would be simple enough and still give a path forward for java8 in master.

After 20 years at Cisco, I hope never to see another point release (we called them hotfixes). That was a consequence of a perceived need to maintain multiple release trains, which I think was error-prone, effort-intensive, and overall an expensive miscalculation.

[johnjaylward]

I don't think any version-specific changes are needed now, and hopefully, will never be needed. This is just a developer restriction to ensure the source code is compatible with java6 (or possibly 7?).

Without some kind of build restriction, I think it will be hard to ensure any kind of source compatibility.

Maybe what you are suggesting is that we re-add the "build-1.6" build that was just compiling the src/main classes but our actual release will be built against JDK 8?

[stleary]

For now, I don't mind doing a manual check during the review process. I believe that Gradle and Maven releases won't build with Java 6, and you can't even install the JDK on a Mac with a recent OS.

[johnjaylward]

For now, I don't mind doing a manual check during the review process. I believe that Gradle and Maven releases won't build with Java 6, and you can't even install the JDK on a Mac with a recent OS.

See #815

[stleary]

@ZachsCoffee I think your branch may be out of date:

From https://github.com/ZachsCoffee/JSON-java

• branch fix_for_701_without_abstract -> FETCH_HEAD
  hint: You have divergent branches and need to specify how to reconcile them.
  hint: You can do so by running one of the following commands sometime before
  hint: your next pull:
  hint:
  hint: git config pull.rebase false # merge
  hint: git config pull.rebase true # rebase
  hint: git config pull.ff only # fast-forward only
  hint:
  hint: You can replace "git config" with "git config --global" to set a default
  hint: preference for all repositories. You can also pass --rebase, --no-rebase,
  hint: or --ff-only on the command line to override the configured default per
  hint: invocation.
  fatal: Need to specify how to reconcile divergent branches.

[stleary]

@ZachsCoffee Thanks for your PR. It turns out JSONParserConfiguration was added in #823, and I am merging your unit tests into #846 so they don't get lost. Closing this PR since all of the functionality is implemented elsewhere.