Нам это не нужно, если мы реализуем Serializable. Так почему это различие? Как это соотносится с реальным механизмом сериализации?
Почему для реализации Externalizable нужен стандартный конструктор по умолчанию?
Ответ 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 не требуется.