Ola! I've been coding a new android keyboard lately, a project for my university degree but also : for fun. While I was doing this, specially while implementing a file-based dictionary containing frequency information of all words stored in there, I stumbled upon a very, very weird Java-behavior.
Let's explain it. Using RandomAccessFile, you have both Interfaces, DataInput and DataOutput ( and Closeable ) at your service. Wonderful, I thought, and started to use them. Well, two weeks and endless debugging sessions later I figured out why nothing worked the way it should: RandomAccessFile.
This little class is unable to provide the most simple functionality: Write a byte value, say 42, to a certain position, say 11223 in a file, then seek back to 11223, read a byte value, and make sure it's the same. The reason for this odd, strange, undesired, undocumented feature? No shared buffers. In fact, no buffers, just for the explicit read and write operations ( they are mapped to native methods anyway ). So basically, everything should work fine in an unbuffered environment, with an operating system directly writing everything down on file.
Because virtually no operating system works unbuffered, RandomAccessFile doesn't work. The working workaround is to sleep for some time or something alike.
By the way, I was only able to figure it out by looking at the openJDK source, an excellent source in case you're wondering about some Java behaviour. And thanks to Marc Seeger for his help!