Currently, the JavaXPCOM code caches the interface info object for each Java proxy and XPCOM stub. This is unnecessary, though, since xptiInterfaceInfoManager (impl of nsIInterfaceInfoManager) keeps the info objects in a hash table. So it should be enough to call |GetInfoForIID()| or |GetInfoForName()| as necessary.
Created attachment 264781 [details] [diff] [review] patch Well, I was mistaken as to what JavaXPCOM was actually doing with the nsIInterfaceInfo objects. I thought I had written something elaborate, but XPCOMJavaProxy and nsJavaXPCOMStub are just keeping around pointers. Still, I didn't like the use of JavaXPCOMInstance object in XPCOMJavaProxy. So I made a few changes, refactored and cleaned up the code. Functional changes in this patch: * Use cached nsIInterfaceInfoManager, rather than calling do_GetService every time. * Take XPConnect's code that uses nsIInterfaceInfoSuperManager to look at different managers, if they exist. * In XPCOMJavaProxy, no need to save the nsIInterfaceInfo pointer, since we know the interface by name and can call GetInfoForName. * In XPCOMJavaProxy, for methods callXPCOMMethod and finalizeProxy, pass native handle and interface name to native method, rather than forcing native method to call back into Java to retrieve them. The rest is just refactoring and cleanup. But getting rid of JavaXPCOMInstance will make it easier to use the native object handle directly in Java (i.e. bug 343580).
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.