Java Read Properties configuration file several considerations __java

Ava loads a properties file by loading a properties configuration file with the Properties class's load () method in the Java.util package, and the load () method needs to receive a file input stream, The InputStream build requires a Java.io.File object, new FileInputStream (path); Now the question is focused on how to dynamically acquire

Ava loads a properties file by loading a properties configuration file with the Properties class's load () method in the Java.util package, and the load () method needs to receive a file input stream, The InputStream build requires the Java.io.File object, new FileInputStream (path), and the question now focuses on how to get the path dynamically.
Here's an example to illustrate. As shown in figure:

It is now necessary to read the Config.properties file in the SRC directory in the Actionfactory class. We know that the Java Web project after compiling the SRC directory is supposed to be web-inf under the classes directory, so we can get to the Actionfactory.class file, and then according to the relative path to use. /step back to the previous level get the path to the Config.properties file, and then have the first one:
InputStream stream = This.getclass (). getResourceAsStream (".. /.. /.. /.. /config.properties ")//here refers to the Actionfactory class
Pro.load (stream);
Of course, we can also return a file input stream via the class loader based on a relative path, that is, the ClassLoader getResourceAsStream method. We know that all the Java files in the project are compiled in relation to the classes directory under Web-inf, and Config.properties files are published in exactly the classes directory as the root directory.
So we get the class loader through the classes in the project to obtain the file stream, and then we have a second way:
InputStream stream = This.getclass (). getClassLoader (). getResourceAsStream ("config.properties");
Pro.load (stream);
Note this here refers to the Actionfactory class, of course you can replace it with other custom classes in your project because the classes in the project are different, but they are the same class
Loader. But it's also important to note that the contents of my green logo above are other custom classes, not any other class. such as Java.lang.Thread class is not good. This is the question you will certainly have: why the class loader is not available through the thread class. This also has to be said from the JVM load class. When the JVM starts, it first uses the JVM default system class loader to help us load some jars, so that the JVM automatically loads the jar files into memory for us. Please look at the picture:

That is, all the classes in the jar represented by the red box shown in the figure. getClassLoader () gets null because they are all loaded by the JVM system ClassLoader, and the Java security mechanism does not allow you to get the System class loader object. The
understands the above, so we can also write:
InputStream stream=thread.currentthread (). GetClass (). getResourceAsStream ("/ Config.properties ");
but cannot write this:
InputStream stream = Thread.CurrentThread (). GetClass (). getClassLoader (). getResourceAsStream (" Config.properties ");
But you can write this:
InputStream stream = This.getclass (). getClassLoader (). getResourceAsStream ("Config.properties");
InputStream stream = new FileInputStream ("/config.properties"); //relative to Project web-inf/classes directory
Why don't I explain it.
If it is in a Web project, we can also write this:
InputStream stream = Thread.CurrentThread (). Getcontextclassloader (). getResourceAsStream ("Config.properties");
But the servlet has encapsulated it for us, as we generally write:
Servletcontext.getrealpath ("/")   The slash here is the root directory relative to the Webroot after the project is deployed.
        A seemingly simple question, if you go deep, it's not easy. Later encountered this problem, will not be confused slightly, haha ~~~~~