如何使用单独的 jar 覆盖一个类？
客户需要预览我们产品的新功能。 他们要求将该功能通过 jar 文件（如补丁）发送给他们。 在上述 jar 文件中包含新类没有问题。 但是，现有的类已被修改，这是集成新功能所必需的。 他们只是想添加这个新的 jar 文件，而不必更新我们产品的核心类。 所以，问题是：是否可以使用单独的 jar 来覆盖已经存在的类？ 如果是这样，怎么办？
提前致谢。
A customer requires a preview of a new feature of our product. They asked to have that feature sent to them in a jar file (like a patch). There's no problem with including the new classes in said jar file. However, an existing class was modified, which is needed to integrate the new feature. They just want to add this new jar file without having to update the core classes of our product. So, the question is: is it possible to override an already existing class using a separate jar? If so, how?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您将新 jar 放在类路径中早于原始 jar，那么它就有可能起作用。 这是值得尝试的，尽管它听起来仍然像是一场灾难——或者至少，如果以某种方式加载了两个类，那么真的很难调试问题。
编辑：我本来计划早些时候写这个，但在火车旅程结束时被打断......
我会回到客户那里并解释说，虽然他们要求的是可能的，但它可能会导致意想不到的问题。 更新 jar 文件是一种更安全的修复方法，风险也更小。 “意外问题”和“风险”这两个短语可能会给客户敲响警钟，因此希望它们能让您做正确的事情。
There's a chance it'll work if you put the new jar earlier in the classpath than the original jar. It's worth trying, although it still sounds like a recipe for disaster - or at least, really hard to debug issues if somehow both classes are loaded.
EDIT: I had planned to write this bit earlier, but got interrupted by the end of a train journey...
I would go back to the customer and explain that while what they're asking is possible, it may cause unexpected problems. Updating the jar file is a much safer fix, with much less risk. The phrases "unexpected problems" and "risk" are likely to ring alarm bells with the customer, so hopefully they'll let you do the right thing.
是或否，这取决于您的环境。
例如，如果您使用 OSGi 并控制您的版本，那么只需安装具有更高版本的导出包的新捆绑包即可（假设您的版本范围足够宽松）。
如果您使用普通的旧 Java，没有花哨的自定义类加载，那么您应该最好将其放在类路径的前面（正如其他人已经提到的那样）。
如果您确实有自定义类加载，则需要确保“修补”类所需的所有类以及整个传递依赖外壳对于正在加载修补版本的类加载器是可见的，这可能意味着您需要发送整个应用程序，最坏的情况。
Yes and no, it depends on your environment.
If you use, for example, OSGi and have your versions under control, it's just a matter of installing a new bundle with the exported package at a higher version (assuming your version ranges are lenient enough).
If you use plain old Java with no fancy custom class loading, you should be good to go putting it earlier on your class path (as others already mentioned).
If you do have custom class loading, you'll need to make sure that all the classes that your 'patched' class needs, and indeed the entire transitive dependency hull, is visible from the class loader which is loading the patched version, which might mean you need to ship the entire application, worst case.
所有规定将更新的类放在类路径中要替换的类之前的答案都是正确的，仅提供原始 JAR 未密封或签名。
All of the answers that stipulate putting the updated classes before the ones they are replacing in the classpath are correct, only provided the original JAR is not sealed or signed.
是的，通过将其放在比原始 jar 更早的类路径中，这可能是可能的。 然而，依赖类路径的顺序并不总是会带来幸福。 我不确定它是否记录在 Java 语言规范中； 如果不是，那么对于不同的 JVM，甚至同一 JVM 的不同版本，它都会崩溃。
相反，请考虑引用一个现实的时间框架将新功能集成到当前的代码库中。 这也许不是您正在寻找的答案。
Yes, it may be possible, by putting it earlier on the classpath than your original jar. However, relying on the ordering of your classpath is not always going to lead to happiness. I'm not sure if it is even documented in the Java Language Spec; if not, then it's going to break for different JVMs and even different versions of the same JVM.
Instead, consider quoting a realistic time frame to integrate the new feature into the current codebase. This is perhaps not the answer you're looking for.
可能比这个特定情况所需的更多，但通常如果您只想调整或增强现有类，您也可以将 AspectJ 与 加载时编织。
Probably more than you need for this specific case, but in generally if you just want to tweak or augment an existing class you can also use AspectJ with load-time weaving.