¿Debería Java romper la compatibilidad con versiones anteriores en beneficio de un lenguaje más limpio?

Question

• ¿Son primitivas las que vale la pena conservar?
• ¿Deberían eliminarse todas las cosas en desuso?
• ¿Necesitamos 2 marcos de GUI?
• ...

Answer 1

Como tengo already mentioned, incluso en su How and When To Deprecate APIs, nada se dice acerca de una política relativa a la eliminación de realidad las API obsoletas ...

El número de aplicaciones basadas en JVM mayores (por ejemplo 1.4) es siendo importante, en parte debido a servidores de aplicaciones que toman mucho tiempo para validar a sí mismos con nuevas versiones de JVM ...

El gran número de aplicaciones que en realidad se están ejecutando en la producción de esta política significa “compatibilidad hacia atrás” puede no estar roto en cualquier momento pronto.

Answer 2

Puesto que, la mayor parte de la cuota de mercado todavía utiliza JDK mayor/jre No creo que vaya a ser pragmáticos para romper la compatibilidad hacia atrás.

Answer 3

Como dijo Pat, la adopción de la última versión de JDK es bastante lenta, y muchas aplicaciones se están ejecutando actualmente utilizando versiones antiguas (a veces muy antiguas) de Java.

Por lo tanto, no creo que haya un beneficio real de no garantizar la compatibilidad con versiones anteriores.

Para sus sugerencias, realmente no veo el interés de eliminar las primitivas. Por supuesto, hay autoboxing desde Java 5. Sin embargo, las primitivas aún tienen sus intereses ...

Answer 4

La compatibilidad de ruptura tendría sentido si la JVM mantiene lo mismo. En ese caso, la "nueva" Java se convertiría en un lenguaje nuevo y diferente que se ejecuta en la JVM, como los enumerados en there. Afortunadamente, la forma en que está diseñada la JVM garantiza la interoperabilidad entre idiomas y versiones, por lo que creo que el impacto sería limitado.

Answer 5

Puede hacerlo con hobby (Ruby), idiomas de baja implementación (Python), pero no puede imaginar cuántas aplicaciones se escriben en Java en todo el mundo. Solo revisa la carne fresca o la forja de origen. Y eso es solo una parte. Entonces no, no es una buena idea. En realidad, sería una idea bastante estúpida.

No hay dos marcos de GUI. Swing depende y usa AWT como su base.

Answer 6

Creo que un tenedor sería más apropiado para darle al lenguaje una revisión adecuada. La forma en que funcionan los genéricos de Java está comenzando a enojarme, francamente.

Answer 7

La razón por la que dejé PHP es porque alteran las funciones API/disponibles entre las actualizaciones de versiones principales. El problema real es que PHP no puede ejecutarse en modo de compatibilidad, para scripts anteriores. No quiero FORZAR para actualizar mi código.

Java está en el mismo lugar. Solo asegúrate de que puedes usar el antiguo material 1.4 en las nuevas versiones. Está bien solicitar nuevos programas para usar una nueva xyntax, ¡pero hacer funcionar las cosas viejas!

Answer 8

En cuanto a los primitivos, siempre estarán ahí, nos guste o no, porque son los componentes básicos de los objetos.Claro, podría usar las clases contenedoras en su lugar, pero eso simplemente sobrecarga el compilador, que finalmente se traduce a primitivas en la mayoría de los casos.

La compatibilidad con versiones anteriores es muy importante, y como ya se ha mencionado aquí, hay muchos usuarios que siguen utilizando el código 1.3 y 1.4. Habiendo dicho esto, creo que si alguien todavía está ejecutando el código de Java 1.0 o 1.1 en algún sistema heredado, no es probable que migren a Java 7 en el corto plazo, y aunque lo hagan, lo más probable es que necesiten reescribir su código. código de todos modos. Creo que la API obsoleta de las versiones> 1.2 se puede eliminar de forma segura.

Otro aspecto de la compatibilidad con versiones anteriores es la adición de palabras clave, que siempre se desaconseja. en Java 5, los principales cambios de idioma se manejaron con la adición de una nueva palabra clave, 'enum', e incluso eso causó un escándalo, ya que cada pieza de código con una variable llamada 'enum' ahora no era compatible. Por lo que yo sé, los cambios en Java 7 están planeados sin palabras clave nuevas (¡uf!).

Yuval = 8-)

Answer 9

Será bueno, dependiendo de Sol no empujar a las nuevas actualizaciones de JDK a todos sus clientes. Aquellos que usan APIs antiguas no actualizarán y usarán un JDK de versión anterior por un tiempo.

O, quizás, implementando el modo de compatibilidad hacia atrás.

Answer 10

Me encantaría que se eliminen ciertas características en desuso - por ejemplo, si el objeto Date fuera verdaderamente inmutable, estaría muy feliz. Tal como están las cosas, si estás escribiendo una clase inmutable no puedes asumir que las fechas son inmutables y tienes que copiarlas a la defensiva, por ejemplo, y no puedes usarlas de manera confiable como claves en Hashmaps (ya que en ambos casos, otro código puede mutar la fecha independientemente de si los métodos están anotados como obsoletos o no).

Cuando se trata de agregar nuevas funciones de idioma, no entiendo completamente el mantra de compatibilidad con versiones anteriores. En mi opinión, no es gran cosa si el código escrito para una versión anterior necesita algunos ajustes para ejecutar en una versión posterior. De hecho, hay un precedente para esto de todos modos; entre 1.5 y 1.6, se agregaron métodos adicionales a la interfaz ResultSet, por lo que el código que se compilaría y ejecutaría en Java 1.5 ni siquiera se compilaría en 1.6.

Considerando las aplicaciones heredadas, ¿es razonable que alguien espere que una aplicación que no se haya actualizado en 5 años funcione perfectamente con la última versión de la JVM? Si las organizaciones todavía usan Java 1.4 y las aplicaciones que fueron escritas para él, ¿realmente les importa lo que entra en Java 7? Romper la compatibilidad con versiones anteriores no significa que todas las versiones anteriores de las JVM también se romperán. Si la aplicación está dirigida a una versión anterior, solo se puede ejecutar en esa versión de la JVM sin preocupaciones.

Lo que es más importante, a medida que pasa el tiempo y la gente utiliza Java, los errores y las brechas de características se hacen evidentes, y corregirlos/implementarlos sería una gran ventaja. Ser recto cuando trato de mejorar el idioma debido a lo que vino antes si es desafortunado, y en mi opinión no es un requisito fundamental.

Por supuesto, habría que pensar un poco en la ruta de actualización. Cambiar repentinamente enteros a enteros, por ejemplo, requeriría una gran cantidad de tediosos cambios de código para todos (además de tener que agregar comprobaciones nulas adicionales, etc.). Sin embargo, agregar una nueva función que rompe la compatibilidad con versiones anteriores (por ejemplo, cierres) o eliminar métodos que han estado obsoletos durante años tendrá poco efecto en el código existente. (Si ha estado usando métodos obsoletos, entonces debería haberlos eliminado antes, pero ahora está obligado a hacerlo)

Answer 11

Yo diría que es una estupidez hacer para romper la compatibilidad con versiones anteriores de Java. Si es así, puedes llamarlo Java ++, ya no es Java.Por otro lado, para las versiones futuras de Java, debe aprender de un lenguaje dinámico para características tales como la simplicidad de la sintaxis. Dado que la potencia del hardware está aumentando tan rápido, el nivel de resumen debe ser mayor para un lenguaje de compilación. Comparando algunas características de las versiones actuales de Java con lenguajes dinámicos, es demasiado torpe y prolijo, por lo tanto, menos productivo para el desarrollo. Parece que C# se está convirtiendo en un lenguaje dinámico?

Answer 12

Por razones de compatibilidad, no pueden hacer eso con las versiones estándar de Java. Ahora hay tanto software de Java en producción que simplemente no puede romperlo con una nueva versión que elimina todo el material.

Sin embargo, creo que Sun podría hacer una versión de "Java X" que eliminó todo lo que era escaso, y agregó todas las API buenas y útiles que existen pero que no están incluidas (incluida la sustitución de API de Java que tienen mejores alternativas disponible, por ejemplo, log4j, y no comencemos en Fecha y Calendario). Esta versión no estaría diseñada para reemplazar a Java, pero podría existir como un objetivo para nuevos proyectos de software. Supongo que también podrían arreglar el lenguaje para incluir características que faltan que hacen que Java parezca un poco complicado en comparación con las últimas versiones de C#, etc. Si también crearan una herramienta de portado de código que podría arreglar o al menos agregar "FIXME" para todas las áreas problemáticas en una base de código ...

Tengo que admitir que Microsoft hace un buen trabajo para trasladar a las personas a las versiones más nuevas de .NET cuando salen. Sun ha fallado totalmente aquí, dada la cantidad de aplicaciones que aún se ejecutan en 1.4, y las políticas letárgicas de la versión de Java de muchas compañías (que parecen felices de dejar que su gente de .NET use lo último y mejor de alguna manera). Dado que es simple tener múltiples instalaciones Java en una máquina, creo que se debe hacer más para alentar a las empresas y las casas de software a actualizarse antes.

Answer 13

Existen varios tipos de compatibilidad con versiones anteriores:

1. Puede compilar el código fuente viejo con el nuevo compilador?

   Esto se puede manejar con herramientas que convierten construcciones antiguas en nuevas, o con algo así como una "fuente 1.6"; directiva en la parte superior del archivo.

2. ¿Se pueden ejecutar archivos de clases antiguas en una nueva JVM?

   En mi mundo, este es un completo stop-show. Utilizamos tantas bibliotecas de terceros que forzar una actualización simultánea de todas ellas sería demasiado costoso.

   Este es también el controlador para no eliminar clases y métodos en desuso, pero en menor medida.

3. ¿Pueden los archivos de la clase anterior codificar la llamada compilada con el nuevo compilador?

   Esta es una parte importante del n. ° 2, debido a las devoluciones de llamada.

4. ¿Puede código de llamada compilado recientemente de archivos de clase anteriores?

   Otra parte importante del n. ° 2.

5. ¿El código se ve sustancialmente similar a los desarrolladores?

   Esto es importante para el entrenamiento y para trabajar con bases de código grandes que no se han convertido completamente. Un aspecto más sutil es la cantidad de la nueva característica que se puede usar en una base de código mixta. Si rompe esto demasiado, tiene algo como Scala en lugar de Java ++.se añadieron

Generics en un tal era como para preservar todo de estos tipos de compatibilidad. Creo que cualquier cambio incompatible en Java debe conservar al menos 2, 3 y 4 para tener alguna posibilidad de aceptación como Java. Las herramientas para manejar # 1 también son un requisito mínimo.

Answer 14

Con muchos idiomas alternativos geniales en la JVM, realmente no veo ningún motivo. Prefiero tener una Java estable y seguir con las cosas nuevas y geniales (y seguir siendo compatible con Java).

Answer 15

Creo que se debe reescribir alguna API para el tiempo de fecha de ejemplo. Si la versión actual recibe EOL, entonces la antigua API debe eliminarse. Nuestra estadística muestra que el 99,3% de nuestros clientes usan Java 6 o posterior. No hay necesidad de compatibilidad muy antigua API. Pero debe haber un marco de tiempo claro si se eliminará una API.