Ya puedes probar Java 8 con Jigsaw: disponible Java 8 Developer Preview
Abraham
Nos acaba de informar @greeneyed_dlj a través de Twitter que una versión Developer Preview de Java 8 que incluye el proyecto Jigsaw está disponible para descarga, lo cual quiere decir que ya podemos probar uno de los dos principales cambios que va a traer Java 8 (el otro son las closures).
El soporte de modularidad permitirá dividir aplicaciones en módulos que puedan cargarse de forma independiente; estos módulos pueden tener dependencias entre sí. Lo importante de esto para nosotros los programadores es que podremos librarnos del jar hell, el típico escenario donde tenemos en nuestro proyecto varias versiones de una misma librería y no hay forma de especificar que para cierta parte de nuestra aplicación necesitamos X versión y para otra, Y.
Además Jigsaw mejorará la mantenibilidad y la encapsulación de nuestra aplicación porque, en teoría, podríamos tener módulos poco acoplados entre sí. Por lo que podríamos hacer cambios dentro de uno, minimizando el impacto de estos cambios ya que los modulos dependerían entre sí sólo a través del contrato público especificado para cada uno.
Java resolverá los módulos en tiempo de:
- Compilación
- Instalación. Si usas algun servidor que tenga módulos preinstalados, Java los encontrará cuando instales tu aplicación en él.
- Ejecución. Java será capaz de encontrar de forma dínamica y en tiempo de ejecución los módulos de los que depende tu aplicación.
Por defecto, los módulos se declararán en un archivo llamado module-info.java y tendrán la siguiente estructura:
module foo @ 1.0 { //declara un módulo y su versión
exports foo; //declara que este módulo exporta las clases en el paquete foo
}
module bar {
requires public foo; // Re exporta los tipos exportados por foo
}
module baz {
requires bar @ >= 1.0; // Declara dependencia al módulo bar, versiones 1.0 o superiores
class baz.Main //declara la clase de entrada al módulo
}
Podéis leer sobre el proyecto Jigsaw en más detalle en esta noticia publicada por Erick.
¿Creéis que esta nueva funcionalidad de Java 8 os será muy útil?
Reader Comments (5)
Tengo la sospecha bien fundada de que en cuanto esté disponible la versión GA de JavaSE 1.8, allá por el verano del año que viene... todavía se estará discutiendo sobre la conveniencia de actualizarse a la última versión de Java SE 1.6ux, que estará obsoleta por entonces.
En mi caso, puesto que uso NetBeans Platform, estoy acostumbrado al diseño modular, y conceptos como "eager" y "autoload", "load and unload", relativos a módulos, son habituales. No me encontraré con un cambio de mentalidad sustancial, en cuanto comience a usar esta nueva versión de JavaSE.
Mi principal interés es el Proyecto Lambda, para lo que ya llevo cierto tiempo haciendo cambios en el código, con vistas a una intensa refactorización, en cuanto me decida a usar JavaSE 1.8 como plataforma por defecto. No antes del año que viene.
Pues la verdad, a nivel de código, no me termina de convencer. Me gusta un sistema modular, pero más dinámico, como por ejemplo, OSGi, donde toda la definición modular y dependencias se hace en el archivo MANIFEST.
Saludos...
@Juan
Creo que ésto responde a tu dudas:
"Module declarations alongside source code — It must be easy for developers to both write and read module declarations. The Java language syntax must be extended to define declarations of module metadata. The syntax and, to the degree possible, the semantics of module declarations must be specified in the Java Language Specification. A module declaration must be written in a file that resides with the module’s source content, rather than in a side file in some other format or, even worse, a set of command-line arguments baked into a build script."
http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12
Hay en este blog, unos comentarios bastante interesantes sobre el tema:
http://njbartlett.name/2011/05/27/jdk8-modularity-requirements.html
"The second point of note is that the requirements for this new module system are really not that far from OSGi itself! Aside from cosmetic differences, such as the location and format of module metadata, the general goals are quite closely aligned and achievable with OSGi. For example, I think that if there were a strong desire to encode metadata in a file named “module-info.java” instead of a file named “MANIFEST.MF” then an agreement could be reached within the auspices of the OSGi Alliance."
Como dice Juan, me parece que OSGi está mejor preparado para aportar una modularidad real sobre Java.
Si bien es cierto, que con el tiempo se busca que Jigsaw y OSGi puedan ser compatibles entre ellos como bien explica Neil Bartlett en la charla del último OSGi Dev Conf (http://njbartlett.name/2011/05/27/jdk8-modularity-requirements.html)
No perdamos de vista que Jigsaw es una especificación del lenguaje, que se implementa sobre el mismo JDK, mientras que OSGi es un contenedor que usa el JDK.
Hay más "vida" en contenedores modulares de la que se supone:
http://wiki.apidesign.org/wiki/NetBeans_Runtime_Container
http://wiki.apidesign.org/wiki/Equinox
http://wiki.apidesign.org/wiki/Netbinox