Backups/JSON-java
1
0
Fork 0
mirror of https://github.com/stleary/JSON-java.git synced 2025-08-02 11:05:28 -04:00
Code Issues Projects Releases Wiki Activity

rewrite - first commit

Browse Source
This commit is contained in:
stleary 2020-07-25 12:27:20 -05:00
parent 98cd8ef8b2
commit 879fba3f7f
1 changed files with 81 additions and 97 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

178
README.md
View File

@ -5,25 +5,29 @@ JSON in Java [package org.json]
**[Click here if you just want the latest release jar file.](https://repo1.maven.org/maven2/org/json/json/20200518/json-20200518.jar)**
JSON is a light-weight, language independent, data interchange format.
See http://www.JSON.org/
# Overview
The files in this package implement JSON encoders/decoders in Java.
It also includes the capability to convert between JSON and XML, HTTP
headers, Cookies, and CDL.
[JSON](http://www.JSON.org/) is a light-weight, language independent, data interchange format.
This is a reference implementation. There are a large number of JSON packages
in Java. Perhaps someday the Java community will standardize on one. Until
then, choose carefully.
The JSON-Java package is a reference implementation that demonstrates how to parse JSON documents into Java objects, and generate new JSON documents from the Java classes.
The license includes this restriction: "The software shall be used for good,
not evil." If your conscience cannot live with that, then choose a different
package.
Project goals include:
* Reliable and consistent results
* Adhere to the JSON specification
* Easy to build, use, and include in other projects
* No external dependencies
* Fast execution, low memory footprint
* Maintain backwards compatibility
* Designed and tested to use on Java 1.6 - 1.11
The package compiles on Java 1.6-1.8.
The files in this package implement JSON encoders and decoders. The package can also convert between JSON and XML, HTTP headers, Cookies, and CDL.
Recently [#515 Merge tests and pom and code](https://github.com/stleary/JSON-java/pull/515), the structure of the project changed from a flat directory containing all of the Java files to a directory structure that includes unit tests and several build tools to build the project jar and run the unit tests. If you have difficulty using the new structure, please open an issue so we can work through it.
The license includes this restriction: ["The software shall be used for good, not evil."](https://en.wikipedia.org/wiki/Douglas_Crockford#%22Good,_not_Evil%22) If your conscience cannot live with that, then choose a different package.
# Build Instructions
The org.json package can be built from the command line, Maven, and Gradle. The unit tests can be executed from Maven, Gradle, or individually in an IDE e.g. Eclipse.
**Building from the command line**
*Build the class files from the package root directory src/main/java*
@ -31,7 +35,7 @@ Recently [#515 Merge tests and pom and code](https://github.com/stleary/JSON-jav
javac org\json\*.java
````
*Build the jar file*
*Create the jar file in the current directory*
````
jar cf json-java.jar org/json/*.class
````
@ -66,6 +70,65 @@ java -cp .;json-java.jar Test
*You can only run the unit tests with Maven or Gradlew.*
# Unit tests
The test suite can be executed with Maven by running:
```
mvn clean test
```
The test suite can be executed with Gradlew by running:
```
gradlew clean build test
```
# Notes
**Recent directory structure change**
_Due to a recent commit - [#515 Merge tests and pom and code](https://github.com/stleary/JSON-java/pull/515) - the structure of the project has changed from a flat directory containing all of the Java files to a directory structure that includes unit tests and several tools used to build the project jar and run the unit tests. If you have difficulty using the new structure, please open an issue so we can work through it._
**Implementation notes**
Numeric types in this package comply with
[ECMA-404: The JSON Data Interchange Format](http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf) and
[RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format](https://tools.ietf.org/html/rfc8259#section-6).
This package fully supports `Integer`, `Long`, and `Double` Java types. Partial support
for `BigInteger` and `BigDecimal` values in `JSONObject` and `JSONArray` objects is provided
in the form of `get()`, `opt()`, and `put()` API methods.
Although 1.6 compatibility is currently supported, it is not a project goal and may be
removed in some future release.
In compliance with RFC8259 page 10 section 9, the parser is more lax with what is valid
JSON than the Generator. For Example, the tab character (U+0009) is allowed when reading
JSON Text strings, but when output by the Generator, tab is properly converted to \t in
the string. Other instances may occur where reading invalid JSON text does not cause an
error to be generated. Malformed JSON Texts such as missing end " (quote) on strings or
invalid number formats (1.2e6.3) will cause errors as such documents can not be read
reliably.
Some notable exceptions that the JSON Parser in this library accepts are:
* Unquoted keys `{ key: "value" }`
* Unquoted values `{ "key": value }`
* Unescaped literals like "tab" in string values `{ "key": "value with an unescaped tab" }`
* Numbers out of range for `Double` or `Long` are parsed as strings
**Unit Test Conventions**
Test filenames should consist of the name of the module being tested, with the suffix "Test".
For example, <b>Cookie.java</b> is tested by <b>CookieTest.java</b>.
<b>The fundamental issues with JSON-Java testing are:</b><br>
* <b>JSONObjects</b> are unordered, making simple string comparison ineffective.
* Comparisons via **equals()** is not currently supported. Neither <b>JSONArray</b> nor <b>JSONObject</b> override <b>hashCode()</b> or <b>equals()</b>, so comparison defaults to the <b>Object</b> equals(), which is not useful.
* Access to the <b>JSONArray</b> and <b>JSONObject</b> internal containers for comparison is not currently available.
<b>General issues with unit testing are:</b><br>
* Just writing tests to make coverage goals tends to result in poor tests.
* Unit tests are a form of documentation - how a given method actually works is demonstrated by the test. So for a code reviewer or future developer looking at code a good test helps explain how a function is supposed to work according to the original author. This can be difficult if you are not the original developer.
* It is difficult to evaluate unit tests in a vacuum. You also need to see the code being tested to understand if a test is good.
* Without unit tests it is hard to feel confident about the quality of the code, especially when fixing bugs or refactoring. Good tests prevents regressions and keeps the intent of the code correct.
* If you have unit test results along with pull requests, the reviewer has an easier time understanding your code and determining if the it works as intended.
# Files
@ -131,33 +194,12 @@ cookie lists.
**XMLTokener.java**: `XMLTokener` extends `JSONTokener` for parsing XML text.
Unit tests are now included in the project, but require Java 1.8 at the present time. This will be fixed in a forthcoming commit.
Numeric types in this package comply with
[ECMA-404: The JSON Data Interchange Format](http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf) and
[RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format](https://tools.ietf.org/html/rfc8259#section-6).
This package fully supports `Integer`, `Long`, and `Double` Java types. Partial support
for `BigInteger` and `BigDecimal` values in `JSONObject` and `JSONArray` objects is provided
in the form of `get()`, `opt()`, and `put()` API methods.
# Release history:
Although 1.6 compatibility is currently supported, it is not a project goal and may be
removed in some future release.
In compliance with RFC8259 page 10 section 9, the parser is more lax with what is valid
JSON than the Generator. For Example, the tab character (U+0009) is allowed when reading
JSON Text strings, but when output by the Generator, tab is properly converted to \t in
the string. Other instances may occur where reading invalid JSON text does not cause an
error to be generated. Malformed JSON Texts such as missing end " (quote) on strings or
invalid number formats (1.2e6.3) will cause errors as such documents can not be read
reliably.
Some notable exceptions that the JSON Parser in this library accepts are:
* Unquoted keys `{ key: "value" }`
* Unquoted values `{ "key": value }`
* Unescaped literals like "tab" in string values `{ "key": "value with an unescaped tab" }`
* Numbers out of range for `Double` or `Long` are parsed as strings
Release history:
JSON-java releases can be found by searching the Maven repository for groupId "org.json"
and artifactId "json". For example:
https://search.maven.org/search?q=g:org.json%20AND%20a:json&core=gav
~~~
20200518 Recent commits and snapshot before project structure change
@ -190,62 +232,4 @@ as of 29 July, 2015.
~~~
JSON-java releases can be found by searching the Maven repository for groupId "org.json"
and artifactId "json". For example:
https://search.maven.org/search?q=g:org.json%20AND%20a:json&core=gav
# Unit tests
The test suite can be executed with Maven by running:
```
mvn clean test
```
The test suite can be executed with Gradlew by running:
```
gradlew clean build test
```
## Conventions
Test filenames should consist of the name of the module being tested, with the suffix "Test".
For example, <b>Cookie.java</b> is tested by <b>CookieTest.java</b>.
<b>The fundamental issues with JSON-Java testing are:</b><br>
* <b>JSONObjects</b> are unordered, making simple string comparison ineffective.
* Comparisons via **equals()** is not currently supported. Neither <b>JSONArray</b> nor <b>JSONObject</b> override <b>hashCode()</b> or <b>equals()</b>, so comparison defaults to the <b>Object</b> equals(), which is not useful.
* Access to the <b>JSONArray</b> and <b>JSONObject</b> internal containers for comparison is not currently available.
<b>General issues with unit testing are:</b><br>
* Just writing tests to make coverage goals tends to result in poor tests.
* Unit tests are a form of documentation - how a given method actually works is demonstrated by the test. So for a code reviewer or future developer looking at code a good test helps explain how a function is supposed to work according to the original author. This can be difficult if you are not the original developer.
* It is difficult to evaluate unit tests in a vacuum. You also need to see the code being tested to understand if a test is good.
* Without unit tests it is hard to feel confident about the quality of the code, especially when fixing bugs or refactoring. Good tests prevents regressions and keeps the intent of the code correct.
* If you have unit test results along with pull requests, the reviewer has an easier time understanding your code and determining if the it works as intended.
**Caveats:**
JSON-Java is Java 1.6-compatible, but JSON-Java-unit-tests requires Java 1.8. If you see this error when building JSON-Java-unit-test, make sure you have 1.8 installed, on your path, and set in JAVA_HOME:
```
Execution failed for task ':compileJava'.
> invalid flag: -parameters
```
| Resource files used in test |
| ------------- |
| EnumTest.java |
| MyBean.java |
| MyBigNumberBean.java |
| MyEnum.java |
| MyEnumClass.java |
| MyEnumField.java |
| MyJsonString.java |
| MyPublicClass.java |
| PropertyTest.java |
| JunitTestSuite.java |
| StringsResourceBundle.java |
| TestRunner.java |
| Util.java |