Vortrag über systemunabhängiges Programmieren

Hallo alle zusammen!

Ich habe im Rahmen des Informatikunterrichts die Aufgabe, einen Vortrag über systemunabhängiges Programmieren zu halten.
Das ganze soll nicht lang sein. Nur zw. 15-20min. Bei der Themenvergabe, dachte ich, dass es wohl nicht so schwer sein kann, etwas über das Thema zu finden. Doch jetzt will ich mal anfangen und ich find eigentlich nichts darüber.

Ich soll auf jeden Fall an einem Beispiel die Vor- und Nachteile einer solchen programmierten Anwendung erklären.

Ansehen soll ich mir dafür z.B. Java oder Star-View. Ich werde Java wählen, da ich zu Star-View nichts finden kann.

Nun meine Fragen: Wo könnte ich über ein derartiges Thema informationen finden? Google spuckt mir nichts aus und Wikipedia hat auch nicht gerade die übermäßige Trefferquote. Es läuft eben alles immer wieder auf Java/Sun herraus.
Ich könnte aus dem Kopf herraus auch nur einen Vorteil finden. Nachteile tun sich mir irgendwie nicht auf.
Und zu guter letzt wäre noch ein gutes Beispiel (vlt sogar mit Quellcode?) zu finden. Aber auch hier: Keine Ahnung, wo Java viel und effektiv genutzt wird und wie man das in einen Vorteil mit Erklärung einbauen kann.

Ich hab mir auch extra eclipse besorgt, um damit vlt. zu arbeiten. Aber leider hab ich keine Kenntnisse im Programmieren mit Java. In der Schule lernen wir Pascal. Und nun liegt die Entwicklungsumgebung erstmal nur auf meiner Platte rum.

Ich hoffe ihr könnt mir helfen. Ich bin für alles dankbar.
Gruß Bond

Nachteile:
.) Langsam weil nicht Systemnah
.) Framewok muss bei Java zB vorhanden sein

Mir würde zu dem Thema auch QT einfallen...

// Ausserdem ist Java verdammt instabil.. Zumindest ist das meine Erfahrung.

//// Auf die schnelle nochwas gefunden:
http://www.wxwindows.org/

Ist Framework nicht ne MS-Anwendung?

Wie meinst das mit Systemfern und deswegen langsam? Ich hätte mir so überlegt, dass es ein Mehraufwand beim programmieren ist, weil man z.B. nicht auf im System vorhandene .dll's und andere Bibliotheken zugreifen kann. Gehört das dazu?

Bond246 schrieb:

Ist Framework nicht ne MS-Anwendung?

Wie meinst das mit Systemfern und deswegen langsam? Ich hätte mir so überlegt, dass es ein Mehraufwand beim programmieren ist, weil man z.B. nicht auf im System vorhandene .dll's und andere Bibliotheken zugreifen kann. Gehört das dazu?

Zum Vergrößern anklicken....

Im Gegenteil. Es ist eher eine Erleichterung, da Java schon alles an Bord hat. Systemnahe Programmierung ist wieder ein anderes Thema und hat wenig mit systemunabhängigem Programmieren zu tun.

Java ist durchaus ein sehr gutes Beispiel für systemunabhängiges Programmieren. Java gibt es für Windows, Linux, Handys, PDAs und es exisitieren auch VMs für embedded Systems. Damit Java-Programme laufen können, benötigen sie eine Virtual Machine, eine Art virtueller Prozessor. Gerade diese zusätzliche Abstraktionsschicht macht es möglich, ein Programm unter Windows zu entwickeln und dann z.B. unter Linux laufen zu lassen. Es wird nur eine native Implementation der VM auf der Zielplattform benötigt.
Um mit der Umwelt zu interagieren, werden zusätzliche Bibliotheken benötigt. Das Java-JDK als Standardbibliothek deckt von Netzwerkprogrammierung bis GUI und Konsole alle wichtigen Bereiche ab. Im Normalfall ist es gar nicht notwendig, irgendwelche DLLs zu verwenden (was natürlich auch möglich ist).

Für Geräte mit weniger Speicher und Rechenleistung existieren "kleinere" Versionen von Java (Java ME, MIPD, CLDC, Personal). Die Sprache selbst bleibt dieselbe, aber die Möglichkeiten und der Umfang der Bibliothek sind eingeschränkt.

Das heutige Java ist übrigens weder langsam, noch instabil.

Abseits von Java gibt es noch QT. Eine Bibliothek für C++, die inzwischen auch eine Menge Bereiche abdeckt (GUI, Netzwerk, Threads, usw.)

Was er meint ist folgendes:

Die Systemunabhängigkeit von Java beruht darauf, dass auf jedem Betriebssystem, auf dem Java-Anwendungen laufen sollen, eine JRE (Java Runtime Environment) installiert sein muss. Diese ist als "Framework" zu verstehen, d. h. jede Java-Anwendungen nutzt nur Funktionen, die das Framework bereitstellt. Wie diese Funktionen aber in einem gewissen Betriebssystem funktionieren, hängt von der jeweiligen JRE ab - im besten Falle ist das Verhalten identisch, dann wäre das Programm systemunabhängig. (Wenn Du Dich zu dem Thema informierst wirst Du feststellen, dass es aber auch bei Java viele Punkte gibt, die die systemunabhängigkeit "kaputtmachen", z. B. bestimmte Gerätetreiber oder eigentliche Fehler in der Programmierung bspw. unterschiedliche Trennzeichen etc.)

Das .NET-Framework von Microsoft ist praktisch nichts anderes als Java. Es stellt auch die Umgebung bereit, die die .NET-Programme dann nutzen (deshalb ist die Programmiersprache, in der Du z. B. mit Visual Studio .NET programmierst dann am Ende egal, weil alles aufs Framework ausgelegt wird). Das .NET-Framework ist aber nicht systemunabhängig, da MS nur eine Version für Windows bereitstellt (bzw. es gibt eine Linux-Alternative "Mono", aber inwieweit die taugt kann ich nicht beurteilen, hab nie damit gearbeitet)

Denke da wirst Du schon was finden, um so einen Vortrag füllen zu können. Hast ja jetzt schon einige Punkte, über "Was bedeutet systemunabhängig", "Warum/Wozu/Wie", Beispiele und Probleme...

Übrigens ist Java weder langsam noch instabil - eine Anwendung kann langsam und instabil sein, aber das hat mit Java wenig zu tun, sondern eher mit der "Quelle" aus der die Programme kommen...

Natürlich ist Java langsamer als C. Und genau das hab ich gemeint...

Das mit instabil ist meine subjektive Meinung an der ich immernoch festhalte.

Langsamer als C, ja ok... das ist ja schon wieder ne andere Aussage Aber langsamer als .NET?

Ein Porsche ist auch langsam... zumindest langsamer als ein F1-Auto - Ok, der Vergleich hinkt, ich gebs zu

MR.Q schrieb:

Natürlich ist Java langsamer als C. Und genau das hab ich gemeint...

Zum Vergrößern anklicken....

Nur marginal. C kann nicht direkt auf einem Prozessor ablaufen. Java übrigens schon ("Jazelle"). C muß erst in Maschinensprache konvertiert werden. Damit hängt es schon mal vom Compiler ab, wie schnell der Code letztendlich ist.
Auch Java wird erst zu Bytecode kompiliert, der dann durch die VM ausgeführt wird. Heutige VMs haben einen JIT-Compiler (Just in Time). Der Bytecode wird in Maschinencode übersetzt. Damit hängt es auch hier von der Güte des Compilers ab, wie schnell das Programm ausgeführt wird.

Man kann in Java und in C instabile und langsame Programme schreiben. In C geht ersteres sogar sehr leicht. Auch wenn C letztendlich ein wenig schneller ist als Java, spielt das auch auf älteren Rechnern keine Rolle mehr.
Viel wichtiger als die letzten Taktzyklen aus dem Code zu quetschen, ist ein guter Algorithmus und dessen Umsetzung. Da läßt sich wesentlich mehr dabei rausholen.

Das wichtigste Einsatzgebiet von C sind immer noch die eingebetteten Systeme. Dabei spielt der minimale Geschwindigkeitsvorteil gegenüber Java meistens keine Rolle. Wichtiger sind hier der geringere Speicherverbrauch, da C keine VM und keine Laufzeitbibliotheken benötigt, die Möglichkeit der hardwarenahen Programmierung und der besseren Kontrolle über das Laufzeitverhalten und das Speichermanagement.

Nicht zu vergessen Spiele und Betriebssysteme
Worauf du meiner Meinung nach evtl. auch achten solltest, ist, die Vorteile bzw. Eigenheiten der einzelnen Sprachen nicht mit deren Plattform(un)abhängigkeit zu vermischen. Viele Features, wie z.B. der Garbage-Collector von Java sind eher einfach Merkmale einer moderneren Sprache und haben nicht direkt mit der Architektur dahinter zu tun. Gerade das sind nämlich oft gebrachte Beispiele, die man an jeder Ecke als Vorteile von Java usw. zu hören bekommt, und was auch oft mal durcheinandergebracht wird.
Und nimm dich in Acht; derartige Themen laufen des öfteren auf einen kleinen Glaubenskrieg hinaus.
Wobei das natürlich stark von der Applikation abhängt, wie UnimatrixZero schon schrieb.
Leute, die Office-ähnliche Programme schreiben werden eher Java bevorzugen. Sobald ein Programm aber Hardware steuern soll (und damit ohnehin nicht mehr plattformunabhängig ist) und nicht bloß mit Maus, Tastatur und Bildschirm interagiert, ist C das Mittel der Wahl.
Bei uns an der Uni sieht man das z.B. sehr deutlich. Die (bzw. manche) Informatiker preisen Java gerne als das Allheilmittel an, während offenbar sämtliche Techniker niemals auf die Idee kommen würden, sowas anzurühren.

PS: Man muss ganz schön aufpassen, bei so einem Thema nicht die eine oder andere abfällige Bemerkung über die andere "Religion" fallen zu lassen.

Danke schon mal für die viele Antworten. Ich hätt' nicht gedacht, dass das Thema so "populär" wird :ja: Ihr habt mir bis hierher auf jeden Fall schon geholfen.
Eine Frage hätt ich aber noch (sry^^): An welchem Beispiel könnte man diese Vor- und Nachteile jetzt vlt. noch belegen? Gibt es vlt. Programme/Lösungen, die sowohl in Java als auch in z.B. C vorhanden sind?

Nochwas: Kann man davon ausgehen, dass die Ausführung einer systemunabhängigen Programmierung immer über eine VM läuft?

Bond246 schrieb:

Nochwas: Kann man davon ausgehen, dass die Ausführung einer systemunabhängigen Programmierung immer über eine VM läuft?

Zum Vergrößern anklicken....

Dazu muß erstmal klar werden, was "systemunabhängige Programmierung" überhaupt ist? Und wo findet sie ihre Grenzen? Komplett systemunabhängig wird es nie gehen. Man kann auch in C systemunabhängig programmieren. Dann ist man allerdings auf die Sprache und die Standardbibliothek beschränkt. Auf eingebetteten Systemen ist sogar diese oft nicht vorhanden. Aus diesem Grund verpackt man solche systemabhängigen Teile in ein extra Modul, so daß bei einer Portierung auf ein anderes System nur dieses Modul ausgetauscht werden muß.
Der Vorteil einer VM ist, daß der Binärcode systemunabhängig ist (Einschränkungen kann es auch hier geben). D.h. ich kann eine "Java-EXE" einfach von Windows nach Linux kopieren und es wird funktionieren. Sprachen wie C muß man erst für das Zielsystem kompilieren.

Systemunabhängig bedeutet, daß für alle benötigten systemabhängigen Komponenten eine Abstraktionsschicht vorhanden sein muß, die den systemabhängigen Teil übernimmt und das eigentliche Programm nichts mehr mit dem System direkt zu tun hat. Das klappt bei Java recht gut, da diese Abstraktionsschicht sehr weitreichend ist.

UnimatrixZero schrieb:

[...]
Der Vorteil einer VM ist, daß der Binärcode systemunabhängig ist (Einschränkungen kann es auch hier geben). D.h. ich kann eine "Java-EXE" einfach von Windows nach Linux kopieren und es wird funktionieren. [...]

Zum Vergrößern anklicken....

Aber warum wandelt man den Bytecode nicht gleich in Maschinencode? Dann würde man sich doch die extra Module sparen, oder verstehe ich da was falsch?

Weil verschiedene Prozessorarchitekturen ihre eigene Maschinensprache haben. Der Bytecode von Java ist universell und wird erst auf dem jeweiligen Zielsystem in den passenden Maschinencode konvertiert. Dass der Bytecode überhaupt "zwischengeschaltet wird" liegt vermutlich in Vorteilen der Größe und der Geschwindigkeit der Übersetzung am Zielsystem. Das kann dir aber sicher jemand genauer erklären.

C wird üblicherweise direkt aus dem Quellcode in die gewünschte Maschinensprache übersetzt. Wobei natürlich auch hier nichts dagegen spricht, z.B. bei einem OpenSource-Programm, den Quellcode auszuliefern und auf dem jeweiligen Zielsystem zu übersetzen. Allerdings ist dazu meistens etwas mehr Interaktion und Wissen erforderlich.

Die Abstraktionsschichten für die Anwendungsebene, wie z.B. Fenstermanagement usw. liefert C aber nicht mit; d.h. die speziellen Fenster-Befehle von Windows funktionieren nicht unter Linux und umgekehrt. Der Programmierer muss sich z.B. mit einer Fallunterscheidung selber darum kümmern, dass die richtigen Befehle verwendet werden, oder eine Funktionsbibliothek wie wxWidgets verwenden, die universell verwendbare Funktionen zur Verfügung stellt.

cmddegi schrieb:

Weil verschiedene Prozessorarchitekturen ihre eigene Maschinensprache haben. [...]

Zum Vergrößern anklicken....

Danke. Genau diese Information schwirrte in meinem Kopf, doch während der Arbeit hab ich gezweifelt, ob ich damit richtig liege.

Dass Java Anwendungen sehr langsam sind, kann ich nur bestätigen.
Als Beispiel möchte ich ein Kopierprogramm anführen, bei dem die Javaanwendung während des Kopiervorganges 70 % CPU brauchte und das Kopieren sehr langsam von statten ging.

Ich finde man merkt den Unterschied wirklich deutlich. Z.B. OpenOffice ist ebenfalls sehr langsam, vorallem das Starten. Damit es schneller geht, hat man einfach eine Anwendung geschaffen, die ständig läuft und ständig Speicher belegt, auch nicht die optimalste Lösung.

Wie bereits angesprochen wurde, kann man mit Java nicht systemnah programmieren und das bedeutet immer Geschwindigkeitseinbußen. Bei C merkt man es deutlich, ob man LowLevelIO verwendet oder die höheren Ebenen. Nur mit den LowLevelIOs erreicht man, dass beim Dateikopieren die CPU fast gar nicht gebraucht wird, bei den höheren Ebenen hat man gerne über 50 % CPU Auslastung, nur für das Kopieren einer Datei.

the ubm schrieb:

Dass Java Anwendungen sehr langsam sind, kann ich nur bestätigen.
Als Beispiel möchte ich ein Kopierprogramm anführen, bei dem die Javaanwendung während des Kopiervorganges 70 % CPU brauchte und das Kopieren sehr langsam von statten ging.

Zum Vergrößern anklicken....

Leider muß ich hier schon wieder widersprechen ;-)
Es mag sein, daß dieses Kopierprogramm langsam war. Das liegt aber schlicht und ergreifend daran, daß der Programmierer Murks programmiert hat.

Ich finde man merkt den Unterschied wirklich deutlich. Z.B. OpenOffice ist ebenfalls sehr langsam, vorallem das Starten. Damit es schneller geht, hat man einfach eine Anwendung geschaffen, die ständig läuft und ständig Speicher belegt, auch nicht die optimalste Lösung.

Zum Vergrößern anklicken....

1. OpenOffice ist nicht in Java programmiert, sondern in C/C++. Also ein gutes Beispiel dafür, daß auch man auch in C/C++ langsame Programme schreiben kann.
2. Das JRE (die Laufzeitumgebung) muß natürlich erstmal geladen werden. Daß Win32-Anwendungen schneller starten liegt einfach daran, daß die benötigten DLLs bereits von Windows beim Starten geladen werden.

Wie bereits angesprochen wurde, kann man mit Java nicht systemnah programmieren und das bedeutet immer Geschwindigkeitseinbußen. Bei C merkt man es deutlich, ob man LowLevelIO verwendet oder die höheren Ebenen. Nur mit den LowLevelIOs erreicht man, dass beim Dateikopieren die CPU fast gar nicht gebraucht wird, bei den höheren Ebenen hat man gerne über 50 % CPU Auslastung, nur für das Kopieren einer Datei.

Zum Vergrößern anklicken....

1. Daß man mit Java nicht systemnah programmieren kann, habe ich nicht geschrieben. Es existieren sogar JVMs für embedded Systems, die auch Zugriff auf die Hardware erlauben.
2. Was ist "LowLevelIO"? Ein C-Programm benutzt in der Regel die Funktionen aus der Standard-Lib, die unter Windows wiederum die Win32-Funktionen verwenden.
Nichts anderes geschieht bei Java. Dateizugriffe werden mehr oder weniger an das Betriebssystem durchgereicht. Wenn der Programmierer keinen Murks gemacht hat, dann sollte die Performance nur geringfügig schlechter sein.

1. OpenOffice ist nicht in Java programmiert, sondern in C/C++.

Zum Vergrößern anklicken....

Ok du hast Recht. Java benötigt man nur für einige wenige Funktionen.

Was ist "LowLevelIO"? Ein C-Programm benutzt in der Regel die Funktionen aus der Standard-Lib, die unter Windows wiederum die Win32-Funktionen verwenden.

Zum Vergrößern anklicken....

LowLevelIO ist mit Handles zu arbeiten statt Funktionen wie "fopen" zu verwenden. Letztere ist bedeutend langsamer als mit der handle Methode.

EDIT: Gerade gefunden Sun will Java Micro Edition einstellen. Zählt darunter eine JVM für embeeded Systems? Wenn fällt dieses Merkmal bald weg.

the ubm schrieb:

Ok du hast Recht. Java benötigt man nur für einige wenige Funktionen.

LowLevelIO ist mit Handles zu arbeiten statt Funktionen wie "fopen" zu verwenden. Letztere ist bedeutend langsamer als mit der handle Methode.

Zum Vergrößern anklicken....

Alle Dateifunktionen arbeiten mit Handles. Auch fopen. Noch mehr LowLevel geht fast gar nicht mehr. Außer Du programmierst die Dateisystemzugriffe selbst ;-) Da dürfte der Arbeitsaufwand den Gewinn an Performance bei weitem übersteigen.

EDIT: Gerade gefunden Sun will Java Micro Edition einstellen. Zählt darunter eine JVM für embeeded Systems? Wenn fällt dieses Merkmal bald weg.

Zum Vergrößern anklicken....

Weil die Hardware immer leistungsfähiger und deshalb die ME überflüssig wird. Embedded VMs wird's natürlich weiterhin geben.

Alle Dateifunktionen arbeiten mit Handles. Auch fopen.

Zum Vergrößern anklicken....

Als ich damals mit einem Kopierprogramm experimentiert hatte, hatte fopen massig CPU-Last erzeugt, als ich das irgendwie mit Handles gemacht hatte, gab es keine messbare CPU-Auslastung durch das Programm während des Kopierens.

Weil die Hardware immer leistungsfähiger und deshalb die ME überflüssig wird.

Zum Vergrößern anklicken....

Allerdings brauchen die Geräte dann mehr Strom -> kürzere Akkulaufzeit, also ganz überflüssig ist die ME nicht.