Author | Topic: File class |
Wai Iu greenhorn |
posted April 11, 2000 08:02 PM
Under the condition: File f = new File("c:\\large.txt"), is the following statement true or false? The code fails to compile on a UNIX machine, because the directory separator is not correct. I think the above statement is true because the new file object
|
John Wetherbie ranch hand |
posted April 11, 2000 08:13 PM
Its a little trickier than that. The default separator is a /. Underneath the covers you could have a path with \'s in it and the file class will make them /'s. You can set what you want the separator to be. Had to worry about this because our software could be run on NT or UNIX and the users needed to enter filepaths. Unfortunately my book which describes all this and my Unix machine are both at work and I can't get at them until tomorrow. If someone doesn't provide a definitive answer by tomorrow I'll check this out.
|
maha anna bartender |
posted April 11, 2000 10:11 PM
The point to note here is , File f = new File("c:\\large.txt"); Is the following statement true or false? The code fails to compile on a UNIX machine, because the directory separator is not correct. The File class constructor changes the argument string as an abstract path name. Other than that it doesn't check anything at all. It is 'RandomAccessFile' class which checks if the file exists or not/ok or not etc. during construction itself. So just construction of a File class WILL NOT give any compile error ,whatever path-separator/file-separator you give on any platform. But you have to give the escape chars correctly. (i.e) \\ (2 backslashes). During runtime when the File object is used to create other input streams only, the problem come into picture. A runtime IOException will be thrown ,if the file doesn't exist. Also if you see the File class constructors in the Java API there is no specification of any Exceptions thrown. But RandomAccess File throws IOException during construction itself. Also the when you hard-code the pathseparator/fileseparator then that code is not 100% pure java. (i.e) not 100% platform independent. You have to code in a generalized manner. Use the File.separator /System.getProperty("file.separator") methods to get the platform dependent values and then substutute them while coining the file/pathNames and then use it in the construction of File/RandomAccessFile. Simillarly you have to take care of other System related properties from System.getProperty() and use them in appropriate situations. So the answer for the above qstn is false. The code will compile in both above mentioned platforms. [This message has been edited by maha anna (edited April 11, 2000).]
|
Wai Iu greenhorn |
posted April 12, 2000 05:13 AM
Thank! Wetherbie and anna! I have another double about this question. File f = new File("c:\\large.txt") will create a file object f, which is a refernce to a file-large.txt in local drive C. However, If I use UNIX workstation, there is no local drive C there. Does the File f = new File("c:\\large.txt") still work?
|
maha anna bartender |
posted April 12, 2000 10:37 AM
No. I don't think so. Because, UNIX platforms have a single root directory, namely "/". Any 'absolute' path will start with "/" in UNIX and any 'absolute' path in WIN will start with "a:" or "c:" or "d:" etc. ALso note that the 'isAbsolute()' method in File class will act accordingly. This method will return true in WIN, only if the 'path' which is (parent+child) in new File(String parent, String child) starts with c:/a:/d: etc. Simillarly, the same .isAbsolute() will return true in UNIX only if the path(parent+child) starts as "/". So my suggestion is don't hard-code the filename-separator /path-separator/ the root. Instead use File.separator/File.pathSeparator/ the static method File.listRoots() to obtain the platform specific roots, while forming the arguments to the File class in order to work perfectly in platform independent manner. regds [This message has been edited by maha anna (edited April 12, 2000).]
|
GMK unregistered |
posted April 13, 2000 08:48 AM
If I remember correctly creating a file object dose not actually create the file or check if it exists it mearly creates a refrence so it should compile fine.
|
| | |