I don't understand all that, but I would like to make a few observations.
First "Serializable" is not JSON as such. If a class implements
java.io.Serializable it's essentially promising that it can be serialized with JVM's internal binary serializer. Which is not JSON or even any plain text format.
Secondly, annotations generally are not the last
word in configuration. Just because a class has been annotated with a particular property doesn't mean that it's permanently stuck with that property.
I cannot speak for your JSON framework offhand, but let's take a common annotation:
By default, the
servlet class containing this annotation will dispatch URLs in the general form of "http://host/context/acccount" to that servlet.
But before there were servlet annotaions there was the
WBE-INF/web.xml configuration file. The web.xml file is still supported, and if you create it with an XML element that provides a different annotation-defined URL resource path, the web.xml definition will override the annotation on the class. As a result, you can use classes in different configurations without having to edit the class source code.
This concept is common in
Java. JavaServer Faces does this, the Spring Framework does this, lots of systems do this. It's a very powerful convention.