
The Unbearable Lightness of Java - step93
https://jodd.org/
======
mark_l_watson
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.

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

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

~~~
avmich
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.

~~~
EdwardDiego
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.

