Erfahrungen zu java-gnome und GNU classpath?

[jd]

Nach dem auf Prolinux.de der zweite Teil zu GNU Classpath GNU Classpath - Einer für alle, alle für einen erschienen ist, bin ich auf java-gnome aufmerksam geworden. Die Examples und auch die FLASH-Demo vermitteln einen guten ersten Eindruck.

Bevor ich mich nun durch die Erfüllung der Abhängigkeiten für eine Test-Installation kämpfen muss, wollte ich mal fragen, ob jemand damit schon mal gearbeitet hat.

Da es java-gnome auch für Windows gibt, scheint es eine brauchbare Möglichkeit der portablen Programmierung zu sein. Unter Windows muss man sich aber auf GTK2 und Glade beschränken. Klar.

Wer hat Erfahrungen mit java-gnome unter Windows?

Da in GNU Classpath ein AWT auf Basis von GTK zur Verfügung steht, kann das eventuell auch eine Alternative sein.

Läuft das GTK-Peer nur unter Linux? Oder geht das auch unter Windows?

Wie stabil sind die beiden Implementationen?

[peschmae]

Ist schon lange her und ich hab das nur sehr kurz mal getestet.

- Stabilität war damals kein Problem
- Windows hab ich damit nicht versucht

Ich hab mich damals dann schliesslich für SWT und gegen Java-Gnome entschieden - gerade weil das auf Windows *nicht* Gtk benutzt und auch auf MacOS läuft (könnte Java-Gnome natürlich auch - aber eher weniger native).

Das mit AWT würde ich eher sein lassen. AWT wird kaum noch benutzt - ist Widgetmässig zu beschränkt.

MfG Peschmä

[jd]

Nachdem ich im Thread Wenn schon Objektorientiert, dann... mit welcher Sprache? versucht habe, mir einen Überblick über "die OO Sprache" zu verschaffen, habe ich einen erneuten Anlauf genommen, mich zwischen C++, C# und Java 1.5 zu entscheiden.

Ich habe zwischenzeitlich viele Meinungen zu den unterschiedlichen Features von C# und Java 1.5 gelesen, sodass ich sagen muss, der Hype um C# hat keine echte Berechtigung. Viele Unterschiede in der Sprache selbst sind nicht so wichtig. Beide Sprachen haben Vorteile, die aber auch wieder zu ihren Nachteilen werden können. So unterstützt CLI von .NET mehrere Sprachen, wobei Änderungen wie "generics" in allen Sprachen Einzug halten müssen. Hier hat es Sun mit der VM und Java einfacher. Ich hatte zu diesem Beispiel auch einen Artikel gefunden, der die "unglückliche Umsetzung" von MS auf diese Tatsache zurückgeführt hat. Ich habe den Link aber nicht mehr.

Betrachtet man nur die Sprache selbst, bin ich zu dem Schluss gekommen, dass es "Geschmackssache" ist, ob man nun C# oder Java 1.5 auswählt.

Bleiben noch die Werkzeuge und die Libraries. Bei den Werkzeugen musste ich feststellen, dass sie beide bei Debian nur in unzureichenden Versionen (nicht aktuell) vorhanden sind. Hier kann ich also auf nichts Aktuelles zurückgreifen.

Bleiben die Libraries. Auch hier bietet Debian nur alte Versionen. Was den Umfang und die Stabilität angeht, scheint Java mit verschiedenen GUIs (SWT, WX, GTK, Gnome, ...) die Nase vorn zu haben. GTK# ist in den Versionen, in denen ich es ausprobiert habe, einfach schlecht. Selbst die GTK-Demos laufen nicht stabil.

[über java-gnome] Ist schon lange her und ich hab das nur sehr kurz mal getestet.
- Stabilität war damals kein Problem
- Windows hab ich damit nicht versucht

Da ich ein absoluter Newbie bin, was Java und C# angeht, würde mich interessieren, wie Du das API von java-gnome findest. Zu SWT gab es ja das eine oder andere "kritische" Wort, was die Erweiterbarkeit angeht.

Ich hab mich damals dann schliesslich für SWT und gegen Java-Gnome entschieden - gerade weil das auf Windows *nicht* Gtk benutzt und auch auf MacOS läuft (könnte Java-Gnome natürlich auch - aber eher weniger native).

Wie baust Du Deine GUI's unter SWT? Von Hand? Bei java-gnome kann man ja Glade benutzen, was ja auch seinen Reiz hat.

Ach ja, hast Du schon mal einen Installer unter Windows benutzt, um SWT und Deine Applikation zu installieren?

Das mit AWT würde ich eher sein lassen. AWT wird kaum noch benutzt - ist Widgetmässig zu beschränkt.

Das AWT kam mir nur in den Sinn, weil es bei GNU Classpath direkt (in GTK) implementiert ist. Unter Windows mit der SUN-VM sieht es dann natürlich grässlich aus, aber immerhin geht es. Du hast aber recht. Für neue Anwendungen sollte man es nicht benutzen.

[peschmae]

Da ich ein absoluter Newbie bin, was Java und C# angeht, würde mich interessieren, wie Du das API von java-gnome findest.

Normal gut. Aber die Dokumentation war (ist?) nicht sehr komplett leider. Natürlich kann man dann in den C-Gnome-Api-Dokus gucken gehen was etwas meinen könnte - aber das ist doof.

Zu SWT gab es ja das eine oder andere "kritische" Wort, was die Erweiterbarkeit angeht.

Nicht zu Unrecht. SWT hat schon einige Nachteile. Deshalb benutze ich das mittlerweile auch nicht mehr - ich tendiere eher zu Qt das es jetzt ja auch für Windows unter der GPL gibt (wobei ich mir wohl auch mal Gtkmm etwas näher angucken werde, nur um informiert zu sein).

Wie baust Du Deine GUI's unter SWT? Von Hand? Bei java-gnome kann man ja Glade benutzen, was ja auch seinen Reiz hat.

Ich habs von Hand gebaut - ist ja meist nicht soo ne Sache. Mittlerweile gibts für Eclipse ja auch ein Visual Editor Plugin - aber das mag ich nicht so.

Ach ja, hast Du schon mal einen Installer unter Windows benutzt, um SWT und Deine Applikation zu installieren?

Ja - aber ich hatte das Programm um Probleme mit fehlenden JREs und so schon mal zu umgehen native mit GCJ kompiliert. Von dem her wars nix anderes mehr als ein normales Programm.

Das AWT kam mir nur in den Sinn, weil es bei GNU Classpath direkt (in GTK) implementiert ist. Unter Windows mit der SUN-VM sieht es dann natürlich grässlich aus, aber immerhin geht es. Du hast aber recht. Für neue Anwendungen sollte man es nicht benutzen.

Das Problem ist nicht soo das Aussehen als der Funktionsumfang.

MfG Peschmä

[BeS]

wobei Änderungen wie "generics" in allen Sprachen Einzug halten müssen.

Wieso? Also C#2.0 kennt generics, ist afaik in der aktuellen Mono Version auch schon implementiert.

Betrachtet man nur die Sprache selbst, bin ich zu dem Schluss gekommen, dass es "Geschmackssache" ist, ob man nun C# oder Java 1.5 auswählt.

ja, wie bei jeder Sprache.

Bleiben die Libraries. Auch hier bietet Debian nur alte Versionen. Was den Umfang und die Stabilität angeht, scheint Java mit verschiedenen GUIs (SWT, WX, GTK, Gnome, ...) die Nase vorn zu haben.

Für Mono gibt es auch wx, gtk, gnome, qt (weiß nicht ob die noch weiterentwickelt werden), window.forms,..

GTK# ist in den Versionen, in denen ich es ausprobiert habe, einfach schlecht. Selbst die GTK-Demos laufen nicht stabil.

Das muß aber eine vor 1.0 Version gewesen sein. Ich programmiere hier selber mit gtk# und haben auch ein paar gtk# Programme im täglichen Einsatz, die laufen mind. so stabil wie gtk+ Programme.

Zu java-gnome, ich denke das kann man ruhigen Gewissens verwenden. Es sind ja nicht nur irgendwelche Gtk+ Bindings sondern sie gehören sogar zu den "GNOME Platform Bindings", ich denke da wird die Qualität schon stimmen.

Zum Thema SWT, funktioniert das heute schon problemlos mit dem gcj + GNU Classpath? Ich habe da nicht so gute Erinnerungen an meine letzten Versuche.

[jd]

Normal gut. Aber die Dokumentation war (ist?) nicht sehr komplett leider. Natürlich kann man dann in den C-Gnome-Api-Dokus gucken gehen was etwas meinen könnte - aber das ist doof.

Das stimmt. Ich habe mir das recht umfangreiche Tutorial ausgedruckt, dass ich am Wochenende mal durchgehen will. Mal sehen...

Nicht zu Unrecht. SWT hat schon einige Nachteile. Deshalb benutze ich das mittlerweile auch nicht mehr - ich tendiere eher zu Qt das es jetzt ja auch für Windows unter der GPL gibt.

SWT -> Die SWT scheint auch intern Probleme zu bereiten. Durch ihren "native interface" Ansatz scheint die Entwicklung sehr schwierig zu sein. Ich habe gelesen, dass unter den Entwicklern schon Stimmen laut wurden, die von einer Weiterentwicklung abstand nehmen wollen.

Qt -> Meinst Du jetzt C++ mit Qt, oder java-bindings zu Qt?

Ja - aber ich hatte das Programm um Probleme mit fehlenden JREs und so schon mal zu umgehen native mit GCJ kompiliert. Von dem her wars nix anderes mehr als ein normales Programm.

Ahh. Das steht auch auf meiner "to-do Liste". Leider fehlt mir die Zeit.

Wie schnell (subjektiv) sind denn die Binaries, die GCJ am Ende produziert? Merkt man einen Unterschied zu den jar's? Wie sieht es mit dem Startup aus? Und was muss man später zum Paket dazupacken? Doch nur noch die DLL's / shared-libs, oder?

Das Problem ist nicht soo das Aussehen als der Funktionsumfang.

Der Umfang reicht für kleine Dinge aus. Ich habe des öfteren kleine GUIs für "embedded devices" zu machen, die einfach nur aus einem Dialog mit ein paar Eingabefeldern und Slidern bestehen. Die Einstellungen gehen dann per RS232 weg.

Bisher nehme ich immer FLTK. Das Toolkit ist zwar prima, aber recht "objekt-orientiert" ist es nicht. Die STL wird garnicht benutzt, sodass das bischen Vorteil von C++ wieder verloren geht.

[BeS]

Wie schnell (subjektiv) sind denn die Binaries, die GCJ am Ende produziert? Merkt man einen Unterschied zu den jar's? Wie sieht es mit dem Startup aus? Und was muss man später zum Paket dazupacken? Doch nur noch die DLL's / shared-libs, oder?

Also ich habe auf dem diesjährigen Linuxtag einen Vortrag von einem RedHat und gcj Entwickler gehört. Dieser meinte das man am Anfang die Möglichkeit des kompilieren in native-code eingebaut hat, weil man sich davon 'große' Geschwindigkeitsvorteile erhofft hatte. Am Anfang war native-code auch schneller, allerdings gibt es heute anscheinend immer mehr Situationen wo der bytecode schneller ist und er sieht anscheinend in dem native-code nichtmehr viele Vorteile.

[jd]

Wieso? Also C#2.0 kennt generics, ist afaik in der aktuellen Mono Version auch schon implementiert.

Eben. Der Artikel bezog sich auf diese Änderungen, die --laut dem Autor-- nicht so "sauber" umgesetzt wurden, wie dies bei Java 1.5 der Fall sein soll.

ja, wie bei jeder Sprache.

Naja, solange der Sprachumfang paßt. Wenn das nicht der Fall ist, dann muss man wohl oder übel zu einer anderen Sprache greifen. IMO scheinen sich in der Beziehung C# und Java nicht mehr viel zu nehmen.

Für Mono gibt es auch wx, gtk, gnome, qt (weiß nicht ob die noch weiterentwickelt werden), window.forms,..

Ja, das stimmt. Ich habe erst mal auf das zurückgegriffen, was leicht zu installieren war. Ich fahre im Büro Ubuntu Warty und zu Hause noch Woody. Da kämpft man ein bischen mit den Abhängigkeiten.

Das muß aber eine vor 1.0 Version gewesen sein. Ich programmiere hier selber mit gtk# und haben auch ein paar gtk# Programme im täglichen Einsatz, die laufen mind. so stabil wie gtk+ Programme.

mono-1.1.8-gtksharp-1.9.5-win32-0.0.exe

Ich habe es unter Windows probiert, da es "auf freier Wildbahn" auch damit funktionieren muss.

Zu java-gnome, ich denke das kann man ruhigen Gewissens verwenden. Es sind ja nicht nur irgendwelche Gtk+ Bindings sondern sie gehören sogar zu den "GNOME Platform Bindings", ich denke da wird die Qualität schon stimmen.

Denke ich auch. Ich muss nur mal sehen, wie sie unter Windows laufen. Leider ist das immer nötig.

Zum Thema SWT, funktioniert das heute schon problemlos mit dem gcj + GNU Classpath? Ich habe da nicht so gute Erinnerungen an meine letzten Versuche.

Das habe ich selbst auch noch nicht verifiziert. Es "soll" funktionieren. Mehr weiß ich noch nicht.

[jd]

Also ich habe auf dem diesjährigen Linuxtag einen Vortrag von einem RedHat und gcj Entwickler gehört. [...] allerdings gibt es heute anscheinend immer mehr Situationen wo der bytecode schneller ist und er sieht anscheinend in dem native-code nichtmehr viele Vorteile.

Da ist ja interessant. Was mich hauptsächlich stört, sind die langen Startup-Zeiten mancher Java-Anwendungen, und der enorme Ressourcenverbrauch. An letzterem dürfte sich durch den native-code nicht viel ändern.

Nur als Beispiel: ich habe meinen Kids als Vokabeltrainer das Programm Pauker installiert. Auf den Woody-Kisten (1GHz Duron; 600MHz P3) mit KDE 3.1 dauert es so lange, dass man meinen könnte, die Kiste wäre abgestürzt.

[BeS]

Eben. Der Artikel bezog sich auf diese Änderungen, die --laut dem Autor-- nicht so "sauber" umgesetzt wurden, wie dies bei Java 1.5 der Fall sein soll.

was verstehst du unter nicht so sauber? Der Syntax?
Also ich finde ein
class foo<T> { ... }
sauber.

Also ich muß zugeben, dass ich selber nicht viel Java kann, aber das was ich vergleichen kann, da kommt mir C# "sauberer" vor.

Ich muß z.B. immer an etwas ganz grundlegendes denken, man will einfach eine Eingabe aus der Konsole. In Java sieht das ungefähr so aus:

BufferedReader is = new BufferedReader(new InputStreamReader(System.in));
String eingabe = is.readLine();


in C# einfach:

string eingabe = Console.ReadLine();


ohne diesem komischen bufferReader usw.

Naja, solange der Sprachumfang paßt. Wenn das nicht der Fall ist, dann muss man wohl oder übel zu einer anderen Sprache greifen. IMO scheinen sich in der Beziehung C# und Java nicht mehr viel zu nehmen.

aber was heißt schon passt? Wenn man mal von äußeren Zwängen absieht, denke ich das jeder die Sprache verwenden sollte die ihm am besten liegt. Was einem am besten liegt ist meistens ein ganz persönliches und subjektives Empfinden.

Ja, das stimmt. Ich habe erst mal auf das zurückgegriffen, was leicht zu installieren war. Ich fahre im Büro Ubuntu Warty und zu Hause noch Woody. Da kämpft man ein bischen mit den Abhängigkeiten.

da hast du natürlich nicht die besten Systeme um Mono und Java in aktuellen Versionen zu testen.

mono-1.1.8-gtksharp-1.9.5-win32-0.0.exe

Ich habe es unter Windows probiert, da es "auf freier Wildbahn" auch damit funktionieren muss.

Also mit windows habe ich nicht viel Erfahrungen. Ich habe ein Programm für einen bekannten auf Windows installiert, da habe ich noch keine klagen wegen instabilität gehört.
Sicher ist aber das Gtk natürlich eine wesentlich längere und stabiliere Tradition auf der X11 Plattform hat. Es gibt auch einige windows Bugs die im CVS schon behoben wurden bisher aber noch in keiner release dabei waren, ich denke mal gerade für windows wird es mit Gtk#2 eine deutliche Verbesserung geben.

Das habe ich selbst auch noch nicht verifiziert. Es "soll" funktionieren. Mehr weiß ich noch nicht.

Weiter wie bis zum "soll" bin ich bei meinen Tests damals auch nicht gekommen.
Wie gesagt bin ich aber auch kein großer Java kenner, kann also sein das ich etwas falsch gemacht habe und die Motivation war dann auch nicht groß sich damit lange zu beschäftigen.

[BeS]

Da ist ja interessant. Was mich hauptsächlich stört, sind die langen Startup-Zeiten mancher Java-Anwendungen,

Also bei dem Vortrag sind sie auch auf die Startzeit von eclipse zu sprechen gekommen, die ja auch nicht so toll sein soll.
Der Entwickler meinte, dass man das Problem gefunden hätte. Irgendwo würde beim Start plötzlich hunderte von exceptions geworfen die das ganze ausbremsen. Allerdings sei es anscheinend nicht so einfach diese exceptions zu verhindern aber man arbeitet daran, wenn ich ihn da richtig verstanden habe (an der Stelle wurde es sehr java-technisch, so dass ich nichtmehr alles 100% verstanden habe).

[peschmae]

Zum Thema SWT, funktioniert das heute schon problemlos mit dem gcj + GNU Classpath? Ich habe da nicht so gute Erinnerungen an meine letzten Versuche.

Ist hatte keine Probleme. Ist natürlich besser wenn du das schon von Anfang an im Auge behältst - aber von SWT-Seite her ist das problemlos.

SWT -> Die SWT scheint auch intern Probleme zu bereiten. Durch ihren "native interface" Ansatz scheint die Entwicklung sehr schwierig zu sein. Ich habe gelesen, dass unter den Entwicklern schon Stimmen laut wurden, die von einer Weiterentwicklung abstand nehmen wollen.

Naja, die Gtk-Version ist nicht gerade genial. Aber im allgemeinen scheint mir das recht gut zu funktionieren.
Deine Aussage ist etwas allgemein

Qt -> Meinst Du jetzt C++ mit Qt, oder java-bindings zu Qt?

In meinem Fall mit C++.

Zu den Startzeiten: Die waren bei meinem nativ kompilierten Programm einiges besser als mit JVM. Bei Eclipse ist es allerdings tatsächlich so dass es tempomässig nichts bringt - dafür sind nachher die Logs voll zeugs

MfG Peschmä

[jd]

was verstehst du unter nicht so sauber? Der Syntax?
Also ich finde ein
class foo<T> { ... }
sauber.

Oh weh. Jetzt muss ich zugeben, dass ich ein bischen auf dem Schlauch stehe. Ich glaube ich habe was durcheinander geworfen. Ich hatte die Artikel abends überflogen (war schon sehr spät) und wollte sie mir ins Büro mailen um sie auszudrucken. Leider hat es dabei den KDE zerrissen (KDE3.1 backport für woody) und so sind die Links verloren gegangen.

Jetzt wo Du das Schnippsel postest, erinnere ich mich, dass die generics bei Java unschön aussehen. Statt class foo<t> schreiben die es vor den Typ. Schlimmer noch war es bei Methoden, weil da der generische Typ vor dem Rückgabewert lag. (Quelle: hier (PDF)).

Code: Alles auswählen

void<T> foo (T parm) // Java 1.5
void foo<T> (T parm) // C# 

Den Link mit dem Artikel bezüglich der "unschönen" Umsetzung finde ich gerade nicht mehr. Wenn ich es wieder finde, dann poste ich das hier. Sorry.

Interessant waren auch die Links:

• http://weblogs.asp.net/ssadasivuni/arch ... 41196.aspx
• http://slashdot.org/article.pl?sid=04/10/11/1454220
• http://www.dur.ac.uk/barry.cornelius/pa ... 5/onefile/
• http://www.geocities.com/csharpfaq/box.html mit der finalen Aussage C# Best Practice: Do not use boxing and unboxing

aber was heißt schon passt? Wenn man mal von äußeren Zwängen absieht, denke ich das jeder die Sprache verwenden sollte die ihm am besten liegt. Was einem am besten liegt ist meistens ein ganz persönliches und subjektives Empfinden.

Mir gefällt zum Beispiel Objective-C sehr gut. Auch wenn mich keiner dazu zwingt es nicht zu benutzen , verwende ich es doch nicht. Die Libraries, die es dafür gibt, sind einfach nicht portabel genug. Und GNUstep für Windows auszuliefern ist vielleicht ein bischen zu viel.

da hast du natürlich nicht die besten Systeme um Mono und Java in aktuellen Versionen zu testen.

Eben. Und das ist IMO eine nicht unbedeutende Einschränkung. Was nutzt es mir, wenn es tolle Programme (Beagle) gibt, wenn ich sie nur dann installieren kann, wenn ich mein halbes System aktualisieren muss. Dann komme ich nämlich langsam in Richtung Windows. Ich merke nämlich zu Hause auch, wie Woody unter den Backports zu leiden hat. Den Freeze, den mir Firefox 1.0.6 verursacht hat, hatte ich vorher noch nie.

Ich möchte aus dem Grund niemanden solche Verenkungen zumuten, nur um ein Programm von mir ausführen zu können.

Also mit windows habe ich nicht viel Erfahrungen. Ich habe ein Programm für einen bekannten auf Windows installiert, da habe ich noch keine klagen wegen instabilität gehört.

Ich hatte mir Mono und GTK# angesehen, aber nachdem mit mehreren mono-Versionen keine Besserung eintrat, habe ich das Ganze erst mal auf Eis gelegt.

ich denke mal gerade für windows wird es mit Gtk#2 eine deutliche Verbesserung geben.

Hm, bei mono-1.1.8 ist doch GTK2 dabei. Oder bezieght isch die 2 auf GTK# selbst?

Von der Sprache her gefällt mir C# eigentlich fast schon besser. Aber wenn ich die Werkzeuge mit einbeziehe, dann scheint mir Java ausgereifter zu sein.

[jd]

Qt -> Meinst Du jetzt C++ mit Qt, oder java-bindings zu Qt?

In meinem Fall mit C++.

Qt mit C++ ist schon ein gutes Gespann, auch wenn ich mit der "Spracherweiterung" durch moc nicht unbedingt einverstanden bin. Aber immer wenn ich wieder mehr mit C++ mache, dann stößt mir die unnötig komplizierte Syntax sauer auf. Brrrrubbbsss Sorry.

Es wirkt einfach irgendwie... aufgepfropft... wie ein Fremdkörper. Java und C# sehen einfach eleganter aus. Dazu tragen auch sicherlich die Klassenbibliotheken bei.

Zu den Startzeiten: Die waren bei meinem nativ kompilierten Programm einiges besser als mit JVM.

Ich werde es mir doch mal näher ansehen. Mit welcher GCC-Release ist der GCJ zu empfehlen? Geht der 3.3.x oder muß es 3.4 sein?

[BeS]

Ich möchte aus dem Grund niemanden solche Verenkungen zumuten, nur um ein Programm von mir ausführen zu können.

Aber woody ist schon sehr alt. Ich glaube kaum das man woody noch auf vielen Desktops findet.
Bei jeder gängigen Distribution ist eigentlich ein einigermaßen aktueller gcj und Mono dabei und sonst findet man Mono Pakete auf der Mono Seite.

Hm, bei mono-1.1.8 ist doch GTK2 dabei. Oder bezieght isch die 2 auf GTK# selbst?

Bei gtk#2 bezieht sich die 2 auf gtk#. Bei Mono1.0.x war gtk#1 dabei, dass waren bindings für gtk+2.2 wenn ich das richtig in Erinnerung habe.
Gtk#2 wird es mit Mono1.2 geben und wird wahrscheinlich auf gtk+2.6 aufbauen. Die gtk# Version bei Mono1.8 ist afaik noch eine Mischung aus Gtk2.4 und Gtk2.6.
Viele Bugs sind schon im CVS head gefixt, aber noch nicht mit einer der windows Versionen veröffentlicht wurde. Die meisten Bugs merkt man aber sehr deutlich, entweder funktioniert etwas erkennbar nicht richtig oder es lässt sich unter windows garnicht kompilieren. Das was aber funktioniert, funktioniert nach meiner Erfahrung stabil und zuverlässig.

Von der Sprache her gefällt mir C# eigentlich fast schon besser. Aber wenn ich die Werkzeuge mit einbeziehe, dann scheint mir Java ausgereifter zu sein.

Ich denke das ist kein Wunder, wenn man bedenkt wie lange es Java gibt und wie lange C#.
Persönlich verwende ich eh für jede Programmiersprache Emacs, da gibt es für mich also keinen Unterschied

Werde mir jetzt mal deine links genauer ansehen...

[BeS]

Qt mit C++ ist schon ein gutes Gespann, auch wenn ich mit der "Spracherweiterung" durch moc nicht unbedingt einverstanden bin. Aber immer wenn ich wieder mehr mit C++ mache, dann stößt mir die unnötig komplizierte Syntax sauer auf. Brrrrubbbsss Sorry.

Es wirkt einfach irgendwie... aufgepfropft... wie ein Fremdkörper. Java und C# sehen einfach eleganter aus. Dazu tragen auch sicherlich die Klassenbibliotheken bei.

sehe ich ähnlich. C++ ist schon irgendwie ein unschönes Monster. Qt macht es in vielen Punkten angenehmer als "reines" C++, aber ganz verdecken kann es C++ doch nicht.
Wenn ich C++ Programmiere dann nur mit Qt, Gtkmm ist zwar "mehr" C++ aber das hat auch den Nachteil das man mit der C++ Käule erschlagen wird.
Ansonsten habe ich mittlerweile die Einstellung, wenn schon "modern" dann richtig, daher verwende ich gerade für GUIs Mono/C# und ansonsten noch C oder Scheme je nach Aufgabe.

Ich werde es mir doch mal näher ansehen. Mit welcher GCC-Release ist der GCJ zu empfehlen? Geht der 3.3.x oder muß es 3.4 sein?

beim gcj würde ich fast sagen, so aktuell wie möglich, also gcj4 wenn du das auf deine "alte Kiste" bekommst.

[peschmae]

sehe ich ähnlich. C++ ist schon irgendwie ein unschönes Monster. Qt macht es in vielen Punkten angenehmer als "reines" C++, aber ganz verdecken kann es C++ doch nicht.
Wenn ich C++ Programmiere dann nur mit Qt, Gtkmm ist zwar "mehr" C++ aber das hat auch den Nachteil das man mit der C++ Käule erschlagen wird.
Ansonsten habe ich mittlerweile die Einstellung, wenn schon "modern" dann richtig, daher verwende ich gerade für GUIs Mono/C# und ansonsten noch C oder Scheme je nach Aufgabe.

Ich mag C++ auch nicht besonders - hat mir viel zu viele Fallstricke und Subtilitäten. Aber mir ist Java schlicht zu Ressourcenfressend - da ist jedes Qt Programm heilig dagegen.
Und bei Mono spielt auch immer noch ein gewisses Misstrauen gegenüber dem was Microsoft als nächstes vorhat mit. Auch wenn das bisher sehr gut zu gehen scheint (und wenn du Gtk# verwendest auch nicht soo ein Problem sein dürfte)

beim gcj würde ich fast sagen, so aktuell wie möglich, also gcj4 wenn du das auf deine "alte Kiste" bekommst.

Auf jeden Fall. GCJ wurde fast nur besser - und insbesondere die libgcj wurde vor jedem Release neu aus dem Classpath-Projekt aktualisiert.

MfG Peschmä

[jd]

Aber woody ist schon sehr alt. Ich glaube kaum das man woody noch auf vielen Desktops findet.
Bei jeder gängigen Distribution ist eigentlich ein einigermaßen aktueller gcj und Mono dabei und sonst findet man Mono Pakete auf der Mono Seite.

Naja, ich habe bisher immer Anfragen gehabt, wo unsere Kunden Linux in Form von Debian Woody eingesetzt haben. Ist wirklich witzig. Da ich im Büro Debian (seit 1/2 Ubuntu Warty) einsetze und alles erst mal unter Debian entwickle, sind diese "Releases" quasi ein Abfallprodukt.

Ich bin mal gespannt wie lange das noch so bleiben kann. Das nächste Projekt ist ein Bildbearbeitungssystem zur Beurteilung und Kalibrierung von OP-Leuchten. Da kommt das Videosignal dann über FireWire rein und muss speziell aufbereitet ausgegeben werden. Mal sehen ob das mit Ubuntu klappt.

Im schlimmsten Fall muss ich auf DirectShow zurückgreifen.

Von der Sprache her gefällt mir C# eigentlich fast schon besser. Aber wenn ich die Werkzeuge mit einbeziehe, dann scheint mir Java ausgereifter zu sein.

Ich denke das ist kein Wunder, wenn man bedenkt wie lange es Java gibt und wie lange C#. Persönlich verwende ich eh für jede Programmiersprache Emacs, da gibt es für mich also keinen Unterschied

Als Editor setze ich auch seit Ewigkeiten auf Emacs. Aber auch von den restlichen Tools, vom Compiler über Buildtools (Ant,..) gibt es zwischenzeitlich eine unüberschaubare Vielfalt. Vorallem GCJ ist hier nochmal zu nennen.

Mal sehen wann ich mal Zeit zum Spielen finde. Dieses Wochenende ist leider wieder mal komplett zu.

[jd]

Ich habe eine interessante Webseite gefunden. Vielleicht bringt es dem einen oder anderen ja was.

The C++ Source ist ein Online-Magazin für Entwickler. Hier schreiben sehr viele namhafte Autoren!

Interessant für mich als "C++ Verächter" war der Artikel As Simple As Possible?. Hier ein Auszug:

When asked to name three things he disliked about C++, Scott Meyers said:

"I'd like to answer this question with 'complexity, complexity, complexity!', but naming the same thing three times is cheating. Still, I think that C++'s greatest weakness is complexity. For almost every rule in C++, there are exceptions, and often there are exceptions to the exceptions. For example, const objects can't be modified, unless you cast away their constness, in which case they can, unless they were originally defined to be const, in which case the attempted modifications yield undefined behavior. As another example, names in base classes are visible in derived classes, unless the base class is instantiated from a template, in which case they're not, unless the derived class has employed a using declaration for them, in which case they are."


Der Artikel Generics in C#, Java, and C++ ist der letzte einer ganzen Reihe, die auf das Thema dieses und meines letzten Threads (zu Programmiersprachen) passt.

Anders Hejlsberg, the lead C# architect, talks with Bruce Eckel and Bill Venners about C# and Java generics, C++ templates, constraints, and the weak-strong typing dial.

Andere Artikel (immer der letzte der Reihe) sind:

C++:

* http://www.artima.com/intv/constP.html

* http://www.artima.com/intv/genericsP.html

* http://www.artima.com/intv/eleganceP.html

Python:

* http://www.artima.com/intv/pycommP.html

* http://www.artima.com/intv/tippingP.html


PS: ich habe das alles auch nocht nicht gelesen. Die Zeit fehlt.