Name: boT120536 Date: 12/28/2000


java version "1.3.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_01)
Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode)


This is a request for a extremely simple but infinitely useful enhancement.

The class java.io.RandomAccessFile implements the methods of the interfaces
DataInput and DataOutput. However, the implementations it provides are final,
and cannot be overridden in subclasses of RandomAccessFile. This is an
undesirable state of affairs...

Subclasses of RandomAccessFile are necessary given that Java does not support
either little endian data (RFE 4206991) in RandomAccessFiles or buffering in
RandomAccessFiles (RFE 4087964, 4056207, 4193259, 4028552 and several
cross-referenced duplicates). However such subclasses cannot override several
methods in RandomAccessFile because they are final, and are therefore very
restricted in how they can go about extending functionality.

I suggest, therefore that these methods be made non-final to allow useful
subclasses to be created.

An example
----------

4206991 argues for a Java class which supports both little endian and big
endian data types via an extra method added to Data{Input|Output}* and
RandomAccessFile. In the meantime, however, a programmer attempting to
create a subclass of RandomAccessFile with similar functionality would be
thwarted because the relevant methods are final:

public final boolean java.io.RandomAccessFile.readBoolean()
public final int java.io.RandomAccessFile.readInt()
public final long java.io.RandomAccessFile.readLong()
public final float java.io.RandomAccessFile.readFloat()
public final double java.io.RandomAccessFile.readDouble()
public final void java.io.RandomAccessFile.writeBoolean(boolean)
public final void java.io.RandomAccessFile.writeInt(int)
public final void java.io.RandomAccessFile.writeLong(long)
public final void java.io.RandomAccessFile.writeFloat(float)
public final void java.io.RandomAccessFile.writeDouble(double)

  To put it in laymans terms, I cannot write a class to override RandomAccessFile
with a class which writes and reads data in little endian format instead of big
endian. Such a class would have a body with the following structure:

public class LittleEndianRandomAccessFile extends RandomAccessFile {

 public int readInt() {
  ...
 }

 public long readLong() {
  ...
 }

 public float readFloat() {
  ...
 }

 public double readDouble() {
  ...
 }

 public void writeBoolean(boolean b) {
  ...
 }

 public void writeInt(int i) {
  ...
 }

 public void writeLong(long l) {
  ...
 }

 public void writeFloat(float f) {
  ...
 }

 public void writeDouble(double d) {
  ...
 }

}

The solution
------------

The solution is exceedingly simple and has little or no impact on
compatibility: simply declare these methods without the final modifier.
There seems to be no good reason for the modifier to be present on
these methods as it stands.
(Review ID: 114195)
======================================================================

Name: gm110360 Date: 09/23/2002


FULL PRODUCT VERSION :
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)


FULL OPERATING SYSTEM VERSION :
Windows 98 [Version 4.10.2222]


A DESCRIPTION OF THE PROBLEM :
  Bug Parade #4400941 requests that the read/write methods of
RandomAccessFile not be implemented as final. I concur.

However, a separate issue is that of subclasses of
RandomAccessFile for which the data typed read/writes (such
as readInt() or writeUTF()) are good, but that would like to
control the low-level byte/byte array file access. For
instance, a BufferedRandomAccessFile would do this.

Except in two cases, low-level control can be done by
overriding a few methods, as higher level read/writes
dovetail into them. These methods are
read()/read(byte[])/read(byte[],int,int) and
write(int)/write(byte[])/write(byte[],int,int).

This almost works now. Unfortunately, two methods --
void writeChars(String s) and void writeBytes(String s) --
directly invoke the private and therefore unverrideable
writeBytes(byte[], int off, int len). Instead, these two
methods should invoke write(byte[], int off, int len),
which can be overridden. There is effectively no
performance loss is this change, especially on a HotSpot VM.

Subclasses of RAF would be great because that way code can
pass an instance of the subclass to existing code. This
will work now so long as no code calls the two methods
above. That is to say, this is dangerous and there is no
way for a subclass to determine whether one of these methods
was invoked.

Rather that subclassing, one could nest an instance of
RandomAccessFile. However, with a nested RAF, one would
have to recompile all code that used the new class, which
may not be possible.



REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 164818)
======================================================================