This bug report is a combination of several reports that describe (at least)
three problems with the readUTF/writeUTF methods:

Problem 1:

    DataOutputStream.writeUTF runs through its argument String twice using
    String.charAt.  Instead, it could use String.getChars to get the chars into
    a local char[] and then walk that (twice).  This would save two calls to
    String.charAt per char, and would avoid the explicit range checks that
    String.charAt does.  One hopes this change would allow a good compiler to
    elide the subscript range checks on the array access, etc. generating
    generally better code.

    One might want to avoid the extra char[] if the argument String were very
    long, to avoid running out of memory.

    peter.kessler@Eng 1998-11-19

Problem 2:

    DataInputStream.readUTF is using a public String constructor, which forces
    the char array to always be reallocated and copied.  It is frequently the
    case that the char array created by readUTF will be of exactly the right
    length, and could be used as-is, without copying, if only there was a
    privilged way for it to create a String.

    In an RMI server that I have, which involves serialization via RMI and then
    serialization to a file for persistent storage, over 4Kb of heap is
    allocated and then discarded by readUTF per single RMI call to the server.
    It would be very beneficial to eliminate this overhead.

    rws@east

Problem 3:

    DataOutputStream.writeUTF computes single bytes of the resulting UTF and
    writes them to the stream one byte at a time.  That's okay for buffered
    output streams, but for ByteArrayOutputStreams (or unbuffered streams) that
    results in a synchronized method call per byte (at least).

    Similarly for DataInputStream.readUTF reading from a ByteArrayInputStream.

    pbk@eng

-- mr@eng 1999/4/19