RFE for Java runtime environment to support chdir() [or similar]
appended.

Part 1/2:

 >Subject: trying to change directory in java
 >From: Alec Muffett <  xxxxx@xxxxx  >
 >Date:  customer  Apr 1997 20:19:59 +0100
 >
 >The attached below is an attempt we've been doing to implement some
 >sort of chdir mechanism in Java; we're not certain if that is even
 >possible (perhaps the JVM thinks directories are too complex a notion
 >to be portable?) but some of the documentation we've been reading
 >seems to imply that setting the "user.dir" element of System
 >properties should have an effect on the current working directory of
 >the running VM...
 >
 >However - it don't work.
 >
 >Could someone wiser than I possibly please comment on why this is
 >failing, and whether we're barking up the wrong tree?
 >
 >Thanks,
 >        - alec
 >

 [DELETIA]


Part 2/2:

 Alec Muffett <  xxxxx@xxxxx  > writes:
 >Roland Schemers <  xxxxx@xxxxx  > writes:
 >
 >>>>   // set the properties for user.dir
 >>>>   newprops.put("user.dir", "/etc");
 >>>>   System.setProperties(newprops);
 >>
 >>You are barking up the wrong tree :-) All setProperties does is
 >>replace one Properties  customer  with another.
 >
 >We suspected as much, but some aspect of the documentation we were
 >reading seemed to imply that it might work, and there didn't seem to
 >be any alternative.
 >
 >
 >>It doesn't do anything
 >>special. As far as I know, there is no "chdir" in the standard java.*
 >>APIs. I don't know if this was intential or not.
 >
 >Possibly intentional, after all the language is designed to target the
 >lowest common denominators of hardware (Game-Boys?) which probably
 >don't have directories, and it would probavly interfere with the
 >threading mechanism.
 >
 >As it is it looks like we have to write error-prone code that has lots
 >of hardwired pathnames in it if we want to do things "The Java Way" (TM).
 >
 >
 >It wouldn't be so bad even, if (say) one of the systems properties was
 >a string which got prefixed onto the start of all filename fetches for
 >you automatically, as part of java.io.*.
 >
 >Admittedly, you'll thrash the kernel inode cache a lot when you start
 >traversing the four-layer-deep, multiply-128-directory-wide tree of
 >some 35,000 subdirectories and 250,000 files; but at least the code
 >will be simpler; anyway, that's what you have to expect from
 > customer -oriented programs which hide functionality from you.
 >
 >Remind me to tell you the story sometime of the student who implemented
 >an array class using singly-linked-lists, remalloc(), and linear
 >searching, when someone used it to create a 100,000 element array and
 >qsort()ed it on the university mainframe back in '89.
 >
 >
 >PS: *NO*, I do not want to have to create a superclass of my own to
 >provide this functionality; as a serious applications/system programmer,
 >I want it to be there, for me, when I am coding, and I do not want to
 >have to overlay system-supplied functions in order to get them provide
 >functionality that's been in every major O/S since 1982.
 >
 >Is anyone out there from Javasoft, listening?
 >
 >   - alec
 >
 >ps: this functionality [traversing enormous directory structures] 
 >is NOT an unreasonable requirement for an application
 >program, as anyone who briefly considers the operation of the Unix
 >"find" command and how it works, will realise.
 >
 >Now, wouldn't it be nice if Java was suitable for writing generic
 >forms of some really useful tools...
  xxxxx@xxxxx   10/15/04 20:41 GMT

N/A

This needs co-operation from the runtime (if we chdir() the VM, then the
IO libariries would get transparently updated). At this point it is not
clear what this means for the VM (which opens its libraries and classes
with relative path names). Assigning to runtime so the VM can be made
chdir() safe first before we add a trivial API to do this.

  xxxxx@xxxxx   1997-11-07

This is primarily an I/O architecture issue, not a runtime issue.

Introducing a straight chdir-like call will add one more piece of mutable
global state, i.e., one more way for a multithreaded program to go awry, as
well as introduce incompatibilities.  At present, for example, an instance of
java.io.File that contains a relative pathname always has the same meaning.
With a chdir call, this invariant would no longer be true.

Having said that, the efficiency problem for a certain small class of systems
programs is quite real.  This could be addressed in a future release by
introducing the notion of a "hot" working directory as a perforamnce hint to
the internal filesystem interface.  This would require tweaking the
java.io.File API so that relative pathnames are always resolved against the
value of the "user.dir" property.

--   xxxxx@xxxxx   11/10/1997
Much of the cause for the original requests for chdir were made moot
by the addition of Runtime.exec methods taking a current directory argument
in JDK 1.3.  If you really need some Java code running in another directory,
simply start up another JDK process using ProcessBuilder or Runtime.exec().
Posted Date : 2006-01-21 09:44:31.0

From
http://lwn.net/Articles/164887/
(note especially the word "race-free")

Ulrich Drepper, the maintainer of glibc, isn't just trying to add a system call; his proposal creates eleven of them. They are all variants on current file operations: 

    int mknodat(int dfd, const char *pathname, mode_t mode, dev_t dev);
    int mkdirat(int dfd, const char *pathname, mode_t mode);
    int unlinkat(int dfd, const char *pathname);
    int symlinkat(const char *oldname, int newdfd, const char *newname);
    int linkat(int olddfd, const char *oldname, 
               int newdfd, const char *newname);
    int renameat(int olddfd, const char *oldname,
                 int newdfd, const char *newname);
    int utimesat(int dfd, const char *filename, struct timeval *tvp);
    int chownat(int dfd, const char *path, uid_t owner, gid_t group);
    int openat(int dfd, const char *filename, int flags, int mode);
    int newfstatat(int dfd, char *filename, struct stat *buf, int flag);
    int readlinkat(int dfd, const char *pathname, char *buf, int size);


 The pattern should be clear by now: each new system call extends an existing one by adding one or more "dfd" (default file descriptor) arguments. In each case, the new argument indicates a directory which is used instead of the current working directory when relative path names are provided. These calls can help applications work their way through directory trees in a race-free manner, and are also useful for implementing a virtual per-thread working directory.
Posted Date : 2006-01-21 09:46:16.0

Ruby is another application platform that embraces threading and has a
process-wide chdir.  In the latest ruby release, a warning is issued if
chdir is used in a program with more than one active thread.
Posted Date : 2006-01-21 09:47:08.0

Paul Eggert wrote:

Jim Meyering wrote:

> It's really too bad that there is no system interface that allows a
> program to save and restore the current working directory reliably

Actually, there is such an interface: it's the AT_FDCWD interface
of Solaris 9 and later.  (Great minds think alike, huh?)  It comes
with new system calls like openat and fstatat.
Posted Date : 2006-01-21 09:48:09.0

This feature can be interpreted in two ways: chdir could change the current
working directory of the process containing the JVM, causing all threads to
change simultaneously, or to provide a more "virtual" per-thread concept of
current directory, which could conceptually be a ThreadLocal.  This would
be merely a convenience for building up complete path names to pass to the
underlying operating system API.  This is how the current directory works
in Emacs - it's just a variable, but a magic one that can have buffer-local
values.  Emacs buffers are kinda sorta like Java threads in this sense.
Such an implementation would offer convenience and safety.
Having each thread with a ThreadLocal current directory gives a programmer
experience familiar to old Unix greybeards, except that Threads replace Processes.
Posted Date : 2006-01-21 09:49:54.0

Here are my personal recommendations:
- It is contrary to the safety-first principle of Java to have a chdir that
  affects all threads in the JVM.  
- We should not try to solve the "current directory locked on Windows" problem.
- A chdir that has inheritable thread local semantics is much safer and
  clearly useful, but it is quite an implementation challenge.  A high-quality
  implementation might look completely different on Solaris, Linux, and Windows.
- If we implement chdir, consistency would seem to demand we implement
  mutable versions of other per-process state such as environment variables.
- We should accept that Java is now a very stable platform and that it may
  be too late to add global mutable process state.  Immutability is in itself a feature.
Posted Date : 2006-01-21 09:55:42.0

First of all, there seems to be some confusion about the purpose of "user.dir".  "user.dir" should be viewed as a read-only property; portions of our implementation of the jdk assume that "user.dir" will not change.  It is possible that other implemenations may not make this assumption so it would be difficult to restrict the expected use of this system property in the spec. Secondly, although it is possible to write JNI code which makes a native call to change the working directory for the entire process, this is not something that we can prevent.  However, we consider this an unsafe operation and do not recommend its use. 
 
Many SDN comments request the ability to launch a new process in a different directory. It seems that a number of scenarios are addressed by some recent additions. In jdk1.3 (Kestrel) we introduced the following method: 
 
    public Process exec(String[] cmdarray, String[] envp, File dir); 
 
where "dir" is the working directory of the process to be launched.  In jdk5.0 (Tiger) we added ProcessBuilder which allows the user to manage a collection of process attributes including the working directory for new processes. 
 
It would be very difficult for us to modify the existing behaviour of java.io.File without introducing compatibility problems.  For this class, we can probably examine the current specification and modify it to more clearly describe the current behaviour with respect to "user.dir". 
 
With respect to the request for chdir-like functionality within the current VM, we are considering a few possible solutions.   
 
  - A thread-local variable representing the current working directory. 
 
  - A true process-wide "chdir" which would probably required careful 
    specification and recommendations for its use, especially for 
    multi-threaded apps.  We would also have to scrub the existing jdk code 
    for any sections that would be sensitive to such a change, even when 
    properly used by the application.  
 
It is possible that we may decide on another solution or even conclude that there is no solution which will achieve adequate safety and compatibility. Our team is resolved to investigate these possibilities for the next feature release, jdk7 (Dolphin).
Posted Date : 2006-02-02 19:55:55.0

In January 2006 we were able to identify only one potential customer who could did not find any of our existing solutions satisfactory.  After getting a complete description of their constraints, we determined that one of the design solutions outlined above would solve most of their problem.  This feature was eventually shelved because that customer had a workaround and when they learned that implemention on the jdk side would still not solve their windows problem (due to constraints imposed by that OS), they lost interest.  

Since that time, no further customers have come forward or were otherwise identified.  Given the huge amount of work required to implement this feature, our limited resources, the apparent little customer demand, and the compatibility and safety concerns of existing proposals, we have decided to close this RFE as "will not fix".
Posted Date : 2008-08-18 22:41:59.0

Acknowledging that a global VM chdir() call is
probably extremely evil for all sorts of reasons,
perhaps it would suffice to leave the semantics of
File alone (it is not so bad really, except for
possibly performance); and just introduce an
optional cwd parameter to the System.exec() suite
(where it is otherwise completely impossible to
simulate without a wrapper shell script!)

This is a definite problem.  I am writing a
shell/desktop which is supposed to be capable
of loading third party classes (java apps).
My desktop starts up with its current directory
( "\desktop" ) preset and unchangeable,
when it attempts to load an app in another
directory ( "\appdir" ), it may fail since the app
may assume that the current directory is it's own
directory and attempt to load data or images.
This problem could occur any time that one java
application attempts to load another application
or class.
If Sun/javasoft does not tend to this problem,
many people will start writing proprietary native
code to get around it.  Soon nobody will be
adhering to the notion of 100% pure java.
 - Possibilities: -
How about having a separate modifiable "current
directory" for each thread.
If you do not want to add the ability to change
the the current directory, then perhaps you should
remove the whole concept of a "current directory".
It would be nice if you could at least set the
current directory when launching or executing
the JVM.  Perhaps you could add a new command
line parameter.

Since it is possible to change user.dir,
it should have (at least) some effect,
and any limitations should be clearly
documented so save programming/debugging
time. Basically I can understand and
agree with the "Evaluation by
xxxxx@xxxxx 11/10/1997", but my main
complaint is exactly the "Comment from
jglick Thu Jan 29 13:33:03 PST 1998". 
Please "introduce an optional cwd
parameter to the System.exec() suite"
into the 1.2 release. Having to write a
lot of _system_dependent_ wrapper 
scripts is really NOT 100% pure Java!

This is really bad - it keeps me from being able to
run a single JVM in my Java server environment.  I'd like
to use thread groups to load seperate Java applications
into a single JVM - because our system could be running
MANY apps.  This is so foolish - it makes it hard to
treat Java as a 'real' OS abstraction.  See 
http://www.interstice.com/~kevinh/projects/javafarm
for more info.

There is an area where this facility is really important, and another where is
would be a great convenience.
The *really important* area is in setting the cwd of a created process. Without
this facility, the class of programs one might call "scripting" is
significantly hampered. Java is a good way to recast "shell scripts"
in a platform-independent way. But without being able to set the cwd of
executed "commands", some jobs just can't be done. (Notice how
frequently "cd" is performed in existing scripts -- it must be
useful!)
The *great convenience* area is in changing the cwd for use in resolving
relative paths in the current process. Obviously, the cwd is *used* by Java
runtime in performing various File functions, it is frustrating that it can't
be manipulated. (Interestingly, setting the property "user.dir"
*does* affect the outcome of File.getAbsolutePath().) It's often possible to
work around this shortcoming, but there are times when it's not: when invoking
a 3rd-party Java class which references a file by relative reference and would
like explicit control of which directory is accessed.
My vote: in agreement with jglick, definitely provide a way to set the cwd in
an exec'd process. I would also support having a way to change the cwd in the
local process. This is one of those "empower the programmer" vs.
"protect her from herself" issues, and I generally prefer
empowerment.

It is precisely because the VM depends on all sorts
of ways on the current working directory that a
straightforward "chdir" call is important.
This isn't a question of making applications a
little more efficient, it's a question of letting
me write Java development tools that behave "right".
If you don't want to provide a global "chdir" call,
then the compiler, for example, should require
absolute pathnames for everything (and it should
work properly with absolute pathnames, the 1.2b3
compiler doesn't).  But the
current situation where all sorts of runtime state
depend on the working directory of the process
but the working directory cannot be changed is
the worst of both worlds.
If, in addition, you want to introduce a notion of
a "per thread working directory" or "per thread
pathname prefix", that's fine.
As a separate notion, it is also really important
to be able to set the working directory of newly
created processes.  This should be separate from
setting the working directory of the current
process destructively before the exec
(although it isn't in all operating systems).

Here are a couple of workarounds I am using that may be helpful:
1) Use this method to change the working directory for a call to
   Runtime.exec() on Windows NT and Unix. It pops up a command prompt
   window on Windows if a command-line program is launched. This can
   be minimised if launched using "start /min /wait <command>".
public static Process execute( String command, java.io.File directory )
  throws java.io.IOException
{
  if ( System.getProperty( "os.name" ).startsWith( "Windows
NT" ) )
    return Runtime.getRuntime().exec( new String[] {
      "cmd /c " + directory.getAbsolutePath()
                  .substring( 0, directory.getAbsolutePath().indexOf(
":" ) ) +
      ": && cd " + directory.getAbsolutePath() + "
&& " + command } );
  else  // assume Unix
    return Runtime.getRuntime().exec( new String[] {
      "/bin/sh", "-c",
      "cd \"" + directory.getAbsolutePath() + "\";
" + command } );
}

2) Use this class instead of File if using a relative file path and
   manipulating the system property user.dir. This class treats a
   relative file path as relative to the current value of user.dir.
   (Does not address multiple thread issues!)
import java.io.File;
public class RelativeFile extends File
{
  public RelativeFile( String path ) {
    super( path ); }
  public RelativeFile( String path, String name ) {
    super( path, name ); }
  public RelativeFile( File dir, String name ) {
    super( dir, name ); }
  public boolean exists() {
    return new File( getAbsolutePath() ).exists(); }
  public boolean canWrite() {
    return new File( getAbsolutePath() ).canWrite(); }
  public boolean canRead() {
    return new File( getAbsolutePath() ).canRead(); }
  public boolean isFile() {
    return new File( getAbsolutePath() ).isFile(); }
  public boolean isDirectory() {
    return new File( getAbsolutePath() ).isDirectory(); }
  public long lastModified() {
    return new File( getAbsolutePath() ).lastModified(); }
  public long length() {
    return new File( getAbsolutePath() ).length(); }
  public boolean mkdir() {
    return new File( getAbsolutePath() ).mkdir(); }
  public boolean renameTo( File dest ) {
    return new File( getAbsolutePath() ).renameTo( dest ); }
  public boolean mkdirs() {
    return new File( getAbsolutePath() ).mkdirs(); }
  public String[] list() {
    return new File( getAbsolutePath() ).list(); }
  public boolean delete() {
    return new File( getAbsolutePath() ).delete(); }
}

What about having user.relativedir which is resolve to a user.dir when the VM
is started. Then if user.dir changed update user.relativedir to keep the same
directory when resolved using user.dir. Also all relitave directory should be
based off user.relativedir so that if user.dir changed the all the relative
directories would still work. This would solve the problems with relative
directories and allow user.dir to be changed as well.

BenPeacock is wrong.  Forking off a shell that
executes a cd command has not impact on the
working directory of the JVM.

I do agree that chdir the complete VM would be
undesirable.
However, I do not follow the argument about one
more piece of mutable global state.  If it is desired that File objects remain
immutable in the
sense that even those constructed with a relative
pathname always refer to the same file, then the relative pathname must be
resolved against the current user.dir at construction time.  Whether
or not this is desirable or not, I don't know,
but why is this seen as a problem?
Also, has this been fixed in 1.2, pardon me
Java2?  Note that Mac's MRJ apparently interprets
changes in user.dir.
  - Godmar

Here's my current workaround. In my Java Shell program
(http://www.vmeng.com/beard/JShell/JShell.sit.bin) I simply replace the
standard File, FileInputStream, FileOutputStream, and RandomAccessFile classes
with versions that always expand relative pathnames relative to the
"user.dir" property before calling native methods. This works because
each tool that runs in my system runs in its own thread group (aka ToolContext),
 which provides a context for I/O streams, and properties. Each tool also gets
its own copy of the venerable System class, so it has unique static variables
for System.in/out/err/properties. When a new tool runs, it gets a copy of the
properties of its parent (usually a shell). Thus, if a particular shell running
in my system changes its "user.dir" property, only it, and newly run
child tools see the change.

By the way, my aforementioned workaround is not necessary on the Mac OS Runtime
for Java (MRJ) because "user.dir" is live. The native methods call
System.getProperty() to determine the current working directory, mainly because
there's really no such thing as a current working directory on the Mac OS
(unless you count SetVol/GetVol which are essentially deprecated).

Another comment: make the submission form
bigger.  It's almost impossible to edit anything
in here.  I just read what I submitted a few minutes ago; people must think I'm
a total dyslexic.

I believe adding general chdir functionality to Java would be a mistake. chdir
can be an effective optimization in some cases, but it is _very_ frequently
abused. Lazy programmers use the "current directory" to pass a path
name around implicitly. This is a hack, and it fails miserably when two
independent applications are running in the same VM & sharing the same
threads.
Java should stay pure in this regard.
System.exec() is the only exception to this rule -- some legacy applications
require a specific current directory.

This same bug/RFE is covered in may other bug reports
4156278 seem to be the most discussed and most voted
for.  4156278 also provides a list of related bug reports.
Both this and 4156278 are in the top 25 RFE's, but they
are separate reports they don't carry a combined vote
tally.

The most annoying part of this entire issue is the
mismatch between the use of the current "user.dir" system
property in the construction of absolute pathnames
from relative ones and the use of the original value
of "user.dir" when resolving relative pathnames for all
other java.io.File operations.  Could you at least make
the java.io.File class internally consistent in this regard?
That would certainly make it easier for programmers to
understand what is happening in the system.
A note in the java.io.File documentation that changing
the "user.dir" system property won't affect (except maybe
on MRJ?) the resolution of relative pathnames -- or a
mention that the effects are VM dependent would also be
useful.

Another solution would be to enable the installation of a
file-name resolver, much like a Factory object, so that a
Java shell can intercept before a given file is opened. 

What is really needed is way to specify working directory
for subprocesses. Inside java application everything can be
done by hand and should be done so (having static variable
for all VM which is randomly changed by various threads is
not a good idea).

I am writing a native implemetation for unix that change
directory
separately for native threads. This is of course a
workaround to the 
current immaturity in java, and generatres big
incompatbility to
diffrent thread models. This is a part of making a runtime
VM-demon for all
java execution... wich makes java a lot faster, and provides
other runtime bennefits I might add.. (...the bennefits from
smalltalk)

I have a .jar file app which sets the current working 
directory to the directory that the jar file is physically 
located in, and it works perfectly.  (As long as the jar 
file is the ONLY thing in the class path)  Here is the line 
of code:

System.setProperty( "user.dir", new File( new File( 
System.getProperty( "java.class.path" ) ).getAbsolutePath
() ).getParent() );

The reason for having two nested File constructors is to 
get the ABSOLUTE path from the RELATIVE inner one, and use 
this to construct an absolute File reference to obtain the 
parent directory from.

I tried this with only a single File constructor and it 
worked fine on Windows systems but failed on *nix systems, 
must be a different implementation of how File resolves 
path names under the *nix JVM.

3 years and counting...

Its now 2001. Is sun aiming for a 5 year turnaround?

Bravo!

As an interim solution you might want to try
a workaround using JNI (tested unter Linux 2.2.13 with
JDK 1.3) <a
href="http://www.klawitter.de/java">http://www.klawitter.de/java</a>.

I encountered the need for a chdir(2) when I wanted to run 
Jakarta Tomcat with the right "conf" directory under the 
current one. I can build a full path name of the 
configuration file from the current directory + the 
relative path from here, but relative paths read from the 
xml file are still broken.

I think the correct way of handling this is for the runtime
to perform its own "current working directory" handling (via
pathname canonicalization and pathname manipulation) and to
make "chdir" a per-thread property.  It's either that, or
Java should stop accepting relative pathnames altogether.

I suggest that a "Context" class be introduced to the IO API. One could then have many contexts, i.e. current directories and calling chdir on some of them would not make global changes in the system. One could then pass such a context as a parameter to a File constructor.
When not supplying a context (in all the code since now) would assume using a default, ummutable one.
Any comments ?

The issue of launching a new process in a specified 
directory having been fixed, only the efficiency issue 
remains. In my opinion this can be addressed without 
changing the public API at all. The JVM can monitor the use 
of file paths and when something appears more than a few 
times, consider making it the working directory. Keeping 
the process hidden has several advantages:
1) It can also track usage by the JVM itself (class loaders 
etc).
2) On Windows it could manage separate current directories 
per drive, if that was worth doing.
3) It is equally easy to adapt to an OS without a notion of 
current directory or where that property is a per thread 
attribute.

Er, mthornton said:

> The issue of launching a new process in a specified 
> directory having been fixed

Has it? How?

(response to petermantell)
JDK 1.3 added the following method to Runtime:
public Process exec(String command,
                    String[] envp,
                    File dir)
where 'dir' specifies the working directory of the new 
process.
             throws IOException

I would like to vote AGAINST this "enhancement", but the
voting system does not seem to support this?

Please add a feture to vote AgainsT. ChDir is quite a hack
for currently running process, so I would like to vote
against. W/  Runtime.exec(String, String[], File) added
there is no clear reason why ChDir should be implemented and
how multi-thread programs could make use of it.

With threads, chdir is dangerous unless every thread has its own private inherited default directory. Instead of opening that can of worms, and carrying needless overhead rarely used, perhaps just let user maintain his own default dirs, and merge them with the relative filenames as needed.

I'm another vote against.

If you need to simulate chdir, it is trivial to do:
System.setProperty("user.dir", newdir);
//...
File file = new File(filename).getAbsoluteFile();

Just get in the habit of never, ever using relative Files - the user can
always specify -Duser.dir=somewhere on the command line, which will
raise nine different flavors of hell if you use relative Files.

Sun could change File to be absolute in the constructor, but I don't see
a dire need for it when you can specify it yourself.

-- <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>

There are times when being able to do a chdir() would be 
nice, and they are when integrating with particularly crufty 
pieces of native code.  The rest of the time (and not just in 
Java), it is far easier to not rely on the working directory at 
all.

Contrary to the evaluation from 11/10/1997 as posted above, 
if this is implemented, it ought to change the real working 
directory for the process on those operating systems where 
such a thing exists.  Introducing an API method called chdir() 
that does *not* do so is dangerously misleading, since this 
piece of process state is externally visible on most operating 
systems.

Opposed.

However, the suggestion by igarn seems to address all the
undesireable effects one could get from a plain "chdir()"
implementation.

Happy 7th birthday, RFE.

I'd like to second cdsmith1's comments on 11/9/2003 in that the current working directory is process state, so you can't just "fake" it.  One more little example where it is nice to have.  Say you have a server running 50 java programs.  One of them has gone nuts.  You do "top", and you see processes named "java" all the way down the page.  Same with ps.  How can you tell them apart?  current working directory could be the thing.

To do this now means you have to write a shell script (and a batch file, assuming you also want to run on Windows) wrapper.  Maybe with an added step of reading a configuration file to find out what the directory should be.  Doesn't this seem like a step backwards?  I thought I was rid of DOS batch scripts around 1990, but then Java came and I was stuck writing batch files again.  Or you could write some trivial JNI code.

What to do with relative files?  You can leave them alone, so they are now pointing somewhere else.  You can patch them up and make them absolute.  You can add classes for absolute and relative files.  Whatever happens, I really don't care.  It's an implementation detail, just document it and I'll live with it.  Surely somebody could come up with something acceptable in 7 years?!? (obviously Sun can't, and don't call them Shirley).

What about systems that don't support chdir?  Fail silently, throw and exception, whatever.  Just document it.

After years of development it's time to start filling in these little gaps.   This should have been done years ago.

Look at this:

[code]
    String rootname = "D:\\tmp";
    String filename = "testfiles.txt";
    String rootfilename = rootname + File.separator + filename;
    String expected = "this is a test";
    writeToFile(expected, rootfilename);
    System.setProperty("user.dir", rootname);
    File file = new File(filename);
    assertEquals(rootfilename, file.getAbsolutePath());
    File rootfile = file.getAbsoluteFile();
    assertTrue(rootfile.exists());
    assertTrue(file.exists());
[/code]

Does not this validate the case for fixing this at last... 8 years later!

Absolutely opposed to the idea of changing the runtime for the JRE.  It makes function calls like myFile.	getAbsolutePath(".") worthless and introduces a lot of bugs in old code. (Unless you WANT to create a sequel to the Millineum bug...).  Consider that a very small percentage of the code running in most JVMs is your own...

I applaud the ability to set dir of the JVM on startup and the ability to set the path on a System.Exec(), though.

The Context idea is an interesting one, but lets forget the macaroni code...

hmmm, So a context is something which refers to a location on the hard drive?  yeah, we had those things, but where I grew up we called those files... ;-)

Adding the following functions  would do for manipulating files in programs, with the explicit understanding that changing a file

My comment got truncated... here is the rest:

File.ls(); //returns a list of files in the current directory File File.cd(String newd); //returns a file pointing to the new location. Just like String, the File would be immutable and yet programmers would be able to avoid ugly System.Exec() calls. There would be system dependant code in creating the correct path strings in a CD, but it is fairly straightforward and only has to be done once.

There are plenty of things you can change that would break multithreaded programs.  All you need is a warning stating that  if you write multithreaded code you might not want to change the cwd.  Developers should be treated as if they have a certain amount of understanding and if the docs say this might be a problem in this situation then it is there problem if they shoot themselves in the foot.  Don't restrict some because you are worried others may make mistakes.

In addition if this is introduced security must be thought of.  If you are writing something like a servlet container you want to stop the servlets contained changing the cwd.

When is this likely to happen?

I need this functionality because I am Runtime.exec() a process that expects to be a particular directory.  This cannot be faked with user.dir

Ken - why you don't use 3 parameter exec method then ? Last parameter allows you to specify a working directory (and it is there since java 1.3).

To  be honest - is anybody, who is aware of this method, still requesting the chdir ? I don't see a point for it at all, given that you can run any child processes in their own working directories.

Just a short though on this. The reason I was interested in this is that if you wan't to write a Java based shell which will execute java programs cwd becomes a problem. For example if you start another java program in the same jvm by calling main then it will get the same working directory because it is in the same jvm. Now you can start another jvm but with the space and time costs of each jvm this is very   expensive for a shell type of environment. However, there is an apparent cure. If and when Isolates  become available, if we start a light weight Isolates inside a single JVM for each required instance of a JVM  and if each isolate can start with a different cwd the problem is mostly cured. There are a few ifs though that the java people need to address...

Also note that some of us like to write unit tests for methods that use the current directory in some way and it would be nice not to have to launch a JVM to do this.  In general, to support testing, if the user can change a parameter from outside the JVM there should be some way to do it inside the JVM.

The real problem is having a global immutable parameters at all - why should current directories have a one-to-one mapping with processes?

(Of course, another solution would be to make launching a new JVM with the current classpath cheap and easy.  ProcessBuilder helps but it's not as nice as a launchJVM method might be, and there's the speed issue.)

Anoter vote on this from someone wanting to test a program that uses the current working directory, from inside Java.

I would be happy with a solution that worked only thread-locally, e.g.,

  System#runWithCurrentWorkingDirectory(File,Runnable);

(possibly inherited by new threads). 

I agree that a global chdir is too dangerous.

Am I the only one to think that a ThreadLocal chdir could be implemented with one (~20 line) class:

public class ChDir
{
    File F_CurrentDir;
    public void chdir( File F ) { ... }
    public File resolve( File F_Relative ) { ... }
}

and using:

doSomething( CD.resolve( F ) );

rather than:

doSomething( F )

whenever the alternative working directory was needed?

Yeah, so it's not the prettiest or most efficient solution out there, but it can be made application-wide, thread-safe, and static if need be. And how many things in Java's innards rely on "user.dir" but can't be efficiently dispatched to run in another process?

Besides, if we get operator overloading, we can write:

doSomething( CD/F );

(Just kidding! ;^)

Personally, I would find a csh like pushd(), popd(), and dirs()
paradigm alot more useful than a chdir() paradigm.  Usually,
when programming, I just want to pushd() over somewhere
else, use relative pathnames, then popd() back when done.

Can't you just fix this problem by avoiding calling any native function with relative paths?  It seems to me that if you just call getAbsoluteFile() and then use that, the problem goes away as user.dir then works.

The developer can sometimes use this trick to avoid the problem in their own code, but I've witnessed things like loadLibrary failing to find a DLL after the directory is changed underneath by some other native code, and since there is no way in Java to set it back...