Problems with Java reading files

Java reads files in two ways: Java.io and Java.lang.ClassLoader (I know both of them ...). ）

//java.io:  File File = new  File ();  FileInputStream FIS = new  fileinputstream ();  FileReader FR = new  filereader (); //classloader:  ClassLoader loader = Xxxclass. class . getclassloader    (); ClassLoader loader2 = Thread. currentthread  (). getcontextclassloader   (); URL url = loader. getresource   (); File File = new  file (url. ()); InputStream input = loader. getresourceasstream  (); 

The classes in the Java.io package always parse relative pathname based on the current user directory , that is, whether the relative path works, depending on the value of User.dir. The system Properties User.dir are set when the JVM is started, usually the calling directory of the Java Virtual machine, which is the directory where the Java command is executed .

For Tomcat/jboss containers, User.dir is the %home/bin%/ directory, because this directory is where we start the Web container

When running a program in Eclipse, Eclipse sets the value of User.dir to the project's root directory

The user directory can be used System.getProperty("user.dir") to view

So, using java.io to read a file, whether it's a relative path or an absolute path, is not a good practice, so don't use it (in Java EE).

Using ClassLoader

Class.getResource () has 2 ways, absolute path and relative path. The absolute path / begins with the search from the classpath or jar package root directory;

The relative path is the directory that is relative to the current class, allowing you .. to use or . to locate the file.

Classloader.getresource () can only use absolute paths and not / start with .

These two ways of reading a resource file, do not rely on user.dir, and do not rely on a specific deployment environment, is the recommended practice (Java EE)

How to select

• java.io:
  Read relative paths to the current user directory, pay attention to working with disk files , or use in pure Java project.
  Although the ClassLoader approach is more generic, it is not reasonable to navigate to the Classpath path if it is not a Java EE environment.

• Java.lang.ClassLoader:
  Relative path reading relative to Classpath; it is recommended to use this approach in Java EE environments.

In general, ClassLoader cannot read too large files, it is suitable for reading the Web project of those configuration files, if you need to read large files, or to use the IO package, you can first get the absolute path to the file through ClassLoader, and then passed to files or other objects, with the IO packet It's better to read the object.

Attached: Spring in Classpathresource implementation

Spring can be said to be an indispensable framework for javaweb development, which provides classpathresource to read files:

/** * This implementation opens a InputStream for the given class path resource. * @see Java.lang.classloader#getresourceasstream (String) * @see Java.lang.class#getresourceasstream (String) */   PublicInputStreamgetInputStream()throwsIOException {InputStream is;if( This.Clazz!=NULL) {is = This.Clazz.getResourceAsStream( This.Path); }Else{is = This.ClassLoader.getResourceAsStream( This.Path); }if(IS = =NULL) {Throw NewFileNotFoundException (getdescription() +"cannot be opened because it does not exist"); }returnis; }

You can see the classpathresource provided by spring, and the underlying use is Class.getResource or Classloader.getresource ()

Reference

http://blog.csdn.net/aitangyong/article/details/36471881

Problems with Java reading files