Re: ClassLoader initialization in _Jv_RunMain

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Fri, 2003-11-14 at 16:07, Andreas Tobler wrote:
> Mark Wielaard wrote:

> > Andreas is trying out a simple workaround for this. Just commenting out
> > the setTime() call in ZipEntry.setExtra(byte[]). Since this seems to be
> > the only call that can trigger a (Calender) resource load while
> > initializing the VMClassLoader.
> 
> Starting program: 
> /Volumes/xufs/gcc-cvs-dylib/objdir/powerpc-apple-darwin7.0.0/libjava/.libs/gij 
> -jar 
> /Volumes/xufs/gcc-cvs-dylib/gcc/libjava/testsuite/libjava.jar/simple.jar
> Failed to load Main-Class manifest attribute from 
> /Volumes/xufs/gcc-cvs-dylib/gcc/libjava/testsuite/libjava.jar/simple.jar
> 
> Program exited with code 01.
> 
> on hppa & darwin.
> 
> So far from the ffi hack lab :)

That is certainly progress :)
No more core dumps and/or huge stacktraces indicating bootstrap
classloader looping. That simple.jar file looks corrupt to me. Running
fastjar xf simple.jar gives: Error! CRCs do not match! Got fd0659a5,
expected 2d4740b5

So the above output "Failed to load Main-Class manifest attribute" is
correct.

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part