classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Moving system properties to gnu.classpath.*


From: David Holmes
Subject: RE: Moving system properties to gnu.classpath.*
Date: Fri, 8 Oct 2004 09:36:05 +1000

> Jeroen Frijters writes
> I don't think the current solution is easy to understand. The library
> initialization bootstrapping is quite complex because many classes
> require access to the system properties and currently that forces
> java.lang.System to be touched (which in turn constructs
> System.in/out/err and that sets off more static initializers).

That is true. Are you proposing that instead of saying System.getProperty
all the classes using these properties will instead get them from somewhere
else and we will leave System.getProperty for use by application code?

Actually you mention GetPropertyAction in your original mail, but I'm not
familiar with that. What is it?

> This is not just a theoretical issue for me. IKVM is very different from
> most VMs in this respect. I don't have a well defined place to
> initialize the library, any class can be the first to be used by client
> code.
>
> In most cases this works fine, except for some scenarios where
> gnu.java.io.EncodingManager is initialized before java.lang.System, then
> it fails because of a cyclic dependency.

In OVM we basically bit-the-bullet and forced initialization of System first
as that was what the docs implied was needed - and what the basic setup of
Object/System/Runtime tried to do (but see below). However, we found that we
needed to initialize the EncodingManager almost immediately to handle string
literals and that caused access to System.getProperty to fail because we
hadn't reached the stage where System.properties had been set. So we changed
the System initialization code to point System.defaultProperties at
Runtime.defaultProperties and we changed Runtime to point System.properties
at the right place too, until everything could be set the way it was
intended. And just for good measure we had to factor out the setting of the
encoding aliases and set them first.

Because of the above specialization we never adopted the Runtime/VMRuntime
split.

I'd oppose any change that forced us to rework all of what we have done, if
the change only benefited one other VM implementation. Note that is an "if",
I'm not clear exactly what you are proposing so I don't know how it may
benefit other VMs.

Can I also note that the initialization comments in System and Runtime and
Object are now all out of sync and no longer accurate. Since Object no
longer forces initialization of System it would seem as if the whole
"initialize System first" thing has been done away with. Did the person who
removed the static initializer from Object realize this?

Cheers,
David Holmes





reply via email to

[Prev in Thread] Current Thread [Next in Thread]