Plattformunabhängig programmieren

[mkinzler]

Zitat:

Mono und C# sind 100% zueinander kompatibel,

Genauso wie c zu Linux kompatibel ist?
Mono ist eine betriebssystemübergreifende Implementierung der .Net-Plattform
Diese ist aber nicht zu 100% komplett und kompatibel

[Hisoka]

Zitat von mquadrat:

Wenn plattformunabhängig entwickelt werden soll, nehmen wir aktuell auch Java. Sind von Eclipse zu Netbeans gewechselt, weil da der GUI Builder brauchbar ist.

Mono hab ich mir noch nicht angeschaut, wird sicher eine Alternative sobald .NET 4 vollumfänglich unterstützt wird.

Das wird nur nie passieren. Das ist auch nicht das Ziel der Mono Entwickler.

Ich würde für Desktop Anwendungen die plattform übergreifend laufen sollen niemals .NET empfehlen.
1. Man brauch für eine brauchbare Benutzeroberfläche wieder eine extra UI Bibliothek. Nicht alle sind brauchbar oder überhaupt fertig. Der Punkt ist das Windows.Forms rein für Windows konzipiert wurde und somit auf anderen Plattformen nur mehr schlecht als recht funktioniert. Dazu sehen die Anwendungen extrem hässlich aus. Das muss man sich nicht antun.
2. Selbst Swing lässt sich besser integrieren. Also wäre es eher zu empfehlen.
3. Es hat so gut wie keinen Vorteil gegenüber der direkten Nutzung des Toolkits.
4. .NET und Mono sind nicht grade beliebt unter Linux und Mac Nutzern. Denn die Performance der meisten Anwendungen ist grauenhaft und daher hat nicht jeder Mono installiert.

Aus meinen Erfahrungen ist auch Lazarus und die LCL nicht brauchbar. Die Performance der erstellten Anwendungen ist katastrophal. Sie ist teilweise so schlimm, das Anwendungen unter leichtgewichtigen Windowmanagern absolut nicht laufen. Also es ruckelt bis zur Unkenntlichkeit.(zumindest unter GTK2)

Würde also im Endeffekt eher C++ und Qt/wxWidgets nehmen.

[creed steiger]

Zitat von Hisoka:

Aus meinen Erfahrungen ist auch Lazarus und die LCL nicht brauchbar. Die Performance der erstellten Anwendungen ist katastrophal. Sie ist teilweise so schlimm, das Anwendungen unter leichtgewichtigen Windowmanagern absolut nicht laufen. Also es ruckelt bis zur Unkenntlichkeit.(zumindest unter GTK2)

Würde also im Endeffekt eher C++ und Qt/wxWidgets nehmen.

Was spricht gegen LCL/Qt?
Davon abgesehen wäre unter "leichtgewichtigen" Systemen eher fpGUI oder MSEgui die beste Wahl anstatt GTK2.

[Hisoka]

Zitat von creed steiger:

Was spricht gegen LCL/Qt?
Davon abgesehen wäre unter "leichtgewichtigen" Systemen eher fpGUI oder MSEgui die beste Wahl anstatt GTK2.

fpGUI und MSEgui integrieren sich mal gar nicht ins Betriebssystem. Mag vielleicht einigen egal sein, aber nicht jedem. Der Punkt ist aber, eine Neuentwicklung der Anwendung mit Python und PyGTK hatte mehr Funktionen und lief deutlich besser als die Pascal/LCL variante. Also da wurde das ganze einfach schlecht umgesetzt, denn die LCL zeichnet zu viele Sachen selbst, was dazu führt das eine große Menge an Ressourcen verschwendet werden. Wobei das GTK1 Interface nicht so schlimm ist, dafür ist es aber hässlich wie die Nacht.


Die Qt Variante könnte ganz brauchbar sein, hab mich mit der aber nicht so sehr beschäftigt, denn wenn ich mit Qt arbeite kann ich auch gleich was ordentliches nehmen und QtCreator wählen und damit die Anwendung erstellen. Die IDE ist wenigstens ausgereift, stabil und bei der direkten Qt Nutzung bekommt man eben noch mehr als nur eine Interface Bibliothek. Damit ist gemeint das die LCL die Möglichkeiten welche Qt bietet nicht nutzt.

[Phoenix]

Zitat von Hisoka:

Ich würde für Desktop Anwendungen die plattform übergreifend laufen sollen niemals .NET empfehlen.
1. Man brauch für eine brauchbare Benutzeroberfläche wieder eine extra UI Bibliothek. Nicht alle sind brauchbar oder überhaupt fertig. Der Punkt ist das Windows.Forms rein für Windows konzipiert wurde und somit auf anderen Plattformen nur mehr schlecht als recht funktioniert. Dazu sehen die Anwendungen extrem hässlich aus. Das muss man sich nicht antun.
2. Selbst Swing lässt sich besser integrieren. Also wäre es eher zu empfehlen.
3. Es hat so gut wie keinen Vorteil gegenüber der direkten Nutzung des Toolkits.
4. .NET und Mono sind nicht grade beliebt unter Linux und Mac Nutzern. Denn die Performance der meisten Anwendungen ist grauenhaft und daher hat nicht jeder Mono installiert.

Ohwei.. selten so einen Schwachfug gelesen.
1.) Teilweise korrekt. Windows Forms ist natürlich für Windows gedacht und man braucht tatsächlich eine Gui-Bibliothek. Wie ich aber schon ausgfeührt habe ich Gtk# fertig und brauchbar. Und die Anwendungen sehen besser aus als mit irgendeinem Java-Gedöns.
2.) Swing ist eine Krankheit. Jede Applikation die damit geschrieben ist sieht auf jedem System anders bescheiden aus und fühlt sich nicht nativ an.
3.) Deswegen gibt es für jede Plattform auch native Bindings - die gibts bei Java nicht.
4.) Bei Linux-Freaks mag das zutreffen, normalen Linux-Usern ist es egal ob da eine Runtime druntersteckt oder nicht und mit der Performance hat das gerade mal gar nichts zu tun. .NET im allgemeinen und auch Mono sind sauschnell. Man merkt allerhöchstens beim ersten Anwendungsstart eine kurze Verzögerung - wenn überhaupt.

Zitat von rollstuhlfahrer:

Mono und C# sind 100% zueinander kompatibel, sind aber von der Entwicklung her zwei komplett andere Sprachen. Die Entwickler von Mono haben sich zum Ziel gesetzt, C#.net multi-platform-fähig zu machen. Das ist ihnen auch gelungen.

PS: Irgendwo habe ich mal gelesen, dass Mono in der Linux-Welt nicht gern gesehen ist, weil es eben kompatibel zu .net ist.

Auch nochmal Autsch.

Mono ist eine zu der ECMA-Spezifikation von .NET 4.0 kompatible Runtime.
Dazu kommen dann teile(!) von Microsoft-Kompatiblen-Implementierungen zugehöriger Bibliotheken wie ASP.NET, Windows Forms, ADO.NET.

Darüber hinaus bringt Mono aber z.B. auch mehr ADO.NET Datenbanktreiber mit als Microsoft.NET - ist in diesem Bereich also sogar weiter. Dazu kommen dann auch noch weitere Bibliotheken wie z.B. Gtk# oder auch die MonoMac-Bindings, die z.B. viele Zugriffe auf die Mac-API Cocoa kapseln und dem Entwickler sonst notwendige P/Invokes abnehmen.

Mono hat sich inzwischen übrigens im Gnome-Desktop fest eingenistet und etliche Default-Anwendungen von Gnome sind für Mono geschrieben. So ablehnend kann die Einstellung der Linux-Anhänger die Gnome entwickeln also gar nicht sein.

So, und nun zum eigentlichen Teil:

Zitat von fkerber:

Mono ist quasi das .Net für Nicht-Windows-Systeme?
Und "glücklicherweise" sind diese beiden Systeme (zumindest bis .NET 2, wenn Wiki recht hat) kompatibel. D.h. wenn ich unter Mac was mit z.B. MonoDevelop programmiere, dann wird es auch unter Windows laufen, wenn dort ein passendes .NET-Framework installiert ist?

Korrekt. Das geht schon etwas tiefer in .NET rein, aber für .NET gibt es drei Laufzeitumgebungen: 1.0, 2.0 und 4.0. Was man Landläufig unter .NET 2.5, 3.0 und 3.5 versteht ist im Grunde nur die 2.0er Runtime + zusätzliche Bibliotheken.

Es gibt von diesen Bibliotheken einige, die nicht oder nur Teilweise unter Mono bzw. auf anderen Plattformen laufen. Das ist z.B. Windows Presentation Foundation (WPF) oder auch Teile von WCF (Windows Communication Foundation). Letztere ist aber grad im kommen.

Auf der anderen Seite gibt es aber auch Teile in Mono, die sind viel umfangreicher als die in Microsofts .NET. Ein gutes Beispiel hier ist ADO.NET. Microsoft kann SQL Server und Oracle. Mono bringt hier Provider für viel mehr Datenbanken von Haus aus mit.

Zitat von fkerber:

Bzgl. dem Programmieren an sich:
Mit MonoDevelop wäre die Sprache der Wahl dann vermutlich C#?

Ja. Oder Delphi Prism

Zitat von fkerber:

Wie ist das mit Delphi-Prism?
Ich hab auf der Download-Seite gesehen, es gibt die IDE für Mac und Windows. Gilt dann hier quasi das selbe wie oben? Ich entwickele unter Mac und das Ganze wäre dann unter Windows mit .NET-Framework lauffähig? Und die Sprache ist dann quasi Delphi im .NET-Style?

Genau. Voll auf den Punkt getroffen

Zitat von fkerber:

Eine zentrale Frage wäre für mich jetzt noch:
Die Verbreitung irgendeiner .NET-Framework-Version unter Windows dürfte wohl recht weit sein - aber wie sieht es auf der anderen Seite für Mac und Linux aus?
Wenn ich das richtig verstanden habe, muss dort ja dann das Mono-Framework installiert sein - das wäre jetzt bei mir beispielsweise nicht der Fall.
Daher meine Frage, ob es da vllt. irgendwo Statistiken/Zahlen (auch wenn ich sie nicht selbst gefälscht habe ) gibt, die dazu was sagen.

Das ist halb so wild.

Wie oben schon erwähnt: Auf einem neueren Linux-System mit GNOME ist Mono schon drin. Mono auf dem Mac ist üblicher als man meinen mag, aber selbst wenn nicht ist das kein Beinbruch:

Mono bietet zum einen die Möglichkeit, die komplette Runtime in die Anwendung gleich reinzupacken. Von der Idee her ist es das gleiche, wie wenn man bei Delphi eben keine Packages ausliefert sondern einkompiliert. http://www.mono-project.com/Embedding_Mono
Natürlich bläht das die Anwendung dann ein wenig auf - aber die komplette Mono Runtime inkl. mscorlib.dll brauchen zusammen nur 3.7 MB. Das kann man sogar noch weiter runterkriegen.

Dazu gibt es bei Mono dann auch noch die Möglichkeit, die Anwendung komplett in nativen Code zu übersetzten. Das wird z.B. auch für iOS-Anwendungen gemacht, so dass man am Ende eine native executable hat: http://www.mono-project.com/AOT Damit ist man dann noch unabhängiger.

Zitat von fkerber:

Dann noch eine letzte Frage:
Auf der Mono-Download-Seite habe ich jetzt auch eine Windows-Version gesehen. Da frage ich mich nun, warum?
Unterstützt die dann Mono-Anwendungen besser, als das .NET-Framework es tut?

Es soll Leute geben, die .NET nicht mögen

Nein, die Idee ist eher die, dass man seine Anwendung dann auch auf Windows direkt gegen die Mono testen kann. Wie gesagt: Es gibt Teile in Mono, die sind in .NET nicht drin (eben die angesprochenen ADO.NET Provider), und umgekehrt.

Die oben genannten Tools (z.B. auch das Ahead-of-time compiling-Tool) sind natürlich auch kein Bestandteil von Microsofts .NET, so das man hierfür auch unter Windows Mono braucht. Es gibt auch ein Tool namens Mono Migration Analyer (MoMA), das eine für Microsoft .NET geschriebene Anwendung analysiert und aufzeigt, bei welchen Stellen es auf anderen Systemen Probleme geben kann (z.B. ein P/Invoke auf eine Windows-DLL, das verwenden von #13#10 anstelle von Environment.NewLine oder - noch schlimmer - das Benutzen von WPF).

Auch dafür braucht man unter Windows eine Mono-Installation.


Als Anmerkung:
Ich mache ja ungeheuer viel im Web-Bereich, und ich habe bisher noch keine ASP.NET Anwendung hinbekommen die nicht auch unter Apache/mod_mono lief.
Übrigens: Die meisten kommerziellen ASP.NET Komponenten laufen inzwischen auch offiziell unter Mono:
http://www.telerik.com/company/press...-for-mono.aspx
http://www.infragistics.com/about-us...ouncement.aspx

Ich schreibe auch etliche Tools und Bibliotheken, die auch alle unter Mono laufen (viele schreibe ich sogar auf dem Mac).

Man muss sich fast schon anstrengen Sachen zu schreiben, die nicht auf Mono laufen - sofern man sich auf ein paar Grundregeln einlässt. Diese wären: Keine hart codierten Pfade, keine hart codierten Zeilenumbrüche. Die Spezialpfade wie z.B. das Userverzeichnis gibts mit .NET-Hausmitteln genauso einfach und das läuft auch unter Mono. Bevor man etwas mit Fremdcode oder Komponenten löst erstmal nachgucken ob .NET / Mono nicht schon was passendes mitliefert. Die Bibliothek ist riesig und ein großes Problem was ich bei vielen sehe ist dass sie einfach loslaufen und zeug selber schreiben was es schon gibt. Ein bisschen einlesen hat noch niemandem geschadet

Bei der GUI immer aufpassen. Windows Forms mag auch auf dem Mac laufen (unter X11) und unter Linux, aber das sieht echt häßlich aus und viele eingekaufte Komponenten gehen da nicht. Also da lieber einheitlich auf Gtk# setzten, ODER (mein Favorit), sich tatsächlich die Arbeit machen, ein MVC-Pattern hernehmen und die GUI für jede Plattform nativ machen (Windows Forms oder WPF für Windows, Cocoa (mittels InterfaceBuilder) auf dem Mac und Gtk oder Qt für Linux. Das sieht auf jedem System viel natürlicher aus, fühlt sichbesser an, ist hintenraus einfacher zu handeln und wenn man hinten mit Model und Controller aufpasst und das sauber löst muss man tatsächlich nur die Form auf jedem System machen, ein bisschen Glue-Code schreiben, und das war's auch schon.

[Unwissender]

Hallo fkerber,

was ist eigentlich der Ausgangspunkt der Debatte gewesen? Ich glaube Du sagtest, dass Du jetzt gelesen hast, das irgendwer sagt: "Java ist doof!" (ok, etwas vereinfacht ausgedrückt ).

Aber mal ganz ehrlich, hast Du das nicht schon mal gelesen? Seit ich mit Java arbeite habe ich das schon häufiger gelesen, trotzdem verdienen meine Kollegen und ich (und viele andere auch) ganz gut mit Java Programmierung ihr Geld und hey, unsere Kunden sind (meistens) ganz zufrieden. Wie in jedem Unternehmen gilt das nicht immer, aber noch kein Kunde hat sich wegen der Programmiersprache beschwert.

Ich meine das übrigens ernst und finde es wichtig für die Debatte. Den Kunden oder Deinem Geldgeber ist es in der Regel egal welche Programmiersprache Du verwendest. Für die bleibt letztlich eine Anforderung die sie erfüllt sehen wollen und die Frage was es kostet. Natürlich gibt es auch Leute die Dir vorschlagen nimm doch Technik X oder die nach einer Java-Anwendung fragen, die Folgendes kann, es ist jedoch nicht deren Aufgabe sich über die technische Umsetzung sorgen zu machen. Ist eine Java-Anwendung nötig, weil die eine eigen QS-Abteilung haben, die nur Java kann, den Quellcode mitkaufen und der eben dort geprüft wird, dann ist das Anforderung und wird mit Kosten berechnet. Wollen die nur Plattformunabhängigkeit (für eine definierte Auswahl von Systemen) bleibt es dem Auftragnehmer überlassen ob der für Linux in C, MacOS in Objective-C und Windows in Java programmiert/ programmieren lässt oder nicht.

Was jetzt also die (ewige?) Debatte um Java angeht, ob es gut oder schlecht ist, so gilt hier das gleiche wie für andere Sprachen auch, die Antwortet lautet: depends. Z.B. kann C++ super sein, wenn Du eine IDE für Windows schreibst (was nicht heißt das andere Sprachen nicht auch super dafür sein können!). Schreibst Du aber einen Linux-Kernel, ist es ungeignet (siehe Post).
Auch Java ist nicht die eierlegende Wollmichsau. Möchtest Du einen Treiber programmieren, ist eine abstrakte Ausführungsschicht so ziemlich das Ungeeignetste, was einem einfallen könnte, das gilt somit auch für .NET Sprachen/ die CLI oder Interpreter. Das versteht sich von selbst. Auch gibt es die ewig gleichen Gerüchte, dass Java besonders langsam ist (gilt schon sehr lange nicht mehr) oder dass die Entwicklung mit der Sprache X (gerne wird hier C# benannt) 30% schneller ist oder so.

Das ist alles so pauschal wie falsch. Es kommt immer darauf an, was Du machen möchtest. Einen ganz wichtigen Punkt hast Du ja schon benannt, Java ist schon fast überall installiert. Das darf (und sollte) man nicht unterschätzen. Natürlich kann man jetzt auf MyBlaster, Conficker oder I-Love-You verweisen, die waren auch weit verbreitet, aber irgendwie doch nur unter Windows (was für die weite Verbreitung von Windows spricht und nicht gegen das OS!). Bei den Dingen, die wie Java oder FireFox, eher freiwillig verbreitet werden, spricht aber eine gewisse Alleinstellung und/oder Qualität für das Produkt. Java gibt es jetzt auch schon ein paar Jahre und bis heute finden sich viele Firmen, die freiwillig auf die Sprache setzen oder die Laufzeitumgebung auf ihren Systemen installieren, trotz der "vielen Nachteile" über die man so gerne liest. Man kann also davon ausgehen, dass es auch Vorteile geben muss oder vielleicht nicht alles stimmt was Leute gerne so behaupten.

Wie schon erwähnt, auch Java hat bestimmte Einsatzzwecke, für die es sich besser eignet und solche, für die es ungeeignet ist. Am Stärksten wiegt immer die Abstraktionsstufe, die Java mitbringt. Java gut für solche Anwendungen, die eine hohe Abstraktionsebene benutzen (und das sind viele Fachanwendungen). Hier möchte man nicht eine bestimmte CPU direkt ansprechen, einen Scheduler selbst steuern oder Treiber bereitstellen, sondern schnell und effizient eine komplexe Problematik (in der fachlichen Domäne) umsetzen.
Hier wird man eher schauen welche Frameworks bereits zur Verfügung stehen und da ist Java einfach sehr gut aufgestellt. SourceForge z.B. hat immer noch deutlich mehr Java-Projekte als irgendwas anderes, JasperReports und Birt sind sehr gute Report-Generatoren, mit JSF gibt es eine gute Mölgichkeit komponentenbasiert Webanwendung (HTML nicht Applets!) zur Verfügung zu stellen, mit der JPA gibt es freie O/R Mapper. Ist so nicht ganz korrekt, denn Java oder die JSRs definieren mit JSF oder JPA erstmal nur Schnittstellen, die eigentliche Bereitstellung erfolgt über Implementierungen (von denen es dann wieder gute Referenzimplementierungen und Alternativen gibt, z.B. EclipseLink und Hibernate als JPA Implementierung).

Wichtig ist aber, dass man für alle bekannten Datenbanksysteme einen jdbc-Treiber findet, der über so einen O/R-Mapper sehr einfache Zugriffe aus Java-Objekten auf die DB erlaubt. Noch viel wichtiger, auch ein Transaktionmonitor ist über Spring oder einen JEE Container gleich mit bei und hier steckt der wahre Mehrwert! Natürlich hat .net bestimmt ähnliche Technologien, aber vergleicht man das z.B. mit C, so fehlt dort dieser "quasi Standard". Ihn selbst zu schreiben und eine gute Qualität sicherzustellen ist mit einem Aufwand von mehreren Personen-Jahren zu beziffern (die Zeit und Erfahrung ist sicher auch bei Java nötig gewesen, aber schon investiert wurden).

Ich möchte hier nur die Domäne von Java rausstellen, die liegt (imho) schon länger nicht mehr auf "plattformunabhängigkeit". Nimm einfach die bekannteste Konkurrenz, C# oder .net. Natürlich kann man jetzt sagen, dass .net Plattformunabhängig ist, aber stimmt das so? Kann ich in VisualStudio mit der neusten .net Version arbeiten (die neueste Version bietet sicher einen Mehrwert gegenüber anderen Versionen, sonst lässt MS die nicht entwickeln und VS ist eine wirklich gute IDE!) und das Produkt dann einfach unter Linux verwenden? Ich glaube nicht. Warum also hat MS so eine CLI geschaffen, wo doch plattformunabhängigkeit hier (offensichtlich) nicht im Fokus stand oder steht (nicht durch MS selbst)? Wenn man sich hier die Unterschiede zwischen .net und Win32 anschaut, dann liegen sie darin, dass C# stärker abstrahiert. Man hat viele mächtige Frameworks wie LINQ und eine relativ hohe Abstraktionsebene. Der Code ist managed und somit gelten ähnliche Vor- und Nachteile wie für Java. Das zeigt aber einfach, dass diese Form von Programmierung/Entwicklung an Bedeutung gewonnen hat. C wird es wie C++ auch weiterhin geben und die Domänen die sie bedienen werden auch weiterhin vorhanden sein, aber es gibt auch viele Anwendungen höherer Abstraktion.

Ich würde Dir deswegen raten Dich nicht von Kommentaren irritieren zu lassen, die sagen, dass Java doof ist oder keine Treiberprogrammierung beherrscht. Klar, stimmt, wenn Du in die HW-nahe Programmierung eintauchen willst solltest Du nicht unbedingt mit C# oder Java anfangen, für die Anwendungsentwicklung ist es aber keine schlechte Sprache.
Auch solltest Du Dich nicht vom Feature-Wahn verfolgen lassen. Natürlich kannst Du in .NET verschiedene Sprachen kombinieren, sowie auch Java das kann (da gibt es eine Schnittstelle für und ich glaube z.B: Ruby oder Scala kann man darüber mit anderen Java-Klassen zusammen verwenden).

Bleibt noch die Sache mit dem GUI. Das ist (und das liegt in der Natur der Sache) ein Problem der Plattformunabhängigkeit. Hier muss man in Java 3 Möglichkeiten unterscheiden, alle mit ihren Vor- und Nachteilen:

1. AWT - Die "älteste" Fenstertechnik in Java. Hier wurde einfach der kleinste gemeinsame Nenner aller Plattformen genommen und in eine Java API gesteckt. Alle Elemente (Fenster, Button, ...) die es überall gibt werden nativ erzeugt. Ein AWT Fenster sieht unter Mac so aus, wie jedes andere auch, unter Windows sind es Windows-Fenster usw. Allerdings ist die Gemeinsamkeit eher klein, schon bei der Anzeige von Bäumen muss AWT passen.
2. Swing - Die Beschwerden über die viel zu vielen Dinge die AWT fehlten führten zu Swing. Um alle Komponenten darstellen zu können, wird bei Swing einfach ein viel kleinerer, gemeinsamer Nenner verwendet, die Zeichenfunktionen. Das führt dazu, dass Java-Anwendungen, die mit Swing erstellt werden, überall gleich aussehen (leider nicht immer schön). Ein Button wird hier einfach mit Grundoperationen gezeichnet, genauso ein Baum oder andere Komponenten. Das können alle Plattformen, aber schnell ist dann auch anders (daran hat man viel gearbeitet und mittlerweile ist die Leistung der Systeme und die Optimierung der Java Umgebung schon ganz ok!).
3. SWT - Bei SWT wurde eine Sammlung von unterstützten Komponenten festgelegt. Diese finden sich alle nativ unter Windows. Vereinfacht kann man hier eine Mischung aus AWT und Swing unterstellen, alle Komponenten, die nativ angeboten werden, werden vom OS aus erzeugt. Alles was eine bestimmte Plattform nicht direkt bietet, wird emuliert. Hier wird gerne darauf verwiesen, dass Windows SWT Anwendungen etwas schneller laufen als die unter Linux oder MacOS, aber ich glaube nicht, dass man hier im relevanten Bereich landet.

Dass die GUI Entwicklung mit Java besonders aufwendig ausfällt liegt hauptsächlich daran, dass es keine gute IDE mit kostenlosem GUI-Designer gibt. NetBeans fühlt sich immer etwas träge an, Ecipse bietet keinen integrierten GUI Editor. Eclipse selbst ist nutzt SWT (und zeigt eindrucksvoll wie wenig eine Java Anwendung schleicht oder sich von anderen Anwendungen unterscheidet). Man kann das Eclipse-Framework auch direkt verwenden um eigene SWT Anwendungen zu erzeugen. Auch finden sich kommerzielle Designer, die man sicher auch testen kann.
Ich selbst kann hier keine Empfehlung aussprechen, da ich aktuell nur Webentwicklung betreibe und dort bestimmt der Webdesigner schon das Layout mit seinen Tools, ich muss da nur die Logik einfügen. In Unternehmen wirst Du hier sicherlich keine Probleme haben ein paar hundert Euro für eine IDE oder eben so eine Erweiterung zu bekommen, ein Visual Studio (ohne Express) oder eine Delphi IDE werden ja auch bezahlt. Hier kommen wieder nur einfache Kosten-Nutzen-Rechnungen zu tragen (eine IDE kostet ein paar hunder Euro, Du kannst aber viiiel schneller arbeiten und nach wenigen PT amortisiert sich die Investion, der Rest interessiert keinen ).


Also nochmal zusammenfassend:

• Java ist mehr als plattformunabhängkeit
• Java ist gut für Fachanwendungen, schlecht für systemnahe Programmierung
• Java ist verbreitet und es gibt viele Frameworks (was die Entwicklung komplexer Fachanwendungen erleichtert)
• Java Anwendungen sind (wie z.B. Eclipse) nicht "langsame, graue Dinosaurier, denen man das Java schon ansieht"
• Java Applets sind nicht Java und sollten verboten werden! (da gibt es wirklich immer Ärger, aber das ist ein anderes Thema)
• Gutes GUI Design kostet bei Java

[Phoenix]

Zitat von Unwissender:

Wichtig ist aber, dass man für alle bekannten Datenbanksysteme einen jdbc-Treiber findet, der über so einen O/R-Mapper sehr einfache Zugriffe aus Java-Objekten auf die DB erlaubt. Noch viel wichtiger, auch ein Transaktionmonitor ist über Spring oder einen JEE Container gleich mit bei und hier steckt der wahre Mehrwert! Natürlich hat .net bestimmt ähnliche Technologien

Ein paar Schlagworte: Spring.NET, NHibernate, nDepend.

Nicht nur ähnliche. Zum Teil sogar die gleichen.

Zitat von Unwissender:

Ich möchte hier nur die Domäne von Java rausstellen, die liegt (imho) schon länger nicht mehr auf "plattformunabhängigkeit". Nimm einfach die bekannteste Konkurrenz, C# oder .net. Natürlich kann man jetzt sagen, dass .net Plattformunabhängig ist, aber stimmt das so? Kann ich in VisualStudio mit der neusten .net Version arbeiten (die neueste Version bietet sicher einen Mehrwert gegenüber anderen Versionen, sonst lässt MS die nicht entwickeln und VS ist eine wirklich gute IDE!) und das Produkt dann einfach unter Linux verwenden? Ich glaube nicht.

Glauben heisst nicht wissen. Ich sage Dir: Ja. Geht. Mache ich tagtäglich und funktioniert einwandfrei.

[rollstuhlfahrer]

Dann würde ich noch Python in den Raum werfen. Mein Informatiklehrer hat demletzt gesagt, dass Python die nächsten Jahre flächendeckend in der Rheinland-Pfälzer Sekundarstufe II als Konsolen/GUI-Anwendungsentwicklung eingeführt wird (anstelle von Delphi). Leider braucht man für Python sowas wie eine Runtime-Bibliothek. Unter Linux wird man schon fast dazu genötigt, diese zu installieren, wenn man bestimmte Anwendungen haben will, unter Windows dürfte es ein leichtes sein, diese mitzuliefern und im Anwendungsverzeichnis gleich mitzuinstallieren.

Ein weiterer Versuch wäre Erlang. Falls es jemand kennt: ejabberd (Jabber-Server) ist mit Erlang geschrieben, zur Verbreitung lässt sich allerdings nichts sagen.


Zu .net und Mono: Meine Musik-Lade-Software lief unter Linux mit Mono zusammen prima. Der Grund, warum sie nicht mehr läuft, ist im Betriebsystem zu suchen und die Software gehört einfach neu kompiliert. Dann würde sie auch wieder laufen. Leider ist mir das unter Linux viel zu kompliziert.

Bernhard

ADD: Und wenns nur Konsole sein soll, ist PHP auch einen Blick wert.

[creed steiger]

Zitat von Phoenix:

..etliche Default-Anwendungen von Gnome sind für Mono geschrieben.

Da würde mich mal interessieren welche das sind.
(Der Notizzettel und der Musikplayer?)

[Phoenix]

Zitat von creed steiger:

Da würde mich mal interessieren welche das sind.
(Der Notizzettel und der Musikplayer?)

Tomboy, Banshee, Muine, F-Spot, iFolder, Gnome DO, gtwitter. Sind so die, die mir auf Anhieb einfallen...