Mit der "freien" QT Version darf man, soweit ich weis nur Programme unterstellen, die unter der GPL stehen. Gilt diese Einschränkung dann auch automatisch für Classpath ?
Wie sieht es beim GCJ aus ?
Der steht ja auch unter der GPL mit der Einschränkung das man Programme gegen die Sachen linken kann ohne das der eingene Code unter die GPL flällt. Also wenn ich
in meinem Code angebe include irgendeine Classpath Klasse gilt die GPL Regel nicht
Wenn ich aus dem Classpath Code eine Funktion in meinen Code kopiere steht mein Code automatisch auch unter der GPL.
Oder gibt es beim Include schon irdendwas das man beachten muss wie z. B. statische und dynamisches Linken?
Irgenwie ist da doch ein Widerspruch zur QT Lizenz wenn ich über Classpath indirekt QT in Programmen verwende die nicht unter der GPL stehen?
> in meinem Code angebe > include irgendeine Classpath Klasse > gilt die GPL Regel nicht
So ist es.
> Wenn ich aus dem Classpath Code eine Funktion in meinen Code kopiere steht > mein Code automatisch auch unter der GPL.
Auch das stimmt.
> Irgenwie ist da doch ein Widerspruch zur QT Lizenz wenn ich über Classpath > indirekt QT in Programmen verwende die nicht unter der GPL stehen?
Welchen Widerspruch meinst Du? GNU Classpath steht gewissermaßen unter einer abgeänderten GPL (besser gesagt unter GPL mit Zusatz) und Qt steht unter der GPL. Betrachte die abgeänderte GPL einfach als soetwas wie die LGPL. Da gab es mal auf der GNU Classpath Mailingliste Diskussionen zu, weshalb GNU Classpath die abgeänderte GPL verwendet und nicht wie die ersten GNU Classpath Versionen die LGPL.
Ich meine der Grund war letztendlich, da der Java Binary-Code anders abgearbeitet wird als nativer Code der durech C/C++ Propgramme erzeugt wurde. Wenn ich mich richtig erinnere wirkt die LGPL auf bei Programmen auf einer JVM so ähnlich wie die GPL. Daher dürften dan eigentlich auf LGPL-Klassen keine propietären Klassen aufbauen. Und damit das aber wieder möglich ist, gibt es die abgeänderte GPL.
Von Dalibor Topic am Fr, 4. November 2005 um 15:45 #
Das mit LGPL und Java ist eine urbane Legende. LGPL hat keinen magischen GPL Effekt wenn man Java einsetzt. Siehe http://www.gnu.org/licenses/lgpl-java.html
Im ueberigen, Sun's JDK benutzt code unter der LGPL, wenn das also mit der LGPL und Java so waere ... waere es lustig. Ist es aber nicht.
Von theBohemian am Fr, 4. November 2005 um 13:53 #
Classpath steht unter einer GPL mit Linking Exception (genau wie GCJ, Guile, die C++-Standardbibliothek und ein paar weitere).
Der Sinn liegt darin, dass Classpath auch im Bereich eingebettete Systeme verwendet wird, wo statisches Linken dem dynamischen vorgezogen wird.
Die Bestimmungen der GPL (jetzt mal ohne LE) sind übrigens im Hinblick auf die regulären Java-Pakete hinfällig. Du kannst dein Programm so proprietär wie nur möglich machen solange es nur Klassen aus den Namensbereichen verwendet, die es bei der Sun Implementierung auch gibt (java., javax. , ...). Anders wäre es wenn auf irgendwas internes bei uns zurück greifst ("gnu.classpath."). Hierfür hast du dann aber unsere Linking Exception.
ch empfehle aber momentan niemandem Klassen aus der internen API zu verwenden, da wir nicht garantieren können, dass das versionsstabil ist und ausserdem würde man sich die Lauffähigkeit auf den proprietären JDK vermasseln. Gleiches gilt übrigens auch für sun.com und com.sun Pakete im JDK.
Von Dalibor Topic am Fr, 4. November 2005 um 15:47 #
Zuerst zum allgemeinen Teil:
Mit Qt und GNU Classpath verhaelt es sich so aehnlich wie mit Qt und, sagen wir mal, KDE Bibliotheken.
Die Art von Frage stellt sich oefters, eine Antwort gibt es zum Beispiel unter http://lists.trolltech.com/qt-interest/2002-03/msg00293.html
Kommen wir zum Java-spezifischen Teil:
Quelltext der nur die implementierungsunabhaengigen Standardklassen und Methoden benutzt, ist unabhaengig vor der Lizenz der Implementierung.
Daraus erzeugter Bytecode ist in Javas Fall extra so entworfen, dass bei dem Kompilat aus Gruenden der binaeren Kompatibilitaet nur implementierungaunaghaengiger Bytecode entsteht. Damit kann das Kompilat nicht ein Derivat der Implementierung sein auf der es ausgefuehrt wird, bzw mit der es erzeugt wird. Im besonderen, kann das Kompilat nicht ein Derivat der internen Bibliotheken sein, welche bei der Implementierung verwendet werden, die zur ausfuehrung des Bytecode eingesetzt wird.
Fuer eine Analogie aus einem anderen Bereich, siehe shell Skripte unter GNU/Linux: Obwohl GNU Bash unter der reinen GPL steht, und ihrerseits die unter der reinen GPL stehende Bibliothek GNU readline benutzt, gbt es keine Lizenzbeschraenkung fuer die Shellskripte die mit der Bash interaktiv geschrieben werden, oder mit der Bash ausgefuehrt werden. Solche Nutzungseinschraenkungen gibt das Copyright, auf des sich die GPL stuetzt, einfach nicht her (und es waere auch nicht wuenschenswert).
Ein VM Projekt, dass sich entscheidet die Qt4 peers fertig gepackt mitzuliefern, muss sich an die Lizenzen von Qt und GNU Classpath halten. Das ist bei einer freien VM die in ihrer Gesamtheit under der GPL steht, wie Kaffe, recht trivial. Fuer andere freie VMs gibt es die moeglichkeit die Qt Bibliotheken (sofern sie diese ueberhaupt mitliefern wollen) unter der QPL zu lizenzieren, die, obwohl GPL-inkompatibel, fuer Projekte unter Lizenzen mit weniger rigidem Copyleft-Anspruch als die GPL geeignet ist.
Fuer Programme, die explizit Bibliotheken aussehalb von GNU Classpath verwenden, mussen die Lizenzbestimmungen dieser Bibliotheken beachtet werden. Wenn sich, zum Beispiel, in einem Binary sowohl mein Code unter meiner Lizenz, GNU Classpath code unter GPL+LE und Qt4 Code unter der GPL befinden, dann kann ich nicht behaupten dass meine Pflichten gegenueber den Authoren von Qt4 durch die LE von GNU Classpath aufgehoben werden. Bespielsweise wenn ich ein statisches Binary aus meinem Code, GNU Classpath und Qt4 erzeugen wuerde. In dem Fall wuerde ich schauen dass ich Qt4 unter der QPL Lizenz nehme, falls mein Code Freie Software ist und nicht unter der GPL steht.
Von einem mit Durchblick am Fr, 4. November 2005 um 12:01 #
Ach ja, das gute "classpath-Spiel"...
a) Kompatibilitätstest Ist Classpath 100%ig bytecodekompatibel zum JRE 1.5? Nein. Fazit: Unbrauchbar
b) Praktischer Gebrauchstest (zweite Chance um Nachteil a aufwerten zu können) Wird mit Classpath-Java-Doc eine deutschsprachige Java-Doc ausgeliefert? Nein. Fazit: Unbrauchbar
Wie man anhand von zwei sehr einfachen Betrachtungen sehen kann, ist Classpath in der jetzigen Version in vollem Umfang zu nichts zu gebrauchen. - Allenfalls als Beschäftigungstherapie für die Programmierer. -
Von einem mit Durchblick am Fr, 4. November 2005 um 12:26 #
a) Ich wollte nicht einfach nur etwas schreiben, sondern die sabbernden Enthusiasten mit Schaum vorm Mund auf den Boden der Realität zurückholen. Open-Source ist gut, aber nur in den wenigsten Bereichen wirklich voll einsatzfähig.
b)1.4-Kompatibilität ist unwichtig, da veraltet; Swing ist absolut unverzichtbar.
Beispiel: Betrieb, Classpath ist installiert. Wenn nun SW mit 1.5 Anforderung kommt, kann sie nicht eingesetzt werden. Jegliche Diskussion ist in diesem Moment sinnlos. Die Durchsetzung von SW wird im betrieblichen Umfeld entschieden und nicht in Kinderzimmern.
Was erwartest du? Soll ein Projekt von null auf hundert katapultiert werden nur weil der Katalysator Freier Software ist? Alles benötigt Zeit zu reifen. Auch deine Gedanken. Gib Dir selbst die Möglichkeit geistreiche Kommentare von Dir zu geben und bearbeite Deine Texte ein paar mal bevor du sie irgendwo veröffentlichst.
Ich persönlich freue mich das es GNU Classpath gibt, auch wenn ich java noch nicht gebraucht habe.
Von Walter Plinge am Fr, 4. November 2005 um 13:19 #
Süße kleine Welt in der Du da lebst. 1.4 Kompatibiliät ist noch immer das A und O beim durchschnittlichen Projekt. Swing wird nur bei Desktop Java-Anwendungen eventuell benötigt. Es ist mit Sicherheit wichtig, aber der Großteil der aktuellen Javaentwicklung findet aber auf einer anderen Ebene statt.
1.4-Kompatibilität ist unwichtig, da veraltet Erzähl das den Leuten, auf deren Plattform es noch kein J2SE 5.0 gibt.
Swing ist absolut unverzichtbar <ironie>Vor allem in der Webentwicklung (J2EE).</ironie> Bei Smart-Clients würd ich z.Zt. eher auf SWT setzen. Erst mit J2SE 6.0 könnte sich da was ändern.
Das mit 1.4 ist totaler Schwachsinn. Es gibt zig Projekte, wo noch unter JDK1.3 (ja, 1.3, schon was betagt, aber z.B. auch auf OS/2 [noch betagter] verfügbar) entwickelt wird. Und auch sonst sieht es in der Praxis nun wahrlich nicht so aus, dass alle nur noch auf J2SE 5.0 (so heisst das nunmal offiziell, bzw. die Runtime dazu JRE 5.0) setzen.
Swing ist schon eher ein Problem, aber da sind die Entwickler mit Hochdruck dran und kommen auch gut voran.
falsch. Wir verwenden GNU Classpath, und zwar in einem kommerziellen/betrieblichen Umfeld.
b)1.4-Kompatibilität ist unwichtig, da veraltet; Swing ist absolut unverzichtbar.
wieder falsch. Viele Kunden im kommerziellen Feld (ich rede hier von Echtzeit und Embedded Systemen) brauchen nur 1.1 Kompatibilität. Swing is wichtig aber bei weitem nicht unverzichtbar.
Hast du wirklich soviel durchblick Gibt's dich noch oder bist du schon irgend jemandem durchlöchert worden, dass bei durchblick besteht?
Es gibt verschiedene Anwendungsgebiete. Es muss nicht immer rückwärtskompatibel sein. Falls der Code sich kompilieren lässt, so ist dies sehr gut und man kann es auch gebrauchen. Ich will auf meiner Maschine z.B. kein Sun/Java. GNU Classpath hingegen läuft sehr gut (für OpenOffice)
Von theBohemian am Fr, 4. November 2005 um 15:20 #
Hi, ich finde es zwar schade, dass du unsere Software nicht gebrauchen kannst, aber ich kann dir sagen, dass es dem Classpath Team sehr viel Freude bereitet sie zu erstellen.
Ich persönlich habe zum Beispiel diese Erfahrung gemacht: Letztlich bemerkte ich das auf einem frisch eingerichteten Ubuntu "Breezy Badger" System mit OpenOffice 2.0 eine Version von GCJ installiert war. Ich stellte mir vor wieviele Ubuntu Systeme es wohl gäbe und wievielen Menschen unsere Arbeit etwas nützt, egal ob sie es wissen oder nicht. Nun, ich kann nicht sagen wieviele Leute Ubuntu einsetzen, aber die die es tun, sind bestimmt froh, dass alles so problemlos funktioniert. Und von all diesen Leuten verlangen wir nichts. Sie können die Software einsetzen ohne das wir sie zu irgendetwas zwingen.
Sogar du, der dem Projekt Classpath nicht vorbehaltlos gegenübersteht, darfst es nutzen (und ich würde mich sogar darüber freuen).
Was ich sagen will ist: "Schau mal, da gibt es noch eine Menge andere Sichtweisen auf diese eine Sache."
> Ich stellte mir vor wieviele Ubuntu Systeme es wohl gäbe und wievielen > Menschen unsere Arbeit etwas nützt, egal ob sie es wissen oder nicht.
Man könnte natürlich auch mal fragen, wie vielen Menschen "eure" Arbeit (diese Information erklärt übrigens einiges an Missioniererei, danke dafür) nicht nutzt, egal ob sie es wissen oder nicht.
> Nun, ich kann nicht sagen wieviele Leute Ubuntu einsetzen, aber die > die es tun, sind bestimmt froh, dass alles so problemlos funktioniert.
Was funktioniert problemlos? Azureus schon mal nicht, also kann es nicht "alles" sein. Da darf man den Ubuntu- und Fedora-Nutzern in den letzten Monaten immer wieder dieselbe Frage beantworten, mit immer wieder demselben Wortlaut: "Nein, das was Du da hast, ist kein Java und funktioniert nicht => runter damit".
> Sie können die Software einsetzen ohne das wir sie zu irgendetwas zwingen.
Dafür, dass das alles so freiwillig, altruistisch und unaufdringlich sein soll, ist doch wirklich erstaunlich viel Missioniererei zu bemerken. Als Zwingen kann man das noch nicht bezeichnen, aber es ist nahe dran, insbesondere wegen der Abschreckungstaktik gegenüber "anderen", sog. "unfreien" Implementationen.
Von Dalibor Topic am Fr, 4. November 2005 um 17:17 #
Das was in einer distribution mit GNU Classpath dabei ist, laeuft normalerweise auch. Ich benutze im moment Ubuntu Breezy, und kam von Fedora Core 4, und in beiden lief das, was von den Distributionen bereits mit GNU Classpath unf gcj getestet und gepackt war, recht sauber. Ich habe keine proprietaere VM installiert, und vermisse sie auch nicht.
Programme die nicht teil einer Distribution sind, koennen funktionieren (und tun es meiner erfahrung nach zunehmend), mussen aber nicht. In dem Fall bleibt immer noch die Moeglichkeit sich zusammen mit den Entwicklern der Applikation und GNU Classpath entwicklern an das beheben von bugs zu machen.
Azureus hatte, zum beispiel, als ich letztes mal reingeschaut habe, nicht portablen Java code der in undokumentierten sun.* Klassen rumfuhrwerkelte. Das ist so, wie wenn eine Applikation versteckte Windows APIs verwendet; dann muss mal erst den Azureus Kode wieder portabel machen.
Das ist in den meisten faellen nicht so schwierieg, und das GNU Classpath Projekt pflegt ein Wiki mit Tips wie man die Qualitaet und Protabilitaet von Java Kode steigern kann. Genaueres gibt es unter http://developer.classpath.org/mediation/ClasspathMigration
Solltest Du interesse daran haben, mitzuhelfen Azureus in Ubuntu und Fedora Core mit freien implementierungen zum fliegen zu bringen, sind die ubuntu-java und fedora-java mailinglisten ein guter start. Meines Wissens nach, wird an Azureus fuer eine zukuenftige Version von Fedora bereits gearbeitet, ich habe die Details jedoch nicht parat.
Ich hoffe, dass ich damit deinen Schrecken verjagt habe, woher er auch gekommen sein mag.
Ich habe nicht das geringste Interesse an einer Bastelei für den ideologisch verblendeten Linux-Haufen. Ihr dürft weiterhin gern den zusammengemurksten Spielkram benutzen, den will euch wirklich keiner nehmen.
Von Dalibor Topic am Sa, 5. November 2005 um 13:21 #
Danke fuer Dein gezeigtes Interesse.
Ich hoffe dass Dein weiteres verweilen auf pro-linux.de Dir hilft, und wuensche alles gute fuer die Zukunft. Die Heise Foren findest Du unter heise.de.
Wird mit Classpath-Java-Doc eine deutschsprachige Java-Doc ausgeliefert?
So ein Quatsch. Wenn ein Programmierer kein Englisch kann, hat er sowieso verloren.
Ich habe schon genug JDK-Dokumentation gelesen und im Prinzip ist der beschreibende Text sowieso unwichtig weil einem als Entwickler meistens nur die Parameter und dessen Typen interessieren.
Auch sonst lese ich lieber die englische Dokumentation weil sie gewöhnlich aktueller und ausführlicher ist als die deutsche Übersetzung.
Sicher kann man dem ganzen so oder so gegenüberstehen, aber so eine pauschalisierende und durch subjektive Kriterien untermauerte Haltung kann keine ernsthafte Diskussionsbasis darstellen.
Ciao, Christian
PS: Ich habe auch das SUN JDK auf meinem Ubuntu installiert, allerdings ging es dabei um ein Swing-Programm, was eben mit der freien Implementation nicht lief. Ich würde mich allerdings freuen, wenn ich auf diesen SUN Kram bald verzichten kann. Schon aus Bequemlichkeitsgründen, da man das SUN JDK ja immer noch umständlich von deren Homepage runterladen muß.
Von Andreas Cordes am Fr, 4. November 2005 um 12:24 #
Hi,
habe gerade auf der HP von denen geschaut und für mein aktuelles Projekt sieht es ganz gut aus, das es auch mit Classpath läuft.
Nutze aufgrund von der Dynamik sehr viele andere Projekte in dem Programm JDOM, FOP, JGoodies usw. java.lang.reflect wird ja schon zu 100% a bgedeckt :-)
Wie sieht es nun mit Java-Webstart aus? Sprich kann ich auch auf Classpath setzen und Java-Webstart nutzen? Wäre für die Verbreitung des Tools was ich gerade schreibe gar nicht mal so unwichtig das mit Classpath auszuliefern/zu verbreiten anstatt mit dem orig. Java.
Was mir da also noch fehlt ist die WebStart funktionalität und die Klasse JNLP. Dann würde nichts gegen Classpath sprechen...
Mal schauen was aus dem Projekt wird. Ach ja, es muss auch unter Win laufen, leider.
Von Dalibor Topic am Fr, 4. November 2005 um 16:01 #
Hallo Andras,
netx sollte seit Mai diesen Jahres mit GNU Classpath laufen. Siehe http://www.peakpeak.com/~tromey/blog/2005/05/22/ . Eine andere implementierung ist OpenJNLP, aber mir ist ueber deren lauffaehigkeit nichts bekannt. Gute und schlechte neuigkeiten diesbezueglich waeren auf der GNU Claspath Mailingliste willkommen.
Ich persoenlich wuerde gerne in eines der naechsten Kaffe releases eine JNLP umgebung integrieren (unter anderen Dingen). Windows ist jedoch noch nicht Kaffe's staerke, in dem Fall empfehle ich sich nach alternativen umzusehen. Eine kurze liste gibt es unter http://www.javagaming.org/forums/index.php?topic=11135.new#new
> Gern gesehen sind Freiwillige, die eine neuere API wie JMX, SQL Rowsets oder die Concurrent Utilites entwickeln bzw. pflegen wollen.
Hm, also wenn mich nicht alles täuscht, gibt es doch für die genannten APIs bereits einige freie Implementierungen. Z.B. beinhaltet MX4J JMX. Die Concurrent API stammt je größtenteils von Doug Lea - gibt es die nciht auch als Open-Source? Und SQL Rowsets sollte es doch in jedem freiem JDBC4-Treiber geben? Nun anscheinend wohl nicht ...
Von Dalibor Topic am Sa, 5. November 2005 um 15:03 #
Man braucht auch Leute die das alles integrieren, testen, die Lizenzen und Dateien auf Ungereimtheiten durchkaemmen, und gegebenfalls, wenn es sein muss, neu und besser implementieren. ;)
Externe Software, die in GNU Classpath integriert wird, muss bestimmten rechtlichen Anforderungen entsprechen.
Sie muss freie Software sein. Das war ein Grund fuer GNU Classpath eine eigene CORBA Implementierung in Java zu entwickeln: die Standard-org.omg Klassen, die man bei der OMG herunterladen kann, duerfen nicht modifiziert werden, und sind daher keine freie Software.
Des weiteren muss externe Software die in FSF's GNU Classpath integriert wird, unter einer GPL-kompatiblen Lizenz stehen. Das schliesst eine Integration von Kode unter der Apache Lizenz, zum Beispiel, vorerst aus, solange wir die Inkompatibilitaet nicht aus dem Weg geraeumt haben. Daran wird von beiden Seiten gearbeitet, und ich erwarte ein paar Ergebnisse zur naechsten ApacheCon.
Das ist eine Selbstbeschraenkung, die sich die FSF freiwillig auferlegt hat, da die FSF bereits einen grossen Fundus an ausschliesslich GPL-kompatibler Software geschaffen hat, und es fuer sie keinen Sinn machen wuerde, Lizenz-Inkompatibilitaeteten zwischen der Software die sie distributieren zu foerdern. Des weiteren sind einige von VMs die GNU Classpath einsetzen und zu GNU Classpaths Entwicklung beitragen, unter der GPL, und die Integration von GPL-inkompatiblem code waere fuer sie problematisch.
Andererseits duerfte das Apache Harmony projekt, welches eine VM unter der Apache Lizenz erstellt, komponenten aus GNU Classpath die bereits im Apache Projekt implementiert sind, bei ihrer 'GNU Classpath Distribution' durch eigene XML komponenten, bespielsweise, ersetzen.
Das ist explizit durch die 'linking exception' erlaubt, so dass man das beste aus beiden Welten hat: ein FSF Projekt, dass sich stark fuer gute, freie Software die auch frei bleibt engagiert, aber es auch explizit erlaubt ihre Bibliotheken durch andere freie oder auch nicht-freie Software zu ergaenzen, sofern man das wuenscht.
Ich habe den Eindruck, dass das Projekt classpath immer einen Schub nach der Fosdem bekam. Leider ist die Fosdem nur einmal im Jahr. Daher meine Frage an die Leute aus dem Projekt:
- wollt ihr Classpath irgendwie institutionalisieren? Also einen Verein oder eine Gesellschaft gründen? Was gerade Businesspartner ja gerne sehen wollen ist ist irgendeine Firma oder Org dahinter. Da müssen wir in europa aufholen, die Amis treiebn auf die Weise eine Menge Geld für Entwickler ein.
- Warum nehmt ihr an so wenigen Veranstaltungen teil und präsentiert eurer Projekt und die derzeitigen Herausforderungen? Ich glaube auch Videos und Audios von Entwicklertreffen (seit es torrents gibt auch kein bandbreitenproblem mehr) und blogs und wikis und dergleichen sind ganz wichtige Mittel um ein Projekt durchstarten zu lassen. Auch wenn 80% sowieso immer von einem Kernteam erledigt werden.
- Classpath macht fantastische Fortschritte. Wo seht ihr im moment die Hauptkompatibilitätsbremsen?
- Es gibt ja Unmengen an Freeware und OpenSource in Java. Wie viel Prozent läuft denn unter Classpath und kann man classpath mit solchen echten Applikationen debuggen oder haltet ihr das für ein falsches Vorgehen?
Von theBohemian am Sa, 5. November 2005 um 01:08 #
Hi, schick mir mal ne Mail mit diesen Fragen und ich beantworte sie umgehend.
Meine ursprüngliche Fassung der News enthielt einen Kommentar einer Firma die sich im Classpath Bereich engagiert. Eine andere Dachorganisation als GNU bzw. die FSF haben wir aber nicht.
Bedenke, dass vieles von dem was wir machen von persönlichem Engagement abhängt (zB diese Presseankündigung, die Classpath-Artikel). Wenn du dich einbringen möchtest und das dem Projekt zugute kommt, bist du herzlich eingeladen. :)
Von Dalibor Topic am Sa, 5. November 2005 um 21:52 #
Ich denke, die naechste FOSDEM wird sehr spassig und interessant. ;)
GNU Classpath selbst, ist wie gcc, und andere GNU toolchain Projekte, ein Projekt der Free Software Foundation. Die FSF hat einen europaeischen Zweig, die FSF Europe, der sich ebenfalls der Foerderung von freier Software verschrieben hat. Naehere informationen zur FSF gibt es unter http://ww.fsf.org . Wenn du Ideen hast wie zum Beispiel ein GNU Classpath e.V. die Arbeit des Projektes in Deutschland verbessern und die Ideen verbreiten koennte, sollten wir uns darueber auf der GNU Classpath mailingliste unterhalten.
Unternehmen, die ein bestimmtes Interesse an der Mitarbeit haben, koennen sich mit Mark Wielaard, dem Maintainer des GNU Classpath Projektes, in Verbindung setzen. Fuer eine Einfuehrung in die ersten Schritte fuer die Mitarbeit an GNU Classpath, siehe http://developer.classpath.org/mediation/ClasspathFirstSteps
Entwicklerblogs gibt es unter http://planet.classpath.org . Von Entwicklertreffen gibt es diverse Slides, aber meines wissens nach noch keine Audio/Video aufzeichnungen. Das waere fuer die naechste FOSDEM eine gute Idee. Falls du interessa hast, mitzuhelfen dafuer etwas auf die beine zu stellen, sollten wir uns ebenfalls auf der Classpath mailingliste darueber unterhalten. Das Projekt lebt sehr stark von Engagement einzelner Mitglieder, und wir koennten sicherlich mehr Leute gebrauchen die uns helfen GNU Classpath praesenter zu machen.
Bei der Kompatiblitiaet sind bei Swing und co. noch ein paar Luecken, wo Klassen und Methoden noch nicht implementiert worden sind. Die groessten Kompatibilitaetsfortschritte lassen sich erzielen, wenn Leute Kode haben, den sie auf GNU Classpath am laufen haben wollen. Daher steht das Projekt mit verschiedenen anderen Projekten in Kontakt, unter anderem Eclipse, JOnAS, OpenOffice.org, und einigen Projekten der Apache Software Foundation, um GNU Classpath in zusammenspiel mit den Entwicklern dieser Applikationen zu verbessern.
Man kann, und es ist sehr wuenschenswert GNU Classpath mit echten Open Source Applikationen und Bilbiotheken beutzen, um Fehler zu finden und zu beseitigen. Da arbeitet das Projekt vor allem mit Distributionen wie Fedora, Ubuntu, Debian und Gentoo zusammen, die interessiert sind moeglichst viel freie Software auf einem voellig freiem Stack zu haben, ohne stoerende propriaetere Elemente dazwischen.
Insbesondere Nutzer und Entwickler von freier Software in Java sind eingeladen mitzuhelfen, die Applikationen die ihnen am Herzen liegen zum laufen zu kriegen, bzw. die Performance zu verbessern. Vor allem da sie selbst die Applikationen am besten kennen ;)
Das Ziel von GNU Classpath ist nicht bloss einen simplen Ersatz fuer proprietaere Bibliotheken zu lieferen, sindern die freien Bibliotheken in vielen Bereichen (Qualitaet, Performance, Ressourcenverbrauch) besser als ihren Gegenpart zu machen.
Ich habe da mal eine Frage. Man liest immer das GCJ, Kaffe usw GNU Classpath verwenden. Heißt das, dass wenn ich zb gcj installiere bereits classpath integriert ist? Oder muß man immer noch GNU Classpath zusätzlich installieren und vielleicht sogar irgendwie dem compiler bekannt machen? Die Frage hat folgenden Hintergrund, selber mache ich sehr wenig mit Java, habe aber alles nötige installiert für den Fall das ich mal an ein java Programm gerate. Aber wenn ich neben gcj+libs noch classpath installiere und mein System dann von Zeit zu Zeit mal aufräumen will, z.B. mit deborphan (Debian), wird mir immer classpath als installierte lib genannt, die eigentlich niemand braucht... Deswegen meine Frage, braucht man Classpath an sich, oder ist das in die entsprechenden java-implementierungen (gcj, kaffe,...) bereits integriert?
Von theBohemian am Sa, 5. November 2005 um 13:05 #
Das ist unterschiedlich.
GCJ, Kaffe & JikesRVM bringen ein Classpath mit. Das geschieht so, dass beim Kompilieren eine Classpath-Version in Quellcodeform in den Quellordner der VM gelegt wird und dann mitkompiliert und -installiert wird. Um diese Details müssen sich aber nur die Paketierer kümmern. Man könnte es auch so sagen: GCJ, Kaffe und JikesRVM sind so wie das JDK: Alles inklusive.
Bei CacaoVM und JamVM ist es so, dass du Classpath als eigenständiges Paket installierst und die VMs dann diese verwenden. Ähnlich also, wie jedes C-Programm eine [g]libc braucht.
Der Grund für diesen Unterschied liegt darin, dass die ersten drei VMs spezielle Implementierungen von bestimmten Basisklassen mitbringen (String, Class, Object, ...) was über das sogenannte VMInterface von Classpath hinausgeht. Schön wäre es natürlich, wenn wir alles noch ein bischen einheitlicher bekämen. Jedoch funktioniert es so schon ganz gut und deswegen stecken wir da auch kaum Energien rein.
Für GCJ und Kaffe wurde der Übergang von einem vollständig autonom gepflegten Classpath-Derivat zu dem Zustand wie wir ihn jetzt haben erst vor kurzem vollzogen und es war AFAIK schon ein ziemlicher Kraftakt für die Beteiligten.
Von Dalibor Topic am Sa, 5. November 2005 um 15:11 #
Das ist korrekt. Siehe http://www.redhat.com/magazine/012oct05/features/java/ fuer einen aktuellen Artikel von Tom Tromey, einem der Authoren von gcj, was man mit gcj machen kann und wie es geht.
Die gcj Entwickler sind auch unter irc://irc.oftc.net/gcj erreichbar.
Wie sieht es beim GCJ aus ?
Der steht ja auch unter der GPL mit der Einschränkung das man Programme gegen die Sachen linken kann ohne das der eingene Code unter die GPL flällt.
Also wenn ich
in meinem Code angebe
include irgendeine Classpath Klasse
gilt die GPL Regel nicht
Wenn ich aus dem Classpath Code eine Funktion in meinen Code kopiere steht mein Code automatisch auch unter der GPL.
Oder gibt es beim Include schon irdendwas das man beachten muss wie z. B. statische und dynamisches Linken?
Irgenwie ist da doch ein Widerspruch zur QT Lizenz wenn ich über Classpath indirekt QT in Programmen verwende die nicht unter der GPL stehen?
> include irgendeine Classpath Klasse
> gilt die GPL Regel nicht
So ist es.
> Wenn ich aus dem Classpath Code eine Funktion in meinen Code kopiere steht
> mein Code automatisch auch unter der GPL.
Auch das stimmt.
> Irgenwie ist da doch ein Widerspruch zur QT Lizenz wenn ich über Classpath
> indirekt QT in Programmen verwende die nicht unter der GPL stehen?
Welchen Widerspruch meinst Du?
GNU Classpath steht gewissermaßen unter einer abgeänderten GPL (besser gesagt unter GPL mit Zusatz) und Qt steht unter der GPL.
Betrachte die abgeänderte GPL einfach als soetwas wie die LGPL. Da gab es mal auf der GNU Classpath Mailingliste Diskussionen zu, weshalb GNU Classpath die abgeänderte GPL verwendet und nicht wie die ersten GNU Classpath Versionen die LGPL.
Ich meine der Grund war letztendlich, da der Java Binary-Code anders abgearbeitet wird als nativer Code der durech C/C++ Propgramme erzeugt wurde.
Wenn ich mich richtig erinnere wirkt die LGPL auf bei Programmen auf einer JVM so ähnlich wie die GPL. Daher dürften dan eigentlich auf LGPL-Klassen keine propietären Klassen aufbauen. Und damit das aber wieder möglich ist, gibt es die abgeänderte GPL.
Im ueberigen, Sun's JDK benutzt code unter der LGPL, wenn das also mit der LGPL und Java so waere ... waere es lustig. Ist es aber nicht.
gruss,
dalibor topic
Der Sinn liegt darin, dass Classpath auch im Bereich eingebettete Systeme verwendet wird, wo statisches Linken dem dynamischen vorgezogen wird.
Die Bestimmungen der GPL (jetzt mal ohne LE) sind übrigens im Hinblick auf die regulären Java-Pakete hinfällig. Du kannst dein Programm so proprietär wie nur möglich machen solange es nur Klassen aus den Namensbereichen verwendet, die es bei der Sun Implementierung auch gibt (java., javax. , ...). Anders wäre es wenn auf irgendwas internes bei uns zurück greifst ("gnu.classpath."). Hierfür hast du dann aber unsere Linking Exception.
ch empfehle aber momentan niemandem Klassen aus der internen API zu verwenden, da wir nicht garantieren können, dass das versionsstabil ist und ausserdem würde man sich die Lauffähigkeit auf den proprietären JDK vermasseln. Gleiches gilt übrigens auch für sun.com und com.sun Pakete im JDK.
Mit Qt und GNU Classpath verhaelt es sich so aehnlich wie mit Qt und, sagen wir mal, KDE Bibliotheken.
Die Art von Frage stellt sich oefters, eine Antwort gibt es zum Beispiel unter http://lists.trolltech.com/qt-interest/2002-03/msg00293.html
Kommen wir zum Java-spezifischen Teil:
Quelltext der nur die implementierungsunabhaengigen Standardklassen und Methoden benutzt, ist unabhaengig vor der Lizenz der Implementierung.
Daraus erzeugter Bytecode ist in Javas Fall extra so entworfen, dass bei dem Kompilat aus Gruenden der binaeren Kompatibilitaet nur implementierungaunaghaengiger Bytecode entsteht. Damit kann das Kompilat nicht ein Derivat der Implementierung sein auf der es ausgefuehrt wird, bzw mit der es erzeugt wird. Im besonderen, kann das Kompilat nicht ein Derivat der internen Bibliotheken sein, welche bei der Implementierung verwendet werden, die zur ausfuehrung des Bytecode eingesetzt wird.
Fuer eine Analogie aus einem anderen Bereich, siehe shell Skripte unter GNU/Linux: Obwohl GNU Bash unter der reinen GPL steht, und ihrerseits die unter der reinen GPL stehende Bibliothek GNU readline benutzt, gbt es keine Lizenzbeschraenkung fuer die Shellskripte die mit der Bash interaktiv geschrieben werden, oder mit der Bash ausgefuehrt werden. Solche Nutzungseinschraenkungen gibt das Copyright, auf des sich die GPL stuetzt, einfach nicht her (und es waere auch nicht wuenschenswert).
Ein VM Projekt, dass sich entscheidet die Qt4 peers fertig gepackt mitzuliefern, muss sich an die Lizenzen von Qt und GNU Classpath halten. Das ist bei einer freien VM die in ihrer Gesamtheit under der GPL steht, wie Kaffe, recht trivial. Fuer andere freie VMs gibt es die moeglichkeit die Qt Bibliotheken (sofern sie diese ueberhaupt mitliefern wollen) unter der QPL zu lizenzieren, die, obwohl GPL-inkompatibel, fuer Projekte unter Lizenzen mit weniger rigidem Copyleft-Anspruch als die GPL geeignet ist.
Fuer Programme, die explizit Bibliotheken aussehalb von GNU Classpath verwenden, mussen die Lizenzbestimmungen dieser Bibliotheken beachtet werden. Wenn sich, zum Beispiel, in einem Binary sowohl mein Code unter meiner Lizenz, GNU Classpath code unter GPL+LE und Qt4 Code unter der GPL befinden, dann kann ich nicht behaupten dass meine Pflichten gegenueber den Authoren von Qt4 durch die LE von GNU Classpath aufgehoben werden. Bespielsweise wenn ich ein statisches Binary aus meinem Code, GNU Classpath und Qt4 erzeugen wuerde. In dem Fall wuerde ich schauen dass ich Qt4 unter der QPL Lizenz nehme, falls mein Code Freie Software ist und nicht unter der GPL steht.
gruss,
dalibor topic
a) Kompatibilitätstest
Ist Classpath 100%ig bytecodekompatibel zum JRE 1.5?
Nein. Fazit: Unbrauchbar
b) Praktischer Gebrauchstest (zweite Chance um Nachteil a aufwerten zu können)
Wird mit Classpath-Java-Doc eine deutschsprachige Java-Doc ausgeliefert?
Nein. Fazit: Unbrauchbar
Wie man anhand von zwei sehr einfachen Betrachtungen sehen kann, ist Classpath in der jetzigen Version in vollem Umfang zu nichts zu gebrauchen. - Allenfalls als Beschäftigungstherapie für die Programmierer. -
In erster Linie strebt das Projekt die 1.4 Kompatibilität an. Nimmt man mal swing raus, funktioniert das auch schon ganz gut.
Bei dem Tempo, ist die 1.5-Kompatibilität höchstens 1 Jahr entfernt ;-)
Da Du aber nichts zum Fotschritt des Projeketes beitragen möchtest, wird es Dich auch nicht sonderlich interessieren...
b)1.4-Kompatibilität ist unwichtig, da veraltet; Swing ist absolut unverzichtbar.
Beispiel: Betrieb, Classpath ist installiert. Wenn nun SW mit 1.5 Anforderung kommt, kann sie nicht eingesetzt werden. Jegliche Diskussion ist in diesem Moment sinnlos. Die Durchsetzung von SW wird im betrieblichen Umfeld entschieden und nicht in Kinderzimmern.
Ich persönlich freue mich das es GNU Classpath gibt, auch wenn ich java noch nicht gebraucht habe.
Gruss
Erzähl das den Leuten, auf deren Plattform es noch kein J2SE 5.0 gibt.
Swing ist absolut unverzichtbar
<ironie>Vor allem in der Webentwicklung (J2EE).</ironie>
Bei Smart-Clients würd ich z.Zt. eher auf SWT setzen. Erst mit J2SE 6.0 könnte sich da was ändern.
Swing ist schon eher ein Problem, aber da sind die Entwickler mit Hochdruck dran und kommen auch gut voran.
falsch. Wir verwenden GNU Classpath, und zwar in einem kommerziellen/betrieblichen Umfeld.
b)1.4-Kompatibilität ist unwichtig, da veraltet; Swing ist absolut unverzichtbar.
wieder falsch. Viele Kunden im kommerziellen Feld (ich rede hier von Echtzeit und Embedded Systemen) brauchen nur 1.1 Kompatibilität. Swing is wichtig aber bei weitem nicht unverzichtbar.
Du solltest Deinen Horizont etwas erweitern.
Gibt's dich noch oder bist du schon irgend jemandem durchlöchert worden, dass bei durchblick besteht?
Es gibt verschiedene Anwendungsgebiete.
Es muss nicht immer rückwärtskompatibel sein.
Falls der Code sich kompilieren lässt, so ist dies sehr gut und man kann es auch gebrauchen.
Ich will auf meiner Maschine z.B. kein Sun/Java. GNU Classpath hingegen läuft sehr gut (für OpenOffice)
ich finde es zwar schade, dass du unsere Software nicht gebrauchen kannst, aber ich kann dir sagen, dass es dem Classpath Team sehr viel Freude bereitet sie zu erstellen.
Ich persönlich habe zum Beispiel diese Erfahrung gemacht:
Letztlich bemerkte ich das auf einem frisch eingerichteten Ubuntu "Breezy Badger" System mit OpenOffice 2.0 eine Version von GCJ installiert war. Ich stellte mir vor wieviele Ubuntu Systeme es wohl gäbe und wievielen Menschen unsere Arbeit etwas nützt, egal ob sie es wissen oder nicht. Nun, ich kann nicht sagen wieviele Leute Ubuntu einsetzen, aber die die es tun, sind bestimmt froh, dass alles so problemlos funktioniert. Und von all diesen Leuten verlangen wir nichts. Sie können die Software einsetzen ohne das wir sie zu irgendetwas zwingen.
Sogar du, der dem Projekt Classpath nicht vorbehaltlos gegenübersteht, darfst es nutzen (und ich würde mich sogar darüber freuen).
Was ich sagen will ist: "Schau mal, da gibt es noch eine Menge andere Sichtweisen auf diese eine Sache."
> Menschen unsere Arbeit etwas nützt, egal ob sie es wissen oder nicht.
Man könnte natürlich auch mal fragen, wie vielen Menschen "eure" Arbeit (diese Information erklärt übrigens einiges an Missioniererei, danke dafür) nicht nutzt, egal ob sie es wissen oder nicht.
> Nun, ich kann nicht sagen wieviele Leute Ubuntu einsetzen, aber die
> die es tun, sind bestimmt froh, dass alles so problemlos funktioniert.
Was funktioniert problemlos? Azureus schon mal nicht, also kann es nicht "alles" sein. Da darf man den Ubuntu- und Fedora-Nutzern in den letzten Monaten immer wieder dieselbe Frage beantworten, mit immer wieder demselben Wortlaut: "Nein, das was Du da hast, ist kein Java und funktioniert nicht => runter damit".
> Sie können die Software einsetzen ohne das wir sie zu irgendetwas zwingen.
Dafür, dass das alles so freiwillig, altruistisch und unaufdringlich sein soll, ist doch wirklich erstaunlich viel Missioniererei zu bemerken. Als Zwingen kann man das noch nicht bezeichnen, aber es ist nahe dran, insbesondere wegen der Abschreckungstaktik gegenüber "anderen", sog. "unfreien" Implementationen.
Programme die nicht teil einer Distribution sind, koennen funktionieren (und tun es meiner erfahrung nach zunehmend), mussen aber nicht. In dem Fall bleibt immer noch die Moeglichkeit sich zusammen mit den Entwicklern der Applikation und GNU Classpath entwicklern an das beheben von bugs zu machen.
Azureus hatte, zum beispiel, als ich letztes mal reingeschaut habe, nicht portablen Java code der in undokumentierten sun.* Klassen rumfuhrwerkelte. Das ist so, wie wenn eine Applikation versteckte Windows APIs verwendet; dann muss mal erst den Azureus Kode wieder portabel machen.
Das ist in den meisten faellen nicht so schwierieg, und das GNU Classpath Projekt pflegt ein Wiki mit Tips wie man die Qualitaet und Protabilitaet von Java Kode steigern kann. Genaueres gibt es unter http://developer.classpath.org/mediation/ClasspathMigration
Solltest Du interesse daran haben, mitzuhelfen Azureus in Ubuntu und Fedora Core mit freien implementierungen zum fliegen zu bringen, sind die ubuntu-java und fedora-java mailinglisten ein guter start. Meines Wissens nach, wird an Azureus fuer eine zukuenftige Version von Fedora bereits gearbeitet, ich habe die Details jedoch nicht parat.
Ich hoffe, dass ich damit deinen Schrecken verjagt habe, woher er auch gekommen sein mag.
gruss,
dalibor topic
Ich hoffe dass Dein weiteres verweilen auf pro-linux.de Dir hilft, und wuensche alles gute fuer die Zukunft. Die Heise Foren findest Du unter heise.de.
gruss,
dalibor topic
gruss,
dalibor topic
Deutsche JavaDoc : da die meisen Prog. kein englisch verstehen. ;-)
Opensource nicht zu gebrauchen : Apache;Tomcat;Turbine;Hibernate;Eclipse;Spring;Struts .. .usw. . OK nicht alles GPL aber opensource.
Gute Arbeit und weiterso an das ClassPath Team
So ein Quatsch. Wenn ein Programmierer kein Englisch kann, hat er sowieso verloren.
Ich habe schon genug JDK-Dokumentation gelesen und im Prinzip ist der beschreibende Text sowieso unwichtig weil einem als Entwickler meistens nur die Parameter und dessen Typen interessieren.
Auch sonst lese ich lieber die englische Dokumentation weil sie gewöhnlich aktueller und ausführlicher ist als die deutsche Übersetzung.
...
...
...
...
Don't feed the Troll ;-)
Sicher kann man dem ganzen so oder so gegenüberstehen, aber so eine pauschalisierende und durch subjektive Kriterien untermauerte Haltung kann keine ernsthafte Diskussionsbasis darstellen.
Ciao,
Christian
PS: Ich habe auch das SUN JDK auf meinem Ubuntu installiert, allerdings ging es dabei um ein Swing-Programm, was eben mit der freien Implementation nicht lief. Ich würde mich allerdings freuen, wenn ich auf diesen SUN Kram bald verzichten kann. Schon aus Bequemlichkeitsgründen, da man das SUN JDK ja immer noch umständlich von deren Homepage runterladen muß.
> Schon aus Bequemlichkeitsgründen, da man das SUN JDK ja immer noch umständlich von deren Homepage
> runterladen muß.
Jedem seine Motivation.
habe gerade auf der HP von denen geschaut und für mein aktuelles Projekt sieht es ganz gut aus, das es auch mit Classpath läuft.
Nutze aufgrund von der Dynamik sehr viele andere Projekte in dem Programm
JDOM, FOP, JGoodies usw.
java.lang.reflect wird ja schon zu 100% a bgedeckt :-)
Wie sieht es nun mit Java-Webstart aus?
Sprich kann ich auch auf Classpath setzen und Java-Webstart nutzen?
Wäre für die Verbreitung des Tools was ich gerade schreibe gar nicht mal so unwichtig das mit Classpath auszuliefern/zu verbreiten anstatt mit dem orig. Java.
Was mir da also noch fehlt ist die WebStart funktionalität und die Klasse JNLP. Dann würde nichts gegen Classpath sprechen...
Mal schauen was aus dem Projekt wird.
Ach ja, es muss auch unter Win laufen, leider.
Grüße
Andreas
netx sollte seit Mai diesen Jahres mit GNU Classpath laufen. Siehe http://www.peakpeak.com/~tromey/blog/2005/05/22/ . Eine andere implementierung ist OpenJNLP, aber mir ist ueber deren lauffaehigkeit nichts bekannt. Gute und schlechte neuigkeiten diesbezueglich waeren auf der GNU Claspath Mailingliste willkommen.
Ich persoenlich wuerde gerne in eines der naechsten Kaffe releases eine JNLP umgebung integrieren (unter anderen Dingen). Windows ist jedoch noch nicht Kaffe's staerke, in dem Fall empfehle ich sich nach alternativen umzusehen. Eine kurze liste gibt es unter http://www.javagaming.org/forums/index.php?topic=11135.new#new
gruss,
dalibor topic
> Gern gesehen sind Freiwillige, die eine neuere API wie JMX, SQL Rowsets oder die Concurrent Utilites entwickeln bzw. pflegen wollen.
Hm, also wenn mich nicht alles täuscht, gibt es doch für die genannten APIs bereits einige freie Implementierungen.
Z.B. beinhaltet MX4J JMX. Die Concurrent API stammt je größtenteils von Doug Lea - gibt es die nciht auch als Open-Source? Und SQL Rowsets sollte es doch in jedem freiem JDBC4-Treiber geben?
Nun anscheinend wohl nicht ...
Cheers
Externe Software, die in GNU Classpath integriert wird, muss bestimmten rechtlichen Anforderungen entsprechen.
Sie muss freie Software sein. Das war ein Grund fuer GNU Classpath eine eigene CORBA Implementierung in Java zu entwickeln: die Standard-org.omg Klassen, die man bei der OMG herunterladen kann, duerfen nicht modifiziert werden, und sind daher keine freie Software.
Des weiteren muss externe Software die in FSF's GNU Classpath integriert wird, unter einer GPL-kompatiblen Lizenz stehen. Das schliesst eine Integration von Kode unter der Apache Lizenz, zum Beispiel, vorerst aus, solange wir die Inkompatibilitaet nicht aus dem Weg geraeumt haben. Daran wird von beiden Seiten gearbeitet, und ich erwarte ein paar Ergebnisse zur naechsten ApacheCon.
Das ist eine Selbstbeschraenkung, die sich die FSF freiwillig auferlegt hat, da die FSF bereits einen grossen Fundus an ausschliesslich GPL-kompatibler Software geschaffen hat, und es fuer sie keinen Sinn machen wuerde, Lizenz-Inkompatibilitaeteten zwischen der Software die sie distributieren zu foerdern. Des weiteren sind einige von VMs die GNU Classpath einsetzen und zu GNU Classpaths Entwicklung beitragen, unter der GPL, und die Integration von GPL-inkompatiblem code waere fuer sie problematisch.
Andererseits duerfte das Apache Harmony projekt, welches eine VM unter der Apache Lizenz erstellt, komponenten aus GNU Classpath die bereits im Apache Projekt implementiert sind, bei ihrer 'GNU Classpath Distribution' durch eigene XML komponenten, bespielsweise, ersetzen.
Das ist explizit durch die 'linking exception' erlaubt, so dass man das beste aus beiden Welten hat: ein FSF Projekt, dass sich stark fuer gute, freie Software die auch frei bleibt engagiert, aber es auch explizit erlaubt ihre Bibliotheken durch andere freie oder auch nicht-freie Software zu ergaenzen, sofern man das wuenscht.
gruss,
dalibor topic
- wollt ihr Classpath irgendwie institutionalisieren? Also einen Verein oder eine Gesellschaft gründen? Was gerade Businesspartner ja gerne sehen wollen ist ist irgendeine Firma oder Org dahinter. Da müssen wir in europa aufholen, die Amis treiebn auf die Weise eine Menge Geld für Entwickler ein.
- Warum nehmt ihr an so wenigen Veranstaltungen teil und präsentiert eurer Projekt und die derzeitigen Herausforderungen? Ich glaube auch Videos und Audios von Entwicklertreffen (seit es torrents gibt auch kein bandbreitenproblem mehr) und blogs und wikis und dergleichen sind ganz wichtige Mittel um ein Projekt durchstarten zu lassen. Auch wenn 80% sowieso immer von einem Kernteam erledigt werden.
- Classpath macht fantastische Fortschritte. Wo seht ihr im moment die Hauptkompatibilitätsbremsen?
- Es gibt ja Unmengen an Freeware und OpenSource in Java. Wie viel Prozent läuft denn unter Classpath und kann man classpath mit solchen echten Applikationen debuggen oder haltet ihr das für ein falsches Vorgehen?
schick mir mal ne Mail mit diesen Fragen und ich beantworte sie umgehend.
Meine ursprüngliche Fassung der News enthielt einen Kommentar einer Firma die sich im Classpath Bereich engagiert. Eine andere Dachorganisation als GNU bzw. die FSF haben wir aber nicht.
Bedenke, dass vieles von dem was wir machen von persönlichem Engagement abhängt (zB diese Presseankündigung, die Classpath-Artikel). Wenn du dich einbringen möchtest und das dem Projekt zugute kommt, bist du herzlich eingeladen. :)
Viele Grüße
Robert
GNU Classpath selbst, ist wie gcc, und andere GNU toolchain Projekte, ein Projekt der Free Software Foundation. Die FSF hat einen europaeischen Zweig, die FSF Europe, der sich ebenfalls der Foerderung von freier Software verschrieben hat. Naehere informationen zur FSF gibt es unter http://ww.fsf.org . Wenn du Ideen hast wie zum Beispiel ein GNU Classpath e.V. die Arbeit des Projektes in Deutschland verbessern und die Ideen verbreiten koennte, sollten wir uns darueber auf der GNU Classpath mailingliste unterhalten.
Unternehmen, die ein bestimmtes Interesse an der Mitarbeit haben, koennen sich mit Mark Wielaard, dem Maintainer des GNU Classpath Projektes, in Verbindung setzen. Fuer eine Einfuehrung in die ersten Schritte fuer die Mitarbeit an GNU Classpath, siehe http://developer.classpath.org/mediation/ClasspathFirstSteps
Entwicklerblogs gibt es unter http://planet.classpath.org . Von Entwicklertreffen gibt es diverse Slides, aber meines wissens nach noch keine Audio/Video aufzeichnungen. Das waere fuer die naechste FOSDEM eine gute Idee. Falls du interessa hast, mitzuhelfen dafuer etwas auf die beine zu stellen, sollten wir uns ebenfalls auf der Classpath mailingliste darueber unterhalten. Das Projekt lebt sehr stark von Engagement einzelner Mitglieder, und wir koennten sicherlich mehr Leute gebrauchen die uns helfen GNU Classpath praesenter zu machen.
Bei der Kompatiblitiaet sind bei Swing und co. noch ein paar Luecken, wo Klassen und Methoden noch nicht implementiert worden sind. Die groessten Kompatibilitaetsfortschritte lassen sich erzielen, wenn Leute Kode haben, den sie auf GNU Classpath am laufen haben wollen. Daher steht das Projekt mit verschiedenen anderen Projekten in Kontakt, unter anderem Eclipse, JOnAS, OpenOffice.org, und einigen Projekten der Apache Software Foundation, um GNU Classpath in zusammenspiel mit den Entwicklern dieser Applikationen zu verbessern.
Man kann, und es ist sehr wuenschenswert
GNU Classpath mit echten Open Source Applikationen und Bilbiotheken beutzen, um Fehler zu finden und zu beseitigen. Da arbeitet das Projekt vor allem mit Distributionen wie Fedora, Ubuntu, Debian und Gentoo zusammen, die interessiert sind moeglichst viel freie Software auf einem voellig freiem Stack zu haben, ohne stoerende propriaetere Elemente dazwischen.
Insbesondere Nutzer und Entwickler von freier Software in Java sind eingeladen mitzuhelfen, die Applikationen die ihnen am Herzen liegen zum laufen zu kriegen, bzw. die Performance zu verbessern. Vor allem da sie selbst die Applikationen am besten kennen ;)
Das Ziel von GNU Classpath ist nicht bloss einen simplen Ersatz fuer proprietaere Bibliotheken zu lieferen, sindern die freien Bibliotheken in vielen Bereichen (Qualitaet, Performance, Ressourcenverbrauch) besser als ihren Gegenpart zu machen.
gruss,
dalibor topic
Die Frage hat folgenden Hintergrund, selber mache ich sehr wenig mit Java, habe aber alles nötige installiert für den Fall das ich mal an ein java Programm gerate. Aber wenn ich neben gcj+libs noch classpath installiere und mein System dann von Zeit zu Zeit mal aufräumen will, z.B. mit deborphan (Debian), wird mir immer classpath als installierte lib genannt, die eigentlich niemand braucht...
Deswegen meine Frage, braucht man Classpath an sich, oder ist das in die entsprechenden java-implementierungen (gcj, kaffe,...) bereits integriert?
GCJ, Kaffe & JikesRVM bringen ein Classpath mit. Das geschieht so, dass beim Kompilieren eine Classpath-Version in Quellcodeform in den Quellordner der VM gelegt wird und dann mitkompiliert und -installiert wird. Um diese Details müssen sich aber nur die Paketierer kümmern. Man könnte es auch so sagen: GCJ, Kaffe und JikesRVM sind so wie das JDK: Alles inklusive.
Bei CacaoVM und JamVM ist es so, dass du Classpath als eigenständiges Paket installierst und die VMs dann diese verwenden. Ähnlich also, wie jedes C-Programm eine [g]libc braucht.
Der Grund für diesen Unterschied liegt darin, dass die ersten drei VMs spezielle Implementierungen von bestimmten Basisklassen mitbringen (String, Class, Object, ...) was über das sogenannte VMInterface von Classpath hinausgeht. Schön wäre es natürlich, wenn wir alles noch ein bischen einheitlicher bekämen. Jedoch funktioniert es so schon ganz gut und deswegen stecken wir da auch kaum Energien rein.
Für GCJ und Kaffe wurde der Übergang von einem vollständig autonom gepflegten Classpath-Derivat zu dem Zustand wie wir ihn jetzt haben erst vor kurzem vollzogen und es war AFAIK schon ein ziemlicher Kraftakt für die Beteiligten.
Die gcj Entwickler sind auch unter irc://irc.oftc.net/gcj erreichbar.
gruss,
dalibor topic