JDK-4276917 : Arbitary setting of system properties cause unpredictable behavior
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1999-09-30
  • Updated: 1999-10-01
  • Resolved: 1999-10-01
Related Reports
Duplicate :  
Description

Name: krT82822			Date: 09/29/99


orig synopsis:  "." symbol (curr dir) affected by system property "user.dir"

When the dot symbol (.) is used to represent the current
directory in classpath strings, And the user.dir property is set
(-Duser.dir), the classpath current directory is altered to that
specified in the property. This results in NodeClassFound
exceptions where in fact classes exist.

c:>javac -classpath . -Duser.dir=z:/ mypackage.myclass

The system should search c:/mypackage/ for classes, but searches z:\mypackage instead.

Very nasty bug as you assume the classpath would work %100 by version 1.2


---------------

9/29/99 eval1127@eng -- (opposite of) 4026927, 1267562, 4030989 (working dir CANNOT be changed in Java)



A statement such as "The user.dir setting affects the '.' implied in the
Java2 CLASSPATH" is somewhat more accurate (though probably no more helpful).

However, user.dir does not seem to really CHANGE the working directory,
as evidenced by the following:

a) my main class is in "." (which is /home/user/tests/in95865)
b) an input file I want to open is in ".." (/home/user/tests)


If, from /home/user/tests/in95865, I do this:

( 91 )% java -classpath . -Duser.dir=/home/user/tests WhereAmI

...I get:

Exception in thread "main" java.lang.NoClassDefFoundError: WhereAmI

Thus, the "." implicit in the CLASSPATH is actually equal to the value of
user.dir at this point.   However, it's still not clear that this (otherwise)
changes the working directory.


If I try this:

( 92 )% java -classpath /home/user/tests/in95865 
                                                        -Duser.dir=/home/user/tests WhereAmI

...I get:

caught:  java.io.FileNotFoundException: Connect.java (No such file or directory)


In other words, the class is found, but the file is not.  Since the latter 
is in user.dir, "." has not actually been altered by user.dir's setting,
because it's not found when we try to open it with no path info preceding the
filename.


---------------

Source:


import java.io.*;

public class WhereAmI {
        static byte buf[];

        public static void main(String[] args) {
                try {
                        FileInputStream is =
                                new FileInputStream(new File("Connect.java"));
                        if(is != null) {
                                is.read(buf);
                                for(int i=0; i < buf.length; i++) {
                                        System.out.print(buf[i]);
                                }
                        }
                }
                catch(Exception e) {
                        System.err.println("caught:  " + e);
                        System.exit(1);
                }
        }
}
(Review ID: 95865) 
======================================================================

Comments
WORK AROUND Name: krT82822 Date: 09/29/99 Substitute the absolute path for the dot symbol ====================================================================== Explicitly set classpath can solve the problem, like: java -cp H:\test -Duser.dir=Z:\ Hello
11-06-2004

EVALUATION This is really an user error. The user.dir property is supposed to reflect the current directory. It should never be set in any way. Most of the properties should not be allowed to set, even though you can normally change it. This is a design mistake regarding System.getProperty(). ###@###.### 1999-09-30 See RFE 4165411. -- mr@eng 1999/10/1
30-09-1999