Board index » jbuilder » Since when FileReader needs absolute pathes in the constructor?

Since when FileReader needs absolute pathes in the constructor?


2005-01-06 12:37:50 AM
jbuilder14
Hello
On Solaris the following snippet worked fine with Java 1.4.1-b21 with
relative pathnames given in the filename (ie. filename =
"../blabla/xy/myfile")
private void readFileList(String filename) {
try {
FileReader fr = new FileReader(filename);
BufferedReader in = new BufferedReader(fr);
}
}
catch (FileNotFoundException ex1) {
}
With Java 1.4.2_01-b06 the same code throws the FileNotFoundException
with a relative pathname.
With an absolute pathname it is still fine, but I need it with
relative pathnames.
Any hint how to make it work again in Java 1.4.2_01-b06 ??
Thanks,
Zoran
 
 

Re:Since when FileReader needs absolute pathes in the constructor?

On 1/5/2005 at 11:37:50 AM, Zoran Pjevic wrote:
Quote
On Solaris the following snippet worked fine with Java 1.4.1-b21 with
relative pathnames given in the filename (ie. filename =
"../blabla/xy/myfile")
:
With Java 1.4.2_01-b06 the same code throws the FileNotFoundException
with a relative pathname.

With an absolute pathname it is still fine, but I need it with
relative pathnames.
AFAIK, relative path names have worked pretty much the same since the
earliest versions of Java. The thing that seems most likely to have
changed is the directory used to resolve the relative paths, which can
change depending on how the program is launched. What mechanism are you
using to launch the programs?
--
Regards,
John McGrath [TeamB]
---------------------------------------------------
Before sending me e-mail, please read:
www.JPMcGrath.net/newsgroups/e-mail.html
 

Re:Since when FileReader needs absolute pathes in the constructor?

On 5 Jan 2005 23:34:03 -0800, "John McGrath [TeamB]"
< XXXX@XXXXX.COM >wrote:
Quote
AFAIK, relative path names have worked pretty much the same since the
earliest versions of Java. The thing that seems most likely to have
changed is the directory used to resolve the relative paths, which can
change depending on how the program is launched. What mechanism are you
using to launch the programs?
Thanks for your hint. Indeed it is not related to the Java version.
The problem was caused by a symbolic link to the executable, which is
used in a script to start the application.
It's a pitty that the apps folder is not the one of the symbolic link,
but the one of the real executable.
Anyway, thanks for your help.
Zoran
 

{smallsort}

Re:Since when FileReader needs absolute pathes in the constructor?

Zoran Pjevic wrote:
Quote

Thanks for your hint. Indeed it is not related to the Java version.

The problem was caused by a symbolic link to the executable, which is
used in a script to start the application.

Ah, symbolic links. I really wish Java would handle those better, since
they are SO useful.
--
Regards,
Lori Olson [TeamB]
------------
Save yourself, and everyone else, some time and search the
newsgroups and the FAQ-O-Matic before posting your next
question.
Google Advanced Newsgroup Search
www.google.ca/advanced_group_search
Other Newsgroup Searches:
www.borland.com/newsgroups/ngsearch.html
Joi Ellis's FAQ-O-Matic:
www.visi.com/~gyles19/fom-serve/cache/1.html
 

Re:Since when FileReader needs absolute pathes in the constructor?

On 1/6/2005 at 4:02:35 AM, Zoran Pjevic wrote:
Quote
The problem was caused by a symbolic link to the executable, which is
used in a script to start the application.

It's a pitty that the apps folder is not the one of the symbolic link,
but the one of the real executable.
The directory used for resolving relative paths will be the CWD setting
when you start the JVM. What that is set to depends on how you start the
program, which is obviously system-specific. Since you start it from a
script, you should be able to do a 'cd' in the script to the directory
that you want to be the base directory for resolving relative paths.
--
Regards,
John McGrath [TeamB]
---------------------------------------------------
Before sending me e-mail, please read:
www.JPMcGrath.net/newsgroups/e-mail.html