O Jigsaw se cae de Java 8, o Java 8 se retrasa
Abraham
Éste es el estado del proyecto Jigsaw, proyecto que pretendía introducir soporte para modularidad dentro de la plataforma Java, y que inicialmente estaba previsto para Java 7 y fue retrasado a Java 8 porque no podría ser completado a tiempo. Hoy Mark Reinhold, Chief Architect of the Java Platform de Oracle, ha comunicado a través de un e-mail a la lista del Openjdk cuál es el estado actual del proyecto.
Mark ReinholdAunque existe una implementación opensource de Jigsaw que ya es funcional, no es viable completar todo el trabajo relacionado con modularizar las distintas partes de la plataforma Java SE antes de mayo de 2013, el momento en el cual Java SE 8 debería de dejar de añadir funcionalidad y dedicarse sólo a resolver bugs para poder estar terminado a mediados de 2013. Parte de los motivos por los cuales no van a ser capaces de hacer esto es porque este mecanismo de modularidad debe ser válido también para Java ME (lo cual facilitará la "convergencia" de las dos plataformas de la cual tanto habla Oracle) y para Java EE.
Según Mark, incluir soporte para módulos es hacer un cambio muy importante en la plataforma y no debe hacerse a la ligera. La implementación debe testarse meticulosamente y con tiempo. No es posible cumplir con el plazo prefijado para Java 8 (septiembre de 2013). Por tanto es necesario realizar la misma elección que ya se realizó en su día entre Java 7 y Java 8, pero esta vez eligiendo entre Java 8 y Java 9; las dos opciones son:
- Se completa Jigsaw, lo cual hará que Java 8 (con soporte para modularidad) se libere a mediados de 2014, en vez de en septiembre de 2013.
- Se retira Jigsaw de Java 8, pasando a incluirse en Java 9 (planeado para mediados de 2015) y Java 8 se publica en la fecha prevista (septiembre de 2013).
Mark apuesta por tener un horario predecible para la plataforma, liberando una nueva versión mayor cada dos años, y asumiendo que esto trae como consecuencia que en este caso Jigsaw se queda fuera de Java 8, y eso es lo que él defiende. Ahora el tema se va a discutir en la lista del OpenJDK entre los miembros del Comité de expertos de Java SE 8 para ver qué se decide finalmente.
¿Cual creéis vosotros que es la mejor opción? Hagamos una pequeña encuesta al respecto:
Reader Comments (15)
Jooodeeeerrrr: sí que tiene faena esto del Jigsaw.
De verdad que no sé (y así lo he dicho en la encuesta) qué haría yo.
Por un lado, al menos para mi, este proyecto es clave para la evolución de Java y se está necesitando con urgencia para resolver no pocos problemas que el modelo actual acarrea; por otro lado más vale que cuando aparezca esté bien concebido, sea completo y sin errores notorios, porque de otro modo nos veríamos en una situación similar o peor a la actual.
En fin, que lo que tengo claro es que no me gustaría estar en el pellejo de Mark Reinhold.
Esta es la relación de mejoras en las que se está actualmente trabajando:
http://openjdk.java.net/jeps/0
Si hay que esperar otro año más, hasta 2014, para que estén disponibles, a causa de Jigsaw... prefiero que sea Jigsaw quien espere.
Por otro lado, sigue sin estar nada claro que Jigsaw se pueda implementar, sin romper la base de código existente. Esa es la causa principal del retraso.
Java no fue concebido con estructura modular, y quien haya realizado una refactorización de un proyecto "monolítico" a otro modular, ya sabe la clase de dificultades a las que debe hacer frente. Precisamente a las que hace referencia Reinhold.
apenas las empresas están empezando a adoptar java7 a pesar de que los cambios son muy pequeños yo creo que podemos esperar un poco mas para 8
Definitivamente debemos esperar, la versión de Java 7 tuvo cambios muy leves, y sacar un Java 8 otra vez con cambios mínimos sería abusar de estar sacando versiones, aparte Java 7 aún no se consolida, yo creo que debemos esperar
Las mejoras sustanciales de Java 8 (Lambdas y Jigsaw) deberían haber salido con Java 7. ¿Será prudente volver a esperar?
No comprendo que se puedan considerar como "cambios mínimos" el soporte de Lambdas, el nuevo Date/Time, o las nuevas Typed Annotations. De igual manera, tampoco creo que fuesen "cambios mínimos" los aplicados a JavaSE 1.7
Con la cantidad de "ruido" a propósito de que Java no implementaba los Lambdas, y el no menor sobre la desastrosa implementación de Date, ahora parece que todo tiene que esperar a que se resuelva la "modularidad".
Yo ya uso implementaciones modulares, aunque JavaSE no las soporte en el JDK. Y quienes usan OSGi estarán en una situación parecida.
Lo de no tener closures ya huele, la modularizacion puede esperar, y en teoría con OSGi se pueden hacer ya estas cosas
Los que dicen que total para sacar Java 8 cuando todavía no esta consolidado Java 7... pensad que la fecha prevista de Java 8 es septiembre del 2013... dentro de más de un año. Para entonces Java 6 ya estará EOL desde hace un rato, como salió por aquí.
Yo prefiero que cuando lo hagan, lo hagan bien. Es una putada tener que esperar, pero es lo que hay dados los recursos que se tienen.
¿Alguien recuerda donde quedaron los resultados de la encuesta sobre versiones de las JVM que armo Abraham en su momento?.
Pregunto, porque seria interesante tener a mano ese dato para darle un poco de contexto a las cosas.
@choces
"Java no fue concebido con estructura modular"
Con todo el respeto, pero java si se pensó para utilizarse de forma modular.
http://docs.oracle.com/javase/1.3/docs/api/java/net/JarURLConnection.html
http://docs.oracle.com/javase/1.3/docs/guide/jar/jar.html
El problema en todo caso es que este concepto de modularidad y dependencias entre módulos no se adecua a la filosofía OSGI.
Un saludo,
@efrigerio
Claro, es así como hay que hacerlo... ahora:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.3
Created-By: 1.7.0_05-b05 (Oracle Corporation)
OpenIDE-Module-Public-Packages: org.jplay.panels.lookup.services.*
OpenIDE-Module-Module-Dependencies: org.jplay.i18n/1 > 1.0, org.jplay.
root/1 > 0, org.jplay.tips > 1.0, org.jptools.core > 1.0, org.jptools
.files > 1.0, org.jptools.logging > 1.0, org.jptools.lookupbus > 1.0,
org.jptools.multimedia/1 > 0, org.jptools.sql/1 > 0, org.jptools.swi
ng/1 > 0, org.jptools.threads/1 > 0, org.jptools.tools/1 > 0, org.ope
nide.modules > 7.22.1, org.openide.util > 8.14.1, org.openide.util.lo
okup > 8.6.1, org.wrapper.jFreeChart/1 > 0.13, org.wrapper.jaudiotagg
er/2 > 0.3
OpenIDE-Module-Java-Dependencies: Java > 1.7
OpenIDE-Module-Implementation-Version: 120716
AutoUpdate-Show-In-Client: true
OpenIDE-Module: org.jplay.panels
OpenIDE-Module-Install: org/jplay/panels/Installer.class
OpenIDE-Module-Localizing-Bundle: org/jplay/panels/Bundle.properties
OpenIDE-Module-Specification-Version: 1.0
OpenIDE-Module-Requires: org.openide.modules.ModuleFormat1
Pero no me negarás que es... un parche indecente ;D
Pues yo creo que hay cosas mas importantes que puede meter Java, tanto a nivel empresarial como a nivel ¿desktop?.
A nivel empresarial lo que mas me ha molestado siempre de Java es que hicieran una especificacion, escribieran los interfaces... y esperaran a que alguien hiciera la implementacion. En el mejor de los casos, unos años mas tarde tomaban una implementacion de los de Apache y la "adoptaban" para hacerla oficial. POr ejemplo, me dio por escribir mi propio framework (otro) y cuando llegue a lo de las transacciones (que total, no son importantes) me encontre con que tenia que buscar un TransactionManager por ahi, y leyendo me encontre con una pesadilla; hay cuatro mal contados, y encima hablan mal los unos de los otros. Nunca sabes si el que estas eligiendo tiene una implementacion completa o no. Llegue a un punto en el que casi me fiaba mas de un TM que hacia un chaval por su cuenta y riesgo y que de entrada ya decia que estaba incompleto... Y usar el del servidor de aplicaciones no es solucion, porque no todo lo que se hace por ahi son JSPs, tambien hay cosas que se ejecutan fuera de un servidor de aplicaciones, con su main (y ademas, los de los servidores de aplicaciones tampoco parecen estar completos).
Si al bajar el JRE ya tuvieras implementaciones de cosas basicas como el TM o unas colas, nos habriamos ahorrado buena parte del infierno de jares en el que vivimos ahora y, sobre todo, daria apariencia de solidez a la plataforma. O aunque no estuvieran dentro del JRE/JDK, que al menos hubiera un jar de Sun/Oracle con una implementacion oficial de colas, que recurriera a librerias oficiales para las trazas, el parser de xml... Que ahora te descuidas y entre el TM, las colas y los logs te encuentras con tres parsers distintos de XML (que ademas son diferentes al que usas tu...)
Y en cuanto al desktop, pues que voy a decir. Despues de años de tenerlo olvidado, de renunciar a la potencia de los applets, de no evolucionar el aspecto de Swing (que es bueno, pero la "imagen" de los entornos graficos caduca pronto), de acordarse de el para sacar JavaFX y cargarse a Flash pero no sacarlo pero sacar la version 2 pero bueno igual no porque parece que ahora pega HTML5... El pelotazo de Java eran los applets. Cuando salieron no eran viables sobre modems de 9600, pero ahora con tanta nube son la solucion natural. Las maquinas aguantan, las redes aguantan, y la alternativa son aplicaciones con funcionalidad reducida porque se hacen HTML+JQuery (con sangre, sudor y lagrimas por parte de los programadores, quehacen magia con JS), y lo peor de todo es que nos hemos acostumbrado a que hagan poco, asi que por ejemplo, el nuevo Windows lleva como interface por defecto algo que esta a la altura del Windows 1.0.
Jigsaw esta bien y puede ayudar. Las lambdas son azucar para los programadores. Pero Java puede hacer muchas mas cosas de las que hace, ya va teniendo una edad y si quiere seguir como numero uno tiene que aplicarse bien, que el C# no es ninguna tonteria y los lenguajes de script para hacer aplicaciones simples quepiden muchos clientes aguantan el tiron.
Nilojg te doy la razón en prácticamente todo lo que dices, la diversidad es buena el problema es que en esa diversidad lo que abunda es la MEDIOCRIDAD, lo pongo con letras grandes, en lo de transaction managers autónomos es un mundo que "tela marinera".
Profesionalmente tuve que renunciar a usar transacciones distribuidas en un proyecto en el que eran VITALES, por el penoso estado de JOTM y porque a los de la herramienta que tenía que soportarlo les importaba un pimiento que la casi única alternativa, Atomikos, no se integrara bien (=no funcionara), así que me toco renunciar a la transaccionalidad.
En un proyecto propio (sí al igual que a ti a mi también me da por hacer el imbécil en mi tiempo libre) JEPLayer conseguí soportar JOTM pero PARCHEANDOLO de forma indirecta, también conseguí hacer funcionar Atomikos el cual no está mal pero tiene errores aleatorios.
Lo que voy a decir no es políticamente correcto, pero el día que renunciamos a sacar la chequera, es decir PAGAR por el software que usamos, renunciamos a exigir calidad, renunciamos a que existan empresas que compitan por llenar los vacíos que dejan otros etc etc.
Yo ahora estoy haciendo Android con acceso a datos en un servidor, cuando pienso en lo que supondría hacer más o menos lo mismo en HTML + jQuery me entran sudores frios.
Yo tengo puestas mis esperanzas en Java en el servidor, JavaFX en el escritorio, Android en las tabletas, Objective-C en iOS (raro de narices para alguien que viene de C/C++ pero creo que podría hasta gustarme) y Dart en el cliente web (o cualquier otra opción decente tipo GWT o similar por no citar mi pobre ItsNat)
Pero si prosperan los cuatro pilares del infierno: JavaScript y HTML a saco en el cliente, JavaScript a saco en el servidor con Node.js, JavaScript a saco en las tabletas con PhoneGap, o hierbas tipo Topcube en el desktop ... pues me dedico a vender seguros (antes de que el mercado laboral me lo recomiende definitivamente porque quiere sangre fresca y baratilla).
Iba a contestarle a choces que eso no es un parche si no un infierno, pero nilojg ....
Bueno no solo me a dejado sin palabras, si no que además me siento totalmente identificado con lo que pone.
@jmarranz,
Para una empresa como en la que yo trabajo (y donde sistemas es solamente un área de servicios y no "el negocio"), antes de aceptar semejante fragmentación es más probable que nos terminemos decantando por alguna herramienta tipo 4GL.
De hecho, se me pidió evaluar GeneXus (http://www.genexus.com/) y si bien para un fanático de la OOP, defensor del modelo de 7 capas y de la contratación de recursos especializados (YO) estas herramientas son horribles, mi recomendación de la herramienta (como herramienta) fue positiva para el contexto y tipo de requerimientos en particular en el que se la puede llegar a utilizar y siempre que se la complemente con otras cosas para mejorar sus prestaciones y rendimiento (EJB, Jasperreport, etc..).
Prefiero que entreguen Jigsaw en Java8 a añadir cualquier otra cosa.
Que quiten closures y demas decoraciones.
Creo que Jigsaw lo vienen anunciando antes de la 5. Parece que hay restricciones/problemas que han impedido sacar Jigsaw a tiempo o eso de cortar un gran jar en muchos pequeños es mas complicado de lo que parece.