This is great news, JSR-367 means that we will now have a standard API for marshalling/unmarshalling
Json objects in java (if you’re confused with regards to JavaEE 7’s
javax.json API, like I was, check this out).
It’s similar to JAXB api for XML marshaling/unmarshalling (does the same harm).
I like the idea of JSON-B quite a lot. What I don’t like is how Yasson implements it. Apparently, like many other parsers, it relises on POJOs’ getters and setters. This is how it works:
It gets the job done, but POJOs are the reason why Java “enterprise” applications turn into mammoths with classes of 1k+ lines (I’m sure 1k lines is few for many). Because that Student will have many more attributes, and these attributes will be read from somewhere and then set. Somewhere, there will be about 50 lines of code calling setters; later, when we need to sanitize the Student, another 50 lines of code. You get the point; POJOs turn a well designed OOP application into an unmaintainable pile of garbage.
I’m not going to go in-depth about interfaces, but here’s how our student should look (assume we read it from a file):
We have a Student instance and we would like it to be marshallable by Yasson, so we write JsonStudent:
Then, we turn a Student to Json like this:
Unfortunately, this does not work (at least in version 1.0). That
dictates the name (key) of the value in the final Json and the class still requires getters for marshalling. Hopefully, it will work in the next versions, as Jackson offers this
Yes, I know the example above would work if the methods were prefixed
get, but I don’t want that. Getters and setters are evil and even having
set as prefixes to the method name changes the way you look at the object.
Try declaring getters and setters in an interface, you’ll see what I’m talking about.
For unmarshalling, you need setters and a default constructor. I honestly don’t see the purpose, since you can (and should) have a
StudentFromJson work elegantly with a
JsonObject can be obtained easily from a
Reader or an
- I don’t like the fact that we have another Java library which encourages developers to use POJOs.
- I don’t see the purpose of marshalling, especially with POJOs; we can already do that with JSON-P.
- I do like the fact that we have a standard API for turning objects into Json. Maybe other implementations or future versions of Yasson will drop support for getters/setters and work with annotations or some other, OOP design.
So please, make every effort necessary to avoid dumb, stale, baskets of data. Make your objects work with something, implement interfaces; they shouldn’t just hold data. Please, let’s see JavaEE8 as an opportunity to stop the POJO maddness.
Use syntax highlighting in your comments, to make them more readable.