Что такое serialVersionUID и почему я должен его использовать?

Я не могу отказаться от этой возможности включить книгу Josh Bloch Эффективный Java (2-й Выпуск). Глава 11 является необходимым ресурсом на сериализации Java.

На Josh, автоматически сгенерированный UID сгенерирован на основе имени класса, реализовал интерфейсы и всю общественность и защитил участников. Изменение любого из них всегда изменится serialVersionUID. Таким образом, Вы не должны смешивать с ними, только если Вы уверены, что не больше, чем одна версия класса будет когда-либо сериализироваться (или через процессы или получаться от устройства хранения данных в более позднее время).

, Если Вы игнорируете их на данный момент и находите позже, что необходимо изменить класс в некотором роде, но поддержать совместимость w/старая версия класса, можно использовать инструмент JDK serialver, чтобы генерировать serialVersionUID на старый класс, и явно установить это на новом классе. (В зависимости от Ваших изменений Вы, возможно, должны также реализовать пользовательскую сериализацию путем добавления writeObject и readObject, методы - видят Serializable javadoc или вышеупомянутая глава 11.)

Было бы хорошо, если CheckStyle мог бы проверить, что serialVersionUID на классе, который реализует сериализуемый, имеет хорошее значение, т.е. что это соответствует тому, что произвел бы последовательный идентификационный генератор версии. Если у Вас есть проект с большим количеством сериализуемых DTOs, например, не забывать удалить существующий serialVersionUID и повторно создать его является болью, и в настоящее время единственным путем (что я знаю о) проверить, что это должно повторно создать для каждого класса и выдержать сравнение со старым. Это очень очень болезненно.

Можно сказать Eclipse игнорировать эти serialVersionUID предупреждения:

Окно> Предпочтения> Java> Компилятор> Ошибки / Предупреждения> Потенциальные Проблемы программирования

В случае, если Вы не знали, существует много других предупреждений, которые можно включить в этом разделе (или даже иметь, некоторые сообщили как ошибки), многие очень полезны:

• Потенциальные Проблемы программирования: Возможное случайное булево присвоение
• Потенциальные Проблемы программирования: Доступ к нулевому указателю
• Ненужный код: Локальная переменная никогда не читается
• Ненужный код: Избыточная пустая проверка
• Ненужный код: Ненужный бросок или 'instanceof'

и многое другое.

Если Вы сериализируете просто, потому что необходимо сериализировать для пользы реализации (кто заботится, сериализируете ли Вы для HTTPSession, например..., если она хранится или нет, Вы, вероятно, не заботитесь [приблизительно 111] об объекте формы), то можно проигнорировать это.

при фактическом использовании сериализации только имеет значение, если Вы планируете хранение и получение объектов с помощью сериализации непосредственно. Эти serialVersionUID представляет Вашу версию класса, и необходимо увеличить ее, если текущая версия класса не назад совместима со своей предыдущей версией.

Большую часть времени, Вы не будете, вероятно, использовать сериализацию непосредственно. Если это верно, генерируйте значение по умолчанию SerialVersionUID путем нажатия на опцию быстрого исправления и не волнуйтесь об этом.

Если Вы никогда не должны будете сериализировать свои объекты к массиву байтов и отправлять/хранить их, то Вы не должны волноваться об этом. Если Вы делаете, то необходимо рассмотреть serialVersionUID, так как deserializer объекта будет соответствовать ему к версии объекта, который имеет ее classloader. Читайте больше об этом в Спецификации языка Java.

Что такое SerialVersionUID? Ответ: - позволяет, говорят, что существует два человека, один от HQ и другого от ODC, оба собираются выполнить сериализацию и десериализацию соответственно. В этом случае для аутентификации этого получатель, кто находится в ODC, является аутентифицируемым человеком, JVM создает Уникальный идентификатор, который известен как SerialVersionUID.

Вот хорошее объяснение на основе сценария,

Почему SerialVersionUID?

Сериализация : Во время сериализации с каждой объектной стороной отправителя JVM сохранит Уникальный идентификатор. JVM ответственна для генерации того уникального идентификатора на основе соответствующего .class файла, который присутствует в системе отправителя.

Десериализация : Во время десериализации сторона получателя JVM сравнит уникальный идентификатор, связанный с Объектом с Уникальным идентификатором локального класса, т.е. JVM также создаст Уникальный идентификатор на основе соответствующего .class файла, который присутствует в системе получателя. Если оба уникальных идентификатора, подобранные затем только десериализация, будут выполнены. Иначе мы получим высказывание Исключения на этапе выполнения InvalidClassException. Этот уникальный идентификатор является только SerialVersionUID