通过同名路径目录修改库类，导出.jar后失效问题

为啥会出这问题 #

IDE里运行时，你的自定义类会被优先加载，但用packr打包后，Gradle可能把第三方库的Jar放在类路径最前面，导致系统先读取库中的原类，不认你写的修改版，自然就找不到你新增的soundCom字段，抛出NoSuchFieldError。

具体怎么修 #

• 调整Gradle依赖配置
  在build.gradle（或build.gradle.kts）里，把原库改成仅编译时依赖，这样编译时能找到类做参考，但打包时不会让原库的类覆盖你的自定义类，保证你的类优先被使用：

  // Groovy写法
  dependencies {
      // 只在编译时依赖原库，避免打包时原类覆盖你的实现
      compileOnly "com.badlogicgames.gdx:gdx:1.12.1"
      // 运行时需要的其他依赖正常添加，比如后端模块
      runtimeOnly "com.badlogicgames.gdx:gdx-backend-lwjgl3:1.12.1"
  }
  

  要是项目还需要原库的其他类，只要这些类和你修改的不冲突就行，有冲突就用同样的方法覆盖。

• 修改packr的打包顺序
  packr打包时，类路径的顺序直接决定哪个类先被加载。你得把自己项目编译生成的Jar放在第三方库Jar的前面。打开packr的配置文件（比如packr-config.json），调整classpath的顺序：

  {
    "classpath": [
      "你的项目编译生成的Jar名.jar",
      "lib/gdx.jar",
      "lib/gdx-backend-lwjgl3.jar",
      // 其他依赖Jar往后排
    ]
  }
  

• 直接替换原库Jar里的类
  要是上面两种方法都不好使，就来硬的：把你编译好的自定义类.class文件，直接替换原库Jar里的对应类：

  1. 找到项目依赖里的原库Jar（比如gdx-1.12.1.jar）
  2. 用压缩软件打开这个Jar，找到你修改的类对应的路径（比如com/badlogic/gdx/utils/xxx.class）
  3. 把你自己编译出来的.class文件拖进去替换掉原文件
  4. 用这个修改后的Jar作为项目依赖，再用packr打包

怎么确认修好了 #

打包完成后，解压生成的程序包，找到对应的Jar文件，打开看看里面的类是不是你修改后的版本，或者在自定义类里加个日志输出，运行程序看看有没有打印，以此确认加载的是你的类。

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