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
- 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!
- 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.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.getFile()may return a URL encoded string. This string cannot be used in
Fileas it will not correctly URL decode it. The string must be manually URLDecoded. Example URL:
- URL test cases is an excellent resource for reminding oneself of the various forms URL’s come in for local files.