> 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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
