In Java you can load a resource in several ways. Depending on context, however, some of these methods can be confusing and not work properly. To find out which method to use, especially in the case, you should be aware of how each of these.
Assuming our application is structured nel seguente modo:
org
eyrene
xxx
NomeClasse.java
risorse
nome_risorsa.ext
ovvero che esista il package org.eyrene.xxx e che dentro tale package sia presente il sottopackage (o sottodirectory) risorse e la classe NomeClasse .
To load the resource nome_risorsa.ext within the class ClassName (ie to get a URL to point to the specified resource) you can use one of the following methods (for the purpose equivalent):
-
NomeClasse.class.getResource ("resources / nome_risorsa.ext");
-
getClass (). getResource ("resources / nome_risorsa.ext");
-
getClass (). getClassLoader (). getResource ( "org / eyrene / xxx / resources / nome_risorsa.ext");
-
ClassLoader.getSystemResource ("org / eyrene / xxx / resources / nome_risorsa.ext");
The first two solutions (1, 2) are in fact identical to the third (3), because they just add the prefix of the package argument passed (always assuming that it is a relative path rather than an absolute ) and then make the same call the third solution (3) passed as an argument the path now complete. The first three
(1, 2 and 3) also engaged in some contexts in which the ClassLoader for the class is null (see documentation ), the same call (4). But it is not always the case!
The first two solutions (1 and 2) are in turn a small and often not perceived difference in the first case (1) The specified resource will be sought from the package (and thus the subdirectories) is located in ClassName, unambiguously in the second case (2), however, the search could start from a subpackage (subdirectory) different if the class ClassName is extended by some child class that is in a different package: the call a getClass() , infatti, restituisce sempre la classe "più derivata", ovvero l'ultima della gerarchia che eredita da NomeClasse . Si tratta in effetti di una piccolezza spesso non fondamentale ma che in alcuni casi può generare ambiguità ed errori.
Al di là delle possibili ambiguità, le prime due soluzioni (1 e 2) presentano tuttavia il vantaggio di non dover specificare l'intero percorso della risorsa, comprensivo delle directory che costituisce il package. Questo consente di non dover ritoccare il codice qualora l'indomani si decidesse di spostare la classe NomeClasse e la directory risorse in una locazione diversa.
Sarebbe tutto finito, se non fosse that the real problems start to arise when you want access to this resource in a JAR archive . In this case, we must bear in mind that relative paths do not work anymore in the same way, as are reported from the location where you will find the . jar! For this reason, the use of the first three solutions (1, 2 and 3) often generates errors or, worse still, it returns a null URL!
Much better, in these cases, use the last solution (4) specifying the full path of the resource to load (in some contexts, the answer becomes more clear and efficient, in my opinion).
Another possible solution for loading a resource is to use the object directly URL ; solution which requires, however, the specific protocol to use and the use of the absolute path to reference the resource:
new URL ("file: / C: / Java / bin / org / eyrene / xxx / resources / nome_risorsa.ext ");that in the case of a resource contained in a JAR archive , becomes:
new URL (" jar: file: / C: / Java / xxx . jar! / org / eyrene / xxx / resources / nome_risorsa.ext ");Finally, a simple trick to quickly create a URL , implies the use of the protocol and specifying a file path relative to the root directory Project (or the file that contains . jar), is to create a File object and return it 's URL as follows:
new File ("bin / org / eyrene / xxx / resources / nome_risorsa.ext). tour (). Tourlite ();to note, in the latter case, as it was necessary to specify the subdirectory bin to properly address the resource: the path is in fact related to from the root of the project (the one containing the directory src and bin, to be precise).
Once you have a URL object with any of these methods will obviously possible to undertake more specific purposes, such as to upload an image:
ImageIcon image = new ImageIcon (getClass (). getResource ("resources / image.jpg"));or
ImageIcon image = new ImageIcon (ClassLoader.getSystemResource ("org / eyrene / xxx / resources / image.jpg"));but that's another story!
[...] complete and updated version on justshareit.pbwiki.com [...]