Interesting business model: collect useful utilities, document them, and also offer consulting services.

I spent some time looking over a couple Jodd libraries and frameworks, and I felt some nostalgia for my past use of Java. I also always used Java ‘lightly’, avoiding J2EE unless the work really paid well. Now professionally my work is in Python (I have been close to 100% deep learning for about four years), and I use Haskell and Common Lisp for my personal projects - but I still think fondly of Java.

When you parse JSON, what is the reason to choose special classes for structure (and sometimes data units) instead of using Java-native equivalents?

Do you mean deserialising to, say, a java.util.Map instead of a Book?

Yes. When I'm done with JSON-specific operations, I'd like to use traditional libraries to do non-JSON-specific things, and I would like to avoid having explicit conversion to Maps and Lists.

Most Java JSON libraries can, but then you usually end up having to deserialise to a Map<String, Object> and then have to do casts when using the values, so people tend to use deserialising to POJOs to remove the manual casting - even if all it does is shift the runtime type checking from the code consuming the map to the code deserialising it.

Also, using POJOs can lead to more readable type signatures - it's easier to determine what the method getBooks of the Author POJO that returns List<Book> is about than a Map<String, Object> that has a List<Map<String, Object>> mapped to the key "books".

Bit of an impedance mismatch between a serialisation format from a dynamically typed language and a statically typed language.

With Jodd you can have both