Почему java.io.Serializable не рекомендуется в Java 5?

В предыдущей версии Java 5 аннотаций не было. В результате вы не можете добавить метаданные в класс.

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

public class MyClass implements Serializable {
   ...
   private transient Bla field;
   ...
}

Теперь вы можете теоретически использовать аннотации (это идеально подходит для них) и иметь:

@Serializable
public class MyClass {
   ...
   @Transient
   private Bla field;
   ...
}

Но интерфейс и ключевое слово не устарели, и в Java 5 не было добавлено примечаний для их замены.

Каковы соображения для этого решения, чтобы сохранить интерфейс и ключевое слово?

Конечно, существует проблема совместимости с кодом до Java 5, но в какой-то момент это закончится (например, в связи с новыми функциями обобщений, JLS указывает, что возможно, что будущие версии языка программирования Java будут запрещать использование сырых видов). Так почему бы не подготовить путь для сериализованных аннотаций?

Какие-нибудь мысли? (хотя я бы предпочел конкретные ссылки:D, которые я не смог найти)

Источник

4 ответа

Решение

Здесь есть интерфейс, поэтому можно определить методы для приема объектов типа Serializable:

public void registerObject(Serializable obj);
Источник

Конечно, существует проблема совместимости с предварительно Java 5 кода...

Да. Это корень проблемы.

  • Если они @deprecated Serializable интерфейс в (скажем) Java 5, тогда много старого кода до Java 5 будет выдавать предупреждения (или ошибки в зависимости от переключателей компилятора).

  • Там нет ничего на самом деле не так с использованием Serializable и "заставлять" людей заменять это раздражает. (У людей есть дела поважнее...)

  • Когда люди "исправят" это в своем коде, он больше не будет компилироваться с использованием компилятора до Java 5 или работать на JVM до Java 5.

  • Это плохая идея делать вещи, которые заставляют компилятор систематически "плакать волком".

... но в какой-то момент это закончится.

На самом деле, вероятность того, что это действительно произойдет, (ИМО) мала. Насколько я знаю, Sun / Oracle никогда не удаляли устаревшую функцию. Даже не такие опасные, как Thread.stop() и друзья.

В качестве сноски разработчики Go используют другой подход к этой проблеме. Когда они хотят изменить язык или функцию библиотеки, они просто делают это. Они предоставляют конвертер, который будет автоматически переписывать ваш код по мере необходимости.

Источник

Serializable а также transient действительно две вещи, которые могли быть заменены аннотациями.

Они не устарели, вероятно, потому что есть много программ, которые используют Serializable и было бы неприятно миллионам разработчиков, если бы компилятор внезапно начал извергать тысячи предупреждений об устаревании.

В стандартном Java API есть много других вещей, которые давно бы устарели - например, классы устаревшей коллекции Vector а также Hashtable (и я уверен, что вы можете легко найти еще много вещей). И есть другие вещи, которые могли бы быть реализованы с помощью аннотаций (например, ключевое слово volatile, strictfp а также synchronized).

Источник

Амортизация для вещей, которые активно вредны. То, что вы предлагаете, заставляет авторов восьмилетнего существующего Java-кода (на тот момент) переписать его, без какой-либо выгоды, просто для того, чтобы отключить предупреждения компилятора устаревания, чтобы вернуться к полностью правильному коду, который они имели в Java 1.4., Это не было бы полезно.

Источник
Другие вопросы по тегам