Solution to path problem when loading resource files in Java

Author：Eve Cole Update Time：2024-11-18 15:54:01

There are two commonly used methods for loading resource files:

1. Use ClassLoader. At this point, I have to mention the classification of ClassLoader. There are three main types of ClassLoader built into Java.

The first is the root class loader (bootstrap class loader), written in C++, which is responsible for loading some key Java classes, such as java.lang.Object and other runtime codes into memory. The package responsible for loading: BootStrp------>JRE/lib/rt.jar

The second is the extended class loader (ExtClassLoader), which is written by java class and is responsible for loading some classes in the JRE into memory. The package responsible for loading: ExtClassLoader---------->JRE/lib/ext/*.jar

The third type is the application class loader (AppClassLoader), or system class loader, which is responsible for loading classes in CLASSPATH into memory. The application class loader can be obtained through ClassLoader.getSystemClassLoader();

Let’s talk about the inheritance of class loaders. Class loaders are not a parent-child relationship of vertical inheritance, but a combination relationship. When instantiating a class loader, the instance of the parent class loader can be passed to the class loader as a construction parameter. in the vessel.

For detailed information about class loaders, you can search by yourself.

After obtaining the application class loader, it is time to obtain the resource file. Call loader.getResource(path) to load the resource file under the corresponding path. It cannot start with '/'. Regarding the resources in the package, you can treat the package as an ordinary folder. , separate each package with '/'.

For example: URL url2 = ClassLoader.getSystemClassLoader().getResource("demo/names.ser"); is to obtain the names.ser serialization file in the demo package.

2. Use the getResource method of the current class that needs to be loaded to load. In fact, this method also calls the class loader that loads this class to obtain the resource file, but the parameters obtained are different.

(1) If you want to get the files in the package where the class is located, you can use relative paths to directly access the resources in the package; for example: Demo1.class.getResource("names.ser"); what you get is the resources in the package where the class file of Demo1 is located.

(2) To obtain resource files outside the package, they must start with '/', such as URL url = Demo1.class.getResource("/demo/names.ser"); what is obtained is the names.ser file in the demo package

In fact, the second method is an encapsulation of the first method, and both use ClassLoader to load resource files. Why do you say that? If you look at the source code of the Class class, you will know:

Copy the code code as follows:

public java.net.URL getResource(String name) {
name = resolveName(name);
ClassLoader cl = getClassLoader0();
if (cl==null) {
//A system class.
return ClassLoader.getSystemResource(name);
}
return cl.getResource(name);
}

Copy the code code as follows:

private String resolveName(String name) {
if (name == null) {
return name;
}
if (!name.startsWith("/")) {
Class c = this;
while (c.isArray()) {
c = c.getComponentType();
}
String baseName = c.getName();
int index = baseName.lastIndexOf('.');
if (index != -1) {
name = baseName.substring(0, index).replace('.', '/')
+"/"+name;
}
} else {
name = name.substring(1);
}
return name;
}

According to the name value passed in by getResource (that is, in the form of relative path or absolute path), we see that after resolveName processing, ClassLoader c1 is called to load. The loading path of ClassLoader is in the form of a relative path that does not start with '/' , it must be that resolveName has converted the path. Look at the resolveName method again. First, determine whether it starts with '/'. If it starts with '/', it is a relative path, otherwise it is an absolute path. Pay attention to the else code block. , it removes the first character. After indeed removing it, it conforms to the loading path of ClassLoader. In the if block, the package path of the current class is intercepted, and then replaces . with '/' and adds That relative path also forms a loading path that conforms to ClassLoader.