Static final buffer passed into FilterOutputStream.write(byte[])

Question

Greetings,
My team is using a custom subclass of FilterOutputStream to XOR some bytes with a key before writing them to an underlying OutputStream. We have never had problems with it until we started testing with Java 1.4.x -- where we noticed that some optimizations had been made to GZIPOutputStream to write the GZIP header out at once using a static final buffer to hold the header.
The problem seems to be that this header, although marked as static final, can still be changed when it is passed to our custom FilterOutputStream's write(byte[] b) method. For speed, we are XORing the bytes in place in the byte[] and then writing it directly back out. So every time we write the header with the same key, the static final byte[] that holds the header in GZIPOutputStream changes from its XORed to cleartext equivalent, and back.
My question is this: should this be considered a bug in the SDK, or a bug in our code? Maybe I'm looking in the wrong place, but I can't find any documentation that specifies what can and can't be done with a byte[] that is passed into the write(byte[]) method of an OutputStream.
Any input is appreciated.
Regards,
Mike Pontillo

Answer 1

Mike,
Need some code here to clarify. Are you saying that
the original final static (constant) changes?
You've got to be careful when you talk about passing a
byte[], which can't be done, of course. You are
passing a reference to a byte[]. Using the reference,
the bytes can be copied. There aren't any restrictions
on what can be done to the copy.
and also, if you have final array, then only that arrays'
reference is final, but the content of array may change
as well as when that array wasn't static.Yes, I understand this. Thank you for your replies. FilterOutputStream.write(byte[]) of course takes a reference to a byte[]. We are overloading this to be something like:
public void write(byte[] b) {
   for(int i = 0 ; i < b.length ; i++) {
      b[i] = foo(b);
out.write(b);
i.e. we modify the array inside the method rather than making a copy and writing out the copy.
This hasn't been a problem until Java 1.4.x -- now GZIPOutputStream passes a private static final byte[] (reference of course) into write(byte[]) in OutputStream. So when our overloaded write(byte[]) method gets called in FilterOutputStream and code similar to the above runs, the private static final reference to a byte[] is overwritten in the java.util.zip.GZIPOutputStream class. This was a change sometime between 1.3 and 1.4, I believe. From the J2SDK 1.4.1_02 source:
     * Writes GZIP member header.
    private final static byte[] header = {
        (byte) GZIP_MAGIC,                // Magic number (short)
        (byte)(GZIP_MAGIC >> 8),          // Magic number (short)
        Deflater.DEFLATED,                // Compression method (CM)
        0,                                // Flags (FLG)
        0,                                // Modification time MTIME (int)
        0,                                // Modification time MTIME (int)
        0,                                // Modification time MTIME (int)
        0,                                // Modification time MTIME (int)
        0,                                // Extra flags (XFLG)
        0                                 // Operating system (OS)
    private void writeHeader() throws IOException {
        out.write(header);
    }As you can see, they are passing a private static final reference to a byte array into somebody's untrusted method (ours). =)
Due to this issue we have to change our code so that it makes a copy of these bytes rather than changing them in the method. Now I'm wondering if this should be considered a bug in Java or not -- does changing bytes like this violate the general contract of an Input/Output stream? It at least seems like a bad idea for encapsulation purposes since anyone can change these bytes in the GZIPOutputStream class. We had previously assumed that if they were writing these bytes to an output stream they didn't care about them any more, which is the case 99.9% of the time in our experience.