有多种方法可以将参数传递给 Java 应用程序。其中有：
properties-style)-D选项传递）从意识形态上讲，什么时候应该更喜欢一个而不是另一个？例如，如果有很多参数要传递给应用程序，是否有任何理由偏爱命令行参数而不是 *.properties 文件？
或者，例如，可以轻松地从堆栈深处的任何类访问系统变量（与 CLI 不同，CLI 只能在 中访问main）。是否应该仅仅因为易于访问而更喜欢使用系统属性而不是 CLI？
取决于部署需要回答其中的一些问题。
命令行参数：当您有其他进程生成您的应用程序并且您想从调用进程控制这些参数时，这很好。一个例子是 CRON 产生它。
文件：我不喜欢 ini 风格......你被困在 Windows 上。如果您想要一些非常简单的东西，请首选可以使用 Properties 类加载的 .properties 文件。或者您可以使用 XML。文件还可以让您选择文件位置，相对于应用程序来说非常适合部署，有些人还喜欢将它们扔到全局的某个地方，例如 /etc
环境变量：它们有它们的位置，尽管它使部署更加复杂。如果环境影响您的应用程序的参数，我只会使用它。这意味着，您的应用程序的行为会有所不同，或者需要根据操作系统、机器等进行不同的配置。
偏好是主观的，可能取决于应用程序、部署、系统等的类型。
Well, coming to configurations, each programmer has its own idea on how's the right way to do... As usual it depends on a whole lot of things.
I use to deal with this choice in this way: if it's something like an enviroment var, (something similar to $PATH or $SHELL), and can/must be set by the caller (another program or a startup script), it goes straight in System.Properties via -D switch.
If it's something else, then it goes straight to property file (and actually how it's loaded is not really important, there are several ways to do it, each with pros and cons, my fav is loading from classpath, but is just a matter of taste).
I try to keep in System.Properties just minimal, really important things, if it's a big configuration, better use Properties or XML or even better database tables, but again, it depends on the complexity of your application (HelloWorld with a DB is plain overkill ^^).