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

Part 1/2:

 >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?
 >
 >Thanks,
 > - alec
 >

 [DELETIA]


Part 2/2:

 Alec Muffett <###@###.###> writes:
 >Roland Schemers <###@###.###> 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 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
 >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
 >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