Почему в Java 5 не было java.io.Serializable?

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

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

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

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

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

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

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

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

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

Ответы

Ответ 1

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

public void registerObject(Serializable obj);

Ответ 2

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

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

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

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

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

  • Плохая идея - делать то, что делает компилятор систематически "плакать волом".

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

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

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

Ответ 3

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

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

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

Ответ 4

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