[kaffe] Java-Gnome: jni or cni
Fri Mar 12 20:35:00 GMT 2004
On Friday 12 March 2004 03:27, Tom Tromey wrote:
> >>>>> "Chris" == Chris Gray <email@example.com> 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.
Indeed the published specs come nowhere close to guaranteeing WORA. And due
to the dominance of one proprietary implementation, developers tend naturally
to use that as the touchstone of "correctness".
Nonetheless, a good level of WOCRAC (write once carefully, run anywhere
conditionally) can be achieved in practice; and one hopes that with the rise
of free Java platforms developers will learn to be more careful. I don't
think you can use the weakness of the Java standardisation process to justify
deliberately ignoring parts of the standard and doing something else instead.
> 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.
Probably most VMs that support JNI also support some kind of "own" native
interface too - Wonka has its WNI, Jamaica has JBI (Jamaica Binary
Interface), etc.. Similarly, Java core library implementations generally
have an equivalent to com.sun.* (e.g. gnu.* or wonka.*). But a project like
java-gnome shouldn't depend on these, just as ant shouldn't depend on
com.sun.*. Then it ceases to be java-gnome and becomes cni-gnome instead.
All the best,
Chris Gray /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi http://www.kiffer.be/k/
firstname.lastname@example.org +32 3 216 0369
More information about the Java