Java 1.6 compatibility.

[skreutzer]

Builds with OpenJDK 1.6 and 1.7.

[stleary]

This was brought up in #181. Are you asking for the project to maintain compatibility with OpenJDK 1.6? Do you have a use case?

[skreutzer]

I'm only suggesting 1.6 compatibility, since it seems you don't really need language features specific to later versions. My target system is a virtual private server, which has only Java 1.6 VMs available to it from configured software repositories, so I'm going to use JSON-java code without multi-catch regardless of whether you accept such change into the official repository or not. Additionally, I'll only use classes for JSON to XML conversion, because I talk to a RESTful API that doesn't support anything else than JSON as hypermedia format, and my client is part of XML based workflows. My software isn't related to Android in any way, it doesn't use the official jar releases nor the POM you seem to have somewhere. I also don't care about 1.7 or 1.8 being more performant, because the workflows are allowed to take some time, while, at the same time, 1.6 compiled bytecode will run on newer VM implementations, therefore I guess such bytecode would benefit from performance and security improvements to some extend. If I would have to choose between a somewhat slower way to work with JSON under 1.6 SE or no (easy) way at all, I obviously prefer the first.

In my opinion, you don't necessarily have to change your source and target versions, but I don't see how it should be of harm if the code successfully builds for 1.6 too. You can make it official policy that this project should only support most recent VM versions, but I guess you're not going to enforce this by introducing arbitrary incompatibilities here and there, right?

That's my perspective so far. The only reason I created this pull request was that git clones of this repository could compile for 1.6 so other developers wouldn't turn away as soon as they see the errors in such environment, which seem to be a lot instead of only the two lines that need this small adjustment.

[stleary]

What problem does this code solve?
Restores 6.0 compatibility. Although not a project goal, there is a use case for people who want to compile with OpenJDK 6.0. It would be reasonable to provide support if it can be done without detracting from the code.

Changes to the API?
No.

Changes to how the code behaves?
No.

Does it break the unit tests?
No; and no additional tests will be added.

Will this require a new release?
Not required, but this is a good time to roll up the changes since Nov 2015.

Should the documentation be updated?
Yes. In addition to documenting 6.0, some text should be included for an OSGi-compatible jar file,
should we move ahead with that in the release build.