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

serialización en netbeans

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, debe implementar la interfaz Serializable (que es solo eso, un marcador) y usar más palabras clave transient para marcar un campo como no serializable si es necesario, algo como:

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

Ahora, en teoría, podría hacer uso de anotaciones (este es un uso perfecto para ellos) y tener:

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

Pero la interfaz y la palabra clave no se desaprobaron y no se agregó ninguna anotación en Java 5 para reemplazarlas.

¿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, relacionado con las nuevas características de los genéricos, el JLS especifica que es posible que las versiones futuras del lenguaje de programación Java no permitan el uso de tipos sin procesar ). Entonces, ¿por qué no preparar el camino para anotaciones serializadas también?

¿Alguna idea? (aunque preferiría referencias concretas: D que no pude encontrar)

Answer 1

Por supuesto, existe la cuestión de la compatibilidad con el código pre Java 5 ...

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

• Si ellos @deprecated la interfaz Serializable en (digamos) Java 5, entonces muchos de los viejos códigos anteriores a Java 5 darían advertencias (o errores dependiendo de los modificadores del compilador).

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

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

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

... pero en algún momento eso terminará.

En realidad, la probabilidad de que esto realmente suceda es (IMO) pequeña. Por lo que sé, Sun / Oracle nunca han eliminado una característica en desuso. Ni siquiera los peligrosos como Thread.stop() y amigos.

Como nota al pie, los desarrolladores de Go están adoptando un enfoque diferente para 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 2

La depreciación es por 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.

Answer 3

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

public void registerObject(Serializable obj);

Answer 4

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

No han sido desaprobados, probablemente porque hay muchos programas que usan Serializable y habría sido molesto para millones si los desarrolladores si el compilador de repente comienza a emitir miles de advertencias de depreciación.

Hay muchas otras cosas en la API estándar de Java que podrían haber quedado en desuso hace mucho tiempo, por ejemplo, las clases heredadas de colecciones Vector y Hashtable (y estoy seguro de que puede encontrar muchas más cosas fácilmente). Y hay otras cosas que podrían haberse implementado usando anotaciones (por ejemplo, la palabra clave volatile , strictfp y synchronized ).