[Kde-java] Qt/KDE java bindings: jni or cni

[Richard Dale]

As I maintain the Qt/KDE java bindings, which currently use JNI, I found this 
Java-Gnome discussion very interesting. We face exactly the same issues about 
the pros and cons of the Sun's jdk vs. gcj, and JNI vs CNI. Mark has done an 
excellent summary, and I forwarded it to the kde-java mailing list.

On Thursday 11 March 2004 17:44, Mark Howard wrote:
> The big question is: should we switch to CNI?
...
>
> The current discussions can be found at [1] and [2]. I will try to
> summarise some of the main points below.
>
> [1] http://sourceforge.net/mailarchive/forum.php?forum_id=5689
>     (subject: What's next)
> [2] http://sourceforge.net/mailarchive/forum.php?forum_id=11301
>     (subject: What's next, migration to cni, topic for discussion)
> 	Migration to CNI thread contains details of three options with
> 	exaple code.
>
Another approach is to use dynamic proxies to avoid the need for a native java 
method for each method in the api being wrapped. Then the only method that 
needs to be native is Proxy.invoke() - you can funnel every api call into a 
single method invocation.

Currently the bindings use JNI like this:

	public native int minimumWidth();

JNIEXPORT jint JNICALL
Java_org_kde_qt_QWidget_minimumWidth(JNIEnv* env, jobject obj)
{
	jint xret = (jint) ((QWidget*) QtSupport::getQt(env, obj))->minimumWidth();
	return xret;
}

The next version will look like this:

	public int minimumWidth() {
		return proxyQWidget().minimumWidth();
	}

A proxy is instantiated for each instance, and all calls are forwarded to it. 
A second proxy is used for static methods, one instance per class.
Instead of 22000 JNI methods as at present there should be more like 22 at 
most. So it will be much easier to offer both JNI and CNI bindings because 
nearly all the code will be exactly the same.

The bindings will use KDE's 'Smoke' library which is an automatically 
generated language independent dynamic runtime for Qt/KDE (used for ruby and 
perl bindings at present). 

To do something similar for Gnome, you would need to be able to look up gtk 
function pointer given the name of the java method call. I assume you don't 
have to worry about overloaded method names as it's a C api, but for KDE the 
lookup has to been on the arg types as well as the name.

> Alternative java guis - we want people to choose java-gnome:
>   * Java-Gnome
>   * Classpath's Swing
>   * Sun's Swing
>   * IBM's SWT
> also, we want gnome developers to choose java-gnome :)
But don't forget the Qt/KDE java bindings! - they are actively maintained for 
each KDE release including the recent KDE 3.2. The QtJava part is also 
crossplatform, and I wouldn't be surprised if it was more complete than SWT.

-- Richard