> Durch die Kontrolle über den Quellcode wollte Sun vor > allem verhindern, dass zueinander inkompatible > Java-Implementationen entstehen.
Damit erreichen die aber das genaue Gegenteil!
Andere Implementierungen entstehen nicht ohne Grund. Im Moment gibt es aber einen sehr guten Grund andere Implementierungen zu entwickeln - nämlich weil das Original unfrei ist...
Andererseits, wieviele zueinander inkompatible Implementierungen gibt es von OpenOffice.org? Denkt mal drüber nach, ihr bei SUN.
Ob Quellcode frei oder nicht-frei ist nur ein Aspekt, der die Fragmentierung beeinflusst. Ein weiterer mindestens ebenso wichtiger Aspekt ist die Standardisierung als Communityprozess. Und da hat Java mit JCP die besten Karten. Das ist meines erachtens übrigens auch einer der Hauptgründe, warum Java sich im Vergleich zu DotNet noch so gut behaupten kann (obwohl es naturgemäß die schlechtere technische Basis hat, da älter).
Mit der Freigabe würde es den nächsten Schub für Java und gegen DotNet geben.
Nun ja - ich würde sagen, dass Java gerade mit der Enterprise Edition und entsprechenden Lösungen drumherum ein ganz gutes Pferd im Stall hat. Und im Bereich mobiler Endgeräte ist J2ME ja quasi schon Standard. Zudem sind u.a. die Annotationen in Java 5 wirklich ziemlich nett.
Das soll nicht heißen, dass Dot.Net schlecht wäre, aber ich sehe die beiden Sprachen doch eher Kopf an Kopf.
und welche Funktion erfüllen Handys bei "fast" allen Privatnutzern, welche den Löwenanteil des Handymarktes ausmachen, genau ne Telefonzelle, mit Telegrammdienst und ner riesen Menge Spielkram.
Ich denke da an verschiedene populäre Distributionen die erst mal alles patchen(vanilla-Kernel irgendwo) bevor sie ihren Namen draufschreiben. Deswegen sind diese Bedenken gar nicht mal so abwegig. Wer sagt denn, dass dann nicht morgen [Name einer populären Distribution hier] das JRE an seinen Code anpasst (damit es für Einsteiger leichter ist, jaja) und nicht umgekehrt?
Andererseits, wieviele zueinander inkompatible Implementierungen gibt es von OpenOffice.org? Denkt mal drüber nach, ihr bei SUN.
Versteh ich nicht. Wie kannst du denn das inkompatibel machen? Definier mal in dem Zusammenhang "kompatibel". Wenn ich mir die Werbung zu [Name einer populären Distribution hier] durchlese ist OOo sogar kompatibel zu MS Office.
Von Anonymous Coward am Mi, 19. Juli 2006 um 10:50 #
Man könnte z. B. das Dateiformat ändern. OpenOffice implementiert nicht den ganzen ODF-Standard (deswegen klapt der Datenaustausch zwischen KOffice und OpenOffice so schlecht), also könnte man diese Features in einem Fork implementieren und schon wären diese beiden inkompatibel. Davon abgesehen wüsste ich spontan keinen Grund, wieso man das JRE patchen sollte. In den Kernel werden ja neue Features, Treiber usw. reingepackt, beim JRE will man einfach nur, dass die Programme laufen. Außer natürlich man ist Entwickler, aber ich wüsste nicht, wieso ein Entwickler an Java ernsthaft was verändern wollen würde. Es gibt ja noch genügend andere Sprachen...
Von The Roadrunner am Mi, 19. Juli 2006 um 10:14 #
Für Sun ist es in erster Linie wichtig, dass der freigegebene Code keine Rechte Dritter verletzt, wozu eine umfassende Überprüfung des ganzen Codes stattfinden muss.
Ist fuer mich nicht ganz nachvollziehbar; weiss etwa sun selber nicht, ob sie code geklaut haben oder nicht? Sollten andere firmen code mit eingebracht haben, wieso sind diese dann nicht erwaehnt worden, es ist ja schliesslich alles unter den namen sun gepackt worden?
Firmen kaufen gerne Teile von Dritten zu. Das ist durchaus sinnvoll und üblich. Wenn sie diese Teile nicht mit allen Rechten erworben haben -was auch normal ist- werden sie auf ihre Zulieferer Rücksicht nehmen müssen.
Es ist auch lobenswert das sie erst denken und kontrollieren bevor sie handeln.
Na hör mal, bist Du so naiv oder tust Du nur so ? Würdest Du als Chef einer 100-Mann-Klitsche für alle Deine Programmierer garantieren können, daß die alle noch nie überhaupt nicht irgendwelchen Sourcecode z.B. von ihrer Vorgängerfirma irgendwo mitgenommen und irgendwie reingepfriemelt haben ? Arbeitsvertrag hin, Haftung her. So lange der Source-Code versteckt ist, ist das relativ Wurst. Aber wenn das offengelegt wird, lohnt es sich wahrscheinlich, noch einmal eine Runde zu drehen. Ob das dann wasserdicht ist, was da rauskommt, ist eine andere Frage.
Ich wette mit Dir, daß bei Microsoft-Code das eine oder andere Stück ...
Weil die OSI nur eine Marketingkampagne für Freie Software ist, aus dem FAQ der OSI: "The Open Source Initiative is a marketing program for free software." Womit wir wieder bei Freier Software sind, was von der FSF definiert wurde.
Haben die ne Entwicklungsabteilung aus 2 Mann oder wie kommen diese Prognosen zustande? Wenn man Software entwickelt und Komponenten Dritter verwendet, wird das bereits zur Entwicklungszeit ordentlich dokumentiert. Diesem Argument glaube ich also eher nicht, einen Überblick darüber werden sie bisher schon haben.
Es sieht mir irgendwie danach aus, als hätte man diesen weit in der Zukunft liegenden Termin gewählt, um zum einen bereits jetzt als "der große Quellcodefreigeber" dazustehen und zum anderen ab sofort Entwicklerkapazitäten für die Alternativprodukte zumindest in Zweifel zu ziehen. Und was passiert dann, wenn man sich im Juni 2007 (oder vielleicht vertröstet man bis dahin noch ein paar mal) dann doch umentscheidet?
Vor allem: Wo ist das "Stück für Stück"? Die ersten Teile könnten sie doch schon heute veröffntlichen. Es wird doch bestimmt Java-Klassen geben, wo sie wissen, daß sie sie zu 100% selber entwickelt haben.
Außerdem sagt Sun (und somit auch Jonathan Schartz) immer wieder, daß sie Angst vor Forks haben und diese verhindern wollen. OpenSource-Software erlaubt soetwas jedoch ausdrücklich!
Wie sie diesen Widerspruch beseitigen wollen, ist mir unklar.
Aber deren Strategie scheint aufzugehen. Classpath 0.91 läuft noch gut und stabil.
Aber wer sich mal die dadrauffolgenden Snapshots angesehen hat, wird feststellen, daß seit der Ankündigfung von Sun, Java unter eine OpenSource-Lizenz stellen zu wollen, die Qualität von GNU Classpath merklich nachgelassen hat.
Nana, das war jetzt aber Verschwörungstheorie. Bei Classpath sitzt RedHat doch dick am Tisch usw. Egal, was jetzt demnächst kommt, die 0.92 wird Massstäbe setzen.
Sicher, ob sowas hier kann man sich eher täuschen http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-classpath.html sieht nicht schlecht aus.
und dabei immer bedenken mit welcher Geschwindigkeit da jetzt implementiert wird. Da muss man nicht fragen wie es jetzt aussieht, sondern wie es in einem Jahr aussehen wird bzw. wie es noch vor einem Jahr aussah.
Und da ja nun auch Swing respektable läuft wird mit 0.92 sich die Statistik sicher noch verbessern. Man teste nur mal http://developer.classpath.org/mediation/FreeSwingTestApps
Die Lizenz darf sich Sun als Inhaber der Urheberrechte - so sehr es missfallen wird - leider nach wie vor selbst aussuchen
Dein Vorposter hat gar nichts anderes behauptet; er hat lediglich darauf verwiesen, daß es GÜNSTIGER wäre, wenn Sun in ihrem Großmute eine geeignete Lizenz wählen würden.
Und das hat jeder andere auch so gelesen und verstanden.
> Für Sun ist es in erster Linie wichtig, dass der freigegebene Code keine Rechte Dritter verletzt, wozu eine umfassende Überprüfung des ganzen Codes stattfinden muss.
Wetten, daß die wieder umkippen und Java doch nicht freigeben?
Viele Dinge in Java gab es schon in Ada, z.B. Packages, Threads. Und das für mich Schöne an Ada ist, es gibt sehr gute und auch freie Kompiler dafür. Ada ist z.B. auch fähig Harte Echtzeit zu bewältigen. Und die Kompiler habne eine sher strenge Syntaxprüfung.
Java ist doch nur für Weichspüler und Internet-Teletuppys!
Wichtige Anwendungen werden in richtigen Sprachen geschrieben, oder ist die Steuerungssoftware vom F90-Jäger aus Java zusammengeklickt. Nein! Hier wurde Ada benutzt, und dann wurde der Assemblercode _zeilenweise_, und das ist wichtig!!!, von Hand überprüft.
Von mir aus kann sich SUN Java ans Knie nageln. Dafür sollten sie lieber mehr Kraft in ihren Fortran-Kompiler stecken, die Norm gibt es seit Januar 2004, und kein aktueller Kompiler ist konform.
Wenn du eine logischen Programmierfehler machst und eine 48bit Zahl in eine 16bit Zahl ungeprüft umwandelst steigt die jeder kompiler aus. Das können die Dinger nicht erkennen. Und aus diesem Grunde drehte der Kreiselkompass auch lustig seine Runden ...
Dies war aber kein Problem der Sprache, sondern dass Software ungeprüft übernommen wurde.
> Ada ist z.B. auch fähig Harte Echtzeit zu bewältigen Das heißt, wenn ich mein Programm in Ada schreibe, bringt das den Rest meines Systems dazu, die Abarbeitung von Interrupts zu unterbrechen oder die Abarbeitung von Systemcalls rechtzeitig zu unterbrechen? :)
Oder sind Adaoptimizer so gut, daß sich jeder Algorithmus zu O(1) zusammenfassen läßt? *g*
> Das heißt, wenn ich mein Programm in Ada schreibe, bringt das den Rest meines Systems dazu, die Abarbeitung > von Interrupts zu unterbrechen oder die Abarbeitung von Systemcalls rechtzeitig zu unterbrechen?:)
Leute, wird sind doch alle nicht auf der Wurstbrühe hergeschwommen! Es ist doch klar, dass ein normales PC-Linux, egal von RotHUt, Susi, oder Deb*** für Harte Echtzeit ausgerüstet ist. Da kann dann auch das tolle Ada nichts ausrichten.
Was ich wollte war nur auszudrücken, dass Java nicht der Nabel der Welt ist.
Ich als Mathematikstudent, obwohl ich mich in die Algebra spezialisiere, muss noch und nöcher für das wissenschaftliche Rechnen und Numerik in Fortran programmieren ...
Also das Java nicht für Steuersoftware entwickelt wurde ist wohl klar. Die Arianne Steuert sich übrigens auch mit Ada und trotzdem stürzte sie wegen Software ab, war aber eines Programmierers schuld. Übrigens die Marsroboter Rover und dingsda würden mit Clisp Programmiert die Bildbearbeitung und Sensor ansteuerung mit Java mit einer abstaktionsschicht C++, für jeden das Richtige. Ada ist geil geb ich zu, aber wenn ich eine Desktopsoftware schreibe wäre ich masochist es mit Ada oder Fortran zu tun geht es aber um Wissenschafftliches wie: http://www.worldcommunitygrid.org/ dann ist klar das ich eher eine solche Sprache nehme...eher
ADA wird verwendet, weil das US militär blödsinnigerweise früher mal auf die Sprache standardisiert wurde. Sonst wäre Ada heute noch mehr Geschichte.
Wenn etwas schiefgeht, kann das natürlich auch die Software mit einem Fehler sein. Na und?
Software in solchen "mission-critical" Systemen macht doch ohnehin keinen Spass mehr. Egal womit sie programmiert wurde. Das ist was für Galeerenskalven oder geborene Qualitätsmanager, Leute, das Gegenteil von Programmierung: Ultrakonservatives Programmengineeren. Wie gut, dass man das auch nirgendwo anders macht.
> allem verhindern, dass zueinander inkompatible
> Java-Implementationen entstehen.
Damit erreichen die aber das genaue Gegenteil!
Andere Implementierungen entstehen nicht ohne Grund. Im Moment gibt es aber einen sehr guten Grund andere Implementierungen zu entwickeln - nämlich weil das Original unfrei ist...
Andererseits, wieviele zueinander inkompatible Implementierungen gibt es von OpenOffice.org? Denkt mal drüber nach, ihr bei SUN.
Mit der Freigabe würde es den nächsten Schub für Java und gegen DotNet geben.
Zudem sind u.a. die Annotationen in Java 5 wirklich ziemlich nett.
Das soll nicht heißen, dass Dot.Net schlecht wäre, aber ich sehe die beiden Sprachen doch eher Kopf an Kopf.
Standard?
Außer für Handyspiele wird J2ME kaum eingesetzt. Bei ernsthafter Handysoftware setzt hingegen fast jeder auf Symbian oder Windows.
genau ne Telefonzelle, mit Telegrammdienst und ner riesen Menge Spielkram.
DB-Fahrplan
Google Map
...
Andererseits, wieviele zueinander inkompatible Implementierungen gibt es von OpenOffice.org? Denkt mal drüber nach, ihr bei SUN.
Versteh ich nicht. Wie kannst du denn das inkompatibel machen? Definier mal in dem Zusammenhang "kompatibel". Wenn ich mir die Werbung zu [Name einer populären Distribution hier] durchlese ist OOo sogar kompatibel zu MS Office.
Davon abgesehen wüsste ich spontan keinen Grund, wieso man das JRE patchen sollte. In den Kernel werden ja neue Features, Treiber usw. reingepackt, beim JRE will man einfach nur, dass die Programme laufen. Außer natürlich man ist Entwickler, aber ich wüsste nicht, wieso ein Entwickler an Java ernsthaft was verändern wollen würde. Es gibt ja noch genügend andere Sprachen...
> man das JRE patchen sollte.
Dann wirf doch einfach mal einen Blick ins GCC-Quellpaket Deiner Lieblingsdistribution.
Ist fuer mich nicht ganz nachvollziehbar; weiss etwa sun selber nicht, ob sie code geklaut haben oder nicht? Sollten andere firmen code mit eingebracht haben, wieso sind diese dann nicht erwaehnt worden, es ist ja schliesslich alles unter den namen sun gepackt worden?
Oder habe ich gedanklich doch etwas uebersehen?
Das ist durchaus sinnvoll und üblich.
Wenn sie diese Teile nicht mit allen Rechten erworben haben -was auch normal ist- werden sie auf ihre Zulieferer Rücksicht nehmen müssen.
Es ist auch lobenswert das sie erst denken und kontrollieren bevor sie handeln.
Gruß
Mark
Ich wette mit Dir, daß bei Microsoft-Code das eine oder andere Stück ...
Man kann auch Code kaufen. Dann hat man allerdings noch lange nicht das Recht den gekauften Code unter eine andere Lizenz zu stellen. (siehe Qt)
Küss die Hand
Was hat denn die FSF bisher zur Java-Plattform beigetragen? Wieso sollte es ausgerechnet deren Definition entsprechen?
Weil die OSI nur eine Marketingkampagne für Freie Software ist, aus dem FAQ der OSI: "The Open Source Initiative is a marketing program for free software."
Womit wir wieder bei Freier Software sind, was von der FSF definiert wurde.
Es sieht mir irgendwie danach aus, als hätte man diesen weit in der Zukunft liegenden Termin gewählt, um zum einen bereits jetzt als "der große Quellcodefreigeber" dazustehen und zum anderen ab sofort Entwicklerkapazitäten für die Alternativprodukte zumindest in Zweifel zu ziehen. Und was passiert dann, wenn man sich im Juni 2007 (oder vielleicht vertröstet man bis dahin noch ein paar mal) dann doch umentscheidet?
lg
Erik
Ich sehe das nur als taktischen Schritt um die Aufholung bei Free Software Java den Wind aus den Segeln zu nehmen.
Vor allem: Wo ist das "Stück für Stück"?
Die ersten Teile könnten sie doch schon heute veröffntlichen.
Es wird doch bestimmt Java-Klassen geben, wo sie wissen, daß sie sie zu 100% selber entwickelt haben.
Außerdem sagt Sun (und somit auch Jonathan Schartz) immer wieder, daß sie Angst vor Forks haben und diese verhindern wollen.
OpenSource-Software erlaubt soetwas jedoch ausdrücklich!
Wie sie diesen Widerspruch beseitigen wollen, ist mir unklar.
Aber deren Strategie scheint aufzugehen.
Classpath 0.91 läuft noch gut und stabil.
Aber wer sich mal die dadrauffolgenden Snapshots angesehen hat, wird feststellen, daß seit der Ankündigfung von Sun, Java unter eine OpenSource-Lizenz stellen zu wollen, die Qualität von GNU Classpath merklich nachgelassen hat.
Sicher, ob sowas hier kann man sich eher täuschen
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-classpath.html
sieht nicht schlecht aus.
und dabei immer bedenken mit welcher Geschwindigkeit da jetzt implementiert wird. Da muss man nicht fragen wie es jetzt aussieht, sondern wie es in einem Jahr aussehen wird bzw. wie es noch vor einem Jahr aussah.
Und da ja nun auch Swing respektable läuft wird mit 0.92 sich die Statistik sicher noch verbessern. Man teste nur mal
http://developer.classpath.org/mediation/FreeSwingTestApps
Die Lizenz darf sich Sun als Inhaber der Urheberrechte - so sehr es missfallen wird - leider nach wie vor selbst aussuchen
Dein Vorposter hat gar nichts anderes behauptet; er hat lediglich darauf verwiesen, daß es GÜNSTIGER wäre, wenn Sun in ihrem Großmute eine geeignete Lizenz wählen würden.
Und das hat jeder andere auch so gelesen und verstanden.
Wetten, daß die wieder umkippen und Java doch nicht freigeben?
Viele Dinge in Java gab es schon in Ada, z.B. Packages, Threads. Und das für mich Schöne an Ada ist, es gibt sehr gute und auch freie Kompiler dafür. Ada ist z.B. auch fähig Harte Echtzeit zu bewältigen. Und die Kompiler habne eine sher strenge Syntaxprüfung.
Java ist doch nur für Weichspüler und Internet-Teletuppys!
Wichtige Anwendungen werden in richtigen Sprachen geschrieben, oder ist die Steuerungssoftware vom F90-Jäger aus Java zusammengeklickt. Nein! Hier wurde Ada benutzt, und dann wurde der Assemblercode _zeilenweise_, und das ist wichtig!!!, von Hand überprüft.
Von mir aus kann sich SUN Java ans Knie nageln. Dafür sollten sie lieber mehr Kraft in ihren Fortran-Kompiler stecken, die Norm gibt es seit Januar 2004, und kein aktueller Kompiler ist konform.
Just my 2 ¢
Aber wo wir schon bei Ada sind. Die erste Ariane 5 wurde auch mittels Ada programmiert. Tja, aber wir erinnern uns ja noch an das Feuerwerk am Himmel.
Gut hier war es ein Pufferüberlauf, aber wat solls.
Und aus diesem Grunde drehte der Kreiselkompass auch lustig seine Runden ...
Dies war aber kein Problem der Sprache, sondern dass Software ungeprüft übernommen wurde.
Das heißt, wenn ich mein Programm in Ada schreibe, bringt das den Rest meines Systems dazu, die Abarbeitung von Interrupts zu unterbrechen oder die Abarbeitung von Systemcalls rechtzeitig zu unterbrechen? :)
Oder sind Adaoptimizer so gut, daß sich jeder Algorithmus zu O(1) zusammenfassen läßt? *g*
lg
Erik
> von Interrupts zu unterbrechen oder die Abarbeitung von Systemcalls rechtzeitig zu unterbrechen?:)
Leute, wird sind doch alle nicht auf der Wurstbrühe hergeschwommen!
Es ist doch klar, dass ein normales PC-Linux, egal von RotHUt, Susi, oder Deb*** für Harte Echtzeit ausgerüstet ist.
Da kann dann auch das tolle Ada nichts ausrichten.
Was ich wollte war nur auszudrücken, dass Java nicht der Nabel der Welt ist.
Ich als Mathematikstudent, obwohl ich mich in die Algebra spezialisiere, muss noch und nöcher für das wissenschaftliche Rechnen und Numerik in Fortran programmieren ...
Wenn etwas schiefgeht, kann das natürlich auch die Software mit einem Fehler sein. Na und?
Software in solchen "mission-critical" Systemen macht doch ohnehin keinen Spass mehr. Egal womit sie programmiert wurde. Das ist was für Galeerenskalven oder geborene Qualitätsmanager, Leute, das Gegenteil von Programmierung: Ultrakonservatives Programmengineeren. Wie gut, dass man das auch nirgendwo anders macht.
Mag dir zwar richtig erscheinen, ist aber definitiv falsch. Oak wurde zur Steuerung von von Embedded Systems wie z.B. in Waschmaschinen entwickelt.
Gruß