JDK-8176456 : Clearing system property user.dir causes File methods to throw NPE
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2017-03-09
  • Updated: 2018-03-05
  • Resolved: 2018-03-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbd_minorResolved
Related Reports
Duplicate :  
JDK-8194154 - System property user.dir should not be changed
Relates :  
JDK-8066709 - Make some JDK system properties read only
Relates :  
JDK-4165411 - java.lang.System: Forbid the modification of read-only system properties
Description
If a File is relative then operations that require current directory, e.g. getAbsoluteFile(), getCanonicalPath(), fail with NPE if user.dir property has been previously cleared (via clearProperty(String) or setProperties(Properties)).
====================
Example:
jshell> new File("foo/bar").getAbsoluteFile()
$1 ==> d:\\foo\bar

jshell> System.clearProperty("user.dir");
$2 ==> "d:\\"

jshell> new File("foo/bar").getAbsoluteFile()
|  java.lang.NullPointerException thrown:
|        at WinNTFileSystem.normalize (WinNTFileSystem.java:83)
|        at WinNTFileSystem.getUserPath (WinNTFileSystem.java:349)
|        at WinNTFileSystem.resolve (WinNTFileSystem.java:312)
|        at File.getAbsolutePath (File.java:556)
|        at File.getAbsoluteFile (File.java:572)
|        at (#3:1)
====================

Note that with empty user.dir calls don't fail.
Example:
====================
jshell> System.setProperty("user.dir", "");
$4 ==> null

jshell> new File("foo/bar").getAbsoluteFile()
$5 ==> \foo\bar
====================
Comments
Already fixed by caching user.dir value in 8194154.
05-03-2018
A better option might be to cache the original value of user.dir at the time system properties are first initialized and to retrieve that value instead of using System.getProperty().
10-03-2017
Or there could be added a method such as getCwd() which delegates to getcwd(3) on Unix and GetCurrentDirectory() on Windows and then replace System.getProperty("user.dir") with System.getProperty("user.dir", getCwd()) in the pertinent places where it occurs. Actually String userDir = System.getProperty("user.dir"); if (userDir == null) { userDir = getCwd(); } would be more efficient so to avoid an unnecessary invocation of getCwd().
10-03-2017
If there's no good general solution to making System properties read-only (or to provide constraints on their values) perhaps only thing to do in this case is to change the uses of user.dir in File and related classes to substitute "" for null.
09-03-2017
As you note, it's silly to change to remove this system property. Sadly, we don't currently have a way to make this, and several other, property, read-only. It has been explored several times.
09-03-2017
I know that clearing/overriding pre-defined system properties is unsafe (although, AFAIK there is currently no specification stating that), and that some parts of JRE rely on that they're immutable, but unexpected NPE from the depth of the runtime doesn't seem correct either. Returning the same result as for user.dir="" seems better.
09-03-2017