Re: [java-gnome-hackers] topic for discussion

[Jeffrey M. <ku...@zo...>]

On Sat, 2004-02-28 at 12:28, Mark Howard wrote:
> On Sat, Feb 28, 2004 at 10:45:08AM -0500, Jeffrey Morgan wrote:
> > The core questions are "How will developers be using our bindings?"
> Gnome/Linux apps - always have gcc; don't often have a jvm.
> Embedded apps - low memory
> Windows apps? (But would require compiled gtk)
> 
> > our bindings work with standard JVMs or should we take the approach
> > that our bindings and all applications should that use them should
> > use the gcc suite?
> I recently released by bugwatcher app to Debian. Trying to support all
> jvms will be virtually impossible. "Forcing" our users to use gcc might
> be beneficial in terms of support.

My thought exactly.  If I were going to develop an application using
java-gnome I would only compile it to binary.  This makes distribution
and support much easier.  You don't need to worry if users have the
'correct' jvm on their system and you don't need to worry about things
like classpaths and if all libs are in the LD_LIBRAY_PATH.

> 
> > Pros/Cons
> 
> > JNI only - JNI runs slower and producers larger bindings.  JNI is also
> Do you have any figures for performance?

There are many testimonials on the gcj site and elsewhere.

> > harder to develop than CNI.  On the plus side our bindings will work
> > with all open source and commercial JVMs.
> This is fallacy. I think we should really avoid phrases like this. It
> makes people think that java-gnome may run under windows. Java-Gnome
> requires gtk/gnome; therefore we require both gcc and some jvm.

very ture.

> 
> > CNI only - CNI will run faster, produce smaller bindings, and is
> > easier to write.  Also, our build process will be significantly 
> > simpler since we will not need to detect and set as many compile
> > alternatives.  On the down side our bindings will only work with 
> > gcc/gcj.
> So all applications also have to be compiled to native code with gcj? 

They would have to be compiled to native code or they would need
to be compiled to bytecode and ran with gij.

> 
> > JNI and CNI bindings - You get the option of choosing the native
> > code you wish.  The down side is that we have to maintain the 
> > native layer in two locations and we add yet another complexity
> > to our build process.
> An example of java-gnome changes to say one class would be good to see -
> what would be involved?

I have already prototyped several classes in order to fully understand
what is involved.  I also think much of the changes could be automated.
I have been in discussions with Per Bothner (the primary developer of
gcj) about the best way to go about this.  I will include his suggestion
at the bottom of this email.

> 
> > Please let me know what you think.  Also, should we take this 
> > debate to the developers list?
> There are probably quite a few people on the developers list who know
> more about jni/cni than I do, so I'd say yes.

I will post to the list later today.


Per Bothner's email
-------------------
You could try it in two steps:

(1) convert the function headers.  Thus:

JNIEXPORT jboolean JNICALL 
Java_org_gnu_gnomevte_Terminal_vte_1terminal_1get_1us
ing_1xft
   (JNIEnv *env, jclass klass, jint handle){
   ...
}

becomes:

jboolean
org::gnu::gnomevte::Terminal::vte_terminal_get_using_xft(jint handle)
{
   JNIEnv *env
     = _Jv_GetJNIEnvNewFrame(&org::gnu::gnomevte::Terminal::class$);
   ...
}

This can be done mechanically with a simple filter.  You might want
to add some macros or annotation to make it easier for a future
version of the filter to generate either JNI or CNI.

I'm hoping this initial conversion will allow the code to compile
as valid CNI, and the result should by itself be a performance
improvement, since you skip the searching for the correct C function
and some extra indirection.

(2) Get rid of the need for the JNIEnv.  That's harder to do generally.
A lot of the JNI methods have very corresponding Jv methods, and they
are simple to convert mechanically.  Looking and access/invoking
fields and methods is trickier, but I'm sure we can find solutions.