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 ).
Yeah thanks. Please also include my other replies if you see fit.
Done.
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 disagree. Actually there are already quite a couple of (proprietary)
implementations of the Java platform which is also fine for Sun, so why
would it be bad for Java to have a couple more?
The diffrent proprietary implementations are based on Suns Java. So it is
unlikly that they are more different to Suns Java, then having a completly
new and different implementation.
Or to show it with browsers: Safari is also a proprietary browser based on
KHTML. But it is more compatible to Konquerer then to other browsers.
Well, first thing is, the technical POV is not the only one important to
some parties. For example, if Sun would decide to choose to license under
GPL, that would be a problem for a reason for some parties to use Classpath
or Harmony. Then there are already a couple of VMs that are written to use
GNU Classpath and it is probably not trivial to port them to use Sun's
class libraries. Then I'm sure there are even some interesting parts in GNU
Classpath. I'm thinking about the Gnome/Cairo peers that fit better with
common Linux platforms than the Motif based peers that Sun has.
A different you only feel if you use AWT. But if you use Swing there isn't
much different, which peers are used.
I am not sure about GNU Crypto but my feeling is that we cover some areas
that are not covered by Sun there (and vice versa of course).
In this case a merger would be better, I think.
In the future there could also be interesting cooperation, I am think about
the AWT/Swing area here, where GNU Classpath could possibly focus on
specialized peers and Swing L&Fs for Gnome and KDE, while Sun focuses more
on the core or something similar. Likewise for other areas too, where
Classpath and/or Harmony could work one implementing the glue to specific
platforms that Sun doesn't want to care about etc etc.
Hmmm... but I still think, it would be better to use Suns Java then for
other platforms.
There is a difference, if you have one program and port it to different
platforms or if you use a complete new written version
For example there existing NeoOffice, which is a fork of OpenOffice.org. But
they are functional the same. But KOffice and OpenOffice.org are
_completely_ different.
One of the reasons is, that OpenOffice.org and NeoOffice have the most parts
the same code.
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.
I also don't think that it's a good idea to have only one browser. I am
quite happy that there are a couple of them and that everybody can pick
whatever he likes best. I think it's good to have IE, Mozilla, Opera,
Konqueror etc all around. The browser situation actually is a good example
why having several implementations is a good thing. Think when IE had a
marketshare of >95%. This is (arguably was) a time of stagnation,
Webdesigners forced to use ugly hacks to make their pages load etc. Having
more then one implementation in the market produces an interesting
competition and somewhat forces everybody involved to write code that is
portable.
The direction, which new features browser have to implement, makes the W3C.
Since over five years, the W3C have decided, that SVG-files can be shown in
browsers. And how SVG files can be interact with JavaScript andf HTML.
Firefox have implemented SVG. Would Firefox the only browser, then there
would already a lot of SVG-pictures on some sides existing. But now we must
wait until the last browser also supports SVG.
It is also to mention, that SVG isn't fast to implement. And SVG-viewer and
-editors are also different then browser-implementations. So there existing
SVG-files, which you can see in Inkscape, but not with Apache Batik. Or with
Batik, but not with Firefox. Or with Firefox, but not in KDE (KSVG). Or with
KDE and not with GNOME (libsvg or librsvg). Or with GNOME, but not with
Inkscape.
So, if other browsers are also implementing SVG, there would be SVG-files,
which you then also only on one of the browsers can see, but not on the
other one.
And imaging, then the JCP decide, that SVG will be part of Java.
The Harmony people can make use of its Batik. Sun have in its
Java-implementation already Apache-code, so for Suns implementation it would
also no make problems. But Batik is neither under the GNU Classpath license
nor have the autors of it signed the Copyright-Assignment, to give the FSF
the copyright. So then, GNU Classpath would to reimplement also SVG and the
whole problem comes also to Classpath.
The very same thing holds true for Java and actually we already see the bad
effects of the dominance of the Sun implementation, which is that many
developers write their code against undocumented API, against Sun specific
bugs etc etc. That wouldn't be possible when we had several implementations
sharing the market equally.
You are right. All have it pros and contras.
On the other side: If Suns implementation is the only one and OpenSource,
why not document the undocumented API and make it official?
Important is only, that the API isn't platformdependent.
I thinnk what you and Sun (and many other devlopers) actually care about is
not having several implementations of the platform (which we already have,
even outside of the Sun/GNU/Apache world), but the problem of keeping them
together and most importantly _compatible_. That means that a program
written against one implementation should run on other implementations too.
(given that the program doesn't use non-public API and doesn't make use of
bugs/special behaviour of one impl). In order to avoid that, Sun would need
to make the TCK more open. I think this has already been said and I don't
felt the need to repeat this. So what I think would be helpful for Java,
Sun, and the GNU and Apache community is 1) a sane license to allow
cooperation and code exchange and 2) opening up the TCK so that all 3
implementations can be compatible.
You are right, an open TCK would be nice. But the TCK can not test all. And
implementations with the same code, are mostly more compatible to each
other, then implementations with different code.
Or to mention the pixelgraphic-fomat png: As I know, there existing also
only _one_ implementation of png: libpng. All programs are using it. And it
have no disadvantage, of having not a second or third implementation of it.
Respectively one other implementation of it exists. It comes from Microsoft
and Microsoft use it in its InternetExplorer. But that implementation have
problems with transparency in png-files.
Greatings
Patrick -- alias theuserbl
