I have a code base that makes extensive use of files to represent a single data object. I have refactored the code so that the data object is now an explicit java object that mostly hides interaction with the underlying file system. However, we use a few external tools (like Weka), that read and write files.
Ideally, I would like to have a subclass of File that I can pass to these other libraries that is backed by an in- memory array of bytes — either for reading or writing.
My google searches turned up memory-mapped files, but this is not the problem I have as I don’t want any actual file on the file system. Are there any solutions already out there, or should I just subclass File myself and over-ride all the methods that refer to the real file system?
This is generally why you should never write methods to take a File unless it’s really necessary. Do your libraries not provide methods that take an arbitrary InputStream? In this case, it’s trivial to pass a ByteArrayInputStream or any input stream that reads from memory.
The problem with overriding File is it’s unlikely that you can override it in a way that will help you. For example, if the library opens it with a FileInputStream, then where the bytes come from at that point is really controlled by the FileInputStream implementation, not by your File.