The specification of java.nio.MappedByteBuffer says:

    All or part of a mapped byte buffer may become inaccessible at any time,
    for example if the mapped file is truncated.  An attempt to access an
    inaccessible region of a mapped byte buffer will not change the buffer's
    content and will cause an unspecified exception to be thrown either at the
    time of the access or at some later time.  ...

This behavior was intended to be implemented in 1.40-beta2 by RFEs 4454110
(runtime), 4454113 (c1), and 4454115 (c2).  The implementation is incomplete on
solaris-sparc and totally absent on linux-i586; I haven't checked any other
os/arch combinations.

With 1.4.0-beta2 on solaris-sparc, the following program crashes the VM with
-Xint but throws the expected error ("java.lang.InternalError: a fault occurred
in an unsafe memory access operation") with -Xcomp -client and -Xcomp -server.
The same behavior was observed with 1.4.0-beta3, 1.4.0-fcs, 1.4.1, 1.4.2,
1.5.0, and 1.6.0-b28.

With 1.4.0-beta2 on linux-i586, the following program crashes the VM with
-Xint, with -Xcomp -client, and with -Xcomp -server.  The same behavior was
observed with 1.4.0-beta3, 1.4.0-fcs, 1.4.1, 1.4.2, 1.5.0, and 1.6.0-b28.

Note that the program must be edited slightly in order to be compiled with
1.4.0-beta2 due to later API changes.  It must also be recompiled from beta3
to FCS.  For convenience I've attached a tarball containing class files for
each version.

----
import java.io.*;
import java.nio.*;
import java.nio.channels.*;


public class Truncate {

    private static final int SIZE = 1 << 16;

    public static void main(String[] args) throws Exception {
	FileChannel fc = new RandomAccessFile("/tmp/z", "rw").getChannel();
	fc.position(SIZE);
	fc.write(ByteBuffer.allocate(1));
	MappedByteBuffer bb
	    // Uncomment this line for 1.4.0 beta2
	    //= fc.map(FileChannel.MAP_RW, 0, SIZE);
	    // Uncomment this line for 1.4.0 beta3 or later
	    = fc.map(FileChannel.MapMode.READ_WRITE, 0, SIZE);

	bb.put((byte)1).put((byte)2).put((byte)3).put((byte)4);
	fc.truncate(0);
	bb.put((byte)5);
    }

}
----

Ideally this bug should be fixed in 1.4.2_XX, 5.0uX, and Mustang.

###@###.### 2005-03-22 22:43:01 GMT
Additional note: This bug only affects Unix systems (i.e., Solaris and Linux).
Windows does not allow a memory-mapped file to be truncated, so it's impossible
to observe this behavior.