Re: ZipInputStream broken?

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Adam Megacz wrote:

>Hrm, what I'm getting isn't very helpful:
>

What you're seeing is the stack trace for the initial GCJ thread, not 
the main thread which your app is running in (CVS GCJ has changed things 
so that main does execute in the first thread, but 3.0.2 doesn't work 
that way). GDB ought to switch to the thread which is throwing the 
exception, but maybe older versions don't do this correctly. Try using 
the "info threads" and "thread x" commands to switch to the thread which 
is actually aborting, and get a stack trace for that.

>
>I've done a bit of printf-style debugging, and I think an exception is
>getting thrown in a class member initializer -- like this
>
>    public class foo {
>      Bar bar = new Bar();
>      foo() { .... }
>    }
>
>Where Bar's constructor is throwing an exception.
>
>Normal JVMs throw the exception out of the "new foo()" call -- but it
>seems that GCJ doesn't work this way. Is that the case?
>

Nope. GCJ's exception semantics should be exactly according to the Java 
spec, and I'm not aware of any bugs. If it isn't working right, can you 
make a small test case?

regards

Bryce.