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