How to do it? Alternate readLine(), read bytes?

Question

Problem: How to alternate between an InputStreamReader and a raw InputStream when reading data from an InputStream. The catch is that the InputStreamReader may read ahead a few bytes and so subsequent reading from the underlying InputStream will miss those buffered bytes.
Background:
I have an application that communicates with a Tomcat servlet with Http protocol.
I want to send a request, and receive a response as a Java Object. The problem is receiving the response as a Java Object.
Actually, I have no problem if I use a URLConnection and create an ObjectInputStream from the URLConnection InputStream. But the URLConnection is very slow to use for uploading large files.
There is a code project called JUpload which uploads files very fast, at least 10 times as fast as URLConnection. It uses sockets and their input/output streams. So I'm adapting some of that code for my application.
The problem is that the JUpload code is harder to use. It parses the HTTP headers in both directions. When receiving the response, it parses the HTTP headers using an InputStreamReader wrapped in a BufferedReader to read lines, and continues reading lines for any other responses destined to the application.
However, I need to read a Java object after the header. Therefore, I need to get the underlying InputStream so I can create my ObjectInputStream.
There is a conflict here. The BufferedReader may (and does) read ahead, so I can't get a "clean" InputStream.
I have a workaround, but I'm hoping there is a better way. It is this: After reading the HTTP header lines, I read all the remaining characters from the BufferedReader and write them to a ByteArrayOutputStream wrapped in an OutputStreamWriter. Then I create a new ByteArrayInputStream by getting the bytes from the ByteArrayOutputStream. I then "wrap" my ObjectInputStream around the ByteArrayInputStream, and I can read my Java Object as a response.
This technique is not only clumsy, but it requires buffering everything in memory after the header lines are processed (which happens to be OK for now as my response Object is not large). It also gets really clumsy if the returned HTTP reponse is chunked, because the BufferedReader is needed alternately to read the chunk headers. Fortunately, I haven't encountered a chunked response.
It feels like what I need is a special Reader object that allows you to alternately read characters or read bytes without "stuttering" (missing buffered bytes).
I would think the authors of the URLConnection would have encountered this same problem.
Any thoughts on this would be appreciated.
-SB
Edited by: SB4 on Mar 21, 2010 8:08 PM
Edited by: SB4 on Mar 21, 2010 8:09 PM
Edited by: SB4 on Mar 21, 2010 8:10 PM

Answer 1

Yes, that is the problem as you noted. My solution is to continue reading all the characters from the BufferedReader and to convert them back to a byte stream using the ByteArrayOutputStream, OutputStreamWriter, etc.
It works, just seems clumsy and not scalable.
I was hoping there might exist a special "CharByteReader" (invented name) class somewhere that would be like a BufferedReader, but that would implement a read(byte[], offset, length) type of method that could access the read-ahead buffer in the same way the read(char[], offset, length) method does.
URLConnection is just too slow, including chunked mode.