Thanks for your comment about the size of the API that is needed to be known. I agree that the number of classes that a developer needs to work with is often very much smaller than the number of classes that makes up the project, and that smallness is not synonymous with simplicity.

Anyway: just to try to explain what exactly I mean, using Jackson as an example: Jackson has quite a few classes (~180 source, almost 300 compiled included inner classes), but its actual public API consists of a rather small set of classes; perhaps a dozen.
Of those, developer only has to know one (org.codehaus.jackson.mapper.ObjectMapper) when using data mapping, as per Tutorial page (http://jackson.codehaus.org/Tutorial).

For other use cases couple of other classes here and there are needed.
Other classes are implementation details that very few developers ever want (or should) worry about.

Same is probably true for other big packages; I know that XStream similarly only requires you to know its main class; whereas other seemingly smaller packages (like json.org’s ref impl) mix API and implementation, so that all classes are part of API.
That’s why I think that smallness and simplicity are not synonyms, if simplicity is related to how simple package is to use and how intuitive its API is.

I understand why smallness matters for some use cases; perhaps even more than simplicity. And for other cases reverse is true. So I am not trying to argue whether size matters.

Anyway, thanks for the article!

I’d like to say that I’ll post an extensive update that takes all this into consideration, but I think that this will be unlikely.

Also: there are generally 2 levels of serialization/deserialization; simple one that converts json to Lists/Maps (or impl-specific nodes), and full one that binds to any Java Beans/POJOs. Might be good to list which are supported. Just an idea.