Just to clarify that post (which I did late last night), here's a more thoughtful version....
I have a Java issue and I don't know how to solve it, so I thought I'd run it by the folks here and see if anyone here knows what to make of it.
First: The (simplified) code below works fine on a PC, but not in a limited memory environment, like a PDA.
Second: I have no control over the Java environment, so I can't control startup switches. In fact, I'll be running in a WebSphere environment. This code will be running in a J2ME environment as well as a J2SE and J2EE environment, so it needs to be friendly.
The problem: It runs out of memory when inflating a large file (greater than ten megs) from a ZIP. If I have 14 files in the ZIP and two are larger than ten megs, it will inflate all but the two large ones.
Where it does NOT occur: Strangely enough, it doesn't happen at a controllable place, like a buffered read. It isn't happening at any place where I can control the number of bytes read.
Where it DOES occur: It's happening at the line where I try to get the input stream getInputStream() for an entry in the ZIP file. Specifically, the large (greater than ten megs) entry in the file.
Why it happens: I have some theories. 1) It may be standard practice to read the entire file during a getInputStream() method call. 2) In order for the inflator to determine strategy, it may have to read the entire file. 3) The blocksize for the stream is determined in some way by the size of the file.
What you can do to help me: If you know the answer, great, let me know. I need to finish this project. ALSO, tell me how I can find this stuff out on my own. If there is some method of seeing the source code behind getInputStream() in java.util.zip.ZipFile, that might lend some clues. Perhaps looking at the bytecode would be handy...if I knew how to intrepret it. If there is a workaround that is more memory-friendly, that would be outstanding. I'm easy.
I'm going to post code at the end of this message.
Thanks in advance for help.