Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4045688

Add chdir or equivalent notion of changing working directory


    • Subcomponent:
    • CPU:
      generic, x86, sparc
    • OS:
      generic, linux, solaris_2.5.1, solaris_2.6, windows_95


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

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


      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


          Issue Links



              • Assignee:
                iris Iris Clark
                duke J. Duke (Inactive)
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: