stleary
commented
7 months ago What problem does this code solve? Reverts some recently released changes that do not work as intended. Changes to improve optLong vs getLong are needed, but must not change existing functionality without good reason. In this case, strings consisting of some number of leading zeros followed by any digits should not be interpreted as numbers, as that goes against the JSON spec.
Does the code still compile with Java6? Yes
Risks Moderate. The faulty code is already released, and may potentially already be in use. On the other hand, the last release was relatively recent, and the misbehaving code is a bit of an edge case.
Changes to the API? getLong(), optLong(), and stringToNumber() functionality is reverted.
Will this require a new release? Yes. However, there are several workflow issues that should be addressed before the release:
- Java 11 builds tend to fail due to parallel execution. It should be executed separately. Actually, all of the executions should be separate.
- The deployment workflow is redundant at the moment, since the actual deployment is still a manual process. The workflow should be silenced until the transition from manual process has been completed.
Should the documentation be updated? No
Does it break the unit tests? No. Some recently added unit tests are removed.
Was any code refactored in this commit? No
Review status APPROVED - by myself
In this case, the review window has already completed.
A release will be performed as soon as the workflows are updated.
See #868. Reverts recent code changes that break existing applications. This PR will be left up for a few days for comments. If there are no objections or concerns it will included in a new release soon.
For more information, please see
XMLTest.clarifyCurrentBehavior()andJSONObjectTest.clarifyCurrentBehavior().