sun.misc.URLClassPath is currently implemented such that if a jar file declares
a Class-Path manifest attribute, and the Class-Path attribute contains a
malformed URL, then the MalformedURLException triggered by the URL will cause
URLClassPath to ignore the jar file when loading resources. This seems
inconsistent with the overall behavior of URLClassPath with respect to
IOExceptions encountered while accessing URLs--i.e., tolerating the exception
and continuing on to search subsequent URLs. It's also particularly
inconsistent with the way new URLs encountered in jar indexes are handled: in
the jar index case, a URL string which causes a MalformedURLException is simply
ignored, but does not cause the enclosing jar file to be itself ignored.

A simple test case demonstrates the problem:

  $ java -version
  java version "1.4.0-rc"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
  Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)

  $ cat Foo.java
  public class Foo {
      public static void main(String[] args) {
          System.out.println("hello");
      }
  }

  $ javac Foo.java
  $ cat manifest1
  Manifest-Version: 1.0
  Main-Class: Foo

  $ jar cfm foo1.jar manifest1 Foo.class
  $ java -jar foo1.jar
  hello

  $ cat manifest2
  Manifest-Version: 1.0
  Main-Class: Foo
  Class-Path: invalid:url

  $ jar cfm foo2.jar manifest2 Foo.class
  $ java -jar foo2.jar
  Exception in thread "main" java.lang.NoClassDefFoundError: Foo

The cause of the problem is in the code for URLClassPath.getLoader(int). In
the section starting at line 220 of URLClassPath.java:

            try {
                loader = getLoader(url);
                // If the loader defines a local class path then add the
                // URLs to the list of URLs to be opened.
                URL[] urls = loader.getClassPath();
                if (urls != null) {
                    push(urls);
                }
            } catch (IOException e) {
                // Silently ignore for now...
                continue;
            }

In the scenario described above, the call to getLoader(url) succeeds, but the
call to loader.getClassPath() (which attempts to construct URL objects from the
jar file's Class-Path attribute string) throws a MalformedURLException, which
transfers control to the catch block, which skips to the next iteration of the
loop, effectively ignoring the successfully constructed loader. A simple fix
would be to split the try block so that an exception thrown by
loader.getClassPath() would not cause loader to be discarded.