JAVA is capabable of very much, and I am happy to use it, but one thing that I cannot comprehend is working with file systems. This issue seems to be where the run-everywhere principle seems to fail. Some OS's are case sensitive, others are not. Some point applications to the directory where they are executed, and others point to the users home directory.
I began developing my application in a single operating system, not thinking that file access would be an issue. Now I have discovered that to bundle an application as a jar and also with a set of data directories for runtime use is not a good idea. It's too difficult to ensure that the application will know how to find the directories if it has to use the operating system to do something as easy as find a file by name. Especially, my users should not have to configure at this level.
For my next revision, I'm considering a different approach and wondering what people here might think of it. The approach is to put everything necessary for execution into the jar. I might even take it further, as to make every object a java class, including the bitmap icons. The reason behind this is that up to this point I can't even seem to get consistent access to files that are not classes, even if they are in the jar.
My hope is that if every object is either compiled code or a serialized object, then java-2 will have no reason whatsoever to complain that it couldn't find a file. Then to access objects, assuming they are in the jar, I could uniformly use the package naming style "org.mypackage.myclass" and never use another slash again in my application unless i'm dividing two numbers or trying to print a tab character.
Chris [ January 26, 2007: Message edited by: Christopher Arthur ]
Serializing all your objects into your jar could be a bad idea. What you are saying is... You could deploy the application into Windows, Linux and Mac and if the Mac icons have to be different the user has to request a code change ? Which means you have to maintain seperate jar files for the environments and that beats the whole compile once and run anywhere thing. Also, when you change the JRE from something like 1.3.1 to 1.3.2 you get an error because the value of the serialVersionUID, long variable, changes. This is assuming you didnt serialize all the data once again just because the JRE version has changed.
I would suggest housing the jar file in a lib folder and placing the data files in a "data" folder. You would then have a shortcut that launches the application from the lib folder and passes the data folder path as a runtime parameter. Or this folder path could be saved in a properties file.
I'll try to take a deeper look into the description of the File class, if I ever have time. My application seemed to work fine on Mac, Fedora Linux, and even XP. Ironically, the one system which did not run it properly was Solaris 10.
The advice about serialization is helpful. Otherwise, using abstract path names does not seem to solve the problem that someone has to tell my application where its datafiles are. Either me, as the java programmer, needs to know a priori the executing operating systems, or the user needs to know a priori the location of the datafiles. Thus, no one can use my application without particular approval from sys admin.
While that seems fair in some respects, for my case I am more inclined to curtail my application into an applet rather than to pine for disk access.