Kümmer ihr euch um Free-Java Kompatibilität?

[Lin728]

Hallo!

Ich habe gerade einen Artikel gelesen, indem es darum ging, dass die OSS-Gemeinde sich oft über SUN beschwert, sie sollte java endlich frei machen, aber selbst relativ wenig dazu beiträgt. (z.B. Apache welches relativ viel Zeit damit verbringt, bug-reports an sun zu senden).

Schön langsam kommen die freien JVMs in ein Standium, wo sie langsam brauchbar werden (die Klassen-Implementierungen, bei den Runtimes siehts leider noch etwas schlecht aus), wollte ich einmal fragen wies bei euren projekten aussieht?

[peschmae]

Ich hab abgestimmt obwohl sich die Zahl meiner Java-Projekte in letzter Zeit ziemlich exakt konstant null ist

Aber das was ich vorher gemacht habe bzw. wenn ich was machen würde würde ich schon drauf schauen.

MfG Peschmä

[Sym]

Ich schaue manchmal, ob meine Projekte laufen. Wenn es klappt, dann ist gut. Wenn ich nach kurzem schauen nicht auf den Fehler komme, lasse ich es aber auch bleiben. Ich weiß, es ist inkonsequent, aber meine Projekte stehen meist unter der GPL. Da kann dann ja jemand weiterarbeiten.

[Lin728]

Erschüttert mich doch etwas.
40% ist es komplett egal. Anscheinend ist der Leidensdruck noch zu klein.

Das wird noch größer wenn Sun dann pleite ist oder aufgekauft wird...

[Jasper]

aehm, was ist free java kompatibilität? wenn ich mich an den standard halte und meine app unter der jvm-referenz-implementierung läuft interessiert mich der rest eigentlich nicht viel.
normalerweise sollte es keine probleme (abgesehen von den beliebten threadsync-problemen) geben, wenn die jvm sich standardkonform verhalten. wenn nicht, sollte doch die jvm geändert werden und nicht die app. wozu gibts den sonst standards?
oder habe ich das alles vollkommen falsch verstanden?


-j

[delmonico]

Ich code kein Java. Wenn ichs machen würde, würde ich schon deshalb drauf achten, weil auf meinem freien Betriebssystem schlichtweg keine Sun-VM läuft

" Ich habe gerade einen Artikel gelesen, indem es darum ging, dass die OSS-Gemeinde zwar immer SUN anmeckert, sie sollte java endlich frei machen, aber selbst relativ wenig dazu beiträgt."
Wieso auch? Java ist ein SUN-Produkt. Wenn sie es nicht freigeben wollen, schön für sie, dann will ich es nicht nutzen und werde auch keine Software in Java schreiben. Punkt. Ich find die Einstellung mancher Leute, es wäre Aufgabe der FreeSoftware-Entwickler, ständig irgendwelchen proprietären {Programmen,Protokollen,Sprachen} hinterherzulaufen, etwas merkwürdig.

[BeS]

Wenn sie es nicht freigeben wollen, schön für sie, dann will ich es nicht nutzen und werde auch keine Software in Java schreiben. Punkt. Ich find die Einstellung mancher Leute, es wäre Aufgabe der FreeSoftware-Entwickler, ständig irgendwelchen proprietären {Programmen,Protokollen,Sprachen} hinterherzulaufen, etwas merkwürdig.

Sehe ich ähnlich. Deswegen bevorzuge ich C#, wenn es um bytecode Sprachen geht, dass ist ein sauberer offener Standard.

Zur Frage. Ab und zu muß ich auch java programmieren (Uni), dann achte ich sehr darauf, dass meine Programme mit einer freien Java Implementierung arbeiten, schon alleine deswegen weil ich nichts anderes installiert habe.

[bockionline]

normalerweise sollte es keine probleme (abgesehen von den beliebten threadsync-problemen) geben, wenn die jvm sich standardkonform verhalten. wenn nicht, sollte doch die jvm geändert werden und nicht die app. wozu gibts den sonst standards?

Im Prinzip hast du Recht. Nur erzeugt man sich, glaube ich, mit der ganz starren Haltung ein "Henne-Ei-Problem". Wenn keine Programme (Übertreibung, natürlich) mit einem freien Java laufen, werden sich eher wenig Leute an der Entwicklung eines freien Java beteiligen, womit wiederum wenig daran gearbeitet wird, den Java-Standard zu 100% in einem freien Java umzusetzen.

Wenn man nun als Entwickler darauf achtet, daß ein selbstgeschriebenes Programm mit einem freien Java läuft, schafft man vielleicht Anreize, weitere Programme damit einzusetzen und deshalb ein wenig an dem freien Java mitzuarbeiten.

[Lin728]

Sehe ich ähnlich. Deswegen bevorzuge ich C#, wenn es um bytecode Sprachen geht, dass ist ein sauberer offener Standard.

Ich nehme an du spielt dabei auf Mono an, wie man an deinem Bildchen unschwer erkennen kann

Ich halte Mono im großen Stil auch relativ gefährlich, da man derzeit APIs implementiert, welche teilweise von Microsoft nicht standardisiert wurden und somit auch nicht unter die fair-use Klausel fallen.
Natürlich kann man sagen, man schmeißt bei Problemen diese APIs einfach raus und ersetz sie durch freie, aber wenn die APIs da sind, werden die auch benutzt, zumal ein nicht kleiner Teil der Mono-Benutzer unter .NET angefangen haben zu programmieren.
Ich möchte mir nicht vorstellen, was es für Linux heißt wenn wichtige Software mit Mono läuft und MS klagt und gewinnt. Alle die dieses Mono einsetzen, verwenden es dann illegal - imho müssten ganze Server stillgelegt werden von den Desktops ganz zu schweigen!

Da ist Java meiner Meinung nach viel weiter. Ich kann Java wie folgt ausführen:
- Auf Mono mit ikvm.net
- mit GCJ kompilieren
- mit einer der freien JVMs ausführen
- mit den SUN/IBM/BEA dingern ausführen und das dann sauschnell (hat mono keine chance)
- als applet
- als webstart

[BeS]

Ich halte Mono im großen Stil auch relativ gefährlich, da man derzeit APIs implementiert, welche teilweise von Microsoft nicht standardisiert wurden und somit auch nicht unter die fair-use Klausel fallen.

In erster Linie geht es mir um C#, CLI und dann noch Gtk# und die ganzen anderen GNU/Linux und gnome APIs und da gibt es kein Problem.

Ja, MS hat nur einen Teil standardisiert, da du aber weiter unten wieder auf java kommst, was hat sun standardisiert? Mit C# und der CLI haben wir eine Basis auf einem offenen Standard, was haben wir bei Java?

Natürlich kann man sagen, man schmeißt bei Problemen diese APIs einfach raus und ersetz sie durch freie, aber wenn die APIs da sind, werden die auch benutzt, zumal ein nicht kleiner Teil der Mono-Benutzer unter .NET angefangen haben zu programmieren.

gleiches Problem bei java und allen anderen Frameworks auch. Wer sagt dir das MS Patente nicht auch Teile von Java abdecken, die Ideen dahinter sind ja nicht so verschieden? Was ist mit den sun Patenten und den ganzen anderen Softwarepatenten von anderen Unternehmen?
Es gibt ein ernstes Problem -> Softwarepatente, dass besteht aber überall.

Ich möchte mir nicht vorstellen, was es für Linux heißt wenn wichtige Software mit Mono läuft und MS klagt und gewinnt. Alle die dieses Mono einsetzen, verwenden es dann illegal - imho müssten ganze Server stillgelegt werden von den Desktops ganz zu schweigen!

Diese Klage kann gegen alles kommen. Mono, java, C++-APIs,...
Es geht hier um Patente und nicht um Urheberrecht, d.h. die Gefahr ist völlig losgelöst von einer speziellen Implementierung.
Ausserdem besteht ein großteil der GNU/Linux Programme aus C#, CLI, Gtk#, gst#,..
Und nicht aus ASP.Net oder ADO.Net, aber wie bereits gesagt, ist auch da das Risiko nicht wirklich höher.

Ich denke die Probleme hängen hier eher mit dem Feindbild MS in den Köpfen der Leute zusammen als dass es ein reelles Problem wäre. Zumindest ist es nicht größer wie bei anderen APIs und anderer Software.

Ich würde sogar einen Schritt weitergehen und MS in diesem Bereich als sehr Mono freundlich einschätzen. Warum?
Was hat MS, sie haben .Net und damit ihr Framework für windows. Sie wollen aber ganz klar einen Gegenpol zu java schaffen. Das funktioniert aber erst, wenn sie Plattformunabhängig sind und genau das verschafft ihnen Mono. Mit Mono wurde "ihr Framework" massentauglich (zumindest in manchen Bereichen).
Ich glaube sie wissen ihren Vorteil sehr wohl zu schätzen, dass es Mono gibt und das sie im Gegensatz zu java einen offenen Standard als Basis für alle geschaffen haben, und werden den sicher nicht aufgeben.
Bevor sie ihre Patente gegen Mono einsetzen werden sie diese sicher gegen Java einsetzen.

aber jedem das seine...

immerhin ein Punkt in dem wir uns einig sind.

[Jasper]

Wenn man nun als Entwickler darauf achtet, daß ein selbstgeschriebenes Programm mit einem freien Java läuft, schafft man vielleicht Anreize, weitere Programme damit einzusetzen und deshalb ein wenig an dem freien Java mitzuarbeiten.

nichts gegen einzuwenden. wenn mein standard-konformer code auf einer freien jvm läuft, bestens. wenn mein code wegen einer nicht spezifikationsgerechten implementierung seitens der jvm nicht läuft, ist mir das bugreports wert. was ich allerdings vehement ablehne: code nicht-standardkonform zu schreiben oder explizite ausnahmen für nicht-spezifikationstreue JVMs zu implementieren, nur damit die app auf auf einer freien JVM läuft. das ist IMHO der falsche weg und läuft dem sinn eines standards zuwider.
man braucht sich nur mal älteren c-code für unices anzusehen: ein verhau von #ifdefs damit der code von allen möglichen c-compiler-implmentierungen compiliert werden kann. das will ich in java nicht haben, man muss ja schliesslich aus fehlern lernen.


-j

[BeS]

nichts gegen einzuwenden. wenn mein standard-konformer code auf einer freien jvm läuft, bestens. wenn mein code wegen einer nicht spezifikationsgerechten implementierung seitens der jvm nicht läuft, ist mir das bugreports wert. was ich allerdings vehement ablehne: code nicht-standardkonform zu schreiben oder explizite ausnahmen für nicht-spezifikationstreue JVMs zu implementieren, nur damit die app auf auf einer freien JVM läuft.

Das ist ja eigentlich auch nicht das Problem. Das was implementiert ist funktioniert im Normalfall so wie es soll.

Es geht afaik eher darum:

- Das du von Anfang an mit einer freien-jvm entwickelst und dann z.B. merkst, dass lib X oder feature Y von lib X noch nicht implementiert ist und du es dann z.B. auf eine andere Art machst (es gibt ja oft mehrere Möglichkeiten etwas zu implementieren) und gleichzeitig das fehlen als wishlist-item meldest oder vielleicht sogar eine erste Implementierung lieferst (je nach deinem Wissensstand und deiner Zeit)
- Das du dein Programm von Anfang an mit einer freien jvm entwickelst oder zumindest testest und dir dadurch Fehler in bereits implementierten Funktionen auffallen, dass kann auch ein nicht ganz korrektes Verhalten im Vergleich zur sun Implementierung sein, und diesen Fehler dann meldest und/oder versuchst ihn zu beheben (je nach deinem Wissensstand und deiner Zeit)

[anda_skoa]

Ich hab mir bis vor kurzem eigentlich nicht so darum gekümmert, unter anderem auch, weil ich in letzter Zeit eher sehr wenig mit Java gemacht habe.

Hab dann anläßlich einer Diskussion über freie Java Implementierungen auf der debian-kde Mailingliste, in der einer der GNU Class Path Entwickler geschrieben hat, daß ohne Feedback schwer entscheidbar ist welche Sachen sie als nächstes angehen sollten, mir mal Kaffe+Classpath angesehen und ein paar meiner alten Projekte kompiliert

Mein damaliges Debian Woody hatte da nicht gerade die aktuellste Version drauf, aber mal abgesehen von Swing lies sich eines meiner größeren Projekte einwandfrei compilieren und in großen Teilen (dynamisches Classloading, etc) auch einwandfrei benutzen.

Werd jetzt mal sehen, wie lange ich auf meine neuen Unstable ohne JVM von Blackdown auskomme

Zur Sache mit C#: praktisch wie bei Java ist die Sprache ohne zugehörige Classlib/VM nicht sehr interessant.
Als Classlib+VM kommt hier ansich nur Mono in Frage, allerdings hat dieses Projekt ein sehr kurzsichtiges Marketing

Es wird zwar gleich am Anfang der Website darauf hingewiesen, daß Mono keinesfalls eine .Net Implementation ist, sondern Mono wie .Net eine Implementation des CLI Standards beinhaltet, aber jeder aus dem Umfeld des Projekts vermeidet es tunlichst, die Allgemeinheit oder Medien über ihren Irrtum aufzuklären, wenn sie wieder mal ".Net für Linux" schreiben.

Kurzfristig ist das nämlich eine feine Sache, man kann da mit bekannten Buzzwords punkten und man versucht ja auch in weiten Teilen .Net kompatibel zu sein, aber längerfristig nutzt das hauptsächlich dem Implementor der echten .Net Classlib, denn nur der ist immer kompatibel zu .Net (logischerweise da er .Net definiert)
Aber Amerikaner stehen nunmal leider auf "marketing over engineering"

Ciao,
_

[Lin728]

Wohl war! Hört, hört ;-)

[BeS]

Es wird zwar gleich am Anfang der Website darauf hingewiesen, daß Mono keinesfalls eine .Net Implementation ist, sondern Mono wie .Net eine Implementation des CLI Standards beinhaltet, aber jeder aus dem Umfeld des Projekts vermeidet es tunlichst, die Allgemeinheit oder Medien über ihren Irrtum aufzuklären, wenn sie wieder mal ".Net für Linux" schreiben.

Naja, das Marketing ist Novell sein Problem und mir als Anwender eigentlich relativ egal.
Die meisten in der windows Welt unterscheiden halt nicht groß und kennen nur .Net und denen sagt man dann halt das Mono eine Plattformunabhängige .Net implementierung ist. Darunter kann sich der windows-user was vorstellen und damit ist das Ziel erreicht. Wenn er sich dann mit Mono beschäftigt, dann wird er schon die Vor- und Nachteile kennen lernen.
Das ist ähnlich wie wenn man mit jemand das erstemal über GNU/Linux redet, dann wird GNU, Freie Software, Open Source und die ganze Philosophie auch meistens weg gelassen oder nur sehr verkürzt und bildlich dargestellt.

Für mich ist Mono mit der C# Implementierung, der CLI, GTk#, gst#,... ,ASP.NET, ADO.NET
Ein Framework für GNU/Linux mit dem ich sehr einfach und sehr schöne Programme für mein System schreiben kann, die ich für ein anderes GNU/Linux, BSD oder Unix System nicht extra neu kompilieren muß und die ich, wenn ich etwas aufpasse, sogar unter windows verwenden kann.
Mehr brauch ich nicht. Wenn in ASP.NET die letzten 3 Funktionen der MS Version noch nicht implementiert sind, dann ist mit das ziemlich egal, da ich sie eh nicht kenne

Bei Java hat man das "Problem", dass es sun java für alle gängigen Plattformen gibt und die freien Implementierungen erst relativ spät gestartet sind.
Bei Mono sieht es anders aus. MS hat mit ihrer Implementierung keinen großen Vorsprung und man hat mit Novell eine Firma dahinter die die Entwicklung stark vorantreibt, zusätzlich hat man auf die Weiterentwicklung der CLI und C# Einfluß.
Wenn jetzt z.B. jemand Server Systeme mit windows und GNU/Linux hat, was wird er nehmen? Wenn es kein Mono geben würde, dann wäre die Entscheidung klar -> .Net. Durch Mono hat man aber auch die Option Mono/.Net. Dann kann man unter Mono entwickeln und die Programme dann unter Mono auf den GNU/Linux Systemen laufen lassen und unter windows .Net oder auch Mono verwenden.

MS hat dadurch auch nur Vorteile. Ihr .Net wird bekannt und erarbeitet sich einen Markt und Entwickler, die sicher auch .Net verwenden werden wenn sie nur für windows entwickelt.
Damit hat MS alles was sie imho wollen. "Ihre" Technologie als starken gegenpart zu Java und eine API für windows die auch dank Mono eine "besseren Ruf" bekommt und bekannt wird. Denn was liegt näher als .Net zu nehmen, wenn man vorher schon unter GNU/Linux oder anderen Unix Systemen mit Mono gearbeitet hat?

Und wir haben mit Mono eine schöne Technologie für Desktop und Server Anwendungen.

Ich schreibe schon wieder viel zu viel
Aber das ist zur Zeit einfach mein Thema