You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
JSONTokener recognizes -0 as a string not as a number, based on usage from json-schema #187
This is breaking schema validation because strings (-0) aren't numbers. We might be able to change the JSON, but it seems odd that this is not acceptable to JSON-java. -0 is well-defined in the spec and does exceed any limits.
Does anyone disagree with the problem statement:
"JSON-Java is not following the spec when parsing the value, '-0'. It should be parsed as a number instead of a string."
@coderextreme I'm not sure if I understand what's the problem. You are saying that -0 is breaking schema. Which schema do you mean? According to information at JSON.org and there mentioned ECMA-404, such token should be considered as a number. So, the original appeal that tokenizer in JSON-java is processing such token as a string incorrectly is valid. Although the existence of something like negative zero is really strange.
Good question, looking at the schema, I either want an integer or a number. I would say integer (since integers are numbers), then parse -0.0 as a float/double.
@Ronon-Dex when performing math with doubles and floats, a -0.0 is a possible value. I don't see it's existence as strange
@stleary I believe it should be parsed as a number. In both specs mentioned in the readme, it should be a number and not a string. I'm working on a PR right now with test cases included
Also, I don't believe this is a problem in the JSONTokener. It treats everything as a string value until it's passed up to the JSONObject.stringToValue method. The PR I'm creating will only have changes in that method.
@johnjaylward Yes, I agree with you. I didn't speak about the floating points. I'm thinking about negative integer zero but that's not the subject. Nevermind ;-)
@stleary I agree with John. This should be parsed as a number.
@Ronon-Dex it's breaking the org.everit json-schema package, everit-org/json-schema#25 It's the only Java JSON schema validator published on json-schema.org which hasn't been abandoned.
The JSON Schema specification makes a distinction between "number" and "integer", and it would be easier for me in my implementation to support these if -0 would be an integer and -0.0 would be a double. If -0 would be returned as a double, then probably the validator wouldn't be able to determine if it was -0 or -0.0 in the original JSON string (and it makes a difference during validation).
Mathematically, you would only encounter a -0 when working with doubles/floats. Most computer systems do not use one's complement for integer calculations and thus would only be seen as a product of a function using float or double precision numbers.
If everyone agrees that -0 should be treated as int(0), then I'm fine with it. I just don't see how you would get a -0 to show up in JSON without it being from a double precision calculation
Just to clarify further, if I convert this to an Integer instead of a Double, the sign would be lost since Java integers are 2's compliment (no negative 0)
Activity
johnjaylward commentedon Jan 27, 2016
I fixed this in #157 and #158 but it was not accepted.
johnjaylward commentedon Jan 27, 2016
https://github.com/johnjaylward/JSON-java/tree/FixBigIntRead has the latest changes outside of PR #158
coderextreme commentedon Jan 27, 2016
This is breaking schema validation because strings (-0) aren't numbers. We might be able to change the JSON, but it seems odd that this is not acceptable to JSON-java. -0 is well-defined in the spec and does exceed any limits.
johnjaylward commentedon Jan 27, 2016
How would you propose to see -0? as a 0 integer, or as a -0 double/float?
stleary commentedon Jan 27, 2016
Does anyone disagree with the problem statement:
"JSON-Java is not following the spec when parsing the value, '-0'. It should be parsed as a number instead of a string."
Merlinio commentedon Jan 27, 2016
@coderextreme I'm not sure if I understand what's the problem. You are saying that
-0is breaking schema. Which schema do you mean? According to information at JSON.org and there mentioned ECMA-404, such token should be considered as a number. So, the original appeal that tokenizer in JSON-java is processing such token as a string incorrectly is valid. Although the existence of something likenegative zerois really strange.coderextreme commentedon Jan 27, 2016
Good question, looking at the schema, I either want an integer or a number. I would say integer (since integers are numbers), then parse -0.0 as a float/double.
John
johnjaylward commentedon Jan 27, 2016
@Ronon-Dex when performing math with doubles and floats, a -0.0 is a possible value. I don't see it's existence as strange
@stleary I believe it should be parsed as a number. In both specs mentioned in the readme, it should be a number and not a string. I'm working on a PR right now with test cases included
johnjaylward commentedon Jan 27, 2016
Also, I don't believe this is a problem in the JSONTokener. It treats everything as a string value until it's passed up to the JSONObject.stringToValue method. The PR I'm creating will only have changes in that method.
stleary commentedon Jan 27, 2016
@johnjaylward Thanks, I will work on the unit test side.
Merlinio commentedon Jan 27, 2016
@johnjaylward Yes, I agree with you. I didn't speak about the floating points. I'm thinking about
negative integer zerobut that's not the subject. Nevermind ;-)@stleary I agree with John. This should be parsed as a number.
coderextreme commentedon Jan 27, 2016
@Ronon-Dex it's breaking the org.everit json-schema package, everit-org/json-schema#25 It's the only Java JSON schema validator published on json-schema.org which hasn't been abandoned.
coderextreme commentedon Jan 27, 2016
Sorry I can't get a better URL for you to look at. It's local to github. And I don't really know markdown.
Here's the non-issue link: https://github.com/everit-org/json-schema
Fixes stleary#187 -0 now returns as a double.
johnjaylward commentedon Jan 27, 2016
@stleary I'll leave the test cases to you as requested. the linked issue to the other project has some test data in it already if you want
johnjaylward commentedon Jan 27, 2016
oh wait. I made an error... that's what I get for not having a test case
stleary commentedon Jan 27, 2016
@johnjaylward Feel free to propose test cases as well, if so inclined. I am a bit behind schedule with end-of-sprint tasks.
johnjaylward commentedon Jan 27, 2016
Will do. although your new test project layout broke my submodule config. No need to change it though. I'll just switch how mine is configured
stleary commentedon Jan 27, 2016
Sorry about that, still a work in progress. build.gradle is defective as well.
johnjaylward commentedon Jan 27, 2016
ok, submitted test cases as well.
erosb commentedon Jan 27, 2016
Hello @stleary , @johnjaylward ,
The JSON Schema specification makes a distinction between "number" and "integer", and it would be easier for me in my implementation to support these if -0 would be an integer and -0.0 would be a double. If -0 would be returned as a double, then probably the validator wouldn't be able to determine if it was -0 or -0.0 in the original JSON string (and it makes a difference during validation).
Thank you.
johnjaylward commentedon Jan 27, 2016
Mathematically, you would only encounter a -0 when working with doubles/floats. Most computer systems do not use one's complement for integer calculations and thus would only be seen as a product of a function using float or double precision numbers.
If everyone agrees that -0 should be treated as int(0), then I'm fine with it. I just don't see how you would get a -0 to show up in JSON without it being from a double precision calculation
erosb commentedon Jan 27, 2016
@johnjaylward that is probably true. In the original issue created by @coderextreme , he is also working with doubles when encountering the -0 literal.
johnjaylward commentedon Jan 27, 2016
Just to clarify further, if I convert this to an Integer instead of a Double, the sign would be lost since Java integers are 2's compliment (no negative 0)
erosb commentedon Jan 27, 2016
Ok, I'm fine with it :)
johnjaylward commentedon Jan 27, 2016
@stleary I did not check the XML components to see if they need to be updated. Do you want me to verify those as well?
stleary commentedon Jan 27, 2016
@johnjaylward Yes, thanks, for the sake of consistent handling of -0/-0.0 wherever they are encountered.
johnjaylward commentedon Jan 27, 2016
ok, updated the PR both here and in the test bench