java-gnome-hackers

[java-gnome-hackers] topic for discussion

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

On Wed, 2004-02-25 at 21:48, Bob Fischer wrote: 
>  3. One might consider building CNI bindings for the GTK+ calls, rather
> than the current JNI bindings.  These would certainly be smaller and
> more efficient when using GCJ.  CNI bindings could also sidestep the
> dynamic library loading problems I experienced (although I sidestepped
> them without CNI).  However, the added work of keeping two sets of
> bindings up to date might not be worth it.

This is something that I have thought about for a very long time.
There are many pros and cons to support CNI. I would like to know
what each of you think.

-Jeff

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

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

On Thu, 2004-02-26 at 20:19, Jeffrey Morgan wrote:
> On Wed, 2004-02-25 at 21:48, Bob Fischer wrote: 
> >  3. One might consider building CNI bindings for the GTK+ calls, rather
> > than the current JNI bindings.  These would certainly be smaller and
> > more efficient when using GCJ.  CNI bindings could also sidestep the
> > dynamic library loading problems I experienced (although I sidestepped
> > them without CNI).  However, the added work of keeping two sets of
> > bindings up to date might not be worth it.
> 
> This is something that I have thought about for a very long time.
> There are many pros and cons to support CNI. I would like to know
> what each of you think.
> 

I would really like to have a good debate about this.  The debate
is should we continue to support only JNI, should we support only
CNI, or should we try to support both.  This will have a significant
impact on our project and should be decided soon.

The core questions are "How will developers be using our bindings?"
and "How will they want to distribute these applications?".  Should
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?

Pros/Cons
JNI only - JNI runs slower and producers larger bindings.  JNI is also
harder to develop than CNI.  On the plus side our bindings will work
with all open source and commercial JVMs.

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.

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.

Please let me know what you think.  Also, should we take this 
debate to the developers list?

-Jeff

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

[Mark H. <mh...@ca...>]

Hello,

First I must say that I know nothing of CNI - before looking at
java-gnome, I didn't know any details of JNI either.

CNI does sound very interesting.

Do CNI apps not use a jvm at all then? Could you please give a summary
of what CNI is/how it works; or point to a website about it (a short one
preferably)

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.

> Pros/Cons

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

> 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.

> 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? 

> 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?

> 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.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

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

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

CNI is the 'standard' native bindings that are provided by gcj.
gcj does provide a compatibility capability with JNI and this is
what we use (the -fjni option).  CNI is C++ instead of C.  The
best way to understand is to read some of the documentation.  Here
are links to an article describing it and to the documentation
on the gcj site:

http://www.linuxjournal.com/article.php?sid=4860
http://gcc.gnu.org/onlinedocs/gcj/About-CNI.html

Please take the opportunity to read both of these and then
we can discuss details on this list.

On Sat, 2004-02-28 at 12:28, Mark Howard wrote:
> Hello,
> 
> First I must say that I know nothing of CNI - before looking at
> java-gnome, I didn't know any details of JNI either.
> 
> CNI does sound very interesting.
> 
> Do CNI apps not use a jvm at all then? Could you please give a summary
> of what CNI is/how it works; or point to a website about it (a short one
> preferably)
> 
> 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.
> 
> > Pros/Cons
> 
> > JNI only - JNI runs slower and producers larger bindings.  JNI is also
> Do you have any figures for performance?
> 
> > 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.
> 
> > 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? 
> 
> > 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?
> 
> > 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.

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.

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

[Luca De R. <pie...@li...>]

Il sab, 2004-02-28 alle 18:31, Jeffrey Morgan ha scritto:
> 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.
Easier support and distribution sounds good to me, and also the
performance speed up.
If gcj can compile the most of the apps around, that's fine and it seems
that we will only have benefits from this move. (When I've tried to
compile cromagnon with a 1 year old gcj, it failed because of
unimplemented classes, but AFAIK the situation now is way better).
-- 
Luca De Rugeriis <pie...@li...>