修补Java软件 [英] Patching Java software

问题描述

我正在尝试创建一个过程来修补我们当前的Java应用程序，因此用户只需要下载差异而不是整个应用程序。我认为我不需要像二进制差异一样低级，因为大多数jar文件很小，所以替换整个jar文件并不是那么大（最多可能是5MB）。

I'm trying to create a process to patch our current java application so users only need to download the diffs rather than the entire application. I don't think I need to go as low level as a binary diff since most of the jar files are small, so replacing an entire jar file wouldn't be that big of a deal (maybe 5MB at most).

是否有标准工具可用于确定哪些文件已更改并为其生成修补程序？我见过像xdelta和vpatch这样的工具，但我认为它们在二进制级别工作。

Are there standard tools for determining which files changed and generating a patch for them? I've seen tools like xdelta and vpatch, but I think they work at a binary level.

我基本上想弄明白 - 哪些文件需要添加，替换或删除。当我运行补丁时，它将检查软件的当前版本（来自注册表设置）并确保补丁用于正确的版本。如果是，它将进行必要的更改。这听起来并不像我自己太难实现，但我想知道其他人是否已经这样做了。我使用NSIS作为我的安装程序，如果这有任何区别。

I basically want to figure out - which files need to be added, replaced or removed. When I run the patch, it will check the current version of the software (from a registry setting) and ensure the patch is for the correct version. If it is, it will then make the necessary changes. It doesn't sound like this would be too difficult to implement on my own, but I was wondering if other people had already done this. I'm using NSIS as my installer if that makes any difference.

谢谢，

杰夫

推荐答案

这样做时要小心 - 我建议不要这样做。

Be careful when doing this--I recommend not doing it at all.

最大的问题是公共静态变量。它们实际上被编译到目标中，未被引用。这意味着即使java文件没有改变，也必须重新编译类，否则你仍然会引用旧值。

The biggest problem is public static variables. They are actually compiled into the target, not referenced. This means that even if a java file doesn't change, the class must be recompiled or you will still refer to the old value.

你也要非常小心更改方法签名 - 如果更改方法签名并且不重新编译调用该方法的所有文件，您将获得一些非常微妙的错误 - 即使调用java文件实际上不需要更改（例如，更改参数从int到long）。

You also want to be very careful of changing method signatures--you will get some very subtle bugs if you change a method signature and do not recompile all files that call that method--even if the calling java files don't actually need to change (for instance, change a parameter from an int to a long).

如果您决定沿着这条路走下去，请为一些非常难以调试的错误做好准备（通常没有痕迹或重要指示，只是奇怪的行为，比如收到的号码与发送的号码不匹配）在客户网站上你无法复制，而且很多生气的客户。

If you decide to go down this path, be ready for some really hard to debug errors (generally no traces or significant indications, just strange behavior like the number received not matching the one sent) on customer site that you cannot duplicate and a lot of pissed off customers.

类文件的二进制差异可能有效，但我假设编译了某种版本号或日期，并且它们每次都会改变一点无缘无故地编译b可以很容易地测试。

A binary diff of the class files might work but I'd assume that some kind of version number or date gets compiled in and that they'd change a little every compile for no reason but that could be easily tested.

您可以采取一些严格的开发实践，不使用 public 最终静态（将它们设为私有）而不是每个更改方法签名（弃用）但我不相信我知道所有可能的问题，我只知道我们遇到的问题。

You could take on some strict development practices of not using public final statics (make them private) and not every changing method signatures (deprecate instead) but I'm not convinced that I know all the possible problems, I just know the ones we encountered.

Jar文件的二进制差异也没用，你必须对类进行差异化并将它们重新集成到jar中（听起来不容易跟踪） ）

Also binary diffs of the Jar files would be useless, you'd have to diff the classes and re-integrate them into the jars (doesn't sound easy to track)

您可以单独打包资源然后稍微减少代码吗？拉出字符串（适用于i18n） - 我想我只是想知道你是否可以修改类文件，以便始终完成构建/发货。

Can you package your resources separately then minimize your code a bit? Pull out strings (Good for i18n)--I guess I'm just wondering if you could trim the class files enough to always do a full build/ship.

On另一方面，Sun似乎可以做出与之前的JRE版本完全兼容的类文件，因此他们必须在某处提供指导。

On the other hand, Sun seems to do an okay job of making class files that are completely compatible with the previous JRE release, so they must have guidelines somewhere.

这篇关于修补Java软件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！