Roman Kennke wrote: > Hi there again, > > What about this pending patch? I didn't quite understand the discussion > around it. IMO the file handling is very platform dependend and while we > could handle this generically, I find this path very inconvenient, as it > clutters the code, where it could be easy, and it certainly isn't very > good for efficiency. I agree that this is not necessarily VM dependent, > but instead platform dependend? But I don't think that we should > introduce some kind of platform-layer that complements the VM layer in > some way. As Jeroen already pointed out, often times the VM is somewhat > tied to the platform(s) it supports and thus can just as well provide a > reasonable implementation of file handling. >
Sorry, that was kind of a bikeshed issue. VM-vs-platform isn't *that* big a deal, it just feels clumsy, and has been used as an "I don't understand this" umbrella in the past. > As for the VMBlahSocketImpl, I would very much like to have this mess > cleaned up (I know, I introduced this in the first place). I came to > think of that we don't really need this anyway, as the specs already > have a way of abstracting this stuff out (by defining the SocketImpl > abstract classes) and we simply added another unnecessary layer here. > This is true, and it's the same with java.nio (it's essentially a service provider interface through the SelectorProvider class). There is *some* value in isolating these platform-specific bits as much as possible (and keeping them, and the amount of JNI code, to a minimum!), and making porting Classpath a low-barrier-to-entry. What, if any, performance tradeoffs there are is a good question, however. > So may I commit this change to the VMFile class for now? Or should we go > another way of splitting out platform dependend stuff? > Sorry for not looking at it. The patch looks reasonable to me. Real code is always preferable to me bickering about vaporware :-)
