I have found myself in a position where I am yet again wadding through the quagmire that are Java's URLs.

• Goal: virtualize a filesystem (i.e. a VFS).
• Interface: URL's are provided that define the scope of the filesystem. These URL's are files (archive and non, local and non) and directories. Lookups and retrievals are done against the VFS and return ByteBuffers. (Think "resource" on ClassLoader.)
• First thought: Just use java.lang.ClassLoader. The problem is that I need granular access to the data to optimize reads and there is no way to change a classpath at runtime.

So what is the problem with Java's URLs? Archives (i.e. JAR and ZIP). Play around with URL's such as:

and you'll know the pain I feel.

There will be more on this ... believe me!

Side notes:

• The path component of a URL can be null. This is a gotcha for handling local files with a statement like:

      if("file".equals(url.getProtocol)))
          File file = new File(url.getFile());
  

• Are query strings useful when the protocol is "file"?
• Consistently using either URL.getPath() or URL.getFile(). When dealing with local files (protocol is "file") getPath() makes the most sense since it will not include the query string (see above).
• URL.getPath() and URL.getFile() may return a URL encoded string. This string cannot be used in File as it will not correctly URL decode it. The string must be manually URLDecoded. Example URL:

      new URL("file:///C:/Program%20Files/Java/j2re1.5.0/bin/java.exe")
  

  URL.getPath() will return:

      /C:/Program%20Files/Java/j2re1.5.0/bin/java.exe
  

• URL test cases is an excellent resource for reminding oneself of the various forms URL's come in for local files.