We Keep Coding

Changing the properties file while the application is running

I have a attribute in properties file. say 'x'.
In my Java class, I use this x in a loop. So the first time loop is executed, it loads from properties file and from the second time, it takes value from memory without loading the props file every time. Now if I want to change the value of x in the properties file, can i load that value without restarting the application? If yes, how?
Also is there any Java equivalent for Session_OnStart in .net? I heard Session_OnStart in .net serves this purpose

You can load and parse the properties each time a variable is requested.
class RefreshingProperties extends Properties {
private final File file;
public RefreshingProperties (File file) throws IOException {
this.file = file;
refresh ();
}
private void refresh () throws IOException {
load (new FileInputStream (file));
}
#Override
public String getProperty (String name) {
try { refresh (); }
catch (IOException e) {}
return super.get (name);
}
}
You can tweak this to reload only whenever a certain time period expires

Creating File & Directories not working properly

I am currently working on a method that will create files and directories. Bellow is the use case & problem explained.
1) When a user specifies a path e.g "/parent/sub folder/file.txt", the system should be able to create the directory along with the file.txt. (This one works)
2) When a user specifies a path e.g "/parent/sub-folder/" or "/parent/sub-folder", the system should be able to create all directories. (Does not work), Instead of it creating the "/sub-folder/" or /sub-folder" as a folder, it will create a file named "sub-folder".
Here is the code I have
Path path = Paths.get(rootDir+"test/hello/");
try {
Files.createDirectories(path.getParent());
if (!Files.isDirectory(path)) {
Files.createFile(path);
} else {
Files.createDirectory(path);
}
} catch (IOException e) {
System.out.println(e.getMessage());
}

You need to use createDirectories(Path) instead of createDirectory(path). As explained in the tutorial:
To create a directory several levels deep when one or more of the
parent directories might not yet exist, you can use the convenience
method, createDirectories(Path, FileAttribute). As with the
createDirectory(Path, FileAttribute) method, you can specify an
optional set of initial file attributes. The following code snippet
uses default attributes:
Files.createDirectories(Paths.get("foo/bar/test"));
The directories
are created, as needed, from the top down. In the foo/bar/test
example, if the foo directory does not exist, it is created. Next, the
bar directory is created, if needed, and, finally, the test directory
is created.
It is possible for this method to fail after creating some, but not
all, of the parent directories.

Not sure of which File API you are using. But find below the simplest code to create file along with folders using java.io package.
import java.io.File;
import java.io.IOException;
public class FileTest {
public static void main(String[] args) {
FileTest fileTest = new FileTest();
fileTest.createFile("C:"+File.separator+"folder"+File.separator+"file.txt");
}
public void createFile(String rootDir) {
String filePath = rootDir;
try {
if(rootDir.contains(File.separator)){
filePath = rootDir.substring(0, rootDir.lastIndexOf(File.separator));
}
File file = new File(filePath);
if(!file.exists()) {
System.out.println(file.mkdirs());
file = new File(rootDir);
System.out.println(file.createNewFile());
}
} catch (IOException e) {
System.out.println(e.getMessage());
}
}
}

better way to point to folders and files in a properties file?

I was wondering if there is a better way to have a point to PATH in a properties file. Consider the following code:
public class Properties
{
//MIKE
public final static String PATH_TO_FILE_A = "C:\\programmer_MIKE\fileA.txt";
public final static String PATH_TO_FILE_B = "C:\\programmer_MIKE\fileB.txt";
//BILL
//public final static String PATH_TO_FILE_A = "/Users/BILL/Desktop/fileA.txt";
//public final static String PATH_TO_FILE_B = "/Users/BILL/Desktop/fileB.txt";
}
when any developer need to invoke FILE_A he simply does:
File file = new File(Properties.PATH_TO_FILE_A);
this works ok for BILL if he commented out MIKE's PATH_TO_FILE_A.
Q: is there a better design? If BILL committed his work including the Properties file - he will cause a problem to MIKE (no worries, he'll get a Coffee Latte later on).
the FILES are big (2-4Gb) and we don't want to put them in our repository (svn) and sometimes there are simply temporary folder to create a PDF so we don't want to put them in a "./docs" path.
Thanks for any pointer!

If for whatever reason you really must have hardcoded paths, then you could store them in some kind of map indexed by username. Something like:
public class Properties {
private static Map<String, DeveloperPaths> properties = create();
private static Map<String, DeveloperPaths> create() {
Map<String, DeveloperPaths> properties = new HashMap<String, DeveloperPaths>();
properties.put("mike", new DeveloperPaths(
"C:\\programmer_MIKE\fileA.txt",
"C:\\programmer_MIKE\fileB.txt")
);
properties.put("bill", new DeveloperPaths(
"/Users/BILL/Desktop/fileA.txt",
"/Users/BILL/Desktop/fileB.txt")
);
return properties;
}
public static File FileA()
{
String user = System.getProperty("user.name");
return properties.get(user).fileA;
}
public static File FileB()
{
String user = System.getProperty("user.name");
return properties.get(user).fileB;
}
}
class DeveloperPaths {
public File fileA;
public File fileB;
public DeveloperPaths(String pathA, String pathB) {
fileA = new File(pathA);
fileB = new File(pathB);
}
}
Then, the code to access each path would be identical regardless of developer, for example:
File myFile = Properties.fileA();

Normally paths are configurable entites and should be stored in property file.
Property files has a build in support in java and it uses Properties object for storing that information.
You can read the property file at startup or init (or similar) method of your application and read the proeprties from property file. This will make your configuration dynamic and anyone would be able to change it.
You can create a static method and call it on startup like:
import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;
public class GetProperties {
public static Properties prop = new Properties();
public static void init() {
InputStream inputStream = GetProperties.class.getClassLoader().getResourceAsStream("application.properties");
try {
prop.load(inputStream);
} catch (IOException e) {
e.printStackTrace();
}
}
}

Things like this should be configured externally and/or passed in via parameter, system parameter, or environment variable. Alternatively you could use DI/IoC, but when there's no attached behavior, IMO a config value is plenty.
It's fine to have a hard-coded default, but otherwise stuff like this doesn't belong in code.

recursively delete a folder in java

I already have a code that works, but I don't want it to actually delete the temp folder if possible. I am using the apache fileutils. Also does anyone know how to exclude folders from being deleted?
public class Cleartemp {
static String userprofile = System.getenv("USERPROFILE");
public static void main(String[] args) {
try {
File directory = new File(userprofile+"\\AppData\\Local\\Temp");
//
// Deletes a directory recursively. When deletion process is fail an
// IOException is thrown and that's why we catch the exception.
//
FileUtils.deleteDirectory(directory);
} catch (IOException e) {
e.printStackTrace();
}
}
}

Here's an actually recursive method:
public void deleteDirectory(File startFile, FileFilter ignoreFilter) {
if(startFile.isDirectory())
for(File f : startFile.listFiles()) {
deleteDirectory(f, ignoreFilter);
}
if(!ignoreFilter.accept(startFile)) {
startFile.delete();
}
}
Hand it a file filter set to return true for directories (see below) to make it not delete directories. You can also add exceptions for other files too
FileFilter folderFilter = new FileFilter() {
#Override
public boolean accept(File paramFile) {
return paramFile.isDirectory();
}
};

How about FileUtils.cleanDirectory ? It cleans a directory without deleting it.
You could also use Apache Commons DirectoryWalker if you need some filtering logic. One of the examples on the page includes FileCleaner implementation.

Simple,
Use isDirectory() to exclude it from being deleted.
Refer here: http://docs.oracle.com/javase/1.4.2/docs/api/java/io/File.html#isDirectory()

First ever post, don't consider myself an expert but am stuck with 1.4...
Here's a recursive delete method that works well, deletes all files and subfolders within a parent folder then the parent folder itself, assumes the File being passed is a directory as it is in my case.
private void deleteTemp(File tempDir) {
File[] a = (tempDir.listFiles());
for (int i = 0; i < a.length; i++) {
File b = a[i];
if (b.isDirectory())
deleteTemp(b);
b.delete();
}
tempDir.delete();
}

Transparent and OS-agnostic path handling in Java

I am developing a graphical installer for our application. Since none of the available installer generators meet the requirements and constraints, I am building it from scratch.
The installer is supposed to run on several operating systems, and therefore the path handling needs to be OS-agnostic. I have written the following small utility for this purpose:
public class Path {
private Path() {
}
public static String join(String... pathElements) {
return ListEnhancer.wrap(Arrays.asList(pathElements)).
mkString(File.separator);
}
public static String concatOsSpecific(String path, String element) {
return path + File.separator + element;
}
public static String concatOsAgnostic(String path, String element) {
return path + "/" + element;
}
public static String makeOsAgnostic(String path) {
return path.replace(File.separator, "/");
}
public static String makeOsSpecific(String path) {
return new File(path).getAbsolutePath();
}
public static String fileName(String path) {
return new File(path).getName();
}
}
Now my code is littered with Path.*Agnostic and Path.*Specific calls in many places. As is apparent, this is very error-prone and not transparent at all.
What approach should I take to make the path handling transparent and less error-prone? Do there exist any utilities/libraries that already address this problem? Any help would be greatly appreciated.
EDIT:
To exemplify what I mean, here is some code I wrote a while ago. (Offtopic: Forgive the long-ish method. The code is in initial stages, and will be undergoing some heavy refactoring soon.)
Some context: ApplicationContext is an object that stores the installation data. That includes several paths such as installationRootDirectory, installationDirectory etc. The defaults for these are specified when creating an installer, and hence are always stored in OS-agnostic formats.
#Override
protected void initializeComponents() {
super.initializeComponents();
choosePathLabel = new JLabel("Please select the installation path:");
final ApplicationContext c = installer.getAppContext();
pathTextField = new JTextField(
Path.makeOsSpecific(c.getInstallationDirectory()));
browseButton = new JButton("Browse",
new ImageIcon("resources/images/browse.png"));
browseButton.addActionListener(new ActionListener() {
#Override
public void actionPerformed(ActionEvent e) {
JFileChooser fileChooser = new JFileChooser();
fileChooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);
fileChooser.setAcceptAllFileFilterUsed(false);
int choice = fileChooser.showOpenDialog(installer);
String selectedInstallationRootDir = fileChooser.getSelectedFile().
getPath();
if (choice == JFileChooser.APPROVE_OPTION) {
c.setInstallationRootDirectory(
Path.makeOsAgnostic(selectedInstallationRootDir));
pathTextField.setText(Path.makeOsSpecific(c.getInstallationDirectory()));
}
}
});
}

Or you could introduce 2 new classes:
class OsSpecificPath implements FilePathInterface
{
String path;
OsAgnosticPath toAgnosticPath();
OsSpecificPath concat( OsSpecificPath otherPath );
// from IFilePath
getFile();
... etc
}
and
class OsAgnosticPath implements FilePathInterface
{
String path;
OsSpecificPath toOsSpecificPath();
OsAgnosticPath concat( OsAgnosticPath otherPath );
// from IFilePath
getFile();
... etc
}
each wrap a path however they need to.
each method could then have methods to convert to the other type of path, but instead of a "stringly-typed" solution where everything is a string and can be misused, you'd have 2 strongly typed classes that can't be incorrectly passed around.
Anything that doesn't care about the type of path would use FilePathInterface, anything that needs to operate on specific kinds of paths would use those types specificly. FilePathInterface could hypothetically have both toAgnosticPath and toOsSpecificPath in the interface if really necessary...

Not sure if this is what you're going for, but usually when I need to do something path-related in an OS-independent Java program, I always use Strings to pass paths around instead of Files, and I always do the following two things:
Whenever I am building a String path, I always use / as the file separator
Whenever I use a String path to create a File or save it as text somewhere, I always make the following calls prior to using the path:
String fSep = System.getProperty("file.separator);
String path = ... //might be built from scratch, might be passed in from somewhere
path = path.replace("/",fSep).replace("\\",fSep);
This seems to work well regardless of whether the path gets built on the local machine or if it gets passed in from a different machine on the network with a different OS, provided that I intend to use the path on the local machine. If you plan to pass the path between different OS'es via networking, just be careful that your own code is consistent.
EDIT
Wow... somehow my answer got mangled up and the code formatting didn't work as initially intended...

You never need to convert back to os-agnostic. here are the conversions to os-specific:
public class Path {
private Path() {
}
public static String concat(String path, String element) {
return new File(path, element).getPath();
}
public static String makeOsSpecific(String path) {
return new File(path).getAbsolutePath();
}
public static String fileName(String path) {
return new File(path).getName();
}
}
Your sample:
#Override
protected void initializeComponents() {
super.initializeComponents();
choosePathLabel = new JLabel("Please select the installation path:");
final ApplicationContext c = installer.getAppContext();
pathTextField = new JTextField(
Path.makeOsSpecific(c.getInstallationDirectory()));
browseButton = new JButton("Browse",
new ImageIcon("resources/images/browse.png"));
browseButton.addActionListener(new ActionListener() {
#Override
public void actionPerformed(ActionEvent e) {
JFileChooser fileChooser = new JFileChooser();
fileChooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);
fileChooser.setAcceptAllFileFilterUsed(false);
int choice = fileChooser.showOpenDialog(installer);
String selectedInstallationRootDir = fileChooser.getSelectedFile().
getPath();
if (choice == JFileChooser.APPROVE_OPTION) {
c.setInstallationRootDirectory(selectedInstallationRootDir);
pathTextField.setText(Path.makeOsSpecific(c.getInstallationDirectory()));
}
}
});
}

I would make my own MyFile object that extends or wraps java.util.File. Then make sure all your code uses this object instead of java.io.File. In here you would be doing the OS checks and calling methods to clean up the file name. The rest of your code would be 'clean'.