Los (sorprendentes) planes que Oracle tiene para Java 9 y Java 10
Abraham
En Londres, en la Qcon 2012, Oracle ha presentado los planes de futuro que tiene para Java 9 y para Java 10, versiones que estarán disponibles en 2015 y en 2017, respectivamente. Las principales novedades en estas versiones serán big data, interoperabilidad multi-language, cloud e integración entre aplicaciones móviles y aplicaciones de escritorio, desapareciendo completamente la versión de "Java ME" como algo independiente de Java SE. Según Oracle, los terminales móviles pronto tendrán memoria y CPU más que suficientes para ejecutar directamente Java SE, haciendo Java ME innecesario.
Otra de las grandes sorpresas que están discutiendo es hacer que en Java 10 la plataforma pase a ser completamente orientada a objetos, descartando los tipos de datos primitivos.
Otras novedades son reemplazar el motor de JavaScript Rhino por Nashorn, instalaciones de la plataforma modulares que no necesariamente tienen que tener instalados todos los módulos (lo cual abre la puerta a la posibilidad de deshacerse de APIs deprecated).
Es mirar un tanto hacia el futuro, ya que todavía no tenemos Java 8. Pero son cambios sorprendentes, sobre todo cosas como deshacerse de los tipos de datos primitivos o que una instalación dejaba (jre) no necesariamente tengan que estar todas las API estándar. ¿Que opináis de ellos?
Reader Comments (15)
Otra de las grandes sorpresas que están discutiendo es hacer que en Java 10 la plataforma pase a ser completamente orientada a objetos, descartando los tipos de datos primitivos.
¿que va aser de la compatibilidad hacia atrás con código viejo?
Me da penilla que desaparezcan los datos primitivos, pero hay que tener en cuenta que Sun los incorporó sólo por razones de rendimiento, y hoy en día, con los nuevos compiladiores, optimizadores y con un hardware mucho más potente, creo que sería buena idea deshacerse de ellos en aras de una mayor simplicidad, que bastante complejo se ha vuelto a estas alturas el lenguaje. De hecho, yo quitaría algunas cosas más con tal de hacerlo más simple.
Por cierto, la interoperabilidad con otros lenguajes me parece crucial y una gran noticia: espero que empiecen por C, porque hasta ahora, es un dolor a menos que se recurra a soluciones como las de nuestro companero José María Arranz.
Por lo demás, creo que el resto de cambios son casi obvios...
Yo lo veo como cambio bastante heavy, sobre todo porque ese cambio va a afectar a la semántica de paso por valor/paso por referencia de parámetros en Java. A todos los efectos en estos momentos los tipos de datos primitivos se pasan por valor, y los objetos por referencia (ya sé que estrictamente hablando se pasa todo por referencia, pero éste es el "comportamiento que observa" alguien que no entiende demasiado de que esta sucediendo realmente). Cambiar de tipos primitivos a objetos haría que todo se "pase por referencia", lo cual puede ser causa de bastantes bugs, especialmente en código legacy.
Quiene quitar los tipos nativos y todavía sufrimos la ausencia de los unsigned cuando hablamos con APIs de bajo nivel. Algunos puntos son interesantes, otros me preocupan. Veremos qué hacen realmente... mientras no termine en un fork como en el móvil...
No se por que se pone tanto énfasis en los tipos primitivos para señalar que Java no es un lenguaje orientado a objetos puro. Hay muchas otras cosas en Java que no son orientadas a objetos. En mi opinión, transformar Java en un lenguaje OO puro sería perder Java...los primitivos son un detalle menor.
Igual, nadie se alarme, son cosas muy a largo plazo, y teniendo en cuenta como se retrasaron los closures, lo mas probable es que no veamos eso hasta dentro de mucho tiempo.
Es una pena que no haya mas pistas sobre el camino futuro de Java, el artículo no da mucha información.
"The ideas on SE 9 and SE 10 are what “we can do in Java, might do in Java, but won’t necessarily do in Java,” Ritter said, adding: “We don't want to make radical changes to Java” that might make programming in Java harder or open to more errors."
Solamente se trata de discusiones sobre lo que se podría, o gustaría hacer. No hay duda de que se haga lo que se haga, siempre se tenderá a no romper la compatibilidad con la gigantesca base de código existente.
Esa es una de las razones del retraso en la implementación de Jigsaw, por ejemplo.
Creo que con la interoperatividad se refieren a los lenguajes que se ejecutan, o pueden ejecutarse, dentro de la VM; que cada vez son más.
Sobre los closures, hay en estos momentos una encuesta en java.net, que no está cerrada, pero que muestra ya una clara tendencia: en estos momentos, solo un 29% de los encuestados responden que las Lambdas tendrán un gran impacto en su código, y un 27% que supondrán alguna diferencia.
Ya veremos, cuando esté disponible el JavaSE 1.8, cuántos de quienes los llevan reclamando con tanta insistencia, los usan realmente. Suponiendo que se actualicen a la versión 1.8 antes de que ya estén disponibles la 1.9 o la 1.10
Estrictamente hablando, en Java se pasa todo por valor, no por referencia. En el caso de los objetos se copia el valor que resulta ser una referencia al objeto y que no se puede modificar. De todas formas, como los wrappers de los tipos primitivos son inmutables, al no poder modificar la referencia ni poder modificar el valor, el resultado es que seria igual que hasta ahora.
Pues a mi me encantaría que quitasen los tipos de datos primitivos. Afortunadamente, desde Java 5 con el autoboxing se puede programar casi todo sin ellos.
También me gustaría que quitasen los arrays, y quizá el modificador static.
@zemi
Muchos métodos de Swing devuelven arrays de primitivas. Sin mencionar que los arrays se usan internamente en las Collections y Lists, y que son más eficientes.
El modificador static es opcional; sin embargo, no veo cómo se pueden usar las clases enum, en toda su potencia, sin él. Sin tener que pensar en usos más sofisticados.
Lo que sería innovador sería un tipo Fecha fácil de usar... que todavía no lo he visto :)
@vlopezf
Ya existe el JSR-310 desde hace años. Lo malo es que todavía no está aprobado por el JCP, y no parece que se vaya a incorporar a la especificación de Java antes de varios meses.
http://sourceforge.net/apps/mediawiki/threeten/index.php?title=ThreeTen
Si finalmente se aprueba, podría incluirse en el JavaSE 1.8, siempre que se den prisa.
Pues yo no veo razón para quitar nada. Si una determinada característica del lenguage no me gusta, no la uso y punto. Los tipos primitivos tienen sus ventajas con respecto a los wrappers, por ejemplo rendimiento, por lo que no entiendo a qué viene eliminarlos.
A mi lo más interesante, con diferencia, me parece lo de que Java SE pueda usarse en móviles. Llamadme clásico pero preferiría poder compilar mi app y que esta funcionase en iOS y Android igual que funciona en sistemas operativos "no móviles"
Suelo ser conservador en temas relacionadas con Java. Cuando estaba JDK 1.3 todavia se desarrollaba en 1.1. Ahora que esta 1.6 todavia hay 1.3 y 1.4.
La diferencia fundamental entre Java y el resto de OO son los tipos primitivos, quitarlos es dejar a Java como una plataforma de ejecucion.
Como siempre cuando Oracle se hace cargo de un producto lo suele emborronar.
Me gustaria ver instrucciones para incluir map /reduce directamente en el lenguaje de forma sencilla, al final nos crearemos una memoria por fuera y trabajaremos directamente con punteros al estilo de C.