Rana Dasgupta wrote: > Hi Gregory/Geir, > Sorry for jumping in, but I have a question... > > > On 6/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: >> >> >This method as the name says allocates a java.lang.Class instance for >> the >> >requested class and assigns class handle to the C native Class struct. >> But >> >java.lang.Class cannot be allocated before java.lang.Class class is >> loaded >> >by VM, so there is a special bootstrap case which doesn't create any >> object. >> >> >Now that I've written this I realized that the patch is not complete >> since >> >it doesn't create instances for these new java.lang.Class >> superinterfaces >> as >> >it is done for Object, Serializable and Class itself. It is necessary to >> do >> >allocation it in different place. I'll correct it right now and >> attach an >> >additional patch to HARMONY-612. > > > I am also trying to understand the flow here. But since this is a dummy > bootstrap case, would it make sense to just disable this assert instead of > instantiating all the new interfaces and resolving everything, or is this > instantiation necessary for the bootstrap in which case the assert of > course > makes sense?
The assert makes sense as a safety, IMO. Notice how it caught this which hinted at work that had to be done elsewhere. :) > Also, are we incrementally fixing all the 1.5 related issues as we find > them? Probably not. But this is just because we want to to keep up w/ the class lib. We need to do a small push to get DRLVM to understand 1.5 classfile format as a first step. geir > > Thanks, > Rana > > -- >> Gregory Shimansky, Intel Middleware Products Division >> >> > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
