Uri's messing with my forks

I'm still stumped on the URI handling. Some mauve tests tries to assert the correctness of the URI and URL, returned by the two methods toURI(), and toURL() of a java.io.File object (where the latter is now deprecated, in favour of the first one). However, the mauve tests cannot be correct, since it for the URI thinks a corect result is the path appended with a file separator, and for the URL result doesn't want the file separator. I.e. in the mauve test, an URI should be "file:ram:t/", and the URL should be "file:ram:t", which is just plain wrong (as corroborated by a simple test on OpenJDK on my mac). If the path points to a directory, it should end with a "/", if it's a file, it should have no ending. So it should in both the URI and URL case be "file:ram:t/".

How to mauve forward

It's very unsettling not being able to rely on the automated tests being correct. So, I'm thinking that I shouldn't give them to much gravitas, but try to get the most obvious errors in JAmiga fixed with the help of Mauve, but not aim for a hundred percent fully successful test run.

Some more URI ranting

GNU classpath has a tendency to add slashes to the end of paths, which denote directories, but doesn't have the ending slash. Like above, the path "ram:t", would become "ram:t/". However, if the path is just "ram:" (being a root directory), it will also get a slash at the end, since GNU classpath doesn't know that colon is a file separator in the amiga world. This leads to the path "ram:/". This is coincidental how Windows does it file URI's, like "C:/" (here normalized from Windows normal backslash notation).

For now i think I'll try and keep it like this, so we might get URI's like "file:ram:/t/tempfile" for our Amiga paths "ram:t/tempfile". Hopefully that will work. Because, like I've on numerous occasions blogged about, the whole URI/file/path-handling is all over the place.