Archive

Posts Tagged ‘working directory’

NetBeans Platform – How to handle the working directory problem

November 9, 2010 7 comments

I have written previously about NetBeans Platform, but as a refresher or an introduction to my new readers, it’s a Java based framework for developing rich desktop applications.  A NetBeans Project is comprised of one or more modules.  The code in Module A cannot be accessed by Module B, unless Module B declares a dependency on Module A, and Module A explicitly declares that its code is public.  In this way, code is segmented and encapsulated into logical blocks.

In this example, I’ve created an example project, with three modules – one for the View, Model, and Controller.  (See Wikipedia if that’s not ringing a bell, and then my post about a Java Solar system for a concrete example implementation).

The project can be run either from the main project node,

or by any of the modules:

While in most cases, the behavior will be identical, there is one way in which the manner in which you launch the application matters enormously: relative paths.
The working directory is directly influenced by whether you choose the project or the module to launch with:
# Application launched from the ExampleApplication node:
Current Directory       = /NetbeansExample/ExampleApplication

# Application launched from the View module:

Current Directory       = /NetbeansExample/ExampleApplication/View

Why is this a problem?

Say my View code has a properties file it needs to read in to initialize some code.  Let’s say I store it at
/NetbeansExample/ExampleApplication/View/resources/example.properties
From within my sourcecode I might attempt to do the following:
File f = new File("resources/example.properties");
If I have started the application from the View module, then this will work fine; the current working directory is /NetbeansExample/ExampleApplication/View, as I previously said; thus by tacking on resources/example.properties, we come to a valid file.  If you launch from the main project, you will find that the file doesn’t exist, because /NetbeansExample/ExampleApplication/resources/example.properties does not exist.

How do can we handle this?

The best way I’ve found is through the use of the InstalledFileLocator class, provided by the Netbeans Platform Module APIs.

First, we need to move the .properties file from View/resources to View/release.

Once we have done that, we need to declare a dependency on the Module API in order to use this InstalledFileLocator class.  Right click on the View node and choose Properties,
In the libraries pane, click Add Dependency, and then start typing InstalledFileLocator.
The Module API should appear in the list.  Choose it and click OK.  You should see
From within your view code, you now replace code that looked like
File f = new File("resources/example.properties");

with

File f = InstalledFileLocator.getDefault().locate("example.properties", "net.developmentality.view", false);

where “example.properties” is the path to the file you’re trying to load, relative to the “release” folder, and where “net.developmentality.view” is the package name of the file in which you’re working.  The last argument is described in the Javadocs as:

localized – true to perform a localized and branded lookup (useful for documentation etc.)

I have had no problem leaving it false for my purposes.

Conclusion

I found this workaround after scouring the forums and being led to an FAQ about the LocalizedFileLocator.  It makes the code slightly more messy, but at least it works regardless of how the user or developer launches the application, which cannot be said for the standard way of specifying relative paths.  It is a very hard thing to search for, so hopefully someone running into this problem using NetBeans Platform finds this post.
Advertisements