2006/6/16, Geir Magnusson Jr <[EMAIL PROTECTED]>:
Gregory Shimansky wrote: > Sorry for delay, JIRA is painfully slow for me today. I submitted > HARMONY-612. > > The reason I didn't do it immidiatelly is that I thought I am missing > something and you have the fix already somewhere as you wrote that VM > worked > on WinXP for you. 'worked' is an overstatement. It survived the smoke test.
This is strange because for it it failed on hello world application and in the very beginning of it. Could it be that some jar file with old API version was floating around, maybe from CLASSLIB build (which checked out some old revision of classlib) which was done by VM itself? I'm learning.
Ok, so let me learn some more. I'll apply the patch, but can you explain why we need this? I know that w/ the 1.5 change to Class.java, we now implement AnnotatedElement, GenericDeclaration and Type. Can you give some background on what this method does, and why we need these added? Is it because we need to register those three as well when Class itself is registered?
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. -- Gregory Shimansky, Intel Middleware Products Division
