設置java系統屬性-D或System.setProperty（）的最佳做法是什么？

Question

我需要為我正在處理的RMI應用程序設置代碼庫，並且首先使用它成功完成了

try{
  ResourceBundle config = ResourceBundle.getBundle("myApp");
  String codeBaseUrl = config.getString("codeBaseUrl");
  System.setProperty("java.rmi.server.codebase", codeBaseUrl);
} catch (Exception e) {
  e.printStackTrace();
}

然后使用

java -Djava.rmi.server.codebase=http://192.168.1.1/path/to/codebase ...

在命令行上。

這兩種方法都允許在不需要重新編譯的情況下更改代碼庫，但System.setProperty方法允許將代碼庫並入屬性文件並使用相同的啟動命令。

我讀過的大部分教程/文檔都使用-D方法讓我相信這被認為是最佳實踐，但我一直無法找到任何解釋為什么我應該使用另一個。

-D被認為是設置系統屬性（如代碼庫）的最佳實踐，它會帶來哪些好處/它會避免哪些陷阱？

Answer 1

（已編輯 - 我誤讀了這個問題）

比較兩者：

• -D是可配置的 - 它是在運行時指定的
• 通過System.setProperty()資源包仍然是“運行時”，但它是通過一個超出啟動命令的文件編輯的

首先，通過在運行時指定設置來驅動靈活行為總是優於硬編碼行為（除非行為實際上不靈活 - 即除非有這樣的值，否則不要使用配置）。

使用文件的主要缺點是它可能包含敏感數據，如密碼，系統管理員不希望永久存在於磁盤上。 如果密碼作為啟動命令的一部分輸入，則它是短暫的並且更加安全（會話命令歷史記錄不能承受）。

使用文件的好處是您可以建立正確的設置並保留在文件中。 您甚至可以通過源代碼管理來管理文件。

還有另一種更安全的選擇，即啟動時要求在命令行輸入密碼，這樣就不會留下任何痕跡。

Answer 2

我會使用System.setProperty（在應用程序的最頂層，因為對於某些屬性，否則可能為時已晚），但從配置文件中獲取信息。

你幾乎已經這樣做了，但我也允許設置任意屬性，而不僅僅是一些硬編碼鍵。

我喜歡將它與我的應用程序已經使用的配置文件相結合，該配置文件還包含其他（nonSystem.properties）設置。 我通過在系統屬性前加上-D來區分這兩者（就像在命令行中一樣）：

 # some configuration
 a.b.c = xxx

 # RMI settings
 -Djava.rmi.server.codebase = http://192.168.1.1/path/to/codebase

將有一個默認位置來查找此屬性文件，但可以通過命令行開關覆蓋（以便您可以在不同的配置之間切換或輕松安裝多個代碼）。

擁有一個文件具有額外的好處，它也可以作為文檔（關於可用的選項，默認值是什么，等等）。

我真的希望Java有一個內置工具來從屬性文件中獲取系統屬性，以及其他JVM設置，如內存和類路徑。 目前，您必須自己完成所有這些工作，無論是使用Java還是使用特定於操作系統的shell包裝器。

Answer 3

除非有特殊原因（例如避免暴露敏感信息或防止修改），否則我建議使用“-D”選項，而不是使用System.setProperty添加屬性。

• 它更簡單（代碼更少）
• 它允許以獨立於應用程序的方式直接配置
• 它避免了在應用程序代碼有機會設置它們之前初始化期間讀取系統屬性的問題。

我的另一個建議是不要將系統屬性用作大量特定於應用程序的屬性的轉儲基礎。 如果您有許多應用程序配置屬性，請使用單獨的Properties對象（或更復雜的東西），並從單獨的屬性文件（或更復雜的東西）加載它。 其他人可能在這方面不同意我，但我發現這是一個更好的方法。

（但很明顯，如果您使用的是查看系統屬性的標准或第三方子系統，那么您需要這樣做。）

Answer 4

因為通過在運行時傳遞參數，您可以輕松地為開發和生產（以及其他）環境提供單個代碼庫，而無需將語句硬編碼到代碼中。 例如，在開發中，您可能希望連接到192.168.0.1的服務器，而在生產中，您可能希望轉到10.0.1.1。 為了通過使用System.setProperty進行硬編碼來實現此結果，您需要具有條件語句，這可能會變得混亂。

您通常不希望為每個環境重新編譯應用程序，因此通常最方便的是在運行時傳遞參數或使用某些類型的屬性文件，該文件可以根據系統進行更改。