ClassLoader initialization in _Jv_RunMain

Mark Wielaard mark@klomp.org
Fri Nov 14 17:04:00 GMT 2003


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20031114/23a0966b/attachment.sig>


More information about the Java mailing list