Unexpected end of ZLIB input stream

I'm pulling data from a SQL database. The data is compressed.

I'm using the following code to read the data:
//------------------------------------------------------------------------------------------
if (rs.next())
    {
         InputStreamReader in = new InputStreamReader(
      new InflaterInputStream(
      new ByteArrayInputStream((byte [])rs.getObject("Compressed_Data")),new Inflater(true)),"UTF-16LE");
          char[] cbuf = new char[16000];
             sb = new StringBuffer("");
          int i = 0;
          while (i > -1) {
                       i = in.read(cbuf);
                     if (i > -1){
                           sb.append(new String(cbuf).substring(0,i));
                                 // System.out.println(new String(cbuf).substring(0,i));
                         }
                     }
          System.out.println( sb.toString());
    }
//------------------------------------------------------------------------------------------

When the commented println statement is uncommented, you can see each piece of data that is decompressed. The data is XML. When it gets to the last read, I get an exception. Also, it's interesting to note that if I change "cbuf" to char[1], and I print out each read as it's being appended, I can verify that the final tag of the xml is in fact being decompressed and appended to "sb". However, java continues to try and read past the xml and is throwing the following exception:


java.io.EOFException: Unexpected end of ZLIB input stream
      at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:215)
      at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
      at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:408)
      at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:450)
      at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:182)
      at java.io.InputStreamReader.read(InputStreamReader.java:167)
      at java.io.Reader.read(Reader.java:100)
      at clsMain.GetStatement(clsMain.java:58)
      at clsMain.main(clsMain.java:28)


I need to know what I can do to correct this. Another application that was written in VB.NET can succesfully read the entire compressed XML without any problems. So, I'm sure it's not a corrupt compression. Java can read the entire compressed xml, but at the end of the stream throws the exception. Is there a bug in my code? or a bug in java? or am I missing something that would correct this?

If you need more information, please let me know and I'll see what I can provide.

Thanks,
Tony




LVL 5
mytonytigerAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
zzynxConnect With a Mentor Software engineerCommented:
See Bug ID 4040920 in Sun's BugParade for more details about the workaround.

There, I read also the following comments:

I have been having the same problem in 1.4.01 under HP-UX (11i). The problem is exactly as described above.
---------------------------------------------------------------------
Yup, it looks like this bug still occurs under JDK 1.4.2_02 on Mac OS X.
It's too bad that this bug is closed or else somebody might realize that it needs fixing.
Can't vote on it either. Can't fix the source and redistribute it either due to the not-really-open-source license for the JDK.
The community has clearly fixed the bug and handed it back to Sun but Sun won't integrate the fixes.

I guess I'll have to code a workaround everywhere I see this problem. Yay!
---------------------------------------------------------------------
The problem is still happening with JRE 1.3.1_13, is someone from Sun going to attend to this?
0
 
zzynxSoftware engineerCommented:
0
 
zzynxSoftware engineerCommented:
I hope you don't use JDK 1.1.x because

There is a bug in JDK 1.1.x which causes the ZipFile class to read beyond the end-of-file.
JavaSoft recommends the following workaround: Do not attempt to read more bytes than the entry contains.
Call ZipEntry.getSize() to get the actual size of the entry and use that value to keep track of the remaining number of bytes while reading the entry.
0
 
mytonytigerAuthor Commented:
I'm using 1.4.2_04

It seems to be a java bug.

What fun!
0
 
zzynxSoftware engineerCommented:
Thanks for accepting

>> What fun!
;)

0
All Courses

From novice to tech pro — start learning today.