281102 - Map multiple java proxies to one xpcom object

Status: RESOLVED FIXED

(Core Graveyard :: Java to XPCOM Bridge, defect)

Description

[jhp (no longer active)]

Spin off from bug 275359.

Comment 1

[jhp (no longer active)]

Attachment: many java objects mapping to one xpcom object

Patch by Michal.  As he explains it:

this patch is the most interesting one, fixes problem of code like this

nsICookieManager cm = ...
nsISimpleEnumerator en = cm.getEnumerator();
while (en.hasMoreElements()) {
  nsISupports s = en.getNext();
  nsICookie c = (nsICookie) s.queryInterface(nsICookie.NS_ICOOKIE_IID); //fails

}

the problem is that the xpcom instance seen from getNext() is coupled 
with the nsISupports_Stub and then ca not be casted to nsICookie anymore.

First, the patch makes possible to map several java-stubs onto one xpcom
instance. Then when an xpcom->java wrapper is required a java instance
is searched or created using the given IID

Additionally I had to fight with releasing of global weak references at any
time by jvm. (because now xpcom instance had associated list of java objects,
and the references were vanishing while iterating that list).
So I've updated the implementation of the java<->xpcom mapping tables
in a similiar way as in the QT/Java implementation.

Comment 2

[jhp (no longer active)]

Attachment: my patch

This is what I came up with.  I liked Michal's implementation of using the
XPCOM object address as the hash key, and then having it point to a structure
that contains all of its associated Java proxies.  He wrote his impl in Java. 
I decided to do it in C++, in order to minimize the calls from C++ to Java to
C++.  

For the list of Java proxies, I decided to do a simple linked list, in order to
cut down on memory usage.  The common case is that there will be one Java proxy
for each XPCOM object, so walking the list of Java proxies will not be a big
performance hit (i.e. no need to make this a hash table also).

I decided to split the hash tables into their own mapping classes (as in
xpconnect).  This allowed me to clean up some code.

Also, as Michal himself mentions, I had to recode the weak reference support. 
I decided to keep around an nsJavaXPTCStub for each
nsJavaXPTCStubWeakReference.  This makes it easier to forward calls to the Java
object.

Patch isn't final.  Still need to clean it up.	But have a look and try it out.

Comment 3

[jhp (no longer active)]

Oh, my patch sits on top of the patch from bug 279649.

Comment 4

[jhp (no longer active)]

Attachment: my patch v1.1

Cleaned up patch.  Added some comments.  Consolidated some code and fixed an
addref problem.
Darin, what do you think of the new weakref handling (see comment at top of
nsJavaXPTCStubWeakRef.cpp)?

Comment 5

[Darin Fisher]

I'm sorry Javier, but I won't have time to give you a good review for a while. 
You can have r=me as a rubberstamp since you've been doing good work and I don't
want to hold you up any longer.  Anyways, none of this stuff is built by
default, so as far as I'm concerned you can go at it.  If you want to discuss
individual things, feel free to drop me mail.

Comment 6

[jhp (no longer active)]

Checked in.  -> FIXED