Java和IDEA打包 解析Java和IDEA中的文件打包问题

问题：想在IDEA中引用相对路径，但是找不到文件。

项目目录结构

当前项目的路径为：D:\source\java\test\

项目结构如下

当前路径

面对无法使用相对路径找到资源文件的问题，首先想到的解决办法是先瞄一眼IDEA在执行时给Java环境设定的当前路径在哪，也就是说看看我们在使用相对路径时到底是相对于哪里的。

应该咋写呢？下面是Java API中的一些描述。

默认情况下， java.io包中的类始终会根据当前用户目录解析相对路径名。 该目录由系统属性user.dir ，通常是调用Java虚拟机的目录。

根据上面的信息，可以想到两个办法来获得当前路径，第一种办法是向Java中传递空字符串，这是一个比较hack的方法，按照相对路径来解析的话，自然会被解析成当前目录。

File f1 = new File(""); // 空字符串，相当于当前路径
System.out.println(f1.getAbsolutePath());

第二种办法，直接获取系统属性中的user.dir。

System.out.println(System.getProperty("user.dir"));

两种办法得到的结果一致：

也就是说，当前目录指向项目的根目录，如果你想要获取src中的一个文件的话，需要使用src/文件名，而如果该文件在某个包下的话，则需要使用src/完整包路径/文件名。

现在我在src下创建一个文件text1.txt，写入内容HELLO , WORLD

File f2 = new File("src/text1.txt");
LineNumberReader reader2 = new LineNumberReader(new FileReader(f2));
System.out.println(reader2.readLine());

结果

这样写好吗？

我们的Java代码最终会被打包上传到目标平台，如某个服务器上，打包的代码应该只包含编译后的文件目录，在IDEA中就是那个out目录，其它的文件都不会出现在目标平台上，到那个时候，你不再拥有当前项目编写时的目录结构，你的程序运行时所在的当前路径也不再是现在这个。

简单来说，我们写出了依赖环境的代码，这个代码不保证程序运行在生产环境下的时候还可以正常执行，而且通常是无法正常执行。

唯一的办法，就是我们在IDEA编译时，告诉它有些文件，请你帮我打包到out目录中，然后我再想办法去out目录中找，这下就不会出问题了。

JavaAPI中有这样一个方法，它被明确说明是用来干这个事的就是ClassLoader中的getResource，下面是API中的说明

寻找给定名字的资源文件。一个资源文件可以是一些能够被class代码以一种独立于代码位置的方式进行访问的数据（图像、声音、文字等）

我们先看看使用这个方法是相对于哪个路径，采用的办法和new File("")大同小异。

String path = Main.class.getClassLoader().getResource("").getPath();
System.out.println(path);

结果如下

它已经找到了我们打包后的二进制代码所在的位置，这下就可以相对于二进制代码的位置读写文件了，不再依赖当前环境。

注意，ClassLoader.getResourceAsStream和Class.getResourceAsStream有些细微的区别，见JAVA 笔记 ClassLoader.getResourceAsStream() 与 Class.getResourceAsStream()的区别

将文件打包到二进制代码位置

创建文件夹，mark directory as -> Resources Root。

o

在其中创建text2.txt，写入HELLO , RESOURCES。

然后这样去读

LineNumberReader r3 = new LineNumberReader(
        new InputStreamReader(Main.class.getClassLoader().getResourceAsStream("text2.txt"))
);
System.out.println(r3.readLine());

这里使用了ClassLoader.getResource的一个变体getResourceAsStream，它的作用就是返回的是一个流，而非URL。我们所做的就是获取当前类的ClassLoader，通过它获取资源文件，转换成LineNumberReader。

读取成功，也就是说，在resources文件夹下的文件，IDEA会自动帮我们打包到二进制代码的位置

其他

src中的文件

如果我们去看out文件夹下的文件结构，你就会发现，除了resources/text2.txt，我们之前在src下创建的text1.txt也被打包到这个位置了。也就是说，我们可以通过同样的方式去读取src下的文件。

D:\source\java\test\out>wsl tree .
.
└── production
    └── test
        ├── io
        │   └── lilpig
        │       └── test
        │           └── Main.class
        ├── text1.txt
        └── text2.txt

5 directories, 3 files

LineNumberReader r4 = new LineNumberReader(
        new InputStreamReader(Main.class.getClassLoader().getResourceAsStream("text1.txt"))
);
System.out.println(r4.readLine());

读取成功

Thread.currentThread.getContextClassLoader

在多线程应用中，有可能你编写的类的类加载器和实际加载resources文件夹的类加载器不是同一个，这会导致你的代码无法获取到资源文件，使用Thread.currentThread.getContextClassLoader能规避这个问题。具体的原理涉及到Java中的类加载机制的委托模型，这部分的内容原理性太强，我已经忘得差不多了，就不露怯了。

我们编写的大部分后端应用，都是多线程应用，我们自己感知不到，那是因为多线程代码被封装在框架中，所以无论如何，使用Thread.currentThread.getContextClassLoader总比使用Main.class.getClassLoader更好。

并且，Thread.currentThread.getContextClassLoader更加具有一致性，你可以轻易的编写一个工具方法来简化代码（无论如何Thread.currentThread返回的总是当前调用者所在的线程）。而如果用之前的方法，每一个类的类名都不同，你在一个类中写的是Main.class.getClassLoader在另一个类中写的又是Other.class.getClassLoader，这不一致的代码会让我们难以编写一个通用的工具类。

框架

在框架中，资源文件夹都是默认被创建好的，有的可能叫static，有的可能叫resources......而且，有可能编译后的目录不是out，而是target，甚至会被打包成war包等。

我们要做的不是管它打包后在哪，而是直接往框架给你指定好的资源文件夹里面放文件就行，剩下的交给框架。

并且在框架中，随处可见Thread.currentThread.getClassLoader().getResource...这样的代码。

参考

Java SE 8 API

Thread.currentThread().getContextClassLoader() 和 Class.getClassLoader()区别