Java LanguageRecursos (en classpath)


Introducción

Java permite la recuperación de recursos basados ​​en archivos almacenados dentro de un JAR junto con las clases compiladas. Este tema se enfoca en cargar esos recursos y ponerlos a disposición de su código.

Observaciones

Un recurso son datos de tipo archivo con un nombre de ruta, que reside en la ruta de clase. El uso más común de los recursos es el agrupamiento de imágenes de aplicaciones, sonidos y datos de solo lectura (como la configuración predeterminada).

Se puede acceder a los recursos con los métodos ClassLoader.getResource y ClassLoader.getResourceAsStream . El caso de uso más común es tener recursos ubicados en el mismo paquete que la clase que los lee; los métodos Class.getResource y Class.getResourceAsStream sirven este caso de uso común.

La única diferencia entre un método getResource y un método getResourceAsStream es que el primero devuelve una URL, mientras que el segundo abre esa URL y devuelve un InputStream.

Los métodos de ClassLoader aceptan un nombre de recurso similar a una ruta como un argumento y buscan en cada ubicación en la ruta de clases del ClassLoader una entrada que coincida con ese nombre.

  • Si una ubicación de classpath es un archivo .jar, una entrada jar con el nombre especificado se considera una coincidencia.
  • Si una ubicación de classpath es un directorio, un archivo relativo debajo de ese directorio con el nombre especificado se considera una coincidencia.

El nombre del recurso es similar a la porción de ruta de una URL relativa. En todas las plataformas, utiliza barras diagonales ( / ) como separadores de directorios. No debe comenzar con una barra.

Los métodos de clase correspondientes son similares, excepto:

  • El nombre del recurso puede comenzar con una barra inclinada, en cuyo caso esa barra inicial se elimina y el resto del nombre se pasa al método correspondiente de ClassLoader.
  • Si el nombre del recurso no comienza con una barra diagonal, se trata en relación con la clase a la que se llama el método getResource o getResourceAsStream. El nombre del recurso real se convierte en paquete / nombre , donde paquete es el nombre del paquete al que pertenece la clase, con cada período reemplazado por una barra y nombre es el argumento original dado al método.

Por ejemplo:

package com.example;

public class ExampleApplication {
    public void readImage()
    throws IOException {

        URL imageURL = ExampleApplication.class.getResource("icon.png");

        // The above statement is identical to:
        // ClassLoader loader = ExampleApplication.class.getClassLoader();
        // URL imageURL = loader.getResource("com/example/icon.png");

        Image image = ImageIO.read(imageURL);
    }
}

Los recursos deben colocarse en paquetes con nombre, en lugar de en la raíz de un archivo .jar, por la misma razón que las clases se colocan en paquetes: para evitar colisiones entre varios proveedores. Por ejemplo, si hay varios archivos .jar en la ruta de clase, y más de uno de ellos contiene una entrada config.properties en su raíz, las llamadas a los métodos getResource o getResourceAsStream devolverán las config.properties de cualquiera que sea .jar aparece primero en el classpath Este no es un comportamiento predecible en entornos donde el orden de la ruta de clase no está bajo el control directo de la aplicación, como Java EE.

Todos los métodos getResource y getResourceAsStream devuelven un null si el recurso especificado no existe. Dado que los recursos deben agregarse a la aplicación en el momento de la compilación, sus ubicaciones deben ser conocidas cuando se escribe el código; un error al no encontrar un recurso en tiempo de ejecución suele ser el resultado de un error del programador.

Los recursos son de solo lectura. No hay forma de escribir en un recurso. Los desarrolladores novatos a menudo cometen el error de suponer que, dado que el recurso es un archivo físico independiente cuando se desarrolla en un IDE (como Eclipse), será seguro tratarlo como un archivo físico separado en el caso general. Sin embargo, esto no es correcto; las aplicaciones casi siempre se distribuyen como archivos .jar o archivos .war, y en tales casos, un recurso no será un archivo separado y no se podrá escribir. (El método getFile de la clase de URL no es una solución para esto; a pesar de su nombre, simplemente devuelve la parte de la ruta de una URL, que de ninguna manera se garantiza que sea un nombre de archivo válido).

No hay una forma segura de enumerar los recursos en tiempo de ejecución. Nuevamente, dado que los desarrolladores son responsables de agregar archivos de recursos a la aplicación en el momento de la compilación, los desarrolladores ya deben conocer sus rutas. Si bien hay soluciones alternativas, no son confiables y eventualmente fallarán.

Recursos (en classpath) Ejemplos relacionados