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.
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.