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

• J2SE可执行JAR文件（非常简单）：使用user.home系统属性来查找home-dir。然后相应地创建一个子目录（例如PGP，SVN，...）
• Java Web Start为安全属性提供了很好的包含方法。始终是用户特定的
• 最后Eclipse RCP：在那里你有用于用户和配置的工作空间（也来自user.home）的概念（不完全确定如何在Vista中访问那些棘手的问题）

所有这些方法，谨慎使用时 - 使用正确的separatorChar - OS中性。

首先是格式：

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

根据您的应用场景，通常使用prefs API可能是好事或坏事。

1. 如果您计划在具有不同配置的同一台计算机上运行相同代码的多个版本，那么使用Preferences API是一个不错的主意。
2. 如果您打算在受限制的环境中使用应用程序（Windows域或紧密管理的Unix机箱），则需要确保您具有对必要注册表项/目录的适当访问权限。这让我不止一次感到意外。
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-ed。应用程序使用模板化配置，并在运行时根据当前主机名从CMDB中进行选择。