Roman Rokytskyy wrote: >>So, I think Otis is right - it's really not a "problem", besides being >>an interesting design problem that is. There is an issue of whether it >>is a good practice to make use of OS-specific behavior in this way. >>Obviously, the portability suffers. I'm not sure if there are >>performance arguments one way or another (Doug?). >> > >My main concern here was that I get exceptions from JDataStore, and I had to >put checks whether there's still open stream. If you say that the file will >be deleted, I have no problem with it. :) I will hope that eventually all >streams will be closed and file will be deleted. > I'm pretty sure it's ok, but you may want to run a few test to make sure.
> >Another interesing design issue is cloneable input streams (this is where >the problem comes). Since I never met it before, it would be great to put >some Javadoc that explains in what state cloned input stream is supposed to >be. Thanks to JDataStore, input stream there is random access and I can seek >where I want, but what if some stream does not provide such functionality? > Yes, I forgot about that one. It's even more interesting than that! The stream objects that Doug coded are not java.io. streams. They are wrappers on top of those. Each clone maintains it's own seek offset. Essentially, they share the same OS file handle but present an abstraction of multiple independent streams into the same file. Dmitry. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
