Ну, Gson поддерживает строки из коробки, и вам не нужно реализовывать какой-либо сериализатор строк и наоборот.Я полагаю, что в вашем случае может произойти просто импорт неверного строкового класса, скажем import foo.bar.baz.String;
или менее очевидного import foo.bar.baz.*
, или у вас просто есть реализация класса String
прямо в пакете, где ваш класс Data
объявлен в(Однако это не может объяснить, какие значения были действительно присвоены str
- в Java это никогда не сработает, вызывая ClassCastException
).Неправильный класс может быть указан числовыми count
и hashCode
без каких-либо объявленных char[]
полей, поэтому я не верю, что это java.lang.String
в вашем случае.Кроме того, более гипотетической вещью здесь может быть использование отражения, которое отбрасывает адаптер строкового типа из вашего экземпляра Gson
, независимо от того, как и как странно это звучит.В любом случае вам не нужно реализовывать даже одну строку для сериализации строк Java с помощью Gson.
Что касается принятого ответа: он неоптимален.Если по какой-либо причине в ваших операциях импорта нет ничего плохого, ваш пакет не объявляет пользовательский класс String
, а ваши экземпляры Gson
не подвергаются операции отражения, но Gson по-прежнему сериализует такие строки как вложенные объекты (естьпонятия не имею почему), вам нужен только один специальный адаптер типа String
без необходимости создания адаптеров типа для любого класса, который использует этот странный String
в качестве поля:
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();