解析Java和IDEA中的文件打包问题
作者：返回主页lilpig
问题：想在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...这样的代码。
参考
Thread.currentThread().getContextClassLoader() 和 Class.getClassLoader()区别
到此这篇关于Java和IDEA中的文件打包的文章就介绍到这了,更多相关Java和IDEA中的文件打包内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！