new java binding

[Havoc Pennington]

Hi,

Cool!

I think you're missing an important layer of the bindings. The
complexity and size of the libdbus API is intended to _support
bindings_, not to be exposed in bindings.

So e.g. you don't need to expose all the watch/timeout stuff, that's
just "main loop glue"; in Java the normal thing is threads rather than
main loop, so I'd just use threads. 

You don't need to expose the Message stuff, since that is intended to
map to methods and listeners.

So basically the bindings you have so far should be private to the
package. The public Java API would be something different built on top.

Or at least the normal/encouraged Java API would be a proxy objects
thing built on top.

An example is the GLib bindings. The Java API should be similar in
number of methods to dbus-glib.h. I'm not sure if the C# bindings are
done as I'm describing or not.

I think I wrote a mail on this a while back but google isn't finding it
for me. There may also be some notes in the spec.

Here's an uninformative but related thread ;-)
http://lists.freedesktop.org/pipermail/dbus/2004-August/001459.html

Some more nitpicky comments:

 - you should use "long" rather than "int" to store pointers, 
   so things don't break on 64-bit; to convert to/from the 
   long you might want to use a macro like this:
   #define JLONG_TO_PTR(v) ((void*) (unsigned long) (jlong) (v))
   #define PTR_TO_JLONG(v) ((jlong) (unsigned long) (void*) (v))
 - in e.g. the GetSessionBus JNI, if the C API returns 
   NULL you probably want to return Java null or throw 
   an exception, right now you return a Java object with 
   a null C pointer which will be useless/dangerous
 - (note that most dbus functions can return NULL on out-of-memory)
 - seems like you should be consistent about using 
   NewObject vs. AllocObject unless there's a rationale for 
   when to use which
 - in wrapping the C object you should be a little more elaborate
   about attaching the C object to the Java object. What you want
   to do is:
      - create a global "data slot" on the C object with dbus
        API
      - store the Java object in that data slot
      - whenever you get a C object from e.g. dbus_bus_get(),
        first use the *existing* Java object, if that fails
        then you would create a new one
   The point is to only have one Java wrapper per C object
 - I think you have to ReleaseStringUTFChars() even if 
   the string was not copied, because the string will 
   be pinned in memory by the garbage collector... 
   this is just my understanding from docs/examples 
   I've seen, if you have read explicit confirmation 
   otherwise then that was probably right
 - in MessageIter_recurse() you need to check that malloc() 
   doesn't return NULL (probably other cases of this too)
 - we need to figure out the automake foo; I have an example
   Makefile.am I based on java-gnome if you don't have anything 
   yet

Anyhow, looking good! I'm happy to have these in CVS if you want to ask
the fd.org admins for access.

Havoc