Should I use a temp buffer to gunzip bytes to bytes?

Question

Folks,
I need a method to gunzip (uncompress) a zipped-byte-array into a plain-byte-array ... The below method (based on that used for file-i/o-streams) works, but I can't figure out if using the buf  "interveening temporary buffer" is good, bad, or indifferent.
As I understand things... There's really no memory saving in reading/writing-by-the-temporary-buffer because the input gzippedByteArray is allready wholey in memory, and we (by definition) need the whole output plain-byte-array in memory concurrently... so it'd probably be more memory efficient to NOT use temporary-buffer and just zip the WHOLE input straight into the ByteArrayOutputStream with one call to output.write
BUT I'm not really sure of myself here... so please can anyone offer an informed opinion?
Memory efficiency is important (I think) because we're handling XML responses, and "the odd one" might be upto maybe 200 Mb (unzipped), though "the norm" is under a meg, and 99% are under 5 meg... So I guess I need to engineer this instead of just slapping it in and seeing if it pops.
      * Returns the g-unzipped (uncompressed) version of the given
      * gzippedByteArray.
      * @param gzippedByteArray byte[] - the bytes to uncompress
      * @return byte[] - the uncompressed bytes
      * @throws IOException
     public static byte[] getUnzippedBytes(byte[] gzippedByteArray)
          throws IOException
          ByteArrayInputStream input = null;
          GZIPInputStream unzipper = null;
          ByteArrayOutputStream output = null;
          byte[] bytes = null;
          try {
               input = new ByteArrayInputStream(gzippedByteArray);
               unzipper = new GZIPInputStream(input);
               output = new ByteArrayOutputStream();
               // unzip bytes onto the output stream
               int len;
               byte[] buf = new byte[BUFFER_SIZE];
               while ( (len=unzipper.read(buf)) > 0 ) {
                    output.write(buf, 0, len);
               // return the contents
               bytes = output.toByteArray();
          } finally {
               IOException x = null;
               if(unzipper!=null) try{unzipper.close();}catch(IOException e){x = e;}
               if(output!=null) try{output.close();}catch(IOException e){x = e;}
               if(x!=null) throw x;
          return bytes;
     }Thanking you all. Keith.

Answer 1

OutputStreams aren't 'exposed by routers... Our bluddy router "encapsulates" the servlet request. It exposes a swag of setters, one of which is setExtractXml(byte[])... the upside is that you don't have to worry about content types, and request headers and all that carp... the downside is the loss of flexibility.
What I meant was that I'll need to customise the session model (which lives in our funky router) to expose the servlet-output-stream to the action class... Then we're laughing.
Or not... My mad tech manager reckons "it's been working that way for years"... he didn't like it when I reminded him of our "odd "unexplained" out of memory" incidents... Nope... His code... His way... Gotta luv the managment, and why do I care anyway... Do I care? Naaah. I just work here.