Java OutputStream 等价于 getClass().getClassLoader().getResourceAsStream()
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2031248/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Java OutputStream equivalent to getClass().getClassLoader().getResourceAsStream()
提问by craig
I am attempting to store the change made to my application's properties. The .propertiesfile is located in resourcespackage, which is different from the package that contains my UI and model.
我正在尝试存储对我的应用程序属性所做的更改。该.properties文件位于resources包中，与包含我的 UI 和模型的包不同。
I opened the package using:
我使用以下方法打开了包裹：
this.getClass().getClassLoader().getResourceAsStream("resources/settings.properties")
Is there a functional equivalent of this that permits me to persist changes to the Properties Class in the same .Properties file?
是否有与此功能等效的功能，允许我在同一个 .Properties 文件中保留对 Properties 类的更改？
采纳答案by Michael Borgwardt
It sounds like you want to store user preferences. Consider using the Java Preferences APIfor that.
听起来您想存储用户首选项。考虑为此使用Java Preferences API。
回答by Stephen C
In general, you cannot put stuff back into a resource you got from the classloader:
通常，您不能将内容放回从类加载器获得的资源中：
Class loader resources are often read-only; i.e. held in read-only files / read-only directories.
If you got the resource from a JAR file, JAR files are not simply updateable. (To "update" you need to extract the old JAR's contents and create a new JAR with the updated contents. It is all to do with the structure of ZIP files ...)
In some cases, the class loader resource will have been downloaded on-the-fly, and there is no way to push changes back to the place where you downloaded from.
类加载器资源通常是只读的；即保存在只读文件/只读目录中。
如果您从 JAR 文件中获取资源，则 JAR 文件不能简单地更新。（要“更新”，您需要提取旧 JAR 的内容并使用更新后的内容创建一个新 JAR。这完全与 ZIP 文件的结构有关...）
在某些情况下，类加载器资源将被即时下载，并且无法将更改推送回您下载的位置。
Even if you can update a resource you got from the classloader, it is a bad idea / bad practice.
即使您可以更新从类加载器获得的资源，这也是一个坏主意/坏做法。
Doing this "pollutes" the clean application installation with a user's preferences. Among other things, this means that the installation cannot be shared with other users (unless you handle preferences for multiple users ...).
There are security issues with having applications installed as writeable so that embedded preferences can be updated. Think viruses! Think one user who might be inclined to trash another user's preferences!
There are administration issues with having user-specific copies of applications. And if the user has to install his own copy of an app, there are potential security issues with that as well.
There may be technical issues with file locking or caching on some platforms that either get in the way of (safe) updates or make it difficult for an application to load the updated resource without a restart.
这样做会根据用户的偏好“污染”干净的应用程序安装。除此之外，这意味着安装不能与其他用户共享（除非您处理多个用户的首选项......）。
将应用程序安装为可写的以便可以更新嵌入式首选项存在安全问题。想想病毒！想想一个用户可能倾向于破坏另一个用户的偏好！
拥有特定于用户的应用程序副本存在管理问题。如果用户必须安装他自己的应用程序副本，那么也存在潜在的安全问题。
某些平台上的文件锁定或缓存可能存在技术问题，这些问题要么妨碍（安全）更新，要么使应用程序难以在不重新启动的情况下加载更新的资源。
Finally, this is NOT the way that system administrators (and educated users) expect software to behave. Java applications should deal with user preferences in the expected way:
最后，这不是系统管理员（和受过教育的用户）期望软件运行的方式。Java 应用程序应该以预期的方式处理用户偏好：
You can use the Java Preferences API.
You can write a Properties filecontaining the preferences to an OS-appropriate user-writable directory.
On Windows, you could use a Windows-specific API to store the preferences in the Windows registry, except that this makes your application Windows dependent. (I can't see any real advantage in doing this, but I am not a Window expert.)
您可以使用Java 首选项 API。
在 Windows 上，您可以使用特定于 Windows 的 API 将首选项存储在 Windows 注册表中，除非这会使您的应用程序依赖于 Windows。（我看不出这样做有什么真正的优势，但我不是 Window 专家。）
回答by Carl Smotricz
When you wrap your app up as a JAR file, your properties file will be one (possibly compressed) file within that JAR, and it would be a bad idea to try to write to your own JAR.
当您将应用程序打包为 JAR 文件时，您的属性文件将是该 JAR 中的一个（可能是压缩的）文件，尝试写入您自己的 JAR 将是一个坏主意。
getResourceAsStream()is meant to open resources for reading, and these can be anywhere on the classpath. You can't write to URLs or inside JARs, you can only write to files, so it doesn't make sense to give you the same API for output.
getResourceAsStream()旨在打开资源以供阅读，这些资源可以位于类路径上的任何位置。您不能写入 URL 或 JAR 内部，您只能写入文件，因此为您提供相同的输出 API 没有意义。
Find yourself a directory you're allowed to write into, and write your properties there.
为自己找到一个允许写入的目录，然后在那里写入您的属性。
It may be a good idea to copy your properties from your installation classpath (possibly inside a JAR) directly out to a file if it doesn't yet exist, as a first operation upon application startup. This will give you a properties file you can write to, yet the master copy of this properties file will come from your project deliverable.
作为应用程序启动时的第一个操作，如果文件尚不存在，将您的属性从安装类路径（可能在 JAR 中）直接复制到文件中可能是个好主意。这将为您提供一个可以写入的属性文件，但此属性文件的主副本将来自您的项目可交付成果。
回答by seh
In addition to Carl's answer, if you're going to read and write to this file frequently, and expect that your application will expand in scope, consider whether to go one step (or several steps) further and use a file-based database like SQLite. There are a few JDBC wrappers for SQLite that would allow you to go beyond the basic string key-value lookup that the Java Properties interface provides.
除了Carl 的回答之外，如果您打算频繁读写此文件，并希望您的应用程序的范围扩大，请考虑是否更进一步并使用基于文件的数据库，例如SQLite。有一些 SQLite 的 JDBC 包装器可以让您超越 Java Properties 接口提供的基本字符串键值查找。
