This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: current CVS: load errors?
- From: Tom Tromey <tromey at redhat dot com>
- To: Nic Ferrier <nferrier at tf1 dot tapsellferrier dot co dot uk>
- Cc: java at gcc dot gnu dot org
- Date: 12 Dec 2001 10:48:27 -0700
- Subject: Re: current CVS: load errors?
- References: <E16Dw33-0008Ra-00@tf1.tapsellferrier.co.uk>
- Reply-to: tromey at redhat dot com
>>>>> "Nic" == Nic Ferrier <nferrier@tf1.tapsellferrier.co.uk> writes:
Nic> When I try to load a jar file (with a Main-Class attribute for
Nic> pointing to the class to run) I get the following exception:
Nic> Exception in thread "main" java.lang.NoClassDefFoundError: gnu.paperclips.boot.webappd
I think I've found the problem.
I recently changed libgcj so that command-line arguments are assumed
to be encoded in the locale's encoding. This has the side-effect of
initializing java.lang.System earlier than was previously done. This
means that the code in _Jv_RunMain which sets _Jv_Jar_Class_Path
doesn't affect the java.class.path property.
This is my theory anyway. I don't have time right at the moment to
find out for certain.
In a way I'm glad we caught this since this code is currently too
fragile. I'd like it to be more resilient in the face of changes like
mine; we should aim to be less dependent on a particular order of
initialization. I'll try to write a patch soon, maybe today.
In the meantime if you want a workaround you can change JvConvertArgv
from this:
*ptr++ = new java::lang::String (bytes, 0, len);
to this
*ptr++ = new java::lang::String (bytes, 0, len,
JvNewStringLatin1 ("8859_1"));
I think that ought to avoid initializing System.
Another workaround would be not to use `jar' mode.
This works for me:
CLASSPATH=paperclips.jar gij gnu.paperclips.boot.webappd --help
Tom