gui - Cargando clases y recursos en Java 9

gui java netbeans

Question

Estaba leyendo este artículo en InfoQ citando a Reinhold:

Los desarrolladores aún pueden usar la ruta de clases de Java en Java 9 para que el tiempo de ejecución de Java busque clases y archivos de recursos. Es solo que con los módulos de Java 9, los desarrolladores ya no necesitan la ruta de clase.

Así que ahora mi pregunta es: ¿cuál es la forma correcta de Java 9 para hacer las tareas enumeradas anteriormente? ¿Cómo se carga dinámicamente, por ejemplo, una imagen (a menos que toque las rutas relativas)?

Aún más interesante, ¿cómo se podría verificar si una clase está disponible y tomar una decisión de forma dinámica (por ejemplo, verificar si Jackson está disponible y, de ser así, usarla para la serialización de JSON y si no se usa otra cosa)?

El artículo también menciona que Spring Boot ya es compatible con Java 9, y Spring Boot definitivamente tiene mucha carga dinámica. Entonces, ¿alguien sabe el código de Spring que puedo ver?

Answer 1

Primero, para dejar las cosas claras, ni dije ni escribí el texto citado anteriormente. Nunca lo hubiera dicho de esa manera. Eso es solo informe descuidado por parte de las publicaciones involucradas.

Lo más importante para comprender sobre la carga de clases y la búsqueda de recursos en Java 9 es que, en un nivel fundamental, no han cambiado. Puede buscar clases y recursos de la misma manera que siempre, invocando Class::forName y los diversos métodos getResource* en las Class y ClassLoader , independientemente de si su código se carga desde la ruta de clases o la ruta del módulo . Todavía hay tres cargadores de clase incorporados, tal como había en JDK 1.2, y tienen las mismas relaciones de delegación. Por lo tanto, muchos códigos existentes simplemente funcionan, listos para usar.

Hay algunos matices, como se señala en JEP 261 : el tipo concreto de los cargadores de clase incorporados ha cambiado, y algunas clases anteriormente cargadas por el cargador de clases de arranque ahora las carga el cargador de clases de plataforma con el fin de mejorar la seguridad. El código existente que asume que un cargador de clases incorporado es un URLClassLoader , o que una clase es cargada por el cargador de clases de arranque, puede por lo tanto requerir ajustes menores.

Una última diferencia importante es que los recursos no pertenecientes a un archivo de clase en un módulo están encapsulados de manera predeterminada, y por lo tanto no pueden ubicarse fuera del módulo a menos que su paquete efectivo esté open . Para cargar recursos desde su propio módulo, es mejor utilizar los métodos de búsqueda de recursos en Class o Module , que pueden ubicar cualquier recurso en su módulo, en lugar de en ClassLoader , que solo puede localizar recursos de archivos no de clase en los paquetes open de un módulo.

Answer 2

[Editar: esta respuesta fue escrita antes de la respuesta autorizada de Mark. He revisado el mío para proporcionar un ejemplo simple, disponible en GitHub .]

Según este video , la carga de clase en Java 9 no se modifica.

Como ejemplo, digamos que tenemos:

• un example.jar que contiene una imagen en el paquete net.codetojoy.example.resources
• para reforzar el jar, net.codetojoy.example.Composer es público (y se exporta, cuando corresponda)
• una clase de App simple que utiliza example.jar como biblioteca e intenta cargar la imagen desde allí

El código relevante en la App :

static InputStream getResourceAsStream(String resource) 
    throws Exception {

    // Load net/codetojoy/example/resource/image.jpg
    // Assume net.codetojoy.example.Composer is public/exported
    // resource is ''resource/image.jpg''

    InputStream result = Composer.class.getResourceAsStream(resource);

    return result;
}   

Aquí hay algunos casos por example.jar en JDK 9:

Frasco pasado de moda, no modular

Si example.jar no es un módulo, el código simplemente funciona. La carga de clase no se modifica.

Tarro modular con paquete abierto

En este caso, este es el archivo module-info.java :

module net.codetojoy.example {
    // export the Composer class
    exports net.codetojoy.example;

    // image is available
    opens net.codetojoy.example.resources;
}

En este caso, el cliente puede cargar la imagen porque el paquete está abierto.

Tarro modular sin paquete abierto

En este caso, module-info.java es:

module net.codetojoy.example {
    // export the Composer class
    exports net.codetojoy.example;

    // package not opened: image not available
    // opens net.codetojoy.example.resources;
}

En este caso, la imagen no se puede cargar debido a una fuerte encapsulación: el módulo protege la imagen al no abrir el paquete.

Fuente completa aquí en GitHub .