3

Is there a way to force the temporary files created in a java program in memory? Since I use several large xml file, I would have advantages in this way? Should I use a transparent method that allows me to not upset the existing application.

UPDATE: I'm looking at the source code and I noticed that it uses libraries (I can not change) which requires the path of those files ...

Thanks

Lyther
  • 67
  • 2
  • 6

5 Answers5

3

The only way I can think of is to create a RAM disk and then point the system property java.io.tmpdir to that RAM disk.

  • Do you know how to do it on linux? – Lyther Feb 16 '11 at 17:35
  • see http://stackoverflow.com/questions/1924136/environment-variable-to-control-java-io-tmpdir – mindas Feb 16 '11 at 17:38
  • For my case it is the only solution (actually a trick) feasible, even if it is not closely related to java. Thanks – Lyther Feb 16 '11 at 21:48
  • 1
    @Lyther: On my computer my entire `/tmp` is tmpfs, i.e., stored in RAM (and swapped out if necessary). In case you're short on RAM, you could use also [compressed swap](http://code.google.com/p/compcache). – maaartinus Jul 15 '12 at 15:00
2

XML is just a String, why not just reference Strings in memory, I think the File interface is a distraction. Use StringBuilder if you need to manipulate the data. Use StringBuffer if you need thread safety. Put them in a type safe Map if you have a variable number of things that need to be looked up on with a key.

If you absolutely have to keep the File interface, then create a InMemoryFileWriter that wraps ByteArrayOutputStream and ByteArrayInputStream to keep them in memory, but again I think the whole File in memory thing is a bad decision if you just want to cache things in memory, that is a lot of overhead when a simple String would do.

  • Or `byte[]` or similar (`ByteBuffer`). XML can specify which character encoding it is in, which means it really needs to be stored in bytes. – Tom Hawtin - tackline Feb 16 '11 at 18:20
  • not really, Java Strings are Unicode so not problems with encoding, especially since the apparently application is generating the XML ( hence the temp file solution), not reading it from somewhere else. –  Feb 16 '11 at 21:01
2

Don't use files if you don't have to. Consider com.google.common.io.FileBackedOutputStream from Guava:

An OutputStream that starts buffering to a byte array, but switches to file buffering once the data reaches a configurable size.

maaartinus
  • 44,714
  • 32
  • 161
  • 320
0

You probably can force the default behaviour of java.io.File with some reflection magic, but I'm sure you don't want to do that as it can lead to unpredicted behaviour. You're better off providing a mechanism where it would be possible to switch between usual and in-memory behaviour, and route all calls via this mechanism.

Look at this example, it shows how to use file API to create in-memory files.

mindas
  • 26,463
  • 15
  • 97
  • 154
  • By reflection magic I mean tricks like in this presentation: http://www.javaspecialists.eu/talks/oslo09/ReflectionMadness.pdf - in my opinion this is highly dangerous and should be avoided at all costs. – mindas Feb 16 '11 at 17:44
  • 1
    memory mapped file io is __not__ the same as in memory storage, it just makes the file on the device look like memory, big difference. –  Feb 16 '11 at 18:16
0

Assuming you have control over the the streams that are being used to write to the file -

Do you absolutely want the in-memory behavior? If all that you want to do is reduce the number of system calls to write to the disk, you can wrap the FileOutputStream in a BufferedOutputStream (with appropriately big buffer size) and write to this BufferedOutputStream (or BufferedWriter) instead of writing directly to the original FileOutputStream.
(This does require a change in the existing application)

Amol Katdare
  • 6,740
  • 2
  • 33
  • 36