将 Java 类库中的类替换为自定义版本
Posted
技术标签:
【中文标题】将 Java 类库中的类替换为自定义版本【英文标题】:Replace a class within the Java class library with a custom version 【发布时间】:2016-02-11 09:57:25 【问题描述】:javax/swing/plaf/basic 中的类BasicLabelUI 受confirmed bug 影响。 在我的应用程序中,我需要 fixed version (filed for v9) 提供的功能。 由于法律和技术原因,我仍然绑定到受影响的 JDK 版本。
我的方法是在我的项目中创建一个包javax/swing/plaf/basic,其中包含固定版本。
如何强制我的项目偏爱我包含的类版本,而不是安装的 JDK 中的缺陷类?
这必须具有一定的可移植性,因为固定类也必须在客户端工作,并且必须忽略 JDK 安装中的缺陷类。因此,我不想修改JDK,而是绕过这个特定的类。
【问题讨论】:
奇怪的是,我无法使用提交的错误代码在 Windows 7 中重现 Java 1.7.0_75 或 1.8.0_65 中的这个错误。我尝试修改它以使用默认外观;我尝试将 EventQueue.invokeLater 的使用添加到 main 方法中。 (我希望尝试基于 InputMap 的解决方法。) 我可以使用来自bugs.java.com/bugdatabase/view_bug.do?bug_id=7172652 的代码重现错误行为。我正在使用 1.8.0_45 【参考方案1】:如何强制我的项目偏爱我包含的类版本,而不是安装的 JDK 中的缺陷类?
简单的答案 - 你不能。至少,在严格遵守您应该使用受影响的 Java 版本的约束的同时,不要这样做。
假设您可以在 OpenJDK 源代码库中找到合适的版本,则可以构建您自己的 Java 库并修补错误。但是,这不是真正的 Java。当然,它不符合您被限制使用的“受影响的 Java 版本”的条件。 (此外,您承诺将自己的补丁重新应用到当前 Java 版本的每个新补丁版本中……)
理论上也可以将一些 Java 标准库类的修改版本放入 JAR 中,并使用 -Xbootclasspath
命令行选项将其添加到 JVM 的引导类路径中。但这无异于改变“受影响的Java版本”。
通过使用 Java 代理来使用修补版本的类也违反了规则。而且更复杂。 (如果你要打破你的规则,就用简单的方法吧……)
如果您和您的客户确实认为调整 JVM 是一种可接受的解决方案,那么通过引导类路径进行调整可能是最简单和最干净的方法。这绝对是合法的1。
但是,我建议您在发布带有您的修复程序的 Java 9 版本之前找到该错误的解决方法。
1 - 实际上,即使是从修改源代码构建的方法也是合法的,因为 Oracle 二进制许可证不适用于该方法。二进制许可证是关于分发 Oracle 二进制文件的修改版本。另一个可能的问题是,如果您分发的版本与“真正的”Java 不兼容,并且将您的发行版称为“Java”,那么您可能违反了使用 Java 商标的条款。解决方案是......不要称它为“Java”!
但是,不要只听我的建议。问律师。更好的是,根本不要这样做。它是不必要的复杂。
【讨论】:
你说[d]通过使用Java 代理来使用类的修补版本也违反了规则这是不正确的。您可以检测任何您想要的引导类。 这不是仪器。这是故意改变 JVM 的行为。除非客户同意,否则您违反了他们的规则;即表示必须支持 Java 版本 X 的那个。为什么不好?假设他们要将您的代码与其他需要相同类/方法以标准方式运行的代码混合在一起? 我的一个等价问题是:如果有两个具有相同名称、相同接口和相同包名称的类 - 你如何设置识别哪个,忽略哪个? @bogus 负责加载 Swing 类的引导类加载器总是首先查询该类并隐藏同一个存在的任何其他类。如果两个类同名(在“硬编码”到 VM 发行版中时是非法的),则加载在该类路径上找到的第一个类。检测 API 允许您将类添加到引导类路径,但这些类会在最后被发现,以便加载有问题的类。 @StephenC 您的方法在这方面有何不同? Instrumentation 只影响被检测的应用程序,更改 VM 会更改 Java VM 的全局行为,这就是 Oracle 不允许这样做的原因。与全局补丁相比,代理的侵入性始终较小。【参考方案2】:正如其他答案所提到的,理论上您当然可以解压缩 JVM 的 rt.jar 文件并用兼容的错误修复版本替换该文件。
Java 类库的任何类(例如 Swing 的类)都由 bootstrap 类加载器 加载,该类加载器从这个 rt.jar 中查找其类。如果不将它们添加到此文件中,您通常不能将它们预先添加 到该类路径中。有一个(非标准)VM 选项
-Xbootclasspath/jarWithPatchedClass.jar:path
您可以在其中添加一个包含修补版本的 jar 文件,但这并不一定适用于任何 Java 虚拟机。此外,部署改变这种行为的应用程序是非法的!正如official documentation中所述:
不要部署使用此选项覆盖类的应用程序 rt.jar 因为这违反了 Java Runtime Environment 二进制代码 许可证。
如果您将一个类附加到引导类加载器(在这种情况下,运行时仍会加载原始类作为引导类加载器搜索 rt.jar 首先。因此,如果不修改此文件,就不可能“隐藏”损坏的类。
最后,总是illegal to distribute a VM with a patched file,即将它放入客户的生产系统中。许可协议明确规定您需要
[...] 分发完整且未经修改的 [Java 运行时],并且仅作为小程序和应用程序的一部分捆绑在一起
因此不建议更改您分发的虚拟机,因为一旦被发现,您可能会面临法律后果。
当然,理论上您可以构建自己的 OpenJDK 版本,但在分发二进制文件时,您无法再调用它,而且我假设您的客户不会允许这样做您在回答中建议。根据经验,许多安全环境在执行之前计算二进制文件的哈希值,这将禁止调整正在执行的 VM 的这两种方法。
对您来说最简单的解决方案可能是创建一个Java agent,您可以在启动时将其添加到 VM 进程中。最后,这与添加库作为类路径依赖非常相似:
java -javaagent:bugFixAgent.jar -jar myApp.jar
Java 代理能够在应用程序启动时替换类的二进制表示,因此可以更改错误方法的实现。
在您的情况下,代理将类似于以下内容,您需要将修补的类文件作为资源包含在内:
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.lang.instrumentation
包详细描述了如何构建和实现 Java 代理。使用这种方法,您可以在不违反许可协议的情况下使用相关类的固定版本。
根据经验,Java 代理是修复第三方库和 Java 类库中临时错误的好方法,无需在代码中部署更改,甚至无需为客户部署新版本。事实上,这是使用 Java 代理的典型用例。
【讨论】:
如果要修改 JVM 行为,有一种更简单的方法。但我认为这违反了(我猜)客户的规则。 我不认为客户在检测运行 Swing 应用程序(即很可能是专用 VM)的进程的类时会遇到问题。最后,大多数客户想要一个没有错误的版本。但是,您的建议违反了 Java 许可协议。 您没有完整阅读我的回答。见该行后的第一段。 我建议了三件事。并推荐其中之一……这绝对不是非法的。此外,如果 Oracle 二进制许可证适用,我的建议 #1 只是违反了 Oracle 二进制许可证。如果您从 OpenJDK 源代码 (GPLv2) 构建并遵循 GPL 规则,则不会。阅读这些...openjdk.java.net/legal OP 表示迁移 VM 版本不是一个选项,它排除了您构建自己的 VM 或调整现有 VM 的建议(忽略法律不允许您更改二进制文件的事实)。如果您的意思是我也建议的-X
选项,那么您的答案应该更具体。 OP 所说的任何内容都没有表明使用 Java 代理不适用于该用例。最后,您的第一句话说 OP 想要的不可能与您自己的答案既不真实也不矛盾,因此我不同意。以上是关于将 Java 类库中的类替换为自定义版本的主要内容,如果未能解决你的问题,请参考以下文章
将管理标题中的默认WordPress-W-logo替换为自定义的替代项