Re: [Java-gnome-developer] RE: Mark Howard's Blog

[Jerry H. <jh...@fe...>]

On Mon, 2004-10-04 at 19:28 +0000, Tiago Cogumbreiro wrote:
> Talking about JNI, you might be interested in GDirect:
> http://www.peakpeak.com/~tromey/blog/2004/05/14#gdirect
> 
> Seems like your idea, if what you want is to get rid of it.

This is nearly exactly what I'm talking about... in fact my approach
uses libffi also. Right now I'm working on it for GObject specifically,
not a general purpose JNI replacement.

Right now my approach is using Java 1.5 metadata and annotations to
decorate Java classes about how they link up to their GObject
equivilent. For instance, the bindings to GtkObject might look like
this:


@GBindClass(Library="gtk-2.0", Name="GObject",
TypeSymbol="gtk_object_get_type")
public class GtkObject extends GObject
{

	@GBindMethod(Name="do_something")
	public abstract void doSomething();

}


At runtime, the metadata for this class would be detected, the specified
library would be loaded with dlopen(), the TypeSymbol would be called in
order to return the GType, and all the method's marked @GBindMethod
would be replaced with proxy's to the underlying method calls.

Since there is no method introspection: at compile time, the .h files
would be scanned, and the .class file would be "enhanced" with
additional metadata that defines what byte offsets the function pointers
for the methods are at.

Creating a new GObject would be as simple as overriding an existing
wrapper.

public class MyNewGObject extends GObject
{

	public void doSomething()
	{
		// do stuff
	}

}

This would create a new GObject in the GObject system with a name like
"__java__package_name_Foo", set up that it inherits from GObject, and
override GObject's methods with libffi generated stubs.

I'm working on some prototype code for this now, to generate GObjects
from thin air at runtime, and to hook up method/signal calls. I don't
have many outstanding issues to figure out before I actually get coding.

Anyways, please comment.