JDK-6458489 : Codebase of a Program in the local Filesystem - Syntax changed ?
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-08-09
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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 6 JDK 7
6u2Fixed 7 b13Fixed
Description
FULL PRODUCT VERSION :
java version "1.6.0-beta2"
Java(TM) SE Runtime Environment (build 1.6.0-beta2-b86)
Java HotSpot(TM) Client VM (build 1.6.0-beta2-b86, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows XP 5.1.2600 (SP 2)

A DESCRIPTION OF THE PROBLEM :
Using Java Webstart, It's possible to launch a Programm located in the local filesystem.

In Java 1.5.0.*, one has to specify the codebase as follows:
codebase="file://localhost/D:/jjdh/"

In the Java 6 Beta 6 Release, this is not longer working and causes exceptions.

Instead, one has to specify the codebase as follows:
codebase="file:/D:/jjdh/"

In this case the program runs well. Probably this syntax-change is a consequence of the rewritten JNLPClassLoader.

But I woul'd expect that the 'old' version with the 'localhost' still should work in Java 6 WebStart. In particular, one should also check if this error also occurs on other operation systems (Is there a localhost on Linux or Solaris ?)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Take any Program which should be deployed as Webstart and save it on the local filesystem. Try to launch it with a 'old-styled' codebase="file://localhost/D:/jjdh/" and a 'new-styled' codebase="file:/D:/jjdh/".


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Both variants should work, in particular the  'old-styled' codebase="file://localhost/D:/jjdh/" variant which worked well in Java 5.
ACTUAL -
The  'old-styled' codebase="file://localhost/D:/jjdh/" variant doesn't work on Java 6 Beta 2.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Here is the core of the problem with the  'old-styled' codebase="file://localhost/D:/jjdh/" variant, taken from the Logging of my Program:

Used Classloader: com.sun.jnlp.JNLPClassLoader
URL Resource = jar:file://localhost/D:/jjdh/jjdh.jar!/META-INF/HOMER_J_.SF
java.io.FileNotFoundException: \localhost\D:\jjdh\jjdh.jar (Syntax for filename, file directory or data medium is wrong - Message translated from German to English)
	at java.util.zip.ZipFile.open(Native Method)
	at java.util.zip.ZipFile.<init>(Unknown Source)
	at java.util.jar.JarFile.<init>(Unknown Source)
	at java.util.jar.JarFile.<init>(Unknown Source)
	at sun.net.www.protocol.jar.URLJarFile.<init>(Unknown Source)
	at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
	at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
	at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
	at com.sun.jnlp.JNLPCachedJarURLConnection.connect(Unknown Source)
	at com.sun.jnlp.JNLPCachedJarURLConnection.getInputStream(Unknown Source)
	at java.net.URL.openStream(Unknown Source)
	at jjdh.java.resource.provider.ClassLoaders.getResourcesAsStreams(Unknown Source)
	at jjdh.java.resource.provider.StandardProvider.createStandardResourceLoader(Unknown Source)
	at jjdh.java.resource.provider.StandardProvider.getInstance(Unknown Source)
	at jjdh.opengl.initialization.Launcher.reloadClasses(Unknown Source)
	at jjdh.opengl.initialization.Launcher.<init>(Unknown Source)
	at jjdh.opengl.exercises.Launcher.main(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at com.sun.javaws.Launcher.executeApplication(Unknown Source)
	at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
	at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
	at com.sun.javaws.Launcher.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Using the  'new-styled' codebase="file:/D:/jjdh/".

Comments
EVALUATION fix in 7.0 and 6u1.
11-08-2006

SUGGESTED FIX in JNLPCachedJarURLConnection.getJarFileURL, no need to canonicalize the URL.
10-08-2006

EVALUATION URLUtil.canonicalize is original from plugin, which is used to fix up the url passed in from the browser. For webstart case, the url is always from the JNLP file, and there is no need to do any fix-up. We should be just able to use the URL from the JNLP file directly.
10-08-2006

EVALUATION bug is in com.sun.deploy.util.URLUtil.canonicalize, we are converting file://localhost/C:/6458489/notepad.jar to file:/localhost/C:/6458489/notepad.jar. however the cache entry is set with url as file://localhost/C:/6458489/notepad.jar. So when we do a lookup on file:/localhost/C:/6458489/notepad.jar, the cache lookup fail and JNLPClassLoader failed to load the jar file correctly.
10-08-2006