¿Por qué no se desaprobó java.io.Serializable en Java 5?

Question

En pre Java 5, no había anotaciones. Como resultado, no podría agregar metadatos a una clase.

Para marcar una clase como serializable, había que implementar la interfaz Serializable (que es sólo eso, un marcador) y el uso de nuevas transient palabras clave para marcar un campo como no serializable si es necesario, algo así como:

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

Ahora usted podría teóricamente hacer uso de anotaciones (este es un uso perfecto para ellos) y tienen:

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

Pero la interfaz y la palabra clave no estaban en desuso y se añadió ninguna anotación en Java 5 para reemplazarlos .

¿Cuáles son las consideraciones para esta decisión de mantener la interfaz y la palabra clave?

Por supuesto, existe la cuestión de la compatibilidad con el código pre Java 5, pero en algún momento terminará (por ejemplo, en relación con las nuevas características de los genéricos, el JLS especifica que It is possible that future versions of the Java programming language will disallow the use of raw types). Entonces, ¿por qué no preparar el camino para anotaciones serializadas también?

¿Alguna idea? (Aunque yo preferiría referencias concretas: D que I podido encontrar)

Answer 1

La interfaz está allí así que los métodos se pueden definir para aceptar los objetos de tipo Serializable:

public void registerObject(Serializable obj); 

Answer 2

Serializable y transient son de hecho dos cosas que podrían haber sido reemplazadas por anotaciones.

Ellos no han sido desaprobados probablemente porque hay una gran cantidad de programas que utilizan Serializable y hubiera sido molesto para millones si los desarrolladores si el compilador de repente comienza a escupir miles de avisos de obsolescencia.

Hay un montón de otras cosas en la API estándar de Java que podrían haber quedado en desuso hace mucho tiempo - por ejemplo, las clases de colección legado y VectorHashtable (y estoy seguro que usted puede encontrar fácilmente muchas cosas más). Y hay otras cosas que podrían haberse implementado usando anotaciones (por ejemplo, la palabra clave volatile, strictfp y synchronized).

Answer 3

Off supuesto que existe la cuestión de la compatibilidad con pre código Java 5 ...

Sí. Esta es la raíz del problema.

• Si @deprecated la interfaz Serializable de (digamos) de Java 5, a continuación, las porciones de código de edad pre-Java 5 darían advertencias o errores (en función de los interruptores del compilador).

• No hay nada realmente malo con el uso de Serializable y "forzar" a las personas a que lo reemplacen es molesto. (La gente tiene mejores cosas que hacer ...)

• Cuando la gente ha "corregido" esto en su código, ya no compilará utilizando un compilador previo a Java 5, o se ejecutará en una JVM previa a Java 5.

• Es una mala idea hacer cosas que hacen que el compilador sistemáticamente "llore lobo".

... pero en algún momento que va a terminar.

En realidad, la posibilidad de que esto sucediendo realmente es (OMI) pequeña. Por lo que sé, Sun/Oracle tiene nunca eliminó una característica obsoleta. Ni siquiera los peligrosos como Thread.stop() y amigos.

---

Como una nota al pie, los desarrolladores Go están tomando un enfoque diferente a este problema. Cuando quieren cambiar un idioma o función de biblioteca, simplemente lo hacen. Proporcionan un converter que reescribirá automáticamente su código según sea necesario.

Answer 4

La depreciación es para cosas que son activamente dañinas. Lo que sugiere es forzar a los autores de ocho años de código Java existente (en ese momento) a reescribirlo, sin ninguna ventaja, solo para cerrar las advertencias del compilador de desaprobación, para volver al código completamente correcto que tenían con Java 1.4 . Eso no sería útil.