虽然现在已经有各种智能的IDE可以为我们生成jar包，war包，ear包，甚至带上了自动替换，部署的功能。但一定会有那么些时候，你需要修改或是替换jar包，war包，ear包中的某个文件而不是整个重新生成。比如说，你有一个ear包已经部署到客户的服务器上，运行了有那么久了，版本也很老，但一个让你头痛的bug需要立即在客户那里fix，这个ear包很大，并且客户的网络很慢，你也没有那么老的整套代码，但是你明白只需要改一个class文件就可以修复了。如果你按照正常的流程，那一般是你得提交代码，由CI编出一个rpm包，在客户的服务器上重新部署，再验证，这时候黄花菜都凉了，客户心里已经骂了你无数遍的无能。
那这时候，我们只有让热替换出场了（我之前写过一篇文章是关于热部署的，但那是通过JDK自带的功能，这里要说的是硬生生的替换文件），很庆幸，现在所有的Java应用程序服务器都支持热部署。所以我们只需要进入到应用程序服务器的路径，把我们修改了bug的class文件或jar文件，whatever else，替换到ear包里面就可以了。这时应用服务器就会检查到ear包发生了更新，会自动热部署。
这里要用到工具是两个，jar和7z，为什么jar和7z或者zip被一起相提并论，因为jar包，war包，ear包，本质上都是zip包或称为压缩包

这是JDK自带的工具。有的放矢，只需知道以下四大命令外加vf后缀：

注意: 这里的压缩包可以是jar, war, ear或者what ever else，你只需在调用jar的时候，指定你要的后缀名。

这个不是我们的重点，只是给大家表述一下jar -cvf的本质是压缩包，而且是啥后缀名都行。假设有如下文件：

用7z或者zip打开：

表明这是一个简单的压缩包，只是多了一个META-INFO文件夹而已。无他

发挥一下想象力，这个example.ear是部署在服务器上的，编译和部署的流程很复杂，你不想重新编译和部署这个exmple.ear只想替换里面的文件。

这个jar很小，50k, 我们修改一下这个文件，放到同一个目录：

这时再发挥一下想象力，这个ear是在应用服务器的deployment目录中，hot deploy是打开的，服务器会发现这个ear包的创建时间更新了，会重新部署这个ear包

注意：上面的例子中，ear包的目录结构是很简单的，所有的文件基本都在根目录，如果你要替换子目录中的文件，那你需要先执行jar -xvf命令，把你需要替换的文件先解压缩出来（会连带目录结构一起解压到当前目录），然后再将新文件替换解压之后的目录结构中的文件，再执行jar -uvf。（如有不懂，评论里面问）

如果是修改，那证明基本上你要修改的不可能是class文件或jar文件，一定是什么xml，properties等被打包在压缩包中的文件，这时就用7z出马了，直接打开压缩，编辑，即可：

简单啊，7z打开，直接删除