Roman Kennke wrote:
I removed the old NSA native state handling and implemented a more
natural approach. The NSA native state API was maintaining (native)
hashtables to hold the native state to the peer objects and others. This
has a couple of disadvantages:
- It's not really scaleable. Performance is only O(1) in the best case
and O(n) in the worst case.
- It's error prone. I was experiencing problems with it at least, which
is why I came to rework this stuff.
- It's ugly. ;-)
I implemented a more natural JNI-ish native state management which
stores the native state directly inside the Java object to which it
belongs. This way, the access to this is guaranteed to be O(1) and the
handling is generally easier (no removal from the table on GC needed for
example). This makes use of the Pointer* classes to store pointers in
the Java objects.
There's one missing piece here. I need to add support for 64bit
pointers. That shouldn't be a biggy though.
I tried to keep the Changelog entry small (ehe) by leaving out all the
functions and methods and only listing the changed files with small
comments.
This looks good. Two comments: 1) we've been using the "cp_gtk_" prefix for
public symbols in libgtkpeer.so, rather than "gtkpeer_". 2) in GCJ we may want
to replace the use of gnu.classpath.Pointer with direct references, but I guess
the Pointer approach makes sense for GNU Classpath.
Tom
