You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Donald <do...@mad.scientist.com> on 2000/07/05 04:33:38 UTC
Working Directory Woes ... or Not ?
Hi,
Can someone point out where my stupidity lies here :P. I was under the
impression that working directory was impossible to set in java. However
recently I have been playing with
System.setProperty("user.dir","someotherdirectory") and everything seems to
work !!! hmmm The only problems occured when I used relative paths. So what
I did at the begining of my program was resolve any relative paths to
absolute paths. This means you have to resolve some system properties (ie
"java.class.path") and also some internal paths inside the program.
So all my tests seem to work but I have always been under impression this
is impossible and have had several knowledgable people preach at me that it
was impossible. So have I missed something ????
If I haven't missed anything this could be implemented in ant no ? Then we
would no longer have to set ant home because everything could be done via
class-loaders and this no ? (Except for rare occasions when need to change
security manager, connection factory or whatever multiple times for
different tasks).
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Working Directory Woes ... or Not ?
Posted by Russell Gold <ru...@acm.org>.
At 10:33 PM -0400 7/4/00, Peter Donald wrote:
>If I haven't missed anything this could be implemented in ant no ? Then we
>would no longer have to set ant home because everything could be done via
>class-loaders and this no ? (Except for rare occasions when need to change
>security manager, connection factory or whatever multiple times for
>different tasks).
I have now realized that I don't understand what you mean by your reference to class loaders. AFAIK, the primary purpose of the working directory is to serve as a starting point for file paths. Class loaders work a bit differently, and the default one appears to work in a system-dependant fashion. Note: there is also a java.class.path property, but it is not clear what the effects are of changing it. Perhaps someone with a copy of the Java language spec knows...
------------------------------------------------------------------------
Russell Gold | "... society is tradition and order
russgold@acm.org (preferred) | and reverence, not a series of cheap
russgold@netaxs.com | bargains between selfish interests."
rgold@thesycamoregroup.com | - Poul Anderson, "Iron"
Re: Working Directory Woes ... or Not ?
Posted by Louis Tribble <lo...@metamata.com>.
Russell Gold wrote:
>
> At 5:00 PM -0400 7/5/00, Louis Tribble wrote:
> >> At 10:33 PM -0400 7/4/00, Peter Donald wrote:
> >> >Hi,
> >> >
> >> >Can someone point out where my stupidity lies here :P. I was under the
> >> >impression that working directory was impossible to set in java. However
> >> >recently I have been playing with
> >> >System.setProperty("user.dir","someotherdirectory") and everything seems to
> >> >work !!! hmmm The only problems occured when I used relative paths. So what
> >> >I did at the begining of my program was resolve any relative paths to
> >> >absolute paths. This means you have to resolve some system properties (ie
> >> >"java.class.path") and also some internal paths inside the program.
> >
> >Some comments:
> >
> >1. Doing this with user.dir is effectively using system properties
> >as a global constant pool (three whacks with a ruler).
>
> But isn't that what system properties are???
I guess I should have said global _variable_ pool :-) I guess
my chief objection is a design one. It's a weak typing rather
than strong typing, and its implicit dependency rather than
explicit dependency.
When redefined from the command line, I have less objection,
by the way. My main reservation in that case is that I know
of no requirement that the VM or native code honor it.
> I think it is likely that changing the property on the fly is not guaranteed to be safe; however, it should always be safe to establish it on the java command line:
>
> java -Duser.dir="/my/proper/directory" ProgramWhichCares
>
> as this setting will happen before any code copies it. The chief benefit of this would be to eliminate the need for the platform-specific batch files when starting a forked java task. This should work in any version of the JDK.
>
> ------------------------------------------------------------------------
> Russell Gold | "... society is tradition and order
> russgold@acm.org (preferred) | and reverence, not a series of cheap
> russgold@netaxs.com | bargains between selfish interests."
> rgold@thesycamoregroup.com | - Poul Anderson, "Iron"
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Louis Tribble louis@metamata.com
Metamata, Inc. http://www.metamata.com
Tools for serious Java developers. +1 510 796 0915
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Re: Working Directory Woes ... or Not ?
Posted by Russell Gold <ru...@acm.org>.
At 5:00 PM -0400 7/5/00, Louis Tribble wrote:
>Russell Gold wrote:
>>
>> At 10:33 PM -0400 7/4/00, Peter Donald wrote:
>> >Hi,
>> >
>> >Can someone point out where my stupidity lies here :P. I was under the
>> >impression that working directory was impossible to set in java. However
>> >recently I have been playing with
>> >System.setProperty("user.dir","someotherdirectory") and everything seems to
>> >work !!! hmmm The only problems occured when I used relative paths. So what
>> >I did at the begining of my program was resolve any relative paths to
>> >absolute paths. This means you have to resolve some system properties (ie
>> >"java.class.path") and also some internal paths inside the program.
>
>Some comments:
>
>1. Doing this with user.dir is effectively using system properties
>as a global constant pool (three whacks with a ruler).
But isn't that what system properties are???
>
>2. A lot of code, including JDK code, puts the value of the property in a
>static initializer, so you which value you get may depend on which class
>loads first.
>
>3. Given 1 and 2, if current directory redirection is really required,
>why not create a CurrentDirectory singleton to make the magic explicit,
>documented, and predictable?
Because the current directory is used by the io package, which won't know about your CurrentDirectory class. As a result, certain programs need to run in specific directories to work properly.
>
>4. exec is unaffected (this is where the current directory has usually
>mattered to me). I understand JDK 1.3 adds a way to set the current
>directory when exec-ing.
>
>5. Never having seen JDK source, I also can't rule out some bits of
>native library code (either JDK or extensions) getting the value from a
>source unaffected by setting the user.dir property.
>
I think it is likely that changing the property on the fly is not guaranteed to be safe; however, it should always be safe to establish it on the java command line:
java -Duser.dir="/my/proper/directory" ProgramWhichCares
as this setting will happen before any code copies it. The chief benefit of this would be to eliminate the need for the platform-specific batch files when starting a forked java task. This should work in any version of the JDK.
------------------------------------------------------------------------
Russell Gold | "... society is tradition and order
russgold@acm.org (preferred) | and reverence, not a series of cheap
russgold@netaxs.com | bargains between selfish interests."
rgold@thesycamoregroup.com | - Poul Anderson, "Iron"
Re: Working Directory Woes ... or Not ?
Posted by Louis Tribble <lo...@metamata.com>.
Russell Gold wrote:
>
> At 10:33 PM -0400 7/4/00, Peter Donald wrote:
> >Hi,
> >
> >Can someone point out where my stupidity lies here :P. I was under the
> >impression that working directory was impossible to set in java. However
> >recently I have been playing with
> >System.setProperty("user.dir","someotherdirectory") and everything seems to
> >work !!! hmmm The only problems occured when I used relative paths. So what
> >I did at the begining of my program was resolve any relative paths to
> >absolute paths. This means you have to resolve some system properties (ie
> >"java.class.path") and also some internal paths inside the program.
Some comments:
1. Doing this with user.dir is effectively using system properties
as a global constant pool (three whacks with a ruler).
2. A lot of code, including JDK code, puts the value of the property in a
static initializer, so you which value you get may depend on which class
loads first.
3. Given 1 and 2, if current directory redirection is really required,
why not create a CurrentDirectory singleton to make the magic explicit,
documented, and predictable?
4. exec is unaffected (this is where the current directory has usually
mattered to me). I understand JDK 1.3 adds a way to set the current
directory when exec-ing.
5. Never having seen JDK source, I also can't rule out some bits of
native library code (either JDK or extensions) getting the value from a
source unaffected by setting the user.dir property.
Hmmm, I hope the above doesn't sound too much like I got up on the
wrong side of the bed today...
Regards,
Louis Tribble
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Louis Tribble louis@metamata.com
Metamata, Inc. http://www.metamata.com
Tools for serious Java developers. +1 510 796 0915
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Re: Working Directory Woes ... or Not ?
Posted by Russell Gold <ru...@acm.org>.
At 10:33 PM -0400 7/4/00, Peter Donald wrote:
>Hi,
>
>Can someone point out where my stupidity lies here :P. I was under the
>impression that working directory was impossible to set in java. However
>recently I have been playing with
>System.setProperty("user.dir","someotherdirectory") and everything seems to
>work !!! hmmm The only problems occured when I used relative paths. So what
>I did at the begining of my program was resolve any relative paths to
>absolute paths. This means you have to resolve some system properties (ie
>"java.class.path") and also some internal paths inside the program.
>
>So all my tests seem to work but I have always been under impression this
>is impossible and have had several knowledgable people preach at me that it
>was impossible. So have I missed something ????
>
>If I haven't missed anything this could be implemented in ant no ? Then we
>would no longer have to set ant home because everything could be done via
>class-loaders and this no ? (Except for rare occasions when need to change
>security manager, connection factory or whatever multiple times for
>different tasks).
My question is: who told you that it was impossible? The only way that Java knows what its home directory *is* by reading the user.dir property. What you have done is exactly right and really out to be an easier (and relatively platform independant) way to implement the "java" task - which in this case would NOT probably be a subclass of the exec task. Of course,
------------------------------------------------------------------------
Russell Gold | "... society is tradition and order
russgold@acm.org (preferred) | and reverence, not a series of cheap
russgold@netaxs.com | bargains between selfish interests."
rgold@thesycamoregroup.com | - Poul Anderson, "Iron"