命令行参数vs文件属性（* .properties）与Java中的系统属性（-D）

Question

有很多方法可以将参数传递给Java应用程序。其中包括：

1. 命令行参数
2. 属性文件（properties - 样式）
3. 系统属性（通过-D选项传递）
4. 系统环境变量

在意识形态上，何时应该优先选择其他人？ 例如，如果有一个参数要传递给应用程序，是否有理由支持命令行参数而不是* .properties文件？

或者，例如，可以从堆栈深处的任何类轻松访问System变量（而不是CLI，只能在main中访问）。是否因为易于访问而更喜欢使用CLI上的系统属性？

Answer 1

取决于部署需要回答其中一些问题。

命令行参数：当您有其他进程生成应用程序并且您想要从调用进程控制这些参数时，这很好。一个例子是CRON产生它。

文件：我不喜欢ini风格......你被困在Windows上。如果你想要一些非常简单的东西，首选你可以使用Properties类加载的.properties文件。或者你可以使用XML。文件还为您提供了文件放置选择，相对于应用程序而言，部署非常适合，而且有些人还喜欢将它们放在像/ etc这样的全球范围内

环境变量：虽然它使部署更复杂，但它们有其自己的位置。如果环境影响应用程序的参数，我只会使用它。这意味着，您的应用程序将采取不同的行为，或者需要根据操作系统，机器等进行不同的配置。

偏好是主观的，可能取决于应用程序的类型，部署，系统等。

Answer 2

嗯，进入配置，每个程序员都有自己的想法如何正确的方式...通常它取决于很多东西。

我用这种方式来处理这个选择：如果它类似于环境变量，（类似于$ PATH或$ SHELL），并且可以/必须由调用者（另一个程序或启动脚本）设置，它通过-D开关直接在System.Properties中。

如果它是其他东西，那么它直接进入属性文件（实际上它的加载方式并不重要，有几种方法可以做到，每种方式都有优点和缺点，我的首选是从类路径加载，但只是品味问题。）

我尝试在System.Properties中保留最小的，非常重要的东西，如果它是一个大的配置，更好地使用Properties或XML甚至更好的数据库表，但同样，它取决于你的应用程序的复杂性（HelloWorld with a DB显然有点矫枉过正^^）。