leadpony / jsonp-test-suite

Test Suite for implementations of Jakarta JSON Processing API (JSON-P)
Apache License 2.0
3 stars 2 forks source link

Change object output comparisons to be order-insensitive #5

Closed ssilverman closed 3 years ago

ssilverman commented 3 years ago

Some of the tests require that objects serialize their output in a particular order. These comparisons would be better if they compared the JSON in an order-independent way.

leadpony commented 3 years ago

@ssilverman

The purpose of this test suite is to minimize the differences between JSON-P implementations in their behavior.

Please see the statement below found in the API Javadoc:

https://eclipse-ee4j.github.io/jsonp/docs/api/?overview-summary.html

The map object's iteration ordering is based on the order in which name/value pairs are added to the corresponding builder or the order in which name/value pairs appear in the corresponding stream.

ssilverman commented 3 years ago

The quote you pasted isn't from the link just above it. In fact, the link you show is another case of the implementation disagreeing with its own specification/documentation. If you go to that link (https://eclipse-ee4j.github.io/jsonp/docs/api/?overview-summary.html), it specifically states:

JsonObject provides a Map view to access the unordered collection of zero or more name/value pairs from the model.

i.e. the API itself, JSON-P, states that a JsonObject is an unordered collection.

I'll pose the same question I did in https://github.com/leadpony/jsonp-test-suite/issues/2: When the implementation disagrees with its own documentation, what should we be testing? I think the implementation has a bug or its official API specification needs to change.

leadpony commented 3 years ago

@ssilverman As you show me, there are some errors in the API documentation, but these errors are not my faults. When we cannot judge what is correct behavior from the specification and API Javadoc, we should respect the Reference Implementation, because it is offered to be referenced by implementators. Also I believe that more deterministic behavior is preferable for the API users.