Einzelnen Beitrag anzeigen

Unwissender

Registriert seit: 11. Dez 2003
16 Beiträge
 
#16

AW: Plattformunabhängig programmieren

  Alt 15. Jan 2011, 13:44
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
  Mit Zitat antworten Zitat