Почему для реализации Externalizable нужен стандартный конструктор по умолчанию?

Нам это не нужно, если мы реализуем Serializable. Так почему это различие? Как это соотносится с реальным механизмом сериализации?

Ответ 1

Подробное объяснение (хотя можно улучшить грамматику статьи) можно найти на http://www.jusfortechies.com/java/core-java/externalization.php. Короткий ответ, для дальнейшего использования в случае, если связанная страница уходит:

Externalizable - это интерфейс, расширяющий Serializable. Однако, в отличие от Serializable, объекты не восстанавливаются, просто читая сериализованный поточный поток, но вызывается публичный конструктор и только после создания объекта его состояние восстанавливается. Это делает восстановление более эффективным.

Изменить: См. также В чем разница между Serializable и Externalizable в Java?.

Ответ 2

В основном это используется для кеширования. Чтобы десериализовать в потоках, вам нужно будет указать, как вы хотите, чтобы ваш объект был десериализованным, поэтому два метода, предоставляемые контрактом в интерфейсе Externalizable: writeExternal и readExternal. Обратите внимание, что Externalizable extends Serializable, поэтому вам необязательно реализовывать интерфейс Serializable (хотя это интерфейс маркера и нет методов, которые будут фактически реализованы).

Для примера реализации посмотрите MimeType.

Ответ 3

При использовании интерфейса Externalizable необходим конструктор public no-arg.

Потому что в случае Serializable

  • readObject считывает требуемую информацию из ObjectInputStream
  • Сериализация использует механизм отражения для получения необходимых полей и их соответствующих значений.
  • Serializable сериализует все элементы данных (кроме статического и переходного).

Но в случае Externalizable

  • Не используется механизм отражения.
  • Пользователь не сериализует все члены данных. Для чего нужны значения элементов, которые не являются внешними, public. Конструктор arg не требуется.