Hi Roman.
Now I have a little bit time, to reply to your comment (I will also write
this reply in the forum at
http://forums.java.net/jive/thread.jspa?threadID=18036&tstart=0 ).
What I'd find best for Java is something like we have in the BSD world.
Friendly competing communities, with code flowing freely in all directions.
Something similar would be healthy for Java too, having 3 implementations
in friendly competetion with code flowing between them as it fits.
I think three different OpenSource implementations would be the worst case
scenario, if Sun makes its Java OpenSource.
Ans I also think, that Suns sees so like I. And I think they want to make it
OpenSource, to have _not_ three different implementations.
I'd really like to see Sun, Harmony and Classpath developing and improving
Java, all in their own ways and using their own methods.
And in which part is the GNU Classpath implementation better then Suns
implementation? (from the technical point of view, not from the license
side) ?
Of course, when GNU, Sun and Apache can get together to work on one
implementation, that would be great, but very very unlikely. Just as
unlikely as a Gnome-KDE merger, or a Linux/*BSD/Hurd merger, etc.
You can not compare the GNOME/KDE situation or the
Linux/*BSD/HURD/OpenSolaris situation with the Java situation. It is
completely different.
To want a GNOME/KDE merger is like wanting a Java/.NET merger.
The difference is, that a GNOME/KDE merker and a Java-implementations-merger
is, that there existing only _one_ GNOME and _one_ KDE. And the programs
written for GNOME and KDE is so only written for this one and only
implementation. You can not parts of GNOME programs running with KDE-libs
and the other way around.
A good comparision of the different Java-implementations would be the
situation with the different Browsers. All Internet-Browsers want to show
the internet-sides. So all takes the same resources and wants to do the same
with it.
So lets look at the Browser-situation:
Ten years ago I tried to create my first homepage.
At first it was something simple. Using <b>bold</b>, <i>italic</i> and other
commands like <br>.
Then there comes frames, textfields and so on. But how more complex it is,
how more differes that what the InternetExmplorer show and that what
Netscape show.
Then there comes some gimmiks in Javascript.
Here are for example some sides with Javascript programs for the homepage:
http://www.ramnip.net/js.html
http://www.lipfert-malik.de/webdesign/tutorial/javascript.html
Sorry, that I have find at the moment only this two sides. But today it
isn't any more so much used like for some years and so there don't existing
no longer so much sides about it.
What you see on this side is, that there is code where stand after it "for
all browsers", some code where stand "only IE" and some code where stand
"only Netscape".
On other sides about JavaScript, there stands how to find out, which browser
is used and writes then with if-else commands, for every browser own code,
so that at the result, the side was shown with both browsers similar.
Important is, that Netscape shows the side on all operating systems
likewise. Only the IE looks different.
It is still today so, that different browsers show the sides different. In
particular if they the homepages using Javascript or other things, which
makes the sides a little bit more complex.
Additional we have today four different browser-rendering engines: IE, Gecko
(Firefox, MozillaSuite/SeaMonkey, ...), KHTML (Konquerer, Safari, ...) and
Opera.
And it is not so, that only Microsoft with its IE going its own way. The
other three browsers show also all the sides different. But the browsers
itself showing the side on all operating systems identical. Firefox/Linux
shows it like Firefox/Windows. Opera/Windows like Opera/Linux.
The webdesigner used and use the least lowest common denominator, so that
all internet-sides are looking equal on all browsers. And I have heard, that
webdisigner having all browsers installed on its system.
Today JavaScript is mentiond in association with Web 2.0 and so.
Mostly things are today written on server-side, so that the clients become
only for the browsers easy-to-understand-sides.
Now have a look at the current situation of Java (only looking at Suns
Java):
Java consists of a little platform-dependent part including the JVM, AWT,
etc and a big platformindependent part including Swing, Java2D and so.
There existing programs which which run on Java 1.1, but no longer since
Java 1.2. But the downward compatibility have also been in the last years
better.
The Java-developer can writes its code for Java 5 and it is very likely that
it runs also on any other platform with Java 5.
They only must now install also Java 6 beta to look if its program running
still on the new Java. If not, then sending a bug-report to Sun or changing
the own program.
Until today GNU Classpath makes sence, because it is an OpenSource
Java-implementation and Suns Java isn't OpenSource.
And it is not only a Java-implementation it is in parts a rewrite of Suns
Java. As i know, there is nowhere defined in any book how the ocean-theme
looks like. Only the old metal theme is defined at
http://java.sun.com/products/jlf/
So in parts GNU Classpath is not only a implementation of what the JCP
defines, its a rewrite of that, what Suns have done.
But until Sun makes its Java implementation OpenSource, then the situation
is different.
The advantage of GNU Classpath over Suns Java is the license. After Suns
Java is OpenSource, this advantage no longer exists.
And to try to rewrite Suns Java can GNU Classpath not make better then Suns
Java. So why then using GNU Classpath?
An additional problem would be that, what already with the browsers exists.
Developer would try its programs not only on Suns implementation, they also
must try it with GNU Classpath and Apache Harmony --- write once, test
thrice.
It isn't enough, that the JCP exists and defindes how Java have to look
like. For the web existing also the W3C and the browser-engines are all
different.
Until a special point all three Java-implementations will be equal. But
especially if new things would be implemented, it would inhibits the
evolution of Java.
A chain is only so strong like it flimsiest limb.
And the newest features of Java will only be of all developers used, if the
last Java-implementation have included it.
So I think, that - if Sun makes its Java OpenSource - it would be a bad
thing, if then GNU Classpath and Apache Harmony still exists.
An additional questions would be: Which distribution would including a GNU
Classpath based Java, when Suns reference-implementation is already
OpenSource.
LessTif also still exists and the most distribution are including OpenMotif
instead. And that though OpenMotif isn't OpenSource. It can only be used on
OpenSource operating systems without paying. And only for OpenSource-systems
the license is similar to OpenSource - but not OpenSource.
Greatings
Patrick -- alias theuserbl
