Spring+OpenJFX桌面应用打包为exe后运行抛出NamingException异常

我帮你分析下这个问题的根源：Java 9及以后的版本中，javax.naming模块不再是JDK默认包含的基础模块了，而Spring Boot的数据源自动配置逻辑在判断是否需要加载池化数据源配置时，会依赖这个模块里的NamingException类，打包后的exe运行环境里缺少这个模块，就会触发这个错误。

给你几个实用的解决办法，按需选择：

• 排除不需要的数据源自动配置
  如果你的桌面应用根本不需要数据库连接，那直接在Spring Boot启动类上排除数据源相关的自动配置类，从根源上避免触发这个判断逻辑：

  @SpringBootApplication(exclude = {
      DataSourceAutoConfiguration.class,
      DataSourceTransactionManagerAutoConfiguration.class
  })
  public class MyApp extends Application {
      // 你的应用逻辑代码
  }
  

  这样Spring Boot就不会去加载数据源相关的配置，自然也就不会去查找javax.naming下的类了。

• 打包时显式引入javax.naming模块
  如果你的应用确实需要用到JNDI相关功能，那在打包阶段要主动把这个模块包含进去：

  1. 如果是用模块化开发（有module-info.java），在模块声明里添加依赖：

     module test.myapp {
         requires spring.boot;
         requires spring.boot.autoconfigure;
         requires javafx.graphics;
         requires javax.naming;
         // 其他你的应用依赖模块
     }
     

  2. 如果用Maven的jpackage插件打包，在插件配置里添加模块参数：

     <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-jpackage-plugin</artifactId>
         <version>1.0.0</version>
         <configuration>
             <addModules>javax.naming</addModules>
             <!-- 其他打包相关配置，比如主类、输出目录等 -->
         </configuration>
     </plugin>
     

  这样打包后的exe运行环境就会包含javax.naming模块了。

• 检查@ComponentScan的扫描范围
  错误日志里也提示了一种可能性：如果你的@ComponentScan不小心扫到了Spring框架本身的包（比如把启动类放在默认包下，没有声明package），也会导致自动配置出错。确认你的启动类所在的包结构，比如启动类在test.myapp下，@SpringBootApplication默认的扫描范围就是当前包及其子包，只要启动类不在无包名的默认位置就没问题。

你可以先在IDE里运行验证下修改后的代码是否正常，再进行打包测试，这样能更快定位问题~

备注：内容来源于stack exchange，提问作者tako21osan