这样做时要小心-我建议完全不要这样做。
最大的问题是公共静态变量。它们实际上被编译到目标中，没有被引用。这意味着即使java文件没有更改，也必须重新编译该类，否则您仍将引用旧值。
您还需要非常小心地更改方法签名-如果更改方法签名并且不重新编译所有调用该方法的文件，您将得到一些非常细微的错误-
即使调用Java文件实际上不需要更改（例如，将参数从int更改为long）。
如果您决定走这条路，请准备好在客户站点上进行一些非常难于调试的错误（通常没有任何痕迹或明显的指示，只是奇怪的行为，例如收到的数字与发送的数字不匹配），并且您无法重复做很多激怒顾客。
编辑（评论太长）：
类文件的二进制差异可能会起作用，但我假设已编译了某种版本号或日期，并且每次编译时它们都会无故更改，但可以轻松进行测试。
您可以采用一些严格的开发实践，不使用 公共
最终静态变量（将它们设为私有），而不是使用每个更改的方法签名（不建议使用deprecate），但是我不相信我知道所有可能的问题，我只是知道我们遇到的问题。
而且Jar文件的二进制差异也没有用，您必须对类进行差异并将它们重新集成到jar中（听起来不容易跟踪）
您可以单独打包资源，然后将代码最小化吗？拉出字符串（对i18n有用）-我想我只是想知道您是否可以对类文件进行足够的修剪以始终执行完整的构建/发布。
另一方面，Sun似乎做得很好，可以制作与以前的JRE发行版完全兼容的类文件，因此它们必须在某些地方提供指导。
