FULL PRODUCT VERSION :
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b02)
Java HotSpot(TM) Client VM (build 1.5.0_16-b02, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows [Version 5.2.3790]

A DESCRIPTION OF THE PROBLEM :
MalformedURLException did not occur in identical application code in 1.5.0_12.  Occurs in 1.5.0_16 when the following sequence is executed when running under Java WebStart (only):

URL resourceBase = MyClass.class.getResource("myfile");
URL newURL = new URL(resourceBase, "anotherfile");

Exception appears to be thrown because sun.net.www.protocol.jar.Handler.parseURL() has the following sequence of code:

            int bangSlash = indexOfBangSlash(file);
            String toBangSlash = file.substring(0, bangSlash);

But indexOfBangSlash(string) returns -1 if it doesn't find !/ in the URL's file property.

But in this scenario only the realURL property of the handler has the full path, and the file property has only the relative path.

Therefore, a StringIndexOutOfBoundException is thrown, which is translated to a MalformedURLException.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
when running under Java WebStart (only):

URL resourceBase = MyClass.class.getResource("myfile");
URL newURL = new URL(resourceBase, "anotherfile");

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
URL should be valid, context should be applied as defined.
ACTUAL -
MalformedURLException is thrown.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
String index out of range: -1
causing MalformedURLExcpeption


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
when running under Java WebStart (only):

URL resourceBase = MyClass.class.getResource("myfile");
URL newURL = new URL(resourceBase, "anotherfile");

Ensure that "myfile" and "anotherfile" are resources in the same package in the same jar.  [Sorry this is not compilable as such -- but scenario requires resources in jars, deployed via JNLP]
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
None found.

Release Regression From : 5.0u12
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.
Posted Date : 2008-09-09 10:55:51.0

N/A

Have the JnlpURLStreamHandler class handle toString() requests.
Posted Date : 2008-10-14 13:10:01.0

In 1.5.0_16 we have seen a bug which sounds like it is closely related to this one. It also only occurs when running via Java webstart.

In the application there is a line like this in org.apache.batik.dom.svg.SVGDOMImplementation.java:

URL url = getClass().getResource("resources/UserAgentStyleSheet.css");

The returned URL is completely bogus, and looks like this:

jar:org/apache/batik/dom/svg/resources/UserAgentStyleSheet.css

Note the "host" part of the URL is empty string. This URL is not valid (and trying to construct a new URL with that string throws an exception).

I suggest you examine your code to determine how a jar: URL could ever end up with an empty host component. Then you will find the bug.

Is this the bug which causes this:
http://forums.java.net/jive/thread.jspa?threadID=44628&tstart=-3
http://forums.sun.com/thread.jspa?threadID=5317755&tstart=120

It doesn't seem like a "medium" bug to me, it seems serious enough to pull the entire release from distribution. Users are getting this via automatic updates (e.g Apple), and breaking all their web start applications. Isn't something that breaks the entire web start universe a serious bug?

I changed my bug votes for this one.
Because of an Apple choice, all Mac OS X users working on a PowerPC or an Intel 32 bits machine can't use Java 6. Thus they are obliged to use Java 1.5.0_16 version with this bug which broke the access to bundled resources in all JWS application. Please fix it.

I have also used all 3 bug votes for this bug as this is surely a serious bug as it breaks our application using WebStart - not good!

With reference to the user comments submitted on the 24-SEP-2008, this does seem like the bug that we are getting that is causing the problems - it won't even allow JavaHelp (which is written by Sun)  to load.

This weems to have stopped one of my company's key WebStart applications from working - can the priority be raised?

Our application uses the JavaHelp system and is deployed via Java Web Start.  As of right now, we cannot launch our application via Web Start with 1.5.0_16.  Application launches just fine under any other 1.5.0 and any 1.6.0 (at this time).  Application also launches just fine from the command line, however, this is obviously not very helpful for our users.  Comment out the calls to load our JavaHelp, and the application launches via WebStart fine.  But again, not helpful for our users.

I would also like the priority to be raised on this bug.

Please raise the priority on this. 

The following code may work around this issue for some people (it does for us):
    public static URL getResource(Class clazz, String name) {
        // Get the URL for the resource using the standard behavior
        URL result = clazz.getResource(name);

        // Check to see that the URL is not null and that it's a JAR URL.
        if (result != null && "jar".equalsIgnoreCase(result.getProtocol())) {
            // Get the URL to the "clazz" itself.  In a JNLP environment, the "getProtectionDomain" call should succeed only with properly signed JARs.
            URL classSourceLocationURL = clazz.getProtectionDomain().getCodeSource().getLocation();
            // Create a String which embeds the classSourceLocationURL in a JAR URL referencing the desired resource.
            String urlString = MessageFormat.format("jar:{0}!/{1}/{2}", classSourceLocationURL.toExternalForm(), packageNameOfClass(clazz).replaceAll("\\.", "/"), name);

            // Check to see that new URL differs.  There's no reason to instantiate a new URL if the external forms are identical (as happens on pre-1.5.0_16 builds of the JDK).
            if (urlString.equals(result.toExternalForm()) == false) {
                // The URLs are different, try instantiating the new URL.
                try {
                    result = new URL(urlString);
                } catch (MalformedURLException malformedURLException) {
                    throw new RuntimeException(malformedURLException);
                }
            }
        }
        return result;
    }

    public static String packageNameOfClass(Class clazz) {
        String result = "";
        String className = clazz.getName();
        int lastPeriod = className.lastIndexOf(".");

        if (lastPeriod > -1) {
            result = className.substring(0, lastPeriod);
        }
        return result;
    }

This problem has affected all of our users that utilize the 1.5.0_16 version. Some large federal organizations cannot easily change to a different version due to organizational restraints. This is a high priority problem for us. Please accelerate a fix or publicly remove this release from circulation.

This bug killed our app on Mac OS X and Win98 (doesn't affect 1.6).  Thanks to dehrlich for the workaround.  FWIW, I made a few modifications:

(this is in my own Toolbox class)

private static String CLASS_SRC_LOCATION = Toolbox.class.getProtectionDomain().getCodeSource().getLocation().toExternalForm();
	
public static URL getResource(String name) throws Exception {
	URL url = Toolbox.class.getClassLoader().getResource(name);
		
	//this is a hack to work around the 1.5.0_16 bug
	if (url != null && "jar".equalsIgnoreCase(url.getProtocol()) && url.toExternalForm().indexOf("!/") == -1) {
		String urlString = "jar:" + CLASS_SRC_LOCATION + "!/" + name;
		if (!urlString.equals(url.toExternalForm())) url = new URL(urlString); //if new URL string is different, instantiate it
	}
		
	return url;
}

 HTH, Nick

Thank you dehrlich for the fix.
But please note that it works only if the resource and the class belongs to the same jar ;-)

By the way, thank you Sun for raising Priority to 1-Very High.
I hope a new java version will be available soon...

I think it's a regression from Java 1.5.0_15 because my program works under that older version. Note also that I don't have problems to access to images.

I am assuming this fix will address #6734163. Can someone confirm that?

If so, that one should be closed as a duplicate.

Thanks.

I have written a work-around that is potentially more flexible than the ones that have been posted so far.  I would like to share it with the Java / Web Start community, as well as solicit your feedback.  If you are interested, please find it at:

http://forums.sun.com/thread.jspa?threadID=5347404

Hi, 
We actually are facing the same problem. The problem comes from the javaws and not the JRE. 
We copied the javaws.jar from the 1.5.0_15 into the jre1.5.0_16\lib (replacing the javaws.jar version _16) and it works!!! 
This can be a temporary solution?