Well, Gson supports strings out of box and you don't have to implement any string serializer and vice versa yourself. What I guess might happen to your case is merely importing a wrong string class, say import foo.bar.baz.String;
or less obvious import foo.bar.baz.*
, or you just have a String
class implementation right in the package where your Data
class is declared in. (This cannot explain what values were really assigned to str
, though, -- it would never work in Java causing ClassCastException
). A wrong class might be indicated with numeric count
and hashCode
without any char[]
-declared fields, so I don't believe this is a java.lang.String
in your case. Also, a more hypothetical thing here might be use of reflection that discarded the string type adapter out of your Gson
instance, no matter how and how weird it sounds. In any case, you don't have to implement even a single line to serialize Java strings with Gson.
Regarding the accepted answer: it is suboptimal. If, for whatever reason, there is nothing wrong with your imports, your package does not declare a custom String
class, and your Gson
instances do not suffer from reflection surgery, but Gson still serializes such strings as nested objects (have no ideas why then), you'd only need a single special String
type adapter without any need of creating type adapters for any class that uses that weird String
as a field:
final Gson gson = new GsonBuilder()
.registerTypeAdapter(/*real.package.here.*/String.class, (JsonSerializer</*real.package.here.*/String>) (s, type, context) -> new JsonPrimitive(s.toString())) // whatever the real Java string is obtained
.create();