jackson-docs

I've read (or not read as it is in some cases) some really bad and/or really convoluted documentation. Some industry standard tools, like Jackson, don't even have documentation but instead point you to various tutorials that are written by others on how to use it: https://github.com/FasterXML/jackson-docs One of the nice things that LLMs have done is taken some of that mess of missing/poor/convoluted/scattered-to-the-winds documentation and distilled it into something accessible enough that you either get a useful answer or get a useful direction on how to narrow your search for the answer. I think "read the docs" is good advice; but even the article itself doesn't go so far as to say *all* documentation is good.

>it is apparently on by default Curious as to what makes you think this - I was under the impression you needed to explicitly call `enableDefaultTyping` to get this unsafe behaviour. The wiki page explicitly tells you not to do this with untrusted input and the method is deprecated in the latest versions of the library. https://github.com/FasterXML/jackson-databind/issues/2195 https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymo...

Since they're compiled into the code, it means you can't change them without recompiling, so they're not actually configuration. But they're not actually code either, so they can't be subclassed or inherited, don't support generics, and have other quirks [1]. Furthermore, they are a sort of explicit notation to make you feel like you're getting 'convention' over 'configuration', but if it were truly convention you wouldn't need them in the first place. For example, to teach my class how to serialize itself into JSON, I can compile com.fasterxml.jackson annotations into it, but by doing so I've made a particular JSON library a dependency of myproject-datatypes. I'd rather my myproject-controller or some other layer of my application take care of how the data looks over JSON. Luckily Jackson supports an entirely different way [2] of teachin