RE: Moving system properties to gnu.classpath.*

[Jeroen Frijters]

David Holmes wrote:
> > 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?

Exactly. I would like to make this new class public to do away with the
overhead (and initialization dependencies) of the security check, but
that would require some VM magic to make the class inaccessible from
untrusted code. Michael Koch (strongly) opposes this. How would you feel
about it?

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

It lives gnu.java.security.action and is used in combination with
AccessControler.doPrivileged() to make sure that a possibly installed
security manager doesn't object to us getting a property.

> 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).

I don't have an efficient way to do that (well, I could push the
responsibility to the user of the library, but that would be lame).

> 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.

Would you like to work with me to try to refactor the way system
properties are handled to untangle the initialization dependencies and
to allow you to use more Classpath code as-is?

To be clear, I don't want this to be about hacking around partictular
problems. I want to improve the general design of the classes to reduce
any circular dependencies.

> Can I also note that the initialization comments in System 
> and Runtime and Object are now all out of sync and no longer accurate.

Good point. I don't use Object.java to I hadn't really noticed it.

Regards,
Jeroen