aspose file tools*
The moose likes Java in General and the fly likes Relation to filesystem when doing file I/O Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Relation to filesystem when doing file I/O" Watch "Relation to filesystem when doing file I/O" New topic
Author

Relation to filesystem when doing file I/O

Russell Bateman
Ranch Hand

Joined: Feb 26, 2008
Posts: 69
I need to find and open a file from my code, but when I attempt it, it's not found. Using Eclipse to figure out where in the world I am (a Unix/Linux guy expects a "current working directory"), I find that



creates a file on the path ECLIPSE_HOME, which has nothing to do with my project location. I assume that if I generated a JAR with a main() inside (in fact, this is in some temporary test code inside a servlet I'm writing), it would create the file in the same directory as the JAR is located? Making the filename "/x.dat" creates it at the root of a Windows filesystem. Sure, I could put in manifest constants that help relate the file to my host's root, but isn't there a relative way?

Then I thought that there might be a way to expect to open a file proximal in some predictable way to the class files, sort of the way properties bundles are related to the package or class. However, I have yet to stumble upon a solution there.

I've Googled this sort of thing, but as you might imagine, the search string is prone to bring up a lot of irrelevant topics. Could someone point me to a tutorial, discussion, documentation, etc. treating this phenomenon. I spent too many years in C, I guess. Now I'm repenting, but I feel like a new guy sometimes when I come up against this sort of thing.

Thanks,

Russ
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19672
    
  18

Officially it's not possible. However, there are a few tricks. I know two of these:
- using ProtectionDomain, as discussed here
- using the class file as a resource: This URL is still not a file. You'll need to modify it:
- cut off the file name
- cut off the package folders
- if the URL is a JAR URL cut off the leading "jar:" part, and the "!" and the JAR file name
- transform the resulting "file:" URL into a File:
Note that this last trick will only work for class loaders that load from the file system. If the class / JAR file is loaded from a web server the URL will start with "http:" or "https:" (possibly prepended with "jar:"), and the conversion to File will fail.

As an example of what these class resource URLs can look like, try the following:


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Russell Bateman
Ranch Hand

Joined: Feb 26, 2008
Posts: 69
Yes, Rob, this worked perfectly. Now I can "abuse" Java file I/O for ad hoc injection of stuff out of a file during early stages of testing and development to my heart's content.

Profuse thanks, my friend,

Russ
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19672
    
  18

Just keep in mind that these trick are not guaranteed to work, especially not if the class isn't loaded from the local file system. I usually use a folder inside System.getProperty("user.home") for that. As an added benefit, each user can then have his/her own settings.
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 542
    
    4

Wow, this is a great topic. Many thanks for the new insights!


Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19672
    
  18

You're welcome.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Relation to filesystem when doing file I/O