Почему java.io.Serializable не рекомендуется в Java 5? - PullRequest
22 голосов
/ 18 июня 2011

В предварительной версии 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, которые I не смог найти)

Ответы [ 4 ]

21 голосов
/ 18 июня 2011

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

public void registerObject(Serializable obj);
10 голосов
/ 18 июня 2011

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

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

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

  • Нет ничего плохого в том, чтобы использовать Serializable, и "принуждение" людей к его замене раздражает. (У людей есть дела поважнее ...)

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

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

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

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


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

2 голосов
/ 18 июня 2011

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

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

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

0 голосов
/ 28 сентября 2016

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

...