Continued from the github issue (
https://github.com/FasterXML/jackson-databind/issues/493#issuecomment-46680797)
Yes, I do think it's right by default to fail: you should be very strict about what you accept by default, then gradually relax your constraint depending in the situation. If you change this default, should JsonParser.Feature.ALLOW_UNQUOTED_FIELD_NAMES be changed to true too to be "robust" to older Json generator? And what about DeserializationFeature.FAIL_ON_INVALID_SUBTYPE? These features are all configured by default to be very strict about what Json is accepted. Then, application code can relax those constraints.
With the specific case of ignoring properties, you can do it with different scope: be very specific JsonIgnoreProperties("foo") on a class, then a little bit larger with JsonIgnoreProperties(ignoreUnknown=true) on a class, then very wide with the feature to true. I think this ties in very well with how Java defined its access modifier: the "default" modifier is very strict (package-private), but it's also probably the modifier used the less.
We clearly don't develop the same kind of system and perhaps in your case it makes sense to always accept unknown properties. And from your twitter "survey", it seems that your circle also thinks the same thing, which is fine. I also enabled this feature for some cases I had, but I don't think Jackson defaults should cater to the majority, simply because the majority changes over time and who you talk to. The defaults should offer a consistent and strict definition of what is valid.