Change default of DeserializationFeature. FAIL_ON_NULL_FOR_PRIMITIVES to true for 3.0

[JooHyukKim]

(part of #72 uber-Discussion)

As of Jackson 2.x, DeserializationFeature. FAIL_ON_NULL_FOR_PRIMITIVES defaults to false, allowing coercion from JSON null into Java int, long and so on.
For some users -- and especially on "low null" languages like Kotlin -- such coercion is rarely expected, so A suggestion in discussion was made to change the default.

This will improve intuitive-ness of feature default value with which module-extension (like kotlin-module). This change will not be done in Jackson 2.x, but for 3.0.0, due to backward-compatibility issue.

[hykilpikonna]

It would be better to allow users to specify their own default behavior (maybe through environment variables?)

For example, if I am migrating from 2.0 to 3.0 and this behavior differs, it would be far easier to change one environment variable instead of modifying every place where I constructed an ObjectMapper.

[JooHyukKim]

You mean like this?

mapper.retainJackson2Behavior().build();

[hykilpikonna]

You mean like this?

mapper.retainJackson2Behavior().build();

Yea, but adding that to every mapper initialization code in our >30k line codebase would be a hassle.

[JooHyukKim]

I don't think system level (through like environment variable) configuration would be a way to go.
Many works been done to be thread-safe and all, providing per-mapper-instance configuration points.

Especially when we are trying to move away from static, also considering (don't have specifics yet but) future ecosystem like lightweight threads...

Anything more global than per-instance configuration should most likely be done by frameworks/application that use Jackson, like how it's been done so far. You may refer to how Spring does it.

[JooHyukKim]

I still agree such thing as mapper.retainJackson2Behavior().build(); how it would be useful... 👍🏼

[JooHyukKim]

On the other hand, I am wondering if adding this hypothetical retainJackson2Behavior() method may open doors to many problems....? 🤔 What if we had a super intuitive 2->3 version migration document?

[cowtowncoder]

I do not think it is a good idea to expose global singleton style forcing mechanism for defaults: Jackson is a library, used transitively by many things and trying to change defaults from under other libraries or frameworks can be a lethal foot-gun.

Instead systems that make heavy use of Jackson should design things so they can set suitable defaults as necessary.

I am not sure what I think of retain2JacksonBehavior() -- I suppose we could add JsonMapper.Builder and JsonFactory.Builder methods as suggets (with name like useJackson2Defaults()) but not sure I really like the idea.

EDIT: my main concern, I think, is that a set of things one can configure for more 2.x compatibility is relatively limited. But I guess I am not entirely opposed to the idea.
If anyone wants to pursue it, should create issue under jackson-databind (and perhaps jackson-core wrt JsonParser/JsonGenerator defaulting).

[cowtowncoder]

After bit over month, poll results are clear: let's change default settings: will approve FasterXML/jackson-databind#4858 .