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. uses
System.getProperty and that would be called before System. 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. 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. 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
