在Java中存储应用程序的conf数据的正确方法是什么？

首先是格式：

1. Java 属性文件适用于键/值对（也会自动处理换行符）。通过使用“点表示法”可以实现一定程度的结构。缺点是该结构不允许您轻松枚举顶级配置实体并以向下钻取的方式工作。最适合用于一小组经常可调整的环境特定设置
2. XML文件 - 经常用于各种Java框架（特别是J2EE和Spring）的更复杂的配置。我建议你至少了解春天 - 它包含许多值得了解的想法，即使你决定不使用它。如果您决定推出自己的 XML 配置，我建议您将 XStream 与自定义的序列化选项结合使用，或者如果您只需要解析一些 XML，请查看 XOM。BTW Spring还允许您插入自定义XML配置语言，但这是一项相对复杂的任务。XML 配置最适合用于最终用户看不到或调整的更复杂的“内部”配置。
3. 序列化 Java 对象 - 一种快速简便的方法来持久保存对象的状态并在以后还原它。如果您编写配置 GUI 并且不关心配置是否为人类可读，则非常有用。在演进类时，请注意兼容性问题。
4. 首选项 - 在 Java 1.4 中引入，允许您将键入的文本、数字、字节数组和其他基元存储在特定于平台的存储中。在Windows上，这是注册表（您可以在HKLM或HKCU下的/Software/JavaSoft/Prefs之间进行选择）。在Unix下，相同的API在用户主页或/etc下创建文件。每个 prefs 配置单元都可以导出并导入为 XML 文件。您可以通过将“java.util.prefs.PreferencesFactory”JVM 属性设置为实现类名来指定 PreferencesFactory 接口的自定义实现。

通常，根据应用方案，使用 prefs API 可能是一件好事，也可能是一件坏事。

1. 如果您计划在同一台具有不同配置的计算机上运行同一代码的多个版本，那么使用首选项 API 是一个坏主意。
2. 如果您计划在受限环境（Windows 域或严格管理的 Unix box）中使用该应用程序，则需要确保对必要的注册表项/目录具有适当的访问权限。这让我不止一次感到惊讶。
3. 当心从漫游配置文件（复制的家庭dirs）中，当涉及多台活动计算机时，它们会弥补一些有趣的场景。
4. 首选项不像应用程序目录下的配置文件那样明显。大多数桌面支持人员不期望也不喜欢他们。

关于prefs的文件布局，它再次取决于您的应用程序。一个一般性的建议是：

1. 将大多数 XML 文件打包到应用程序的 JAR 中，或者打包在 /META-INF 目录下。这些文件将是只读的，并且对于应用程序被视为私有的。
2. 将用户可修改的配置放在 $APP_HOME/conf 下。它应该主要由属性文件组成，有时还包含一个简单的 XML 文件（XStream 序列化）。这些文件作为安装过程的一部分进行调整，通常用户无法使用。
3. 在用户主页下，在点目录（即“~/.myapplication”）中存储任何用户配置。用户配置可能会覆盖应用程序 conf 目录中的配置。从应用程序内部进行的任何更改都转到此处（另请参阅下一点）。
4. 您还可以使用 $APP_HOME/var 目录来存储特定于此应用程序实例（而不是用户）的任何其他可变数据。此方法的另一个优点是，您可以通过一个目录的简单复制来移动和备份整个应用程序及其配置。

这说明了管理配置的一些标准技术。您可以使用不同的库和工具实现它们，从原始JRE开始，添加Spring /Guice或使用完整的J2EE容器（可能带有嵌入式Spring）

管理配置的其他方法包括：

1. 使用多个基目录运行使用不同配置的应用程序的多个实例。
2. 使用轻量级注册表进行集中式配置管理
3. 集中管理的配置管理数据库 （CMDB） 文件（包含每台计算机的主机特定值）每晚都会对所有生产主机进行 rsync。应用程序使用模板化配置，并在运行时根据当前主机名从 CMDB 中进行选择。

这取决于您的 J2SE 应用程序类型：

• J2SE 可执行 JAR 文件（非常简单）：使用 user.home 系统属性查找 home-dir。然后相应地制作一个子目录（例如PGP，SVN，...喝倒彩
• Java Web Start提供了非常好的包含方法来保护属性。始终特定于用户
• 最后，Eclipse RCP：在那里，您有工作区（也来自user.home）的概念，用于用户和配置（不完全确定如何在Vista中访问棘手的内容）用于计算机广泛使用

所有这些方法，当谨慎使用时 - 使用正确的分隔符 - 操作系统中立。