Почему нативную Java-сериализацию (Serializable) редко используют в новых проектах?

Встроенная Java-сериализация (реализация интерфейса java.io.Serializable) считается устаревшим и проблемным подходом для сериализации в новых проектах из-за серьёзных недостатков.

Критические недостатки:

1. Низкая производительность:

   • Использует рефлексию, что медленно.
   • Создает большой объем служебных данных (метаданные класса, граф объектов).
   • Формат вывода (поток байт) неэффективен по размеру.

2. Хрупкость и сложность поддержки (Brittleness):

   • Жестко привязана к внутренней структуре класса (serialVersionUID). Любое изменение класса (переименование поля, изменение типа) может сломать десериализацию.
   • Требует ручного управления serialVersionUID.

3. Уязвимости безопасности:

   • Известный вектор атак. Десериализация недоверенных данных может привести к удаленному выполнению кода (RCE).
   • Атаки типа SerializationDos могут создать чрезмерно глубокий граф объектов.

4. Плохая переносимость и интероперабельность:

   • Бинарный формат специфичен для Java. Не подходит для обмена данными с системами на других языках.
   • Нет человеко-читаемого формата для отладки.

Современные альтернативы:

• JSON (Jackson, Gson): Человеко-читаемый, интероперабельный, широко поддерживаемый.
• Бинарные протоколы (Protocol Buffers / gRPC, Apache Avro): Эффективные, компактные, типобезопасные, с явной схемой и версионированием.
• MessagePack: Бинарный аналог JSON, более компактный.

Пример сравнения:

// Проблема с Serializable
class User implements Serializable {
    private String name;
    // Добавление нового поля сломает десериализацию старых данных,
    // если не управлять serialVersionUID вручную.
    // private String email; // Опасно!
}

// Решение с Jackson (JSON)
class User {
    @JsonProperty("user_name") // Гибкое управление маппингом
    private String name;
    @JsonIgnore // Можно легко исключить поля
    private String password;
    // Новые поля игнорируются при десериализации старых JSON по умолчанию
    private String email;
}

Вывод: Нативную сериализацию следует использовать только для совместимости с устаревшими системами (RMI, некоторые фреймворки) или для кратковременного хранения в памяти. Для всего остального существуют лучшие альтернативы.