[kaffe] Java-Gnome: jni or cni

Tom Tromey tromey@redhat.com
Fri Mar 12 02:39:00 GMT 2004

>>>>> "Chris" == Chris Gray <chris@kiffer.eunet.be> writes:

I trimmed the follow-ups on this since it isn't really java-gnome
related.  I chose the gcj list since the classpath list, which seems
to be our clearinghouse for this sort of thing atm, is experiencing
lengthy delays.

Chris> Frankly this sounds to me like the worse kind of
Chris> embrace-and-extend; it will result in the emergence of a set of
Chris> "Java" programs which run only on certain implementations of
Chris> Java.  Hm, hasn't that been tried before?

First of all, let's note that there are plenty of Java programs which
fall into cracks in the various Java specifications and are not, in
fact, WORA.

For instance, you can wind up in this situation if you make
assumptions about how eagerly or lazily classes are loaded, something
the VM is explicitly allowed to control.  Eclipse 2.x has at least one
bug in this area.

Don't get me wrong, Java is actually very good in this regard; it is
one of Java's strengths.  But the idea that existing Java programs are
VM-independent doesn't turn out to be true in practice.  It's more
accurate to say that non-Sun VM implementors generally try for
compatibility, even when explicitly not required by the spec, to
preserve the illusion of WORA and to work around buggy applications.

You can also see this by the number of programs that rely on
com.sun.*.  Even ant does this.

Chris> Some people inside Sun seem to think that open source Java is a
Chris> Bad Idea, because it risks fragmenting the language.  Until
Chris> today, I thought they were just imagining things ...

IMO, they are :-).

I think one of the big messages of the Free Java movement has to be
that we all recognize the value of an unfragmented platform.  And so
far I think it is clear that all our (the bigger "our" including not
just libgcj but classpath, kaffe, etc) intentions point that way.  We
run scripts to ensure API compatibility with the JDK, we write test
suites and test the JDK against them, there's stuff like the Java Spec
Report, etc.

Frankly I don't see fragmentation as a big issue.  Sure, in a purely
Free Java world, people would be free to fragment.  But I think any
such forks, at least in the free OS space, would either be relatively
trivial (particular bug fixes in a particular OS distribution) or
generally ignored.

Anyway, I definitely don't see CNI as some major threat.  As far as I
know nothing requires a VM to supply a single native interface.
Whether or not you want to tie your application or library to a single
VM is, IMO, a decision to be made based upon your goals.  Practically
speaking most Java applications seem to have relatively little native
code, rewriting to use another interface probably isn't a big deal.


More information about the Java mailing list