This is the mail archive of the
mailing list for the Java project.
Personal - Yes (Re: Java-Gnome: jni or cni)
- From: Zenaan Harkness <zen at freedbms dot net>
- To: java-gnome-developer at lists dot sourceforge dot net
- Cc: java at gcc dot gnu dot org, debian-java at lists dot debian dot org, kaffe at kaffe dot org, sablevm-developer at lists dot sourceforge dot net, java-gnome-developer at lists dot sourceforge dot net
- Date: Fri, 12 Mar 2004 08:11:41 +1100
- Subject: Personal - Yes (Re: Java-Gnome: jni or cni)
- References: <20040311174441.GA26451@pathfinderii.chu.cam.ac.uk>
On Fri, 2004-03-12 at 04:44, Mark Howard wrote:
> The big question is: should we switch to CNI?
My experience is running through some of the java-gnome tutorials, using
gcj to compile 'native executables'. I just used whatever defaults were
there, and from what you say below it is currently jni. I could go so
I had a bit of an issue when trying to use xercesj - I think I might
have needed to unroll the jar files or something, and I switched to
.class file production, rather than native compilation, and things woked
again. I could go back to native when I switched back to jdom.
If going to cni will make things work more flawlessly/ seamlessly, that
would be a great step I'd say, from a learning something new (and the
And from reading the gcj info docs on CNI (both a year or two ago, and a
couple of months ago again) had me drooling. Essentially the promise is
seamless integration with C++ (and I guess 'hence C').
So, +1 for CNI from me, albeit a limited experience perspective.
> 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)
This doesn't bother me personally. If something is important enough, I'm
happy to start hacking on classpath to achieve what I need.
> JNI runs slower (although it is probably fast enough for basic gui's,
> IMHO. But not e.g. complex TreeModelFilters)
Another +1 for CNI.
> JNI produces large bindings
Not an issue for me. I guess it would be for embedded dev's.
> Ease of development
> JNI is harder to develop
I would vote for the more seamless option, from a newbies point of view.
At the end of the day, I want the least build chain hassle as possible.
Those developing for Windows might have other priorities though I
> Entry barrier/learning curve
> Most users have to compile java-gnome. This requires both gcc and javac.
> For applications, it requires javac. Java developers are used to javac.
> 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.
I've been a full time Java developer (more recently, I have to say "sort
of") since pre-Java-1.0 and Windows 95 - some 8 years ago. Over those
first couple of years, I got my first real taste of proprietary software
lockin, with respect to the garbage collector, and trying to debug the
software I was part of developing at the time:
I could see so clearly that if I'd had source code, I could have written
a GUI object count list for the GC (each .new, add one to the count of
that class) - and then could have added in-memory hierarchy navigation,
This was not an option given Java's (GC) binary status. We had the
option to spend thousands per developer seat to get source code, or make
do. Due to the financial situation of the company, we had to make do.
To this day I have been pissed at SUN.
I realise it was of course my choice to use 'cool' propritatary product
(Java running in Netscape/ IE) that produced those frustrations.
So now I am a little more informed, and damned if I have to use
proprietary products again.
I want *Free Software* thank you very much!
I want *control* over the source code - the ability to instrument,
modify, etc. and to have others be allowed to do that so we can actually
work together (my gosh, what a concept!).
So, my vote is for gcj/cni.
> 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.
One thing I think would be great to see, at least on Debian, is a
distro-wide consistent built/ deployment model for Java - where
everything is Free Software and everything is compiled in the same way -
and for performance reasons I'd like that to be CNI.
> 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
Perhaps you can put up a sign "Free Software Bigots Welcome".
There's plenty out there...