Many times the most innocuous aspects of programming create lot of trouble. Take the innocent Properties file. These avatars of Hashtable are collections of key-value pairs, frequently used by applications for their need for external resources and configuration settings. Now pointers such as these tell you that reading the Properties file using java io is evil, owing to the fact that it warrants absolute file names and that in turn poses hinders application portability. So we have the recommended ways to use the ResourceBundle class or classpath resources. Nothing wrong with this!
Or so I thought, till I had to work on a web-interface to create, modify and delete Properties files. I realized that when loading a Properties file using the Classloader and ResourceBundle and after I modify my files and store() the values, the changes won't reflect to the user. The same old properties were displayed despite the fact that some of them had been changed. The reason it seems was the fact that the classloader somehow cached the Properties. While this would be termed most efficient and desirable when reading the properties, this perhaps wouldn't be so in an Property File Editor application like mine.
In a nutshell what I ultimately had to do was to take the evil route and use java.io to load the files, as below:
//Do not load the properties file as Resource stream or ResourceBundle
//if caching is not acceptable
//InputStream in = loader.getResourceAsStream(name);
//Load it using direct I/O, obviously we need the file "path" here, which can be
//retrieved using the ServletContext
in = new FileInputStream(path);
//rest is usual
if (in != null) {
Properties objProps = new Properties();
objProps.load(in);
}
Since this is a web-application I am fetching the relative file-path of the Properties file (situated along with other classes in a package structure) using the ServletContext (getRealPath()), this works well in Tomcat, I am not sure if this approach works for all containers.