Joseph, > My problem is that the call stack during initialization of > the System class I looks something like ... > The last line causes an exception, since the static member > properties isn't initialized yet.
Initialization is quite tricky. Basically your VMClassloader is making assumptions about the initialization state of the system that are not valid in the default initialization sequence. We encountered a similar problem (and others). If we tried to create a String from a byte[] we needed the EncodingManager which needed to access a system property but System had not reached a point in initialization where you could call getProperty. I actually posted an email to the list about this a couple of weeks ago - which I've attached below. We had to change the way System.java behaved during initialization. (Somewhat related we also have to take pains to avoid referencing String literals early in the VM startup process because they can't be interned at that point.) David Holmes -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Holmes Sent: Thursday, 25 September 2003 2:21 PM To: classpath Subject: File encodings and initialization sequence Just wanted to share experiences with the initialization sequence and trying to resolve the character encoding problem. To fill in various system properties in Runtime we use native code to get C char arrays with output from things like uname, cwd etc. These are returned as Java byte arrays and have to be converted to Java Strings. The correct way to do this seemed to be to use the String(byte[]) constructor and ensure the corrected decoder was used. But this wasn't possible because the EncodingManager.<clinit> uses System.getProperty and that would be called before System.<clinit> had actually initialized its properties object. Hence we'd get a NullPointerException. To fix this Runtime now forces System to use it's properties object until System.<clinit> reaches the point were it clones runtime's properties object. Before I set any system properties I now extract the default character set name, acquired via native code, and use that to set the file.encoding property. Then I set all the encoding alias properties in case the default charset name is actually an alias. After that I can construct Strings from byte[] using the right decoding. I'm curious how others have dealt with this issue. I'm no expert on character-set/locale/internationalization issues. Related to this problem, I also found out that any exception that occurs prior to the point where System clones the runtime properties will cause recursive exceptions because Throwable.<clinit> also uses System.getProperty, which will throw NPE. I'd be tempted to have any static initialization code that needs a system property to read it direct from Runtime.properties - though of course that only works for classes in java.lang. Cheers, David Holmes _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
