JDK-6610897 : New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathS
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 6u2,6u5
  • Priority: P5
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_2.5.1
  • CPU: other,sparc
  • Submitted: 2007-09-28
  • Updated: 2013-06-26
  • Resolved: 2012-05-17
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 7 JDK 8
7u40Fixed 8 b36Fixed
Related Reports
Duplicate :  
JDK-6695325 - REGRESSION: Classpath returned by sun.rmi.rmic.BatchEnvironment.createClassPath(
Relates :  
JDK-7161282 - Move test/sun/tools/classpath/RMICClassPathTest.java to a more appropriate location
Description
New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathSeparator.Char

When Sun added support for fix 6473331, which adds support for Class-Path manifest entries in JAR files to rmic, they added a new constructor for sun.tools.java.ClassPath:

	public ClassPath(String[] patharray)

which calls a new private method:

	private void init(String}[] patharray)

The init method builds the String pathstr. The problem is that it separates the path entries by using File.separator instead of File.pathSeparatorChar. Any application that is using the pathstr as a search path will not be able to properly parse the entries. Such an application is the IBM ORB used by Websphere.
Bug Workaround
Comments
SUGGESTED FIX The following one-line change to src/share/classes/sun/tools/java/ClassPath.java should fix this bug: --- ClassPath.java~ Wed May 21 14:03:23 2008 +++ ClassPath.java Wed May 21 14:09:39 2008 @@ -123,7 +123,7 @@ } else { StringBuilder sb = new StringBuilder(patharray[0]); for (int i = 1; i < patharray.length; i++) { - sb.append(File.separator); + sb.append(File.pathSeparator); sb.append(patharray[i]); } this.pathstr = sb.toString();
21-05-2008
EVALUATION It is true that there is a bug in sun.tools.java.ClassPath when the new constructor, which was added with the 6473331 fix and which takes a String[] instead of a String, is used. The corresponding new private init(String[]) method, when it builds a string value for the "pathstr" instance field to be consistent with the behavior of the original constructor, uses File.separator when it should use File.pathSeparator (or File.pathSeparatorChar or the static field ClassPath.dirSeparator). But this "pathstr" instance field of ClassPath isn't used for any important functional behavior of ClassPath objects: it only affects the result of invoking toString() on ClassPath objects, which as far as I know is not used by the implementation of the rmic tool-- and the sun.tools.java classes only exist to support the rmic implemention. So I don't understand the described case of an "application that is using the pathstr as a search path". Is this some application (other than the JDK's rmic) that is using sun.tools.java.ClassPath directly? Such usage is unsupported; note the following blurb in the doc comment for the class: * WARNING: The contents of this source file are not part of any * supported API. Code that depends on them does so at its own risk: * they are subject to change or removal without notice. Note that this class and other remnants of the old javac implementation are expected to be removed entirely for JDK 7.
28-09-2007