United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6610897 New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathS
JDK-6610897 : New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathS

Details
Type:
Bug
Submit Date:
2007-09-28
Status:
Closed
Updated Date:
2013-06-26
Project Name:
JDK
Resolved Date:
2012-05-17
Component:
core-libs
OS:
solaris_2.5.1,generic
Sub-Component:
java.rmi
CPU:
sparc,other
Priority:
P5
Resolution:
Fixed
Affected Versions:
6u2,6u5
Fixed Versions:

Related Reports
Backport:
Backport:
Duplicate:
Relates:

Sub Tasks

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
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.
                                     
2007-09-28
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();
                                     
2008-05-21



Hardware and Software, Engineered to Work Together