RFE for Java runtime environment to support chdir() [or similar]
>Subject: trying to change directory in java
>From: Alec Muffett <###@###.###>
>Date: 02 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?
> - alec
Alec Muffett <###@###.###> writes:
>Roland Schemers <###@###.###> writes:
>>>> // set the properties for user.dir
>>>> newprops.put("user.dir", "/etc");
>>You are barking up the wrong tree :-) All setProperties does is
>>replace one Properties object 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
>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
>object-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...
###@###.### 10/15/04 20:41 GMT