JDK-4180841 : Tools invoked via UNC pathnames cannot find their resource files (Win32)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.2.0,1.2.1,1.2.2,1.3.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_95,windows_nt
  • CPU: generic,x86
  • Submitted: 1998-10-13
  • Updated: 2001-08-10
  • Resolved: 1999-10-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
1.3.0 kestrelFixed
Related Reports
Duplicate :  
JDK-4258001 - UNC support in Classpath
Duplicate :  
JDK-4197204 - File URL with UNC path does not work
Relates :  
JDK-4032066 - java.io: File classes do not recognize Windows UNC filenames (win32)
Relates :  
JDK-4105595 - AppletViewer doesn't recognize UNC names
Description

Name: dk30142			Date: 10/12/98


In attempting to use the latest javadoc from the
JDK 1.2fcs-J 14-Sep-98 release, I found that you 
can't invoke it using a UNC path on Windows NT 
4.0.  It's possible this bug was in earlier 
releases but I'm not sure.

For instance:
     \\ntserver\jdk1.2\bin\javadoc -help
fails with the stack trace:

Exception in thread "main" java.lang.Error: Fatal: Resource for javadoc is missing
        at com.sun.tools.javadoc.Res.initResource(Res.java:46)
        at com.sun.tools.javadoc.Res.getText(Res.java:90)
        at com.sun.tools.javadoc.Res.error(Res.java:172)
        at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:210)
        at com.sun.tools.javadoc.DocletInvoker.optionLength(DocletInvoker.java:1
24)
        at com.sun.tools.javadoc.Main.main(Compiled Code)

The same result is obtained if the PATH is 
modified to contain the share of the server and 
the javadoc command is invoked without a leading 
path:
    PATH=\\ntserver\jdk1.2\bin;%path%
    javadoc -help
fails in the same manner as the above.

The same result is also obtained when trying to 
run javadoc via the java command as follows:
    \\ntserver\jdk1.2\bin\java -cp \\ntserver\jdk1.2\lib\tools.jar com.sun.tools.javadoc.Main -help
(Review ID: 38966)
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.3 kestrel FIXED IN: kestrel INTEGRATED IN: kestrel
14-06-2004
EVALUATION ResourceBundle.getResource() fails when app launched from UNC path. Effects javac and javadoc (at least). Sorry can't look into this more since I'm working at home (no PC). I've assigned to Mark for now because of similiarity to 4032066. robert.field@Eng 1998-10-19 You can verify this bug still exists by running this on your PC by running: \\grinder\local-java\jdk1.2fcs\win32\bin\javadoc And, indeed, the exception still happens. Same problem seems to happen with javac. I know the ResourceBundle stuff uses classloading to find the file; maybe URLClassLoader has a bug wrt UNC names. In any case, it's a somewhat annoying problem... probably should be a P3. Gordon.Hirsch@Eng 1998-10-18 This looks like another case of java.net.URL not dealing with UNC names very well (see also 4105595), although it could also be a problem in URLClassLoader. This bug has been with us since 1.2beta3, which was the first 1.2 release that could deal with UNC pathnames at all. Prior to that you couldn't even start a JVM from the command line using a UNC pathname. -- mr@eng 1998/10/26 [mayank.upadhyay@eng 1999-09-30] There are basically two things that needed to be fixed: (a) On a windows machine sun.www.protocol.file.Handler.openConnection(URL) must not try to ftp from a host for a file URL that has the host set. It should instead try to treat it as a UNC path. Only if UNC access fails, try to ftp as it has been doing till now. (b) On a windows machine sun.www.protocol.jar.JarFileFactory.get(URL) must not ignore the host part of a URL when trying to obtain a Jar file at that URL. (It ends up using certain native code while trying to obtain a handle to the Jar file and cannot depend on the fix (a) alone. Therefore, the host part must be made part of the file component as you will see in the diffs. I've moved the two files sun/www/protocol/file/Handler.java and sun/www/protocol/jar/JarFileFactory.java to both win32 and solaris specific source directories. The copy under win32 has the needed changes described in (a) and (b).
11-06-2004
WORK AROUND Name: dk30142 Date: 10/12/98 Map a drive letter and invoke javadoc using the drive letter: net use j: \\ntserver\jdk1.2 j:\bin\javadoc -help or directly from java: \\ntserver\jdk1.2\bin\java -cp j:\lib\tools.jar com.sun.tools.javadoc.Main -help Note that the drive letter is only needed for the path to tools.jar, not the java command. ======================================================================
11-06-2004
SUGGESTED FIX [mayank.upadhyay@eng 1999-09-30] See evaluation also. File: sun/net/www/protocol/jar/JarFileFactory.java Add to win32 version - 75,85d74 < < // Deal with UNC pathnames specially. See 4180841 < < String host = url.getHost(); < if (host != null && !host.equals("") && < !host.equals("localhost")) { < < url = new URL("file", "", "//" + host + url.getPath()); < < } < File: sun/net/www/protocol/file/Handler.java Change win32 version - 67,68c67,68 < /* < * If you reach here, it implies that you have a hostname. --- > /* If you reach here, it implies that you have a hostname > so attempt an ftp connection. 70,83d69 < < // First attempt to treat this as a UNC path. See 4180841 < < try { < URL u2= new URL("file", "", "//" + host + u.getPath()); < FileURLConnection uc = new FileURLConnection(u2); < uc.connect(); < return uc; < } catch (IOException e) { < // carry on forward with ftp < } < < // Now attempt an ftp connection. <
11-06-2004