扩展类加载器仅加载java.ext.dirs指定的固定路径（如$java_home/jre/lib/ext）下的jar/zip，不可运行时修改路径；jdk 9+已废弃该机制，推荐使用urlclassloader或模块系统替代。
扩展类加载器（Extension ClassLoader）本身不支持直接指定任意目录去加载类，它只认系统属性 java.ext.dirs 所指向的固定路径（如 $JAVA_HOME/jre/lib/ext 或自定义扩展目录），且加载逻辑由 JVM 内部硬编码控制，**不能在运行时动态修改其扫描路径**。
扩展类加载器默认加载哪些目录
它会自动扫描 java.ext.dirs 系统属性列出的所有目录下的 .jar 和 .zip 文件。你可以用下面代码查看当前生效的路径：
System.out.println(System.getProperty("java.ext.dirs"));
典型输出类似：E:\JAVA\jdk1.8.0_221\jre\lib\ext;C:\Windows\Sun\Java\lib\ext
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
只要把你的 jar 包复制到其中任一目录下，JVM 启动时就会被 Extension ClassLoader 自动加载。
想让扩展类加载器加载自定义目录？不推荐但可间接实现
你无法在程序运行中“配置”Extension ClassLoader去扫新路径，但有两类可行方式：
-
启动前设置系统属性：在 JVM 启动参数中覆盖
java.ext.dirs，例如：-Djava.ext.dirs=E:/my-ext-lib;E:/JAVA/jdk1.8.0_221/jre/lib/ext
注意：这会完全替换默认路径，所以通常要把原路径也拼进去，否则核心扩展类可能丢失。 -
把 jar 放进标准 ext 目录：最稳妥的做法是将目标 jar 复制到
$JAVA_HOME/jre/lib/ext（JDK 8 及以前）或$JAVA_HOME/jre/lib/ext（部分 OpenJDK 版本仍保留）。JDK 9+ 已废弃扩展机制，改用模块系统，此方式不再适用。
为什么不建议强行用 Extension ClassLoader 加自定义类
扩展类加载器的定位是加载“JVM 扩展级”的稳定库（如加密、XML 解析等），不是为业务 jar 设计的。强行混用会带来风险：
- 类可见性问题：它加载的类对 AppClassLoader 可见，但反过来不可见；若你的业务类依赖它，可能引发
NoClassDefFoundError； - 安全限制：部分安全管理器会限制 ext 目录外的加载行为；
- JDK 版本兼容性差：从 JDK 9 开始，
java.ext.dirs被彻底移除，Extension ClassLoader仅作兼容保留，实际已不工作。
更现代、更可控的替代方案
如果你的目标只是“从特定目录加载 jar 中的类”，应优先使用：
-
URLClassLoader：继承自
AppClassLoader，可传入任意File.toURI().toURL()列表，动态构建类路径； -
自定义 ClassLoader：重写
findClass()，配合URLClassLoader或JarFile解析 jar 内容，灵活控制加载逻辑； -
模块化（JDK 9+）：用
ModuleLayer+Configuration动态定义模块路径，取代传统 classpath。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
