What is the easiest way to have a custom file implementation that only uses memory in Java

Question

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?

Answer 1

java.io.File is essentially a wrapper around a String that represent a file path (it should have been a final class, but there you go). So you are out of luck with that approach. You can, of course, create temporary files and files on "RAM discs".

Answer 2

you should rather look out for in-memory implementation of OutputStreams/InputStreams such as ByteArrayOutputStream with its toByteArray() method, or the ByteArrayInputStream with the byte[] constructor. if your data is represented more complex, you might implement the interface directly.

Answer 3

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.

Answer 4

You have to find out what File methods are being used by your 3rd party and provide the custom implementation for them.

Is almost sure you won't be able to succeed because the java.io.File object is not in charge of the reading/writing of the File content.

The best approach would be to refactor the code so it don't depend on the File object but in the byte array returned by that file.

Creating a subclass of file is possible.

public class InMemoryFile extends File { 
    public InMemody() { 
         super( "/dev/null" );
    }
    // find out what methods should be overwritten ?????
}