Yesterday a friend asked me a question about Java resource bundles: how can I get my application to discover resource bundles dynamically?
It seemed like a simple question. I answered in my typical fashon: Well, everytime you need a new bundle, just add that bundle’s jar or directory to your classpath and run the application. Or if it’s just a single properties file, add that file to your existing classpath, maybe drop it into the same directory as your other properties files.
My friend wasn’t content with that. He had done some homework before asking me. He said, “My application is in a jar file. I launch it on the command line like this, java -jar MyApp.jar. When I wanted to add new resource bundle jar files, I tried this: java -cp Hello_ja.jar -jar MyApp.jar. It didn’t work. The app doesn’t see the additional Hello_ja.jar file.”
I explained that when you use java -jar MyApp.jar, the jar’s own classpath settings defined by its manifest file will override anything on the command line that is defined by the cp option. The cp option is worthless for setting a classpath in this situation.
Of course, he still needed a solution. Hmmm…how could I help him?
It turns out that you actually can add classes to your classpath dynamically at runtime. Your application can discover new jar files and use the functionality it finds in them. The ClassLoader class can help you. The ClassLoader class can add class directories, jar files, and even lists of jar files to a classpath. Then when you need a class from that directory or jar file, you can use ClassLoader to load the class.
Let’s look at how this might work for loading resource bundles. In my examples, I’m going to create an application that displays three greetings in a panel. I’ll package the application as a jar file. The application will load its resource bundles from jar files that I’ll place into a “plugins” subdirectory directly under the application jar. The big deal about this is that the application will discover the jar files that are in the plugins subdirectory each time it launches. So, if you want to add another localized set of bundles, just drop the new jar into the plugins directory.
First, let’s start with the Greetings application. It’s simple just to demonstrate the point. It loads resources from a standard resource bundle and puts the resource strings in a dialog. Although the ResourceBundle for messages is just a standard bundle, notice that I’ve provided a class loader. The class loader has been instructed to add jar files to the classpath, specifically the jars found in the plugins subdirectory. I’ll show you the ResourceLoader class later. For now, here’s part of the basic dialog-based app:
package com.joconner.hello;
import com.joconner.resplugin.ResourceLoader;
import java.util.Locale;
import java.util.ResourceBundle;
/**
*
* @author JOConner
*/
public class GreetingDialog extends javax.swing.JDialog {
/** A return status code - returned if Cancel button has been pressed */
public static final int RET_CANCEL = 0;
/** A return status code - returned if OK button has been pressed */
public static final int RET_OK = 1;
private ResourceBundle res = null;
/** Creates new form GreetingDialog */
public GreetingDialog(java.awt.Frame parent, boolean modal) {
super(parent, modal);
ClassLoader resourceLoader = ResourceLoader.createForDirectory("plugins/");
res = ResourceBundle.getBundle("com.joconner.hello.resources.messages",
Locale.getDefault(), resourceLoader);
initComponents();
}
/** @return the return status of this dialog - one of RET_OK or RET_CANCEL */
public int getReturnStatus() {
return returnStatus;
}
private void initComponents() {
tfMorning = new javax.swing.JTextField();
tfAfternoon = new javax.swing.JTextField();
tfEvening = new javax.swing.JTextField();
addWindowListener(new java.awt.event.WindowAdapter() {
public void windowClosing(java.awt.event.WindowEvent evt) {
closeDialog(evt);
}
});
tfMorning.setText(res.getString("greeting.morning"));
tfAfternoon.setText(res.getString("greeting.afternoon"));
tfEvening.setText(res.getString("greeting.evening"));
As you can see, the above dialog doesn’t do anything surprising with the bundles; it retrieves a bundle, pulls strings from it, and uses those strings in 3 text fields. However, notice that I’ve instructed the ResourceBundle class to use a special class loader. The class loader code is here:
public class ResourceLoader {
private ResourceLoader() {}
private ResourceLoader(File dir) {
this.directory = dir;
}
/**
* Create a ResourceLoader for a specific file system location.
* All JAR files and subdirectories in the location will be added
* to the classpath
*/
public static ClassLoader createForDirectory(File dir) {
ResourceLoader loader = null;
if (dir.isDirectory()) {
loader = new ResourceLoader(dir);
}
loader.addJarsToPath();
return loader.getClassLoader();
}
public static ClassLoader createForDirectory(String dir) {
File f = new File(dir);
return createForDirectory(f);
}
private File[] addJarsToPath() {
File[] jarFiles = directory.listFiles();
List urlList = new ArrayList();
for(File f: jarFiles) {
try {
urlList.add(f.toURI().toURL());
} catch (MalformedURLException ex) {
Logger.getLogger(ResourceLoader.class.getName()).log(Level.SEVERE, null, ex);
}
}
ClassLoader parentLoader = Thread.currentThread().getContextClassLoader();
URL[] urls = new URL[urlList.size()];
urls = urlList.toArray(urls);
URLClassLoader classLoader = new URLClassLoader(urls, parentLoader);
this.loader = classLoader;
return jarFiles;
}
public ClassLoader getClassLoader() {
return this.loader;
}
private File directory;
private ClassLoader loader;
}
This ClassLoader puts all jar files that are in my application-defined “plugins” subdirectory onto the classpath. See the addJarsToPath method for the exact wa to do this. Of course, this particular implementation isn’t robust. If you were doing this in an important application, you might want to confirm that a jar file really was a resource jar file….maybe your jar has a particular manifest file entry to provide very basic assurance that it is what you think it is.
Finally, just create your ResourceBundles as you normally would. Create jar files for each set of localized bundles for a specific language. Then drop them into a “plugins” directory immediately under your application’s main directory…the place your applications sits on the file system.
Now you can add new localized bundles to your application without having to recompile or jar your primary application. You don’t even have to change its classpath since new “plugins” jar files will automatically be added to the classpath for resource bundle creation.
There you go. Enjoy.
VN:F [1.9.3_1094]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.3_1094]
