Michael Koch wrote: > Personally I'm against both types of such hacks. The current solution > probably duplicates some code but it easy to understand, needs no > hacks and extra support from the VMs.
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). 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. Regards, Jeroen _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
