There's no operation for replacing different-sized data in a RandomAccessFile, therefore you have to do it yourself. If the data you are replacing is a different length to the new data, you must move the rest of the file contents appropriately. If the file is known to be small, this is pretty easy. If it could be big, you need to take plenty of care.
In general, it is bad to have a data file structure that requires you to do this type of thing. If you have the opportunity to change the file format, you probably should do so. You could consider allowing enough space for any likely value, and filling unused spaces with some special byte. Or you could go for a more advanced format, using indirection within the file.
On a minor point, you have a bug in your code regarding line endings. You are writing the line ending as '\n', and reading using readLine(). These two are not guaranteed to use the same line endings (I guess they do on the platform you currently use, if you program "works"). In addition, you should be aware that you are implicitly doing lots of String/byte and byte/String conversions using the JVM's default locale. [ September 22, 2006: Message edited by: Peter Chase ]
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Creating temp file does not seem to be good solution to me.
I guarantee it will be easier than coming up with an "in-place" editing scheme that can handle un-equal record lengths. Furthermore, note that if in-place editing fails for any reason, the original data file will be corrupted.
If you absolutely have to pursue in-place editing of files too big to hold in memory, look at the way word processors handle this sort of thing. Bill
if you can guarantee that records will not exceed a fixed size, RandomAccessFile will work fine. Of course, you have to consider what to do about inserting, deleting and even finding records in that big of a file. At some point you are doing a lot of work creating a low-level database and less work on your problem. At that point it's easier to use an in-process database like Berkeley DB or, for larger applications, a full-blown RDBMS. [ September 27, 2006: Message edited by: Joe Ess ]