Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
August 8, 2003
What is the best strategy for loading property and configuration files in Java?
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.
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
Using good old files (via
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.
An ideal Java module is something you add to the classpath, and it's ready to go. Think EJB jars, Web applications packaged
.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.
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).
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.
You can get at
some/pkg/resource.properties programmatically from your Java code in several ways. First, try:
|Forum migration complete By Athen|
|Forum migration update By Athen|
|A much smarter way to load properties and onfig By Bruce Conrad|
|Small inconvenience with classpath By Catalin|
|Loading properties from a static context By Anonymous|
|Smartly load your properties (nice Artical) By ihab|
|Consider using Jakarta Commons - Configuration By mortenhattesen|
|Bad exception handling, again By Anonymous|
|Issue loading properties file in an EAR By Prashant_Basawa|
|Toolbox stuff By rodney_draziw|
|ClassPath conflict By Anonymous|
|A property file in WEB-INF folder By lKamal99|
|Multi-user, multi-properties By Anonymous|