我正在尝试创建一个Jar文件,其中包含Jar内的数据,这些数据在程序执行之间持续存在.我知道还有其他保存数据的方法,但是我要准备一个完全独立的Jar文件.
我有一些似乎可行的方法,我想就您在方法中遇到的任何漏洞提供反馈,因为有些漏洞让人对此有些怀疑.我在做什么是这样的:
> Jar包含一个文件saves.txt.该文件包含一位数字:开头是1.
>运行Jar时,它将读取该文件(使用getResourceAsStream)并向用户显示该编号.
>然后,我使用ZipFile API将整个jar提取到一个临时目录中.
>现在saves.txt是文件(不是资源),我增加数字并覆盖temp目录中的文件.
>然后,我使用JarOutputStream将临时目录的内容(包括更新的saves.txt文件)重新压缩到同一jar中.
>最后,我删除临时目录,程序退出.当用户再次运行jar时,saves.txt文件已更新.
而且我不使用jar -u命令,因为我不想要求最终用户拥有JDK.
我可以看到一些问题,但对我来说,这些都不是破坏交易的因素:
>这不适用于签名罐子.对我来说这不是问题,因为无论如何这些罐子都不会被签名.
>如果jar位于没有写权限的目录中,则此方法将无效.我可以警告用户.
>如果在运行程序时在存档浏览器(如7zip)中打开了jar,则此功能将无效.我可以通过向用户显示一条消息要求他们关闭它来解决此问题.
>这使得部署新版本的jar变得烦人,因为保存内容保存在jar中.用户要么必须以某种方式从旧的jar中加载数据,要么开始清理.我也同意
所以,我的问题是:以上任何一项看起来特别恐怖吗?如果是这样,为什么?
编辑:我应该注意的是,我并不是真正在问这种方法是标准的还是令人困惑的,而是关于代码的.有什么原因导致代码无法正常工作?
“在运行jar时重写jar的内容”这一步使我最紧张,但是我找不到任何文档说明您不能甚至不应该这样做.如果我在程序中间执行此操作,则可能会发生不好的事情,但这只会在程序结束时发生.覆盖jar是程序的最后一行.
最重要的是,这一切似乎都有效!我已经在Windows 7,Windows 8和Mac上对此进行了测试.因此,如果有人知道任何文档,或者可以想到此代码无法正常工作的特殊情况,我一定会非常感激的.
这是显示以上所有内容的MCVE.为此,您必须将此类编译为可运行的jar文件以及包含一位数字的saves.txt文件.
import java.io.BufferedOutputStream;
import jav