А как вы себе представляете сериализацию методов? Только заголовки? Или байт-код Dalvik EXecutable?
Второе делается через рефлексию, и очень сомнительна надежность, не говоря уже о том, что работать, естественно, будет только на Android, скажем на сервер такой объект не отправить.
А в первом нет никакого смысла.
А можно чуть подробнее расписать, откуда появилась такая задача? Просто сериализация геттеров - это что-то совсем за гранью добра и зла, как мне кажется. Может быть можно как-то переформулировать задачу, чтобы стало понятно, что там нужно сделать?
Artem Gapchenko: конкретно мой пример - есть интерфейс с 2мя геттерами. В моей имплементации первый геттер возвращает приватное поле. Второй - константу (у которой нет приватного поля). В Json версию попадает данные из первого геттера (точнее - приватного поля), но не попадает второе поле (так как для него нет какого-либо свойства где храниться значение). Свою имплементацию я переписал так, что Gson работал с ней корректно. Просто удивило что gson не умеет так, вызывать геттеры и сериализовать результат. Согласен, по умолчанию такого делать не стоит, но с помощью какой-либо аннотации можно было бы.
mitaichik: Gson не использует методы вообще и в этом нет ничего плохого. Совсем, так как это by design, и, если не ошибаюсь, где-то об этом упоминалось самими разработчиками библиотеки. Посмотрите на реализацию ReflectiveTypeAdapterFactory -- там есть реализация адаптера, который работает исключительно с полями. Чего-то подобного для работы через методы попросту нет.
Сериализуются данные, а не методы. Т.е. в каком-то виде сохраняется состояние(данные) объекта, а потом может быть загружено в объект такого же класса. Именно классом будут определяться методы (поведение). При этом класс должен быть известен в приложении, в котором производится десериализация и SerialVersionUID должен совпадать с тем, что был у класса объекта при сериализации.
