sintaxis - Nuevas palabras clave en Java 9

tipos de variables en java ejemplos

Question

Una de las características más grandes de Java 9 será un sistema de módulos definido por Project Jigsaw. Al leer diapositivas del "Proyecto Jigsaw: Under the Hood" en JavaOne 2015, noté el siguiente código fuente:

// src/java.sql/module-info.java
module java.sql {
exports java.sql;
exports javax.sql;
exports javax.transaction.xa;
}

Lo que es interesante para mí es que el archivo termina en .java y parece usar dos nuevas palabras clave: module y exports . ¿Qué otras palabras clave se presentarán en Java 9? ¿Cómo se tratará la compatibilidad con versiones anteriores (es decir, funciones o variables denominadas module )?

Answer 1

Probablemente esta no sea una lista completa, y nada de esto se ha finalizado a mi leal saber y entender, pero encontré algunas.

También tenemos module , exports , provides , uses , with , to y requires ; explicado aquí :

El sistema de módulos podría identificar los usos de los servicios escaneando los archivos de clase en artefactos de módulos para las invocaciones de los métodos de carga de ServiceLoader ::, pero eso sería tanto lento como poco confiable. El hecho de que un módulo utilice un servicio en particular es un aspecto fundamental de la definición de ese módulo, por lo tanto, tanto para la eficacia como para la claridad, lo expresamos en la declaración del módulo con una cláusula de uso:

module java.sql {
requires public java.logging;
requires public java.xml;
exports java.sql;
exports javax.sql;
exports javax.transaction.xa;
uses java.sql.Driver;
}

El sistema de módulos podría identificar proveedores de servicios escaneando artefactos de módulos para META-INF / entradas de recursos de servicios, como lo hace la clase ServiceLoader en la actualidad. Sin embargo, que un módulo proporcione una implementación de un servicio en particular es igualmente fundamental, por lo que lo expresamos en la declaración del módulo con una cláusula de suministro:

module com.mysql.jdbc {
requires java.sql;
requires org.slf4j;
exports com.mysql.jdbc;
provides java.sql.Driver with com.mysql.jdbc.Driver;
}

...

module java.base {
...
exports sun.reflect to
java.corba,
java.logging,
java.sql,
java.sql.rowset,
jdk.scripting.nashorn;
}

view y permits :

En sistemas de software grandes, a menudo es útil definir vistas múltiples del mismo módulo. Una vista puede ser declarada para uso general por cualquier otro módulo, mientras que otra proporciona acceso a interfaces internas destinadas solo para ser utilizadas por un conjunto selecto de módulos estrechamente relacionados.

Por ejemplo, con JNDI queremos que com.sun.jndi.toolkit.url sea visible solo para los módulos cosnaming y kerberos, tal como se especifica en la declaración del módulo.

view jdk.jndi.internal {
exports com.sun.jndi.toolkit.url.*;
exports sun.net.dns.*;
permits jdk.cosnaming;
permits jdk.kerberos;

}

De esta manera, tenemos más flexibilidad para definir los límites del módulo.

También he escuchado mención de optional .

Answer 2

Para la parte de compatibilidad hacia atrás de la pregunta.

Creo que JAVA9 / project jigsaw es un cambio de paradigma en la tecnología Java. para que java9 no sea compatible con versiones anteriores, pero puede transformar fácilmente su dependencia no modular con la versión modular de la misma biblioteca. el concepto de "No-Pain, No-Gain" funcionará aquí. Todo el mundo tiene que actualizar / transformar para aprovechar el nuevo java modular. El desarrollador de IDE, el desarrollador de complementos, el sistema de compilación y, por supuesto, el desarrollador de java de nivel de group necesitan comprender los nuevos sistemas de Java.

JAVA9 aboga por la dependencia limpia. también proporciona una nueva forma de proteger su código mediante módulos privados. incluso la reflexión no puede acceder a los módulos no expuestos por el propietario de la biblioteca / API.

Hay dos enfoques para usar LIB / API no modulares.

1. Enfoque de arriba hacia abajo
2. Enfoque de abajo hacia arriba (mucho dolor aquí para implementar)

segundo enfoque hacer una jerarquía de dependencia de módulo muy limpio.

Answer 3

módulo es una nueva palabra clave introducida para definir las interdependencias entre paquetes. ¿Por qué necesitamos módulos? Porque antes

1. la encapsulación no estaba inmaculada. Con la ayuda de la reflexión y con técnicas similares podríamos acceder incluso al campo privado.
2. Todas las clases en todos los frascos fueron de acceso público.

3. Si el Classloader no obtiene la clase, debe buscar en muchas áreas y cargar muchos archivos relacionados, e incluso después de eso, si no se encuentra la clase, lanzará NoClassDefFoundErrors en tiempo de ejecución.

   Entonces, por todos los motivos anteriores, necesitamos un mecanismo que permita a JVM saber esto en tiempo de ejecución. Para implementar el módulo, necesita definir module-info.java . en ese paquete

    module com.exporter{
   exports com.a;
   provides com.b.M;
   with com.b.MImpl; }

En algún otro paquete,

module com.consume {
requires com.a;
}

Otros atributos utilizados son " exportaciones " y " requiere " para realizar una interdependencia (dependencia transitiva solamente), " proporciona " y " con " para exponer la interfaz y mencionar la implementación. Por lo tanto, una encapsulación fuerte, puede ser, es por eso que java 9 está más inclinado a una mejor característica orientada a objetos.

Answer 4

Las palabras clave agregadas para las declaraciones de módulo en Java 9 se resumen en el §3.9 de la Especificación del lenguaje Java, Edición Java SE 9 :

Otras diez secuencias de caracteres son palabras clave restringidas: open , module , requires , transitive , exports , opens , uses , provides y with . Estas secuencias de caracteres se tokenizan como palabras clave únicamente donde aparecen como terminales en las producciones ModuleDeclaration y ModuleDirective (§7.7). Se tokenizan como identificadores en cualquier otro lugar, para compatibilidad con programas escritos antes de Java SE 9. Hay una excepción: inmediatamente a la derecha de la secuencia de caracteres se requiere en la producción ModuleDirective, la secuencia de caracteres transitiva se tokeniza como palabra clave a menos que sea seguido de un separador, en cuyo caso se tokeniza como un identificador.

Si actualmente tiene un método denominado module o cualquiera de las otras palabras clave que se enumeran aquí, continuará compilando.

(La view y los permits eran palabras clave en un prototipo de Jigsaw anterior, pero se simplificaron hace tiempo).