bug in ZipInputStream

["Erik Poupaert" <erik dot poupaert at chello dot be>]

I think I am the latest victim of the notorious java.util.zip.ZipInputStream
bug. Google is bulking with reports on it. I think the bug is slowly but
surely taking over the world.

I'm talking about the latest and the greatest release candidate
gcj-3.2-20021210-1.tar.gz; and it's still in there!

I was trying to read from the executable's core with Anthony Green's "core
protocol" stuff; which works brilliantly by the way, and shove the
inputstream received from the core into a ZipInputStream. Believe it or not,
the bytecount is there, and all is well for several entries, until I do
getNextEntry() on a non-directory ZipEntry, and then it all flies in my
face. I tried remediate by shoving in jazzlib; in vain, it complains about
UTF-8 stuff. It's dead too in gcj.

You know what's strange? java.util.zip.ZipFile, however, does work as
advertised! Incredible, isn't it? Unfortunately, I can't open a ZipFile on
an InputStream. The constructor requires you to supply a filename.

Has anybody heard of an imminent fix for the bug?

By the way, how do you produce a corresponding tree of *.o files for a
source tree of *.java files? I'd like to do some incremental compiling. Now
I work with a self-produced response file that I supply to gcj: gcj
@files.txt -o myexe.exe --main=MyMain. gcj recompiles everything, every
time. And please, don't refer me to Gnu Make. Whenever I see the convoluted
syntax involved, I start heading for a nervous breakdown. I'd really like to
stick with Ant.

Another small thing. If I put my compiled resources in @files.txt, for use
with Anthony Green's core protocol, gcj complains. I have to put my
resources in a separate folder and proceed as following: gcj @files.txt
resources/*.o -o myexe.exe main=MyMain. Otherwise gcj starts complaining
violently about not finding class declarations, unexpected characters "."
and so on. It took me the whole night to find this workaround! Is it a bug,
or a feature?

And then an annoying newbie question: how do I switch on the stacktrace in
gcj?

And last, probably another annoying question: what compilation options can I
use to maximally reduce the executable's size? HelloWorld amounts to a
whopping 4 Mb. With gcc, I get away with 50 Kb. The only justification gcj
has for larger sizes, is the automatic linkage of a garbage collection
library. You're not going to tell me that the garbage collector weighs in at
4 Mb? For Christ's sake, which redundant space shuttle logic is shoved
automatically in every executable to beef it up to 4 Mb? I'm baffled. Still,
compared to dragging around the latest and bloatest 30 Mb trashcan of a JRE,
gcj is already paradise ...