Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The method _parseInteger of StdDeserializer #664

Closed
wenzis opened this issue Dec 29, 2014 · 7 comments
Closed

The method _parseInteger of StdDeserializer #664

wenzis opened this issue Dec 29, 2014 · 7 comments
Milestone

Comments

@wenzis
Copy link

wenzis commented Dec 29, 2014

The method _parseInteger of StdDeserializer auto handle JsonToken.VALUE_NUMBER_FLOAT to JsonToken.VALUE_NUMBER_INT,could you support enum to prohibit this feature?
_parseShort、_parseIntPrimitive and so on.

@cowtowncoder
Copy link
Member

Just to make sure I understand: you would NOT want a floating point number (like 2.05) to be used for Enum values (rounded as 2)? If so, that should be doable yes.

@wenzis
Copy link
Author

wenzis commented Dec 30, 2014

Sorry, I didn't say it clearly.
Let me to describe.

first: I have a class
public class Site {
private Integer type
public Integer getType() {
return type;
}
public void setType(Integer type) {
this.type = type;
}
}

Second, there is a json
String json = "{"type":1.2}";

Third: data conversion
private static final ObjectMapper OBJECT_MAPPER = new ObjectMapper();
Site site = OBJECT_MAPPER.readValue(json, Site.class);

the result is successful and I get the site, the value of site type is 1,but I don't think so,
exactly I want a format exception. should I do?

@cowtowncoder
Copy link
Member

Different users want different things: many prefer to try very hard to match data; and since (for example) floating point numbers are still numbers, rounding to closest or truncating may make sense in cases where there is mismatch.

So if your specific desire is NOT to allow coercion of floating point numbers to integer numbers, it would make sense to have a new DeserializationFeature, which determines whether such coercion is allowed. This should then be applied to deserialization of various things.

It sounds like this is what you want, then. I don't know when I'll have a chance to work on it, but it will probably not make it in 2.5 yet, but 2.6.

@wenzis
Copy link
Author

wenzis commented Dec 30, 2014

@cowtowncoder Thanks!

@cowtowncoder
Copy link
Member

Added DeserializationFeature.ACCEPT_FLOAT_AS_INT, disabling of which prevents coercion from JSON (etc) floating-point numbers into int/long/BigInteger.

@cowtowncoder cowtowncoder added this to the 2.6.0 milestone May 2, 2015
@Skarafaz
Copy link

Just noticed this crazy behaviour... no words! Having DeserializationFeature.ACCEPT_FLOAT_AS_INT = true as default is simply insane. Truncating a float means loosing information, so it MUST NOT be the default.

@cowtowncoder
Copy link
Member

cowtowncoder commented Nov 28, 2017

@Skarafaz you have right to voice your opinion. And I am free to disregard it.
If you want it changed, GO FUCKING CHANGE IT on your set up. Behavior has been here since beginning of the project and I am annoyed by people like you butting in and DEMANDING FOR IMMEDIATE CHANGE. Just go away.

@FasterXML FasterXML locked and limited conversation to collaborators Nov 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants