Bug Reports 4137835 and 4170047 concerned performance
enhancements to java.io.RandomAccessFile.   A set of
simple changes to RandomAccessFile preserves the
derived class behaviour of the current version
and yet gives the performance boost originally
suggested.  The concept of a temporary buffer
was rejected as being too costly in  customer  creations.
This would be the case if a new buffer was used
for each call.

The solution is to use a SINGLE buffer for all
read and write calls.  A single 8-byte array is
allocated on RandomAccessFile instantiation and
retained throughout its life.  This is NOT a
very heavy price to pay for performance gains
of up to 800% !!

For example readShort() changes from

public short readShort() {
int ch1 = read();
int ch2 = read();
if (ch1 < 0 || ch2 < 0)
  throw new EOFException();
return (short) ((ch1 << 8) + (ch2 << 0));
}

Add an  customer  instance variable:
  private byte[] tmpBuf = new byte[8];

public short readShort() {
if (2 != read(tmpBuf, 0, 2))
  throw new EOFException();
return (short)((tmpBuf[0] << 8) + (tmpBuf[1] << 0));
}

Similar changes can be made to all the multi-byte
read and write methods.

email me for a copy of the file with the changes
already made (  xxxxx@xxxxx  )
(Review ID: 43137)
======================================================================

N/A

The problem with using a single private buffer is that we then must synchronize
on it.  At present the RandomAccessFile class is not thread-safe, and adding
such synchronization could have other adverse performance and correctness
consequences, especially for existing subclasses.  As noted in 4170047, the
best answer here is most likely to design a new and cleaner random-access
stream abstraction.  --   xxxxx@xxxxx   1998/12/16

Yeah, like one that isn't synchronized.