[vc_row][vc_column][vc_column_text]El arquitecto de Java, Mark Reinhold, Jefe del Grupo de Plataformas Java en Oracle, tiene literalmente millones de desarrolladores Java para mantenerse feliz. Esa no es una tarea simple.
Justo antes de JavaOne, se hicieron varios anuncios sobre la plataforma Java, incluido el cambio a un tiempo de lanzamiento de seis meses, así como una propuesta para un nuevo esquema para las versiones del JDK.
Es justo decir que la comunidad de Java respondió muy favorablemente a la idea de que se lanzaría una nueva versión dos veces al año. Una queja sobre Java en el pasado ha sido la velocidad a la que las nuevas funciones se han puesto a disposición. En teoría, la cadencia de lanzamiento desde que Oracle adquirió Sun Microsystem ha sido de dos años. En la práctica, ese no ha sido el caso. JDK 7 fue lanzado en julio de 2011, que fue más de cuatro años y medio de JDK 6. JDK 8 salió a la luz un poco menos de tres años después y, con el lanzamiento de JDK 9, este septiembre, pasaron tres años y medio entre lanzamientos.
Con un calendario estricto de lanzamientos, los contenidos de las versiones estarán impulsados por lo que está listo para ser lanzado, no por lo que se apunta para una versión específica. Menos cambios en cada lanzamiento, pero la oportunidad de obtener cambios más rápidamente.
Hasta aquí todo bien. Sin embargo, la propuesta para el nuevo esquema de numeración de versiones no fue bien recibida.
Podría parecer que la numeración de versiones debería ser relativamente sencilla, pero ese no es el caso en realidad. Históricamente, Java ha tenido lo que mejor podría describirse como un esquema de numeración de versiones algo esquizofrénico.
Echemos un vistazo al historial de versiones Java.
Al principio, teníamos JDK 1.0, eso tiene sentido, la primera versión oficial con la posibilidad (indicada por al extensión .0) demás actualizaciones. El problema se convierte de inmediato en lo que se califica como una actualización. La siguiente versión, JDK 1.1, incluía nuevas características razonablemente significativas, como inner classes y reflection. En retrospectiva, esto se habría denominado mejor JDK 2.0.
Las cosas salieron un poco raras cuando se lanzó la siguiente versión. Lo siguiente es la forma en la que el marketing chocó con la ingeniería, y ninguno admitiría la derrota. En este punto, Java fue rebautizado (entrada del marketing) a Java 2. También se dividió en tres grupos tecnológicos distintos. Así tuvimos Java 2 Micro Edition (J2ME) para teléfonos y aplicaciones integradas, Java 2 Standard Edition (J2SE), para la plataforma central y Java 2 Enterprise Edition (J2EE) para aplicaciones basadas en el contenedor del servidor de aplicaciones. Esto debería haber estado bien; excepto que la ingeniería de alguna manera no se metió en esto (al menos no para Java SE) y así terminamos con Java 2 SE versión 1.2. Esto, fue un error, ¿Por qué mantener el 1. prefijo y no cambiarlo a 2.0?[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]Para hacer las cosas aún mas confusas, la siguiente versión fue Java 2 SE versión 1.3 seguida de una actualización con cambios más pequeños, Java 2 SE versión 1.3.1. La adición de una subdivisión adicional parece algo arbitraria, dada la numeración de la versión anterior. En este momento, el departamento de marketing decidió que Java 3 no iba a suceder y obtuvimos una distinción entre la marca Java (Java 2 SE) y el JDK, luego JDK 1.4, JDK 1.4.1 y JDK 1.4.2.
La siguiente versión de Java incluía el conjunto más significativos de cambios en el lenguaje desde su lanzamiento (enumeraciones, tipos genéricos, monedas en los proyectos, etc) así como nuevas librerías sustanciales (por ejemplo, las librerías de concurrencia). Se tomó la decisión de que esto se refleje en el número de la versión. Por lo tanto, tuvimos Java 2 SE versión 5.0. Desafortunadamente, la ingeniería, presumiblemente consciente de los problemas de compatibilidad, se quedó con el esquema de numeración existente internamente, por lo que la versión Java inicialmente devolvió 1.5.0. Sin embargo, se requieren actualizaciones periódicas que incluían errores y correcciones de seguridad, por lo que se introdujo un esquema de actualización oficial. Esto nos dio Java 2 SE 5.0 actualización 1 y JDK 1.5.0.1 de java -version.
Con nueva gente en marketing de Sun, se tomó la decisión de simplificar las cosas, así que la siguiente versión era Java SE 6. No más de 2 y el .0 fue oficialmente descartado. java – version aún devolvió jdk 1.6.0.1.
Los siguientes 10 años fueron un período de relativa estabilidad de numeración de versiones que nos dio Java SE (JDK 1.7.0) y Java SE (JDK 1.8.0). Lo único que se nota que cambio fue la numeración de las actualizaciones. Esto cambio a un incremento de cinco para cada versión de actualización limitada o actualización de parche crítico, que es la terminología de Oracle. La razón de esto era que estos lanzamientos estaban programados para cada trimestre y en el caso de un parche de emergencia antes de la fecha de lanzamiento prevista, era necesario que hubiera números disponibles. Además, en algún momento (que no puedo determinar) el valor devuelto por java -version comenzó a usar un guión bajo en lugar de un período para la actualización, por lo que se convirtió en jdk1.8.0_131, por ejemplo.
Con JDK 9 teniendo una serie de cambios incompatibles, se tomó la decisión de limpiar correctamente la numeración de la versión de una vez por todas. Esto fue descrito en JEP 223, y ahora tenemos un esquema de numeración de versión más semántica. La especificación para la plataforma central es Java SE 9 (definida a través de JSR 379), y la versión JDK ahora es $ MAJOR. $ MINOR. $ PATCH (por ejemplo, 9.0.5).
En este punto, parecería que todo está bien.
Lamentablemente no. Como se menciono al principio, la nueva cadencia de lanzamiento de seis meses para el JDK también provocó una propuesta para un nuevo formato de cadena de versión. Esto se basaría en la fecha del lanzamiento ya que esto se arreglaría. Por lo tanto, la próxima versión de Java sería Java SE 18.3 (18 para el año, 2018 y 3 para el mes, marzo). Otros lo han usado en el pasado, obviamente Ubuntu.
Desafortunadamente, esto no fue recibido con la misma aceptación universal que la idea de una cadencia de lanzamiento de seis meses. Personalmente, no vi ningún problema con esto, pero algunos miembros de la comunidad plantearon importantes objeciones.
Con base en esta retro alimentación, Mark ha revisado el esquema de numeración propuesto. Ahora tenemos un esquema definido de cuatro dígitos: $ FUNCIÓN. $ INTERMEDIO. $ ACTUALIZACIÓN. $ EMERG. Los detalles completos de esto se pueden encontrar en la publicación de Mark en la lista de correo de jdk-dev.
Esto parece más popular que el esquema AÑO.MONTH, pero a Stephen Colebourne en particular todavía no le gusta esto. Hablé con Mark sobre esto en JavaOne, e hizo una buena observación, que creo que Stephen está pasando por alto. Si ignora los cambios en el esquema de numeración y piensa en esto en términos de lo que hemos tenido antes, la única diferencia es que las versiones de actualización del JDK ahora pueden contener cambios de funciones, ya sea por adición o eliminación de características.
El mayor problema que enfrenta Java es cómo atraer a dos audiencias distintas de desarrolladores. Por un lado, tiene grandes usuarios comerciales que desean estabilidad con soluciones de seguridad públicamente disponibles a largo plazo y corrección de errores. Por otro lado, tiene desarrolladores de vanguardia que desean acceder a las últimas funciones lo más rápido posible. El tercer cambio que se anunció al mismo tiempo que el nuevo esquema de cadencia de versión y cadena de versión resuelve este dilema.
Las versiones de Java se dividen en dos grupos:
- Lanzamiento de funciones: Tendrán actualizaciones públicas solo hasta la próxima versión de la función, es decir, durante seis meses. Estos son, en efecto, los mismos que los lanzamientos de actualización a los que hemos estado acostumbrados, con la excepción de que pueden contener nuevas características o eliminar las que ya estaban en desuso.
- Versiones de soporte a largo plazo (LTS): Estos son los mismos que los de una publicación de características, excepto que tendrán actualizaciones disponibles públicamente durante tres años. Las correcciones de errores y de seguridad de las futuras versiones de las funciones serán retransmitidas a estas versiones. JDK 8 es una versión LTS, y la próxima será en septiembre del próximo año, que será JDK 11. Para ser claros, JDK 9 es una publicación de características, no una de LTS.
Los usuarios comerciales que buscan estabilidad solo tienen la opción de usar las versiones LTS, actualizándose cada tres años. Para los desarrolladores más avanzados, pueden tomar la versión que deseen para las nuevas características y moverse de una manera más ágil, pero aceptando que necesitarán actualizarse cada seis meses.
Con suerte, se aprobará el nuevo esquema de numeración y Java 10 será la próxima versión.
¿O deberíamos llamarlo Java X?[/vc_column_text][/vc_column][/vc_row]
