将Java源文件与class文件同存Jar包的运行时技术弊端咨询

• 类加载逻辑冲突风险：部分带有动态编译、热加载能力的框架/自定义类加载器会扫描classpath下所有.java后缀文件，若误将Jar包内的源文件识别为待编译资源，轻则抛出编译异常，重则加载与现有class文件逻辑不一致的代码，引发非预期的业务错误。
• 资源查找性能损耗：JVM提供的Class.getResource()、ClassLoader.getResourceAsStream()等资源查找接口，以及Spring、MyBatis等框架的配置/注解扫描逻辑，都需要遍历Jar包内的所有文件索引，额外的.java文件会提升单次遍历的开销，多Jar叠加、高频率调用资源查找的场景下会产生可观测的性能损耗。
• 运行时安全风险放大：若服务存在任意文件读取、目录遍历漏洞，攻击者可直接获取Jar包内的完整Java源码，相较于反编译class文件得到的无注释、可能被混淆的代码，直接泄露的源码可读性极高，会大幅提升核心业务逻辑、敏感配置逻辑的泄露风险。
• 字节码增强组件异常：SkyWalking、Arthas、自定义切面Agent等字节码增强工具，会全量扫描classpath下的类文件匹配增强规则，多余的源文件会增加Agent运行时的扫描开销，极端场景下还可能被误识别为类文件导致增强逻辑报错，甚至触发类加载冲突。
• 热部署/动态更新逻辑异常：使用JRebel、Spring Boot DevTools等热部署工具时，工具会通过比对源码与class文件的时间戳判断是否需要重新编译加载，Jar包内携带的源文件时间戳若与编译产物、本地开发源文件不一致，会导致热部署逻辑混乱，出现更新不生效、类版本冲突报错等问题。

内容的提问来源于stack exchange，提问作者ledlogic