die Popularität von Java-Entwicklungswerkzeugen wie z.b. Eclipse, die keine kommandozeilen basierten Werkzeuge zum kompilieren der Quellen bieten (wie bspw. ant), was eine (ordnungsgemäße) Paketierung sehr aufwändig macht.
Die Pakete sollten weiterhin aus den Quellen erstellt worden sein, damit sich Patches erstellen lassen (delta rpms), die dann wesentlich kleiner sind und somit den Nutzer und den Distributor entlasten.
Also, ich mache grundsätzlich alles mit Ant (ausser Compilieren), auch in Eclipse. Das ist schon seit Version 2.x drin. Ich verstehe die hervorgebrachte vermeintliche Ursache nicht.
siehe oben, ums Kompilieren geht es aber eben. Verstehen tue ich auch nicht, warum hauptsächlich Eclipse Nutzer Probleme damit zu haben scheinen, da ich Eclipse selbst nicht nutze. Meine Erfahrung beruht auf java Projekten die in Eclipse bearbeitet werden und gerade eben dieses build-script das aus einem script (spec - file) augerufen werden kann, nicht zu haben scheinen. Gib doch mal einen link/howto wie ich ein Eclipse project auf der Kommandozeile baue.
Ziemlicher Mehraufwand, bei netbeans bekommt man das automatisch mit ... Komisch eigentlich, das für diese Funktion noch keine Notwendigkeit gesehen wurde, weil das für die Paketierung eigentlich vorausgesetzt wird und eclipse viele Jahre DIE Java IDE war/ist, vor allem im open source Bereich.
... das Problem, muss aber darauf hinweisen, dass ich nicht verstehe, warum das nicht bereits von den Päcklibauern erledigt worden ist, zumal alle Informationen vorhanden sind (1 XML-File, 1 Propertyfile, also nichts kompliziertes). Das Compilieren ist damit vollständig und automatisch ausführbar, man muss diese Infos halt richtig verwerten und den javac entsprechend anstossen. Danach erfolgt die Ausführung des eigentlichen Buildskriptes. Im Detail: Die Sourcepfade, der Classpath und die Projektabhängigkeiten gehen aus ".classpath" hervor. Manchmal sind die Libs extern, dann muss man eben etwas tun (herunterladen, Classpath anpassen). Wenn das Compilieren durchgelaufen ist, kann man das eigentliche Buildskript aufrufen. Also, soooo compliziert ist das nun auch nicht. Lediglich ist das einfach nicht so vorbereitet, weil aus Eclipse halt meistens die fertigen Jars geliefert werden. Im übrigen, die Compilerargumente findet man in .settings/org.eclipse.jdt.core.prefs. Also, das ist ohne Probleme machbar, aber eher ein Problem der Integration in die Buildumgebung als eines der Javaentwickler.
Bei den C-Sourcen ist im übrigen auch nicht alles einheitlich, das ./configure ist nicht immer am gleichen Ort. Ein schönes Beispiel für die Einheitlichkeit ist z.B. bristuff.
Es können sowohl maven als auch ant in Eclipse verwendet werden. Ich halte die Argumentation im Artikel für falsch bzw. sehr ungenau.
Das Problem liegt eher in der Komplexität und schnellen Weiterentwicklung bzw. häufigen Refactoring von Libraries und Frameworks. Aber auch das ist wahrscheinlich etwas zu einfach ausgedrückt.
Möglicherweise kann man die Versionsauswahl über Maven etwas nachbessern.
Javaentwickler sind beim Refactoring nicht gerade zimperlich. Wenn Refaktoring nicht das Problem ist, dann die häufige Veränderung der Signaturen. Die Anpassungen in den abhängigen Projekten werden halt automatisch nachgeführt, ausser eben in anderen Workspaces, aber an die anderen denkt man nicht immer.
Dem kann ich mich leider nicht anschliessen. Ich benutze Jaikoz zum Taggen meiner MP3's und Alben. Ist wirklich komfortabel und gut. Basiert auf Java. Vor allen Dingen mag ich es die Alben zu laden, dann per CTRL+1 das ganze dann automatisch von Musicbrainz und Dicogs zu updaten.
jabref ist toll, leider ohne office integration für den Nutzer im Alltag (fast) wertlos. Warum wurde daran eigentlich nie etwas gemacht ... ich meine von beiden Seiten - Office (OOo, KWord, ... ) als auch seitens Jabref? Sehr schade! zotero ist da schon ein stück weiter...
Ein großteil aktueller Software (leider nicht alle) benutzen heutzutage das maven archive (ob per maven, ivy, grape oder gradle). Dort ist nun fast jede Bibliothek in beliebiger Version verfügbar. Eigentlich müsste man nun nur einen Weg finden dieses Bibliotheken-System in das Packetsystem der Distribution zu integrieren.
Na klar gibt es dann immer noch verschiedene Libs (in verschiedenen Versionen) als Abhängigkeit aber diese Liegen zumindest zentral. Weiterhin kann man halt entsprechend drauf hinweisen, dass bei Verwendung dieses Systems nicht die aktuallität bewahrt werden kann und sich somit Sicherheitslücken nicht von der Distribution direkt beheben lassen.
Jedoch kann das ein schrittweiser prozess sein. Ist eine sicherheitslücke in einer bibliothek bekannt kann entsprechend der Hersteller einer Java-Produkts auf diese Weise informiert werden und entsprechend reagieren. Aktuell ist die Situtation so, dass bei vielen Java-Projekten die Dependencies kaum verändert werden. Vor allem auch weil Informationen über Sicherheitslücken fehlen (Keine zentrale Informationsstelle).
Hier müsste herrscht entprechender Verbesserungsbedarf und ein Zusammenwachsen dieser Systeme würde eine Win-Win-Situation erzeugen.
Softwareprojekte die maven als build system verwenden, werden damit auch während das Paketierungsprozesses gebaut (so sollte es sein, Realität kann abweichen) .... und dann in ein rpm/deb verpackt.
Ich verstehe nicht so ganz, welchen Vorteil Du Dir von einem zweiten paketmanagement bzw. modulverwaltung versprichst? Indem man die Abhängigkeiten für das Paket angibt, können die entsprechenden Pakete mitinstalliert werden.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 27. Sep 2010 um 11:19.
Von The Linux Lover am Mo, 27. September 2010 um 12:15 #
Java zu lernen ist nun wirklich nicht sonderlich schwer, allein sich durch den Wust der relevanten Bibliotheken zu arbeiten, war immer eine Krankheit. Das ganze Ökosystem Java verlangt einen Aufwand sich einzuarbeiten, der einfach zu hoch ist, auch wegen schlechter Dokumentation Das spiegelt sich letztlich auch in solchen Problemen wieder.
Der Wust an Bibliotheken ist bei C bzw. C++ nicht geringer. Und pauschal zu behaupten alles an Java wäre schlecht dokumentiert ist doch Quatsch. Im Gegenteil, amn findet sehr viel an guter Dokumentation. Schon bei Sun bzw. jetzt Oracle, gibt es sehr viele gute Anleitungen und Referenzen.
Und so verschieden sind die Meinungen. Ich finde die Python-Doku katastrophal, auch wenn mir die Programmiersprache an und für sich ganz gut gefällt. Aber in der API-Doku für Java[1] bin ich fast immer schneller fündig als bei Python [2]. Auch die Übersichtlichkeit (Rückgabewerte, Exceptions, Basisklassen, ...) gefällt mir in der Java-API-Doku besser.
Allerdings ist das Umfeld bei Java ein anderes als normalerweise unter Linux. In Java werden oft Enterprise-Anwendungen geschrieben, für die die entsprechenden Bibliotheken mitgeliefert werden. Da diese Bibliotheken auf dem entsprechenden Host dann von sonst keiner Anwendung benötigt werden ist das auch kein Problem und hat dann auch Vorteile.
Wenn nun allerdings eine Bibliothek von vielen Anwendungen gebraucht wird, ist man mit diesem Verfahren nicht so gut bedient. Allerdings würde ich dann ein Konzept besser finden, bei dem man, ähnlich maven oder OSGI, verschiedene Versionen einer Bibliothek vorhalten kann. Aber das normale Linux-Konzept, eine Bibliothek systemweit nur in einer Version zu verwenden, würde hier nicht hinhauen.
Was mich bei Python wirklich stört ist, dass man für jedes Programm eine Python Umgebung starten muss. Wenn man zehn Python Programme hat, dann hat man auch zehn Interpreter mit ihren ganzen Footprints am laufen. Da wird aus einem einfachen 'hello world' daemon ein fettes Batzen inkl hohem RAM Verbrauch. Würde ich das in C schreiben, würde ich das Programm nicht mal im Hintergrund merken.
Ähm... Du merkst auch 10 kleine Python-Scripte nicht im Hintergrund. Außer natürlich sie machen viel. Und du wirst auch 1000 "hello wourld"-Scripte in Python nicht im Hintergrund merken.
Von Anonymous am Di, 28. September 2010 um 00:09 #
Jaja, die Python-Doku ist schon super. Z. B. für pulldom: http://docs.python.org/library/xml.dom.pulldom.html. Diese ... sind wirklich enorm aussagekräftig.
Ein Problem, auf das ich immer wieder stosse, ist dass "unvollständige" Methoden/Klassen in der Bibliothek final sind. Ein prominentes Beispiel ist JGoodies, wo alles und jedes final ist, selbst wenn völlig offensichtlich eine begrenzte Anzahl von Fällen abgehandelt behandelt wird. Da wäre viel Schulung zu leisten, nämlich dass man den Entwicklern beibringt, dass nur das final zu sein hat, was unter keinen Umständen geändert werden darf, weil sich das gesamte Verhalten auf unvorhersehbare Weise ändern könnte. Workarounds um solche Probleme erhöhen die Versionsabhängigkeit drastisch (alternativ kann man forken, dann haben wir wieder das obengenannte Problem).
Allgemein werden die Aufrufe in Javabibliotheken nicht sehr stabil gehalten. Die Änderung der Schnittstelle nach aussen fällt gar nicht so auf, da es keine Headerfiles gibt. Wenn man die Signatur einer public-Methode anpasst, ist es eben schon passiert.
Unendliche Vererbungsketten sind zu vermeiden aber in vernünftigem Masse ist das das einzig sinnvolle für moderne Applikationen. Damit, dass man Java als Sprache beherrscht, garantiert aber noch kein gutes Design. Es wird zu wenig Wert darauf gelegt, zu vermitteln, zu welchem Zweck welches Mittel eingesetzt wird.
Es ist zudem nicht nur Vererbung, die unter "final" zu leiden hat sondern auch, wenn man Interceptoren implementieren will (Codeinjection). Das ist natürlich complettes Teufelszeug. Um Beans automatisch auf dem Client zu propertyChangeEvent-enablen, ohne bei jedem die gleiche Liternei zu coden, hat sich das jedoch bei meinem Programm gut bewährt. Ich programmiere doch nicht zu dem Zweck, möglichst viele Codezeilen zu produzieren...
Zumindest hat das vollständige Paketieren einen nicht unerheblichen Vorteil: egal welche Distribution, passt die JVM, gilt drop and run. Das ist was sich User wünschen. Jeder von uns kennet doch die Probleme Software ist nicht im Repository der Distribution und benötigt Lib X Lib Y und Lib Z die wieder zig Abhängigkeiten haben und mit bestehenden Versionen kollidieren. Nicht jeder normale Desktop Nutzer möchte sich da durch kämpfen. Ich kann das gut verstehen. Warum soll sich ein normaler Desktopbenutzer mit den Libraries abschlagen, es wird ja auch nicht verlangt das jeder in seinem Auto die Zylinderkopfdichtung selbst tauschen kann.
PS: Ich nutzte übrigens Gentoo, welches aber definitiv nichts für den normal Nutzer ist.
Ich verstehe die Argumentation des Artikels überhaupt nicht. Was bitte unterscheidet Java Anwendungen, von C/C++ Anwendungen?
In C/C++ sind auch alle Bibliotheken irgendwo verteilt und haben alle ganz unterschiedliche Versionen. Ein C/C++ Entwickler nimmt sich eine Bibliothek mit Version X und solange es funktioniert bleibt er dabei. Auch FF wird mit ganz bestimmten Versionen ausgeliefert, wenn man sich das tar.gz Paket runter lädt.
Wie machen die Distributionen das mit den C/C++ Programmen? Man nimmt den Code, kompiliert es gegen die Bibliotheken in der Distribution und testet das Programm. Genauso kann man es doch mit Java machen? Sehe ich nicht wo die Gründe, die der Autor angibt, irgendwas speziell mit Java zu tun haben.
Auch andere Scriptsprachen (nicht C/C++ Sprachen), kochen ihr eigenes Süppchen. Php mit PEAR, Perl mit CPAN, Python mit pypi, Ruby mit gems. Wenn man sich das überlegt, ist eigentlich C/C++ die Ausnahme, ohne ein zentrales Repository für Bibliotheken. Java hat Maven.
Es gibt halt nicht so viele Java Programme für den End-User. Die meisten sind in den Unternehmen zu finden und sind bestimmt nicht Open Source.
Von Anonymous am Di, 28. September 2010 um 00:14 #
Open Source-Programme werden in der Regel eben ohne gebundelte Bibliotheken ausgeliefert; Firefox stellt hier eine Ausnahme dar (übrigens liefert auch Firefox nicht alle benötigten Bibliotheken mit, gtk wird z. B. glaube ich nicht mitgeliefert).
die Popularität von Java-Entwicklungswerkzeugen wie z.b. Eclipse, die keine kommandozeilen basierten Werkzeuge zum kompilieren der Quellen bieten (wie bspw. ant), was eine (ordnungsgemäße) Paketierung sehr aufwändig macht.
Die Pakete sollten weiterhin aus den Quellen erstellt worden sein, damit sich Patches erstellen lassen (delta rpms), die dann wesentlich kleiner sind und somit den Nutzer und den Distributor entlasten.
schön' Tach noch.
Also, ich mache grundsätzlich alles mit Ant (ausser Compilieren), auch in Eclipse. Das ist schon seit Version 2.x drin. Ich verstehe die hervorgebrachte vermeintliche Ursache nicht.
siehe oben, ums Kompilieren geht es aber eben.
Verstehen tue ich auch nicht, warum hauptsächlich Eclipse Nutzer Probleme damit zu haben scheinen, da ich Eclipse selbst nicht nutze.
Meine Erfahrung beruht auf java Projekten die in Eclipse bearbeitet werden und gerade eben dieses build-script das aus einem script (spec - file) augerufen werden kann, nicht zu haben scheinen.
Gib doch mal einen link/howto wie ich ein Eclipse project auf der Kommandozeile baue.
Exportiere dein Eclipse Projekt einfach als ant Script. Eclipse ist nun mal eine IDE und kein Build-Tool.
Ziemlicher Mehraufwand, bei netbeans bekommt man das automatisch mit ...
Komisch eigentlich, das für diese Funktion noch keine Notwendigkeit gesehen wurde, weil das für die Paketierung eigentlich vorausgesetzt wird und eclipse viele Jahre DIE Java IDE war/ist, vor allem im open source Bereich.
... das Problem, muss aber darauf hinweisen, dass ich nicht verstehe, warum das nicht bereits von den Päcklibauern erledigt worden ist, zumal alle Informationen vorhanden sind (1 XML-File, 1 Propertyfile, also nichts kompliziertes). Das Compilieren ist damit vollständig und automatisch ausführbar, man muss diese Infos halt richtig verwerten und den javac entsprechend anstossen. Danach erfolgt die Ausführung des eigentlichen Buildskriptes.
Im Detail:
Die Sourcepfade, der Classpath und die Projektabhängigkeiten gehen aus ".classpath" hervor. Manchmal sind die Libs extern, dann muss man eben etwas tun (herunterladen, Classpath anpassen). Wenn das Compilieren durchgelaufen ist, kann man das eigentliche Buildskript aufrufen.
Also, soooo compliziert ist das nun auch nicht. Lediglich ist das einfach nicht so vorbereitet, weil aus Eclipse halt meistens die fertigen Jars geliefert werden. Im übrigen, die Compilerargumente findet man in .settings/org.eclipse.jdt.core.prefs. Also, das ist ohne Probleme machbar, aber eher ein Problem der Integration in die Buildumgebung als eines der Javaentwickler.
Bei den C-Sourcen ist im übrigen auch nicht alles einheitlich, das ./configure ist nicht immer am gleichen Ort. Ein schönes Beispiel für die Einheitlichkeit ist z.B. bristuff.
Es können sowohl maven als auch ant in Eclipse verwendet werden. Ich halte die Argumentation im Artikel für falsch bzw. sehr ungenau.
Das Problem liegt eher in der Komplexität und schnellen Weiterentwicklung bzw. häufigen Refactoring von Libraries und Frameworks. Aber auch das ist wahrscheinlich etwas zu einfach ausgedrückt.
Möglicherweise kann man die Versionsauswahl über Maven etwas nachbessern.
Javaentwickler sind beim Refactoring nicht gerade zimperlich. Wenn Refaktoring nicht das Problem ist, dann die häufige Veränderung der Signaturen. Die Anpassungen in den abhängigen Projekten werden halt automatisch nachgeführt, ausser eben in anderen Workspaces, aber an die anderen denkt man nicht immer.
Ich kenne eh keine Java-Anwendungen (außer IDEs), die es Wert wären von mir benutzt zu werden.
+1
http://java-apps.org/ könnte Dir helfen
Dem kann ich mich leider nicht anschliessen. Ich benutze Jaikoz zum Taggen meiner MP3's und Alben. Ist wirklich komfortabel und gut. Basiert auf Java. Vor allen Dingen mag ich es die Alben zu laden, dann per CTRL+1 das ganze dann automatisch von Musicbrainz und Dicogs zu updaten.
Daumen HOCH!!
Jaikoz ist das nonplusultra was Tag-Programme angeht.
Subsonic wäre in diesem zusammenhang auch noch zu erwähnen (genialer Soundserver).
Jabref ist auch ein Blick wert.
jabref ist toll, leider ohne office integration für den Nutzer im Alltag (fast) wertlos.
Warum wurde daran eigentlich nie etwas gemacht ... ich meine von beiden Seiten - Office (OOo, KWord, ... ) als auch seitens Jabref? Sehr schade! zotero ist da schon ein stück weiter...
Wenn man den Fernseher überhaupt noch nutzt dann ist TV Browser echt toll. Hab ich aber eben schon lange nicht mehr verwendet.
Stimmt, aber solange jEdit existiert, besteht ein Daseinsgrund für Java.
Ein großteil aktueller Software (leider nicht alle) benutzen heutzutage das maven archive (ob per maven, ivy, grape oder gradle). Dort ist nun fast jede Bibliothek in beliebiger Version verfügbar. Eigentlich müsste man nun nur einen Weg finden dieses Bibliotheken-System in das Packetsystem der Distribution zu integrieren.
Na klar gibt es dann immer noch verschiedene Libs (in verschiedenen Versionen) als Abhängigkeit aber diese Liegen zumindest zentral. Weiterhin kann man halt entsprechend drauf hinweisen, dass bei Verwendung dieses Systems nicht die aktuallität bewahrt werden kann und sich somit Sicherheitslücken nicht von der Distribution direkt beheben lassen.
Jedoch kann das ein schrittweiser prozess sein. Ist eine sicherheitslücke in einer bibliothek bekannt kann entsprechend der Hersteller einer Java-Produkts auf diese Weise informiert werden und entsprechend reagieren.
Aktuell ist die Situtation so, dass bei vielen Java-Projekten die Dependencies kaum verändert werden. Vor allem auch weil Informationen über Sicherheitslücken fehlen (Keine zentrale Informationsstelle).
Hier müsste herrscht entprechender Verbesserungsbedarf und ein Zusammenwachsen dieser Systeme würde eine Win-Win-Situation erzeugen.
Softwareprojekte die maven als build system verwenden, werden damit auch während das Paketierungsprozesses gebaut (so sollte es sein, Realität kann abweichen) .... und dann in ein rpm/deb verpackt.
Ich verstehe nicht so ganz, welchen Vorteil Du Dir von einem zweiten paketmanagement bzw. modulverwaltung versprichst? Indem man die Abhängigkeiten für das Paket angibt, können die entsprechenden Pakete mitinstalliert werden.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 27. Sep 2010 um 11:19.Java zu lernen ist nun wirklich nicht sonderlich schwer, allein sich durch den Wust der relevanten Bibliotheken zu arbeiten, war immer eine Krankheit. Das ganze Ökosystem Java verlangt einen Aufwand sich einzuarbeiten, der einfach zu hoch ist, auch wegen schlechter Dokumentation Das spiegelt sich letztlich auch in solchen Problemen wieder.
Der Wust an Bibliotheken ist bei C bzw. C++ nicht geringer. Und pauschal zu behaupten alles an Java wäre schlecht dokumentiert ist doch Quatsch. Im Gegenteil, amn findet sehr viel an guter Dokumentation. Schon bei Sun bzw. jetzt Oracle, gibt es sehr viele gute Anleitungen und Referenzen.
Nö, ich bin zu Python übergegangen. Python und alles was damit zusammenhängt, ist wesentlich übersichtlicher dokumentiert.
Und so verschieden sind die Meinungen. Ich finde die Python-Doku katastrophal, auch wenn mir die Programmiersprache an und für sich ganz gut gefällt. Aber in der API-Doku für Java[1] bin ich fast immer schneller fündig als bei Python [2]. Auch die Übersichtlichkeit (Rückgabewerte, Exceptions, Basisklassen, ...) gefällt mir in der Java-API-Doku besser.
Allerdings ist das Umfeld bei Java ein anderes als normalerweise unter Linux. In Java werden oft Enterprise-Anwendungen geschrieben, für die die entsprechenden Bibliotheken mitgeliefert werden. Da diese Bibliotheken auf dem entsprechenden Host dann von sonst keiner Anwendung benötigt werden ist das auch kein Problem und hat dann auch Vorteile.
Wenn nun allerdings eine Bibliothek von vielen Anwendungen gebraucht wird, ist man mit diesem Verfahren nicht so gut bedient. Allerdings würde ich dann ein Konzept besser finden, bei dem man, ähnlich maven oder OSGI, verschiedene Versionen einer Bibliothek vorhalten kann. Aber das normale Linux-Konzept, eine Bibliothek systemweit nur in einer Version zu verwenden, würde hier nicht hinhauen.
[1] http://download.oracle.com/javase/6/docs/api/
[2] http://docs.python.org/library/index.html
Was mich bei Python wirklich stört ist, dass man für jedes Programm eine Python Umgebung starten muss. Wenn man zehn Python Programme hat, dann hat man auch zehn Interpreter mit ihren ganzen Footprints am laufen. Da wird aus einem einfachen 'hello world' daemon ein fettes Batzen inkl hohem RAM Verbrauch. Würde ich das in C schreiben, würde ich das Programm nicht mal im Hintergrund merken.
Ähm... Du merkst auch 10 kleine Python-Scripte nicht im Hintergrund. Außer natürlich sie machen viel. Und du wirst auch 1000 "hello wourld"-Scripte in Python nicht im Hintergrund merken.
warum sollte man viele Programme, die fast nur warten nicht in interpretersprachen wie Python, Basic oder Perl schreiben...
Jaja, die Python-Doku ist schon super. Z. B. für pulldom: http://docs.python.org/library/xml.dom.pulldom.html. Diese ... sind wirklich enorm aussagekräftig.
Ein Problem, auf das ich immer wieder stosse, ist dass "unvollständige" Methoden/Klassen in der Bibliothek final sind. Ein prominentes Beispiel ist JGoodies, wo alles und jedes final ist, selbst wenn völlig offensichtlich eine begrenzte Anzahl von Fällen abgehandelt behandelt wird. Da wäre viel Schulung zu leisten, nämlich dass man den Entwicklern beibringt, dass nur das final zu sein hat, was unter keinen Umständen geändert werden darf, weil sich das gesamte Verhalten auf unvorhersehbare Weise ändern könnte. Workarounds um solche Probleme erhöhen die Versionsabhängigkeit drastisch (alternativ kann man forken, dann haben wir wieder das obengenannte Problem).
Allgemein werden die Aufrufe in Javabibliotheken nicht sehr stabil gehalten. Die Änderung der Schnittstelle nach aussen fällt gar nicht so auf, da es keine Headerfiles gibt. Wenn man die Signatur einer public-Methode anpasst, ist es eben schon passiert.
Vererbung ist eh zu vermeiden.
Sehr modern, man schreibt alles neu.
Unendliche Vererbungsketten sind zu vermeiden aber in vernünftigem Masse ist das das einzig sinnvolle für moderne Applikationen. Damit, dass man Java als Sprache beherrscht, garantiert aber noch kein gutes Design. Es wird zu wenig Wert darauf gelegt, zu vermitteln, zu welchem Zweck welches Mittel eingesetzt wird.
Es ist zudem nicht nur Vererbung, die unter "final" zu leiden hat sondern auch, wenn man Interceptoren implementieren will (Codeinjection). Das ist natürlich complettes Teufelszeug. Um Beans automatisch auf dem Client zu propertyChangeEvent-enablen, ohne bei jedem die gleiche Liternei zu coden, hat sich das jedoch bei meinem Programm gut bewährt. Ich programmiere doch nicht zu dem Zweck, möglichst viele Codezeilen zu produzieren...
Zumindest hat das vollständige Paketieren einen nicht unerheblichen Vorteil: egal welche Distribution, passt die JVM, gilt drop and run. Das ist was sich User wünschen. Jeder von uns kennet doch die Probleme Software ist nicht im Repository der Distribution und benötigt Lib X Lib Y und Lib Z die wieder zig Abhängigkeiten haben und mit bestehenden Versionen kollidieren. Nicht jeder normale Desktop Nutzer möchte sich da durch kämpfen. Ich kann das gut verstehen. Warum soll sich ein normaler Desktopbenutzer mit den Libraries abschlagen, es wird ja auch nicht verlangt das jeder in seinem Auto die Zylinderkopfdichtung selbst tauschen kann.
PS: Ich nutzte übrigens Gentoo, welches aber definitiv nichts für den normal Nutzer ist.
Ich verstehe die Argumentation des Artikels überhaupt nicht. Was bitte unterscheidet Java Anwendungen, von C/C++ Anwendungen?
In C/C++ sind auch alle Bibliotheken irgendwo verteilt und haben alle ganz unterschiedliche Versionen. Ein C/C++ Entwickler nimmt sich eine Bibliothek mit Version X und solange es funktioniert bleibt er dabei. Auch FF wird mit ganz bestimmten Versionen ausgeliefert, wenn man sich das tar.gz Paket runter lädt.
Wie machen die Distributionen das mit den C/C++ Programmen? Man nimmt den Code, kompiliert es gegen die Bibliotheken in der Distribution und testet das Programm. Genauso kann man es doch mit Java machen? Sehe ich nicht wo die Gründe, die der Autor angibt, irgendwas speziell mit Java zu tun haben.
Auch andere Scriptsprachen (nicht C/C++ Sprachen), kochen ihr eigenes Süppchen. Php mit PEAR, Perl mit CPAN, Python mit pypi, Ruby mit gems. Wenn man sich das überlegt, ist eigentlich C/C++ die Ausnahme, ohne ein zentrales Repository für Bibliotheken. Java hat Maven.
Es gibt halt nicht so viele Java Programme für den End-User. Die meisten sind in den Unternehmen zu finden und sind bestimmt nicht Open Source.
Open Source-Programme werden in der Regel eben ohne gebundelte Bibliotheken ausgeliefert; Firefox stellt hier eine Ausnahme dar (übrigens liefert auch Firefox nicht alle benötigten Bibliotheken mit, gtk wird z. B. glaube ich nicht mitgeliefert).
Habe noch nirgemdwo GTK wegen Firefox installieren müssen