Message12054

Hmmm ... I've learned a lot about URLs and a bit about JBoss (or WildFly now) trying to find a good answer to this. One thing I definitely understand is that one should not use a URLDecoder on a URL. (https://stackoverflow.com/questions/6519746/url-decode-in-java-6#6603584)

The best way to derive a file path from a URL is surely to use the facilities Java offers: it knows what platform we're on and is more likely to get the parsing right (UNC paths anyone?). And it's satisfyingly brief. But precisely because Java does this properly, I end up with the platform-specific separator character in my file path.

The behaviour I'm not totally sure about is the one for the JBoss protocols. I've gone for the same solution here, the one that produces the platform-specific slash. Essentially one simply replaces the vfs: or vfszip: with file: and assumes the URL is valid. It is difficult to know whether this is right: I'm fairly sure the current code only works in particular circumstances anyway. In general, these VFS URLs cannot be translated to a file path, but when they can, it makes sense to me that the path should be properly slashed, not as "required" by the test.

I'm going to assume that the forward-slash we currently end up with universally (and the test enforces) is just a consequence of the home-cooked parser, and of relying on the tolerance of java.io on Windows. As indeed is the pesky leading slash: #msg6157.

It would be a problem if some application (on Windows) depended on the forward slash, for example to re-compose a URL into VFS, but I've no evidence of such a use.

Now here:
https://hg.python.org/jython/rev/d83a36fe9f8e
Except I've credited it to Richie Bendall :( Not sure I can fix that now.