Closed bigfatbrowncat closed 10 years ago
I like the approach with a boolean constant, if anyone is interested :)
Another idea: I found out that it's not an easy task to determine if a path is absolute in Windows, or not, but thankfully, MS made some WinAPI functions for that (that should be added to the Os implementation)...
So the other option:
We make another Os interface implementation called Windows, that encapsulates Posix inside (so we shouldn't create another native functions) and adds its own special API functions. For example, this: http://msdn.microsoft.com/en-us/library/bb773660%28VS.85%29.aspx
So the check if we are on Windows, or Posix is obvious - we use instanceof
.
The only question is - how to change new Posix()
with new Windows()
in Libcore.java?
I think in this case patching is the best solution. What do you think? (For now we don't have any special place to keep necessary WinAPI functions there)
I like the idea of adding a Windows class which extends Posix, and modifying Libcore.java to choose between new Posix() and new Windows() based on System.getProperty("os.name").
Please, take a look into this citation from java.io.File class:
On POSIX systems this works well, cause absolute paths start from "/". But on Windows we have a problem with drive letter.
That leads to losing the "absolute path" state for all the paths and prepending the base again to them like this:
This could be solved easily, but we have a global problem here - how we should solve such problems?
We could:
and set it to true in the native
Posix.init()
function on Windows. Here we check it and decide the algorithm for absolute paths.This problem is the most noticeable one for now cause you can't even use FileInputReader or any other IO routine with absolute paths - all of them are broken.
Please, tell us your opinion.