Archie Cobbs wrote: > FYI, when I started working with Classpath I tried to respect the > Foo-VMFoo split and not modify any Foo classes but eventually decided > that it was too costly. E.g., every loaded class already has a Class > object (I don't create them on-demand), but you double that number > if you also have a VMClass object for each class.
Ouch! I hadn't seen the VMClass split as we're still on 0.05. I have to agree there is no way I will use this version of things. Class is pretty much guaranteed to be VM specific. I can see the benefit of having the class initialization process spelt out in VMClass, but I'd be inclined to use VMClass as a helper, with static methods that take a Class instance, rather than having a VMClass shadow per Class object. (Just like VMClassloader is a helper and there is not a VMClassloader per Classloader). Whilst on the subject of class Class, I've mentioned before that it really should not have any static initialization in it. class Class is the first class that must be initialized and trying to set up protection domains as the first thing the VM does seems implausible to me. At a minimum you have defer processing of Class's <clinit> until later in the bootstrapping process. We moved that code into a method for lazy initialization later in the bootstrap process. Cheers, David Holmes _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
