[kaffe] Re: [Java-gnome-developer] Java-Gnome: jni or cni

Elias Martenson elias-m at algonet.se
Fri Mar 12 02:23:25 PST 2004


fre 2004-03-12 klockan 03.07 skrev Tom Tromey:

> >>>>> "Elias" =3D=3D Elias Martenson <elias-m at algonet.se> writes:
>=20
> Elias> Going CNI-only would severely limit the number of 3'rd
> Elias> party component you'd be able to integrate.
>=20
> You can mix and match CNI and JNI in a single process.  This happens
> any time you use JNI in libgcj.  Maybe you meant to say that going CNI
> only would mean that you couldn't use java-gnome on non-libgcj
> runtimes, which is true.

You misunderstood what I said. You seem to believe that I'm putting down
the efforts of the GCJ project.

What I meant was that if I have a 3'rd party component, say a
high-performance JDBC driver, which happens to use JDK 1.4 IO channels,
JDBC 3.0 rowsets and JDK 1.5 code instrumentation, I want to be able to
use it with Java-GNOME. If GCJ was a requirement for Java-GNOME, then I
would have to wait until you guys support JDK 1.5. Considering the fact
you aren't even up to 1.4 level yet, I think I'd have to wait a long
time.

I'm not dissing the GCJ efforts at all. GCJ has some advantages and some
disadvantages. Whether you should use it depends on the circumstances.
In particular, current PDA's need it, as has been proven on this mailing
list.

> Elias> The fact that Java is heavily dynamic (sandboxed execution, etc...=
) is
> Elias> an enormous advantage, and I fail to see how an experienced Java
> Elias> developer who uses these things could ever even consider turning t=
he
> Elias> back on everything that is Java, just to gain a little perceived
> Elias> performance.
>=20
> This is a common misconception of what gcj is all about.
>=20
> It's true that the AOT compiler is the centerpiece of the gcj
> approach.  And it is also true that historically this meant less than
> perfect compatibility with the Java specification.

To be fair, I'm quite amazed at the results you have achieved so far.
The goal should always be to reach 100% compatibility, which is extra
hard when one has to play catchup all the time. Are you involved in the
JCP at all?

> However, it has always been our plan to provide a complete, compatible
> Java system.  This year we are making great strides in this area.  In
> particular the new binary compatibility ABI will let us erase the few
> remaining semantic differences; in essence gcj will look like a sort
> of caching JIT more than a pure AOT compiler.

I'm aware of this. However, the discussion is not really about AOT vs.
VM execution. It's not even about GCJ vs. JDK. It's abut CNI vs. JNI.

GCJ does JNI and CNI. Other platforms do JNI only. Based on this the
choice should be pretty clear, don't you think?

> Second, for me at least, the primary consideration isn't the features,
> the performance, or any facet of the implementation (including even
> AOT compilation if it comes to that).  The primary thing is freedom.
> Based on what you say, it sounds like we have different priorities
> here.

Not at all. Unless we define freedom differently. :-)  My focus is
"freedom of choice". I want to be able to choose the Sun JVM, at least
at the current point in time. Other people (esp. the PDA people) wants
to choose GCJ.

Regards

Elias M=C3=A5rtenson






More information about the kaffe mailing list