Smartly load your properties

Strive for disk location-independent code nirvana

By Vladimir Roubtsov, JavaWorld.com, 08/08/2003

http://www.javaworld.com/javaworld/javaqa/2003-08/01-qa-0808-property.html

巧妙地加載屬性

為獨立于磁盤位置的代碼天堂而努力

Q：What is the best strategy for loading property and configuration files in Java?

問：在Java中加載屬性和配置文件最好的策略是什么？

A：When you think about how to load an external resource in Java, several options immediately come to mind: files, classpath resources, and URLs. Although all of them eventually get the job done, experience shows that classpath resources and URLs are by far the most flexible and user-friendly options.

答：當你考慮如何在Java中加載一個外部資源時，多種選擇立即浮現在腦海：文件，類路徑資源和URL。雖然最終它們都能完成工作，但是經驗表明類路徑資源和URL顯然是最靈活最好用的選擇。

In general, a configuration file can have an arbitrarily complex structure (e.g., an XML schema definition file). But for simplicity, I assume below that we're dealing with a flat list of name-value pairs (the familiar .properties format). There's no reason, however, why you can't apply the ideas shown below in other situations, as long as the resource in question is constructed from an InputStream.

通常，一個配置文件可以有任意復雜的結構（例如，XML schema定義文件）。但是對于簡單的結構，下面我假設我們正在處理一個簡單的名-值對列表（常見的.properties格式）。然而，只要討論的資源是從一個InputStream構造時，你沒有理由不在以下列出的其它情況下應用那個想法（選擇類路徑資源和URL）。

Evil java.io.File

不幸的java.io.File

Using good old files (via FileInputStream, FileReader, and RandomAccessFile) is simple enough and certainly the obvious route to consider for anyone without a Java background. But it is the worst option in terms of ease of Java application deployment. Using absolute filenames in your code is not the way to write portable and disk position-independent code. Using relative filenames seems like a better alternative, but remember that they are resolved relative to the JVM's current directory. This directory setting depends on the details of the JVM's launch process, which can be obfuscated by startup shell scripts, etc. Determining the setting places an unfair amount of configuration burden on the eventual user (and in some cases, an unjustified amount of trust in the user's abilities). And in other contexts (such an Enterprise JavaBeans (EJB)/Web application server), neither you nor the user has much control over the JVM's current directory in the first place.

使用舊文件（通過FileInputStream, FileReader, 和 RandomAccessFile)相當簡單，當然考慮到沒有Java背景的人這也是明顯的方式。但是就Java應用部署的簡易性而言文件是最壞的選擇。在你的代碼中使用絕對文件名不是編寫可移植、獨立于磁盤位置的代碼的方式。使用相對文件名好像是一個較好的替代方法，但是記住它們是相對于JVM的當前路徑被解析的。目錄設置依賴于JVM加載進程的細節，像啟動shell腳本或其他加載JVM的方式使得目錄設置變得混亂。將決定如何設置的配置負擔加給最終用戶是不公平的（在某些情況下，對用戶能力的信任是不合理的）。而且在其它環境（像企業JavaBeans(EJB)/Web應用服務器）中，在一開始你和用戶對JVM的當前路徑都沒有太多的控制。

An ideal Java module is something you add to the classpath, and it's ready to go. Think EJB jars, Web applications packaged in .war files, and other similarly convenient deployment strategies. java.io.File is the least platform-independent area of Java. Unless you absolutely must use them, just say no to files.

理想的Java模型是你添加到classpath的東西，準備上手吧。考慮一下EJB jar，打包到.war文件的Web應用程序和其他類似方便的部署策略。除非你絕對要使用文件，否則還是對文件說不。

Classpath resources

Having dispensed with the above diatribe, let's talk about a better option: loading resources through classloaders. This is much better because classloaders essentially act as a layer of abstraction between a resource name and its actual location on disk (or elsewhere).

我們不再對File進行抨擊，讓我們討論一種更好的選擇：通過類加載器加載資源。因為類加載器在資源名稱和在磁盤上（或其他地方）的實際位置之間主要扮演了一個抽象層角色，這是相當好的。

Let's say you need to load a classpath resource that corresponds to a some/pkg/resource.properties file. I use classpath resource to mean something that's packaged in one of the application jars or added to the classpath before the application launches. You can add to the classpath via the -classpath JVM option each time the application starts or by placing the file in the <jre home>\classes directory once and for all. The key point is that deploying a classpath resource is similar to deploying a compiled Java class, and therein lies the convenience.

比如說你需要加載一個類路徑資源，它對應some/pkg/resource.properties文件。我使用類路徑資源意味著這個資源要打包到應用程序的某個jar中或者在應用程序啟動之前加到類路徑中。你可以在應用程序每次啟動時通過-classpath這個JVM參數添加類路徑，或者干脆把那個文件放到<jrehome>\classes目錄中。關鍵點是部署一個類路徑資源類似于部署一個已編譯的Java類，方便的地方就在于此。

You can get at some/pkg/resource.properties programmatically from your Java code in several ways. First, try:

你可以通過多種方式在你的Java代碼中以編程方式訪問到some/pkg/resource.properties。首先，試一試：

Additionally, if the code is in a class within a some.pkg Java package, then the following works as well:

此外，如果代碼在some.pkg這個Java包中的類，以下方式也可以：

Note the subtle differences in parameter formatting for these methods. All getResourceAsStream() methods use slashes to separate package name segments, and the resource name includes the file extension. Compare that with resource bundles where the resource name looks more like a Java identifier, with dots separating package name segments (the .properties extension is implied here). Of course, that is because a resource bundle does not have to be backed by a .properties file: it can be a class, for a example.

注意這些方法在參數格式上的細微差別。所有getResourceAsStream()方法都是使用斜杠(/)來分隔包名段，而且資源文件名包括文件擴展名。比較一下，使用資源包（resource bundle）時資源名看上去更像Java標識符，它是以點(.)分隔包名段（這里的.properties擴展名被隱含了）。當然，一個資源包（resource bundle）不必非要是.properties文件：例如，它可以是一個類。

To slightly complicate the picture, java.lang.Class's getResourceAsStream() instance method can perform package-relative resource searches (which can be handy as well, see "Got Resources?"). To distinguish between relative and absolute resource names, Class.getResourceAsStream() uses leading slashes for absolute names. In general, there's no need to use this method if you are not planning to use package-relative resource naming in code.

對于稍復雜的情況，java.lang.Class的 getResourceAsStream()實例方法可以執行相對于包的資源搜索（這是相當方便的，參見” Got Resources?”）。為了區別相對和絕對資源名稱，Class.getResourceAsStream()對絕對名稱使用前導斜杠(/)。一般來說，如果你沒有計劃在代碼中使用相對于包的資源命名沒有必要使用這種方法。

It is easy to get mixed up in these small behavioral differences for ClassLoader.getResourceAsStream(), Class.getResourceAsStream(), and ResourceBundle.getBundle(). The following table summarizes the salient points to help you remember:

很容易混淆ClassLoader.getResourceAsStream(), Class.getResourceAsStream(), 和 ResourceBundle.getBundle()在行為上的細小區別。下表總結了一些顯著點來幫助你記憶：

Behavioral differences