JDK-8168205 : Should not default class path to CWD if -cp is not specified but -m is specified
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.module
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-10-18
  • Updated: 2016-11-17
  • Resolved: 2016-10-27
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.
JDK 9
9 b143Fixed
Related Reports
Duplicate :  
JDK-8163309 - SecurityException from Applet calling Thread.setPriority(int)
Relates :  
JDK-8169909 - java agent fails to add to class path when the initial module is a named module
Description
$ java Hi

classpath has always been default to PWD. 

With modules:
$ java -p mods -m m1/p.Hi

-classpath option and CLASSPATH environment variable are not set.   The current implementation defauts class path to PWD.  In other words, the builtin application class loader will search classes from PWD.

The VM always sets "java.class.path" to an empty string for the following cases
1. -Djava.class.path is not set
2. -Djava.class.path is set to no value (without = sign)
3. -Djava.class.path= explicitly set to empty value

Automatic modules are used to bridge to the class path and it might expect that $PWD is the class path.
Comments
If the initial module is a named module and -cp is not set and CLASSPATH is not set, the built-in system class loader should default to no class path, as it was originally designed.
26-10-2016
The JDK launchers currently set -Djava.class.path (with no = sign) as the jdk tools are modules. The launcher code will need to be updated per the resolution of this issue.
18-10-2016