javax/swing/plaf/basic 中的 BasicLabelUI 类受到已确认 bug 的影响。在我的应用程序中，我需要固定版本（为v9提交）提供的功能。由于法律和技术原因，我仍然受制于受影响的JDK版本。
我的方法是在我的项目中创建一个包javax/swing/plaf/basic，其中包含固定版本。
如何强制我的项目偏爱我所包含的类版本，而不是已安装的 JDK 中的缺陷类？
这必须具有一定的可移植性，因为固定类也必须在客户端工作，并且必须忽略JDK安装中的缺陷类。因此，我不想修改JDK，而是绕过这个特定的类。
正如其他答案所提到的，理论上你当然可以解压缩JVM的rt.jar文件，并用兼容的错误修复版本替换该文件。
Java 类库的任何类（如 Swing 的类）都由引导类加载程序加载，该加载程序从此 rt.jar查找其类。通常，如果不将类添加到此文件中，则不能将类预置到此类路径中。有一个（非标准）VM 选项
-Xbootclasspath/jarWithPatchedClass.jar:path
其中，您将在其中预置包含修补版本的 jar 文件，但这不一定适用于任何 Java 虚拟机。此外，部署更改此行为的应用程序是非法的！正如官方文档中所述：
不要部署使用此选项重写 rt.jar 中的类的应用程序，因为这违反了 Java 运行时环境二进制代码许可证。
但是，如果将类追加到引导类装入器（如果不使用检测 API 使用非标准 API 即可实现），运行时仍将装入原始类，因为在这种情况下，引导类装入器首先搜索 rt.jar。因此，如果不修改此文件，就不可能“隐藏”损坏的类。
最后，分发带有修补文件的VM（即将其放入客户的生产系统中）始终是非法的。许可协议明确规定您需要
[...]分发 [Java 运行时] 完整且未经修改，并且仅作为小程序和应用程序的一部分捆绑在一起
因此，不建议更改分发的 VM，因为在发现此问题时可能会面临法律后果。
当然，从理论上讲，你可以构建自己的OpenJDK版本，但是当你分发二进制Java时，你不能再调用它了，我假设你的客户不会因为你在答案中的建议而允许这样做。根据经验，许多安全环境在执行之前计算二进制文件的哈希值，这将禁止调整执行 VM 的两种方法。
最简单的解决方案可能是创建一个 Java 代理，并在启动时将其添加到 VM 进程中。最后，这与添加库作为类路径依赖项非常相似：
java -javaagent:bugFixAgent.jar -jar myApp.jar
Java 代理能够在应用程序启动时替换类的二进制表示形式，因此可以更改 buggy 方法的实现。
在您的例子中，代理将如下所示，您需要将修补的类文件作为资源包括在内：
public static class BugFixAgent {
public static void premain(String args, Instrumentation inst) {
inst.addClassFileTransformer(new ClassFileTransformer() {
@Override
public byte[] transform(ClassLoader loader,
String className,
Class<?> classBeingRedefined,
ProtectionDomain protectionDomain,
byte[] classfileBuffer) {
if (className.equals("javax/swing/plaf/basic/BasicLabelUI")) {
return patchedClassFile; // as found in the repository
// Consider removing the transformer for future class loading
} else {
return null; // skips instrumentation for other classes
}
}
});
}
}
javadoc 包提供了有关如何构建和实现 Java 代理的详细说明。使用此方法，您可以使用相关类的固定版本，而不会违反许可协议。java.lang.instrumentation
根据经验，Java 代理是修复第三方库和 Java 类库中临时 bug 的好方法，无需在代码中部署更改，甚至无需为客户部署新版本。事实上，这是使用 Java 代理的典型用例。
如何强制我的项目偏爱我所包含的类版本，而不是已安装的 JDK 中的缺陷类？
简单的答案 - 你不能。至少，在严格遵守应使用受影响的 Java 版本的约束时，不会这样做。
假设您可以在OpenJDK源代码存储库中识别出适当的版本，则可以使用修补的错误来构建自己的Java库。但是，这不会是真正的Java。当然，它不符合您被限制使用的“受影响的Java版本”的条件。（此外，您正在致力于将补丁重新应用于当前版本Java的每个新补丁版本的无休止的循环......
从理论上讲，也可以将某些 Java 标准库类的修改版本放入 JAR 中，并使用命令行选项将其附加到 JVM 的引导类路径中。但这无异于改变“受影响的Java版本”。-Xbootclasspath
通过使用 Java 代理来使用该类的修补版本来执行此操作也违反了规则。而且它更复杂。（如果您要打破规则，请以简单的方法进行...）
如果您和您的客户确实认为调整 JVM 是一个可接受的解决方案，那么通过 bootstrap 类路径进行调整可能是最简单、最干净的方法。这绝对是合法的1。
但是，我建议您找到该错误的解决方法，直到发布带有您的修复程序的Java 9版本。
1 - 实际上，即使是从修改源代码构建的方法也是合法的，因为Oracle二进制许可证不适用于此。二进制许可证是关于分发Oracle二进制文件的修改版本。另一个可能的问题是，如果您分发的版本与“真正的”Java不兼容，并将您的发行版称为“Java”，则可能违反了使用Java商标的条款。解决方案是...不要称它为“Java”！
但是，不要只听从我的建议。请咨询律师。更好的是，根本不做。这是不必要的复杂。
