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.