(for Jackson 3.x) Reconsider DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES default setting

DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES currently defaults to true. So assuming you’re using Jackson to deserialize HTTP request bodies this will mean, deserialization fails if the clients sends a single property unknown to the server. This blatantly violates Postel’s law.

So if all the world is reconfiguring that default immediately, is it maybe worth considering to change it? I know that’s a tough thing to do (and probably - if ever - will only make it into a new major release), but I thought I’d raise the question as in general, not failing is definitely the better default.

[odrotbohm]

Interesting, so you think it’s right to by default fail, if you get a JSON data structure that meets all requirements of the type it’s supposed to be projected on (which you can of course happily use to document what you expect) just because a single additional element is present which you actually don’t care about at all?

Why is it important to document which properties you don’t care about? If you think through that, wouldn’t you have to mention every possible property that could appear? You document what you expect, not what you not expect.

Let’s say you order a steak at a restaurant. As long as the waiter brings steak, you’re fine. Do you return the order if there’s lettuce on the plate and say: “No, I wanted steak!”. If you don’t like the extras, ignore them. Also, you don’t order: “A steak, but without a burger, chips, lettuce, coffee, tissues, a new iPhone and a pair of socks”.

I don’t follow a law blindly, I think there’s value in it, cause you can build resilient systems with it. 😃

[cowtowncoder]

@olivergierke I don’t follow your example: if my order came with side of some unknown stuff I didn’t order, yes, I’d probably send it back; but I most definitely would want to know about it. Throwing an exception is perfectly valid thing to do, if unknown stuff comes in. In fact, blindly accepting any kind of thing is often (but not always) pretty bad strategy – my experience has been that it will hide issues and delay finding of things you should have found earlier. Your logic and preferences may well differ, and I am not trying to convince you to change what you want; however, your preferences are not universal.

Regardless I see no point in changing defaults for 2.x. If 3.x is ever released, yes, by all means we can change this (with brief discussion as appropriate). So I’ll change the title, and there won’t be much action for this item until then.

FWIW, I used to curse at JAXB that had (so I thought) idiotic and stupid default settings of NOT complaining about unknown elements – I wasted plenty of time before realizing that a typo made things not match. And I could not understand how anyone anywhere could possibly choose such “Obviously Wrong” defaults. So I’ve come full circle in some ways… and I nowadays agree with “Open Content” style modelling; specifying things you want, and improving forward-compatibility by allowing inclusion of possibly other content.