[kaffe] Java-Gnome: jni or cni

Fri Mar 12 03:51:00 GMT 2004

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

Let's not be so innocent. ;-) Sun makes big money by licensing its
implementation of the JRE and JDK to IBM (AIX, PowerPC), HP (PA-RISC), BEA
(Jrockit) and lots of JVMs for embebbed, PDA and cellphone space. Having an
open source JRE and or JDK which delivers almost 100% specs compatibility would
ruin this market, just like Linux is ruining the market for proprietary
embebbed OSes. The use of com.sun packages and divergences between Sun JRE and
it's own Java specs may not be accidental, they may be part of a vendor lock-in
strategy. But don't take me too literaly.
Sun is very afraid of fragmentation. Not fragmentation of the Java language,
forking into different, mutually incompatible implementations. It's afraid of
forking it's licensees, each one choosing a different base JRE for their
porting efforts.
As was stated on many e-zines recently, A GPL or LGPL JRE would prevent any
incompatible fork from a single vendor, but would promote evolution. For
example, lots of Java developers hate Swing, but Sun choose it and won't give
up. If this decision weren't Sun's own, but were given to the community, to the
market, or to an indepdent standards group, maybe SWT would become the
"standard" GUI toolkit for Java. Would this be bad? IMO, just as bad as moving
from AWT to Swing -- sometimes a solution proves to be bad, and you need
another solution.
On another scenario, maybe IBM would build a new Swing implementation, using
native base widgets (just like SWT), but almost 100 compatible to the Swing
API, thus bringing what people wanted (performance and native look and feel)
without sacrificing compatibility and WORA. Sun's original "more Java" Swing
would still be an option for when porting something as big as SWT were too costly.
If does the hypotetical native-Swing break compatibility with a few APIs? Well,
I know some Java1.1 Swing apps that won't run on Java2. Sun also sometimes
breaks compatibility on newer releases of their own APIs. Anyway, the current
license for Java prevents anyone from building a native-Swing, but the
"nonstandard" SWT do not violates the license. An OSS Java would not prevent
users and developers from evaluating such alternative.
[]s, Fernando Lozano