Java-Gnome: jni or cni

[Mark Howard <mh at debian dot org>]

Dear Java Developers,

I am writing to you on behalf of the java-gnome project for advice
regarding a major change we are currently considering. I apologise if
this is off topic for this mailing list but we really need input and you
are the most knowledgeable open source java developers; it may also
help determine whether we will be using your projects in the future.
Sorry for cross posting - we think members of each list are likely to
have different opinions on this topic and want to hear them all.

The big question is: should we switch to CNI?

Java-Gnome is a set of libraries for creating GTK/GNOME based
applications in java. It is different from SWT in that it aims to
implement the entire gnome libraries so will be able to create
applications with integrate fully with gnome. It is different from swing
in that it is completely free and has a high quality graphical interface
builder tool (glade).

At the moment, java-gnome uses jni to communicate with the gtk/gnome
libraries. This works well with good performance but makes the build
process very difficult and also makes the task of application developers
more difficult since they are trying to support many jvms.

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.


Our users
- gnome/linux apps - always have gcc; rarely have a jvm
- embedded - want as small as possible (but java-gnome might not be
  suitable anyway). Need a jvm for security/sandboxing?
- Windows - nobody has tried yet but everyone likes the idea 
  (would a CNI approach ever work on windows?)

JVM support
JNI supports most JVMs. The library has to be compiled with two
compilers (gcc + "javac"), which is tricky
CNI requires everything to be compiled with GCJ, including applications.
This means that some features found only in sun's latest jvm will not be
available (in particular, classpath is quite outdated)

Performance
JNI runs slower (although it is probably fast enough for basic gui's,
IMHO. But not e.g. complex TreeModelFilters)

Size
JNI produces large bindings

Ease of development
JNI is harder to develop

Entry barrier/learning curve
-compilation
Most users have to compile java-gnome. This requires both gcc and javac.
For applications, it requires javac. Java developers are used to javac. 
-use
Eclipse, debuggers, other java tools
Java developers know (and like?) these. open source ones are probably
better once people get to know them.
eclipe use (+debug/profile) may still be possible with the cdt plugin
for eclipse.

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 :) 

Combined CNI & JNI approach (possibly generating code)
Added complexity for us and our build process.
Worst of both worlds?
Would not be possible to optimise for either cni or jni.
Please see java-gnome ml archives for details - then suggest something
else if you have an idea of another way to do this.


Java-Gnome developers are currently unsure about what to do. We like the
idea of cni but it sounds risky. That's why we're asking for your input.
Thank you in advance for taking the time to read this and hopefully
responding.

http://java-gnome.sf.net

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh@debian.org | mh@tildemh.com | mh344@cam.ac.uk

Attachment: signature.asc
Description: Digital signature