This is something that’s been bugging me for a while and I finally confirmed that it’s a known bug in Java–not just some weird thing going on in the Java applications I’ve used.

A bit of background: I’m not a huge fan of the Microsoft way of storing documents. It’s not really Microsoft’s fault (or, at least it wasn’t back in XP days)–I just never have liked programs creating their own folders within my personal data folders. I never really cared to have a “My YouCam Photos” folder or whatever some software maker decided they wanted to add to my documents folder.


Image 1: The Default Windows XP My Documents Folder

Image 2: The Default Windows XP Profile Folder

Image 3: The Default Windows 7 Profile Folder

Image 4: The desktop folder location is a user-configurable option in Windows Vista/7

Image 5: The Issue

Image 6: NetBeans has fixed the issue on its own

In the days of Windows XP, the “My Pictures” and “My Music” folders, along with whatever other folders you choose to create, lived inside the “My Documents” folder (itself being a child of the user’s profile folder). In Vista, Microsoft changed the structure of the User Profile folder. Each of those three folders dropped the “My” prefix and began life directly within the user’s profile folder, along with some other new default folders. The “My” prefix has made a comeback in Windows 7, but the overall structure is the same.

Show the hidden files and folders and then you’ll see the “AppData” folder mixed in there, too. That’s the folder where Windows apps should store their settings data, if they’re going to use files instead of registry entries. For me, that means there’s mostly a bunch of stuff I don’t care about backing up–things I don’t want to transport to a new install or new computer when that time comes. (Temporary internet files and things like that.) Of course, there are a few files there I do want to keep–FileZilla settings with usernames & passwords and stuff like that, so when it’s time to move to a new install, I’ll keep a backup of the folder, just in case.

Since I’m not a fan of the default Windows documents structure, I usually partition my hard drive into two partitions: one for Windows and programs, one for my personal document storage. On my personal partition, I get to organize things my way. One of the main sub-folders I have there is a folder named “Desktop”, which I have configured Windows to use as my official desktop folder. Why? A simple answer is because at times I store things on my desktop that I want to keep when I backup. Usually it’s just a temporary landing place for downloaded files or quickly saved files to be moved to their proper location later. There’s another reason, however, why I find this so convenient. Moving files from folder to folder on the same partition means you’re just updating the location of the file in the file system’s file listing (or however that works). Moving files from folder to folder across partitions means moving the file physically from one part of the hard drive to another. That’s a lot slower and more annoying (especially when you consider that Windows’ default drag & drop preference when dragging from a source on one partition to a destination on another is to copy–not move, which is the case on an intra-partition drag & drop operation).

The issue: So how does Java play into all of this? Well, Java developers sometimes want to store settings for their applications in a folder within the user’s profile directory. It’s the Linux way, and Java tends to do things the Linux way. (As mentioned earlier, Windows’ “AppData” folder servers the same purpose, with some extra separation for data dependent on whether or not it should roam with the user’s profile.) For some reason, Java does not use the Windows environment variable to determine the location of the user’s profile, but instead access a registry key that references the user’s desktop folder. It then takes the parent directory of the desktop and assumes that is the user’s profile folder (assuming the user makes use of the default setup Windows chooses).

Essentially, when a programmer calls the Java command:

System.getProperty("user.home");

Java uses the following idea to determine where my user profile folder is:

PATH_TO_DESKTOP_FOLDER_AS_SET_IN_THE_REGISTRY + "\..\"

This breaks down when the desktop folder has been modified.

So, with my setup, instead of saving settings at:

c:\users\tim\

Java apps tend to save data to:

t:\tim\

In reality, Java apps should save settings to:

c:\users\tim\AppData\Roaming\

or something like that.

To add insult to injury, the Java apps continue to follow the Linux way and use a period at the beginning of the folder name in an attempt to “hide” the folder (as is done on Linux). For Windows users, this simply ensures these folders are listed first in directory listings. (Hiding a folder on Windows is achieved through setting the hidden attribute for the file.)

It looks like NetBeans has addressed the issue for their application, but the root issue remains an unresolved, low priority bug. Somehow I’d bet it would get fixed a lot faster if the mechanism for determining the user’s home path on Linux was wrong.