Reputation: 3261
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?
Upvotes: 1
Views: 515
Reputation: 199215
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 ?????
}
Upvotes: 0
Reputation: 21795
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.
Upvotes: 3
Reputation: 16518
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.
Upvotes: 0
Reputation: 147154
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".
Upvotes: 1