vorteile einer virtual machine?

mathik

Hallo leute!

heute laufen immer mehr Programme auf virtuellen Maschinen (siehe JAVA, dotNET). Diese haben ja bekannterweise den Vorteil, dass man das Programm nur einmal kompilieren muss, und dann auf allen möglichen Plattformen mit der virtuellen Maschine ausführen kann. Der just-in-time compiler übersetzt dann den "Zwischencode" in den native Code beim jeden Programmstart.

Meine Frage ist, warum? Wieso wird der Code nicht einfach gleich für jede Plattform in native Code kompiliert? Wann braucht man schon "compile once, run everywhere"? "write once, compile everywhere" wäre doch besser!? Dadurch würden die Programme viel schneller starten... Welchen Vorteil hat es, erst in den Zwischencode zu kompilieren?

Ich habe da auch gehört, dass durch virtuelle Maschinen der Code zur Laufzeit optimiert werden kann. Doch bringt das wirklich was?

Gruß mathik

Vermutlich, weil der Hardwarezugriff sich auf andren Systemen unterscheidet.
Für ein Konsolentextausgabeprogramm mag z.B. Standard C++ ausreichen, aber die meisten brauchen mehr.

Artchi

SeppSchrott! Was ist das denn für ein Argument??? Wenn ich Qt, GTKmm u.a. nehme, kann ich auch mehr als "Konsole" machen, interessiert mich als C++ Programmierer nicht was für ein System dahinter steckt.

Das Argument der Plattformunabhängigkeit steht meistens garnicht im Vordergrund. Sehe ich bei unserem Kunden. Der will Java haben, weil es "modern" und "zukunftssicher" ist. Da kann ich ihm noch soviele Gegenargumente bringen. Obwohl der Kunde 99% Windows-Landschaft hat (bestimmt 30.000 PCs!), die anderen 1% sind CAD-Maschinen, die wirklich nur für CAD genutzt werden.

Ich habe bisher ehrlich gesagt auch noch keinen Vorteil einer VM gesehen, außer vielleicht bei Java-Applets für Online-Banking oder so. Aber selbst da sind einige Online-Broker (z.B. Consors) zurück zu HTML gegangen.

Und wenn ich z.B. etwas in C++ programmiere, kann ich doch heute mit einer Library programmieren die es auf mehreren Plattformen gibt. Mein Programm könnte ich dann für mehrere Plattformen durch compilieren und fertig. Macht doch Adobe auch so?

Sovok

mathik schrieb:

Wann braucht man schon "compile once, run everywhere"? "write once, compile everywhere"

"write once, compile everywhere" setzt voraus, dass du für jede plattform build tools hast/kaufst

bei "compile once, run everywhere" kannst dus direkt dem user geben egal ob er n anderes os hat

frenki

Du brauchst sowieso alle Plattformen, für die du dein Programm rausgibst. Oder willst du mir erzählen, das du ein Programm, das du meinetwegen in Java unter Linux entwickelt hast einfach so für Windows freigibst, ohne es jemals getesetet zu haben?

Sovok

frenki schrieb:

Du brauchst sowieso alle Plattformen, für die du dein Programm rausgibst. Oder willst du mir erzählen, das du ein Programm, das du meinetwegen in Java unter Linux entwickelt hast einfach so für Windows freigibst, ohne es jemals getesetet zu haben?

das is zumindest der gedanke dahinter wenns ordentlich funktioniert
wenn nich kann man auch gleich "write once, compile everywhere" mittels qt bzw. standard c++ verwenden

ich entwickel kein java... also klär mich auf... gibts in der praxis gravierende unterschiede bei der ausführung auf verschiedenen plattformen?

Termite

Hi

es gibt z.B. Anwendungsfälle wo man das gut gebrauchen kann. z.B. bei "Wandernden Agenten" das sind Programme die von Server zu Server hüpfen können um dort z.B. recherche Arbeiten zu erledigen. Sowas in C++ zu erledigen setzt voraus, das alle server das gleiche OS und ähnliche HW haben. Bei java /.Net ist es egal ob auf der kiste nun Windows läuft, AIX,
Solaris oder Linux. Wichtig ist nur das die VM drauf läuft und die notwendigen Pakete installiert sind. Anderes Beispiel ein Dienst der auf einer Serverfarm läuft. Soll jetzt eine Maschine wegen wartungsarbeiten abgeschaltet werden, müssen dort alle laufende aufrtäge auf andere Maschinenen Vershoben werden. In java lieses sich das so realisiern, das die Aufträge sich selber einen neuen server suchen und dann selber umziehen.

auserdem bringen VMs noch andere nette sachen mit wie z.B. garbageCollector, eine ReflectionApi und eine intigrirte Lib Schnitstelle ( zumindest in java)

gruss

mathik

Sovok schrieb:

mathik schrieb:

Wann braucht man schon "compile once, run everywhere"? "write once, compile everywhere"

"write once, compile everywhere" setzt voraus, dass du für jede plattform build tools hast/kaufst

bei "compile once, run everywhere" kannst dus direkt dem user geben egal ob er n anderes os hat

die Virtual Maschine ist auf vielen Plattformen verfügbar. Das bedeutet, dass diese bereits solche Bibliotheken haben, die eine gemeinsame Schnittstelle haben, und auf jede Plattform angepasst ist! D.h. die gibt es einfach so von Sun oder Microsoft! Nur liegen diese zum sehr großen Teil in diesem "Zwischencode" vor.
Warum nicht in native Code?

Termite schrieb:

es gibt z.B. Anwendungsfälle wo man das gut gebrauchen kann. z.B. bei "Wandernden Agenten" das sind Programme die von Server zu Server hüpfen können um dort z.B. recherche Arbeiten zu erledigen. Sowas in C++ zu erledigen setzt voraus, das alle server das gleiche OS und ähnliche HW haben. Bei java /.Net ist es egal ob auf der kiste nun Windows läuft, AIX,
Solaris oder Linux. Wichtig ist nur das die VM drauf läuft und die notwendigen Pakete installiert sind. Anderes Beispiel ein Dienst der auf einer Serverfarm läuft. Soll jetzt eine Maschine wegen wartungsarbeiten abgeschaltet werden, müssen dort alle laufende aufrtäge auf andere Maschinenen Vershoben werden. In java lieses sich das so realisiern, das die Aufträge sich selber einen neuen server suchen und dann selber umziehen.

ok, das ist sicherlich ein Argument. Hier sollte man eine VM verwenden. Aber das sind für mich eher "exotische" Fälle (genauso wie Applets). Meine Desktop-Anwendungen müssen nicht durch Server wandern...

Termite schrieb:

auserdem bringen VMs noch andere nette sachen mit wie z.B. garbageCollector, eine ReflectionApi und eine intigrirte Lib Schnitstelle ( zumindest in java)

Das ist für mich kein Argument für eine VM. Sowas könnte man auch in native Sprachen realisieren. z.B. gibt es GC-Bibliotheken für C++. Bei Reflection werden z.B. im Java-Bytecode einfach zusätzliche Informationen zu Typen und Funktionen hinterlegt. Sowas könnte man auch im native code machen.

@all das soll hier keine JAVA vs. dotNet vs C++ Diskussion seien!

Termite schrieb:

es gibt z.B. Anwendungsfälle wo man das gut gebrauchen kann. z.B. bei "Wandernden Agenten" das sind Programme die von Server zu Server hüpfen können um dort z.B. recherche Arbeiten zu erledigen. Sowas in C++ zu erledigen setzt voraus, das alle server das gleiche OS und ähnliche HW haben. Bei java /.Net ist es egal ob auf der kiste nun Windows läuft, AIX,
Solaris oder Linux. Wichtig ist nur das die VM drauf läuft und die notwendigen Pakete installiert sind. Anderes Beispiel ein Dienst der auf einer Serverfarm läuft. Soll jetzt eine Maschine wegen wartungsarbeiten abgeschaltet werden, müssen dort alle laufende aufrtäge auf andere Maschinenen Vershoben werden. In java lieses sich das so realisiern, das die Aufträge sich selber einen neuen server suchen und dann selber umziehen.

Sowas machte man früher mit Perl.

Ich sehe den Vorteil einer VM auch eher aus Marketinggründen. Es gibt bestimmt Studien die belegen, daß die Entwicklung mit Hilfe einer VM einfacher und schneller ist. Gründe sind dafür GC, keine Speicherüberläufe, daraus resultieren weniger Wartungsarbeiten und kürzere Test- Entwicklungsphasen.

Dazu kommt, daß C++ bei den Führungskräften in dem Ruf steht schwer zu sein und Java/C# leichter zu sein. Der Manager sieht das wie folgt: Es geht schneller, es läuft auf vielen Plattformen(wenn auch für ihn egal), geringere Kosten und vorallem Zukunftssicherheit. Microsoft wird sicherlich in Zukunft sehr viel über die C# VM machen.

Ich finde die Gründe für nicht IT-Spezies doch sehr überragend.

mathik

[quote="BWL-Manager"]

Termite schrieb:

Es gibt bestimmt Studien die belegen, daß die Entwicklung mit Hilfe einer VM einfacher und schneller ist. Gründe sind dafür GC, keine Speicherüberläufe, daraus resultieren weniger Wartungsarbeiten und kürzere Test- Entwicklungsphasen.

Es bestreitet denke ich niemand, dass durch GC und Schutz vor Buffer-Overflows die Programmierung deutlich einfacher ist. Aber für sowas braucht man keine VM!
Wieso wird JAVA nicht in native Code kompiliert?

Erklär das mal unserer Geschäftsführung, oder einem anderen WI/BWL'er

Artchi

Termite schrieb:

auserdem bringen VMs noch andere nette sachen mit wie z.B. garbageCollector, eine ReflectionApi und eine intigrirte Lib Schnitstelle ( zumindest in java)

GCs haben doch nichts mit VMs zu tun. GCs sind eine reine Implementierungssache. Wenn z.B. Windows keinen GC anbietet, kann das eine VM "besorgen". Aber genausogut könnte auch Windows oder ein C++ Compiler sowas mitliefern. Bufferoverflow-Schutz z.B. kann ich in meinem VC++7.1 Compiler aktivieren! Hat aber mit C++ an sich nicht viel zu tun, dann macht das halt die Runtime. Reflections könnte man auch in C++ machen, auch ohne VM. Ich kann immerhin in C++ schon mit typename den Klassennamen als String erhalten. D.h. diese Reflection-Information (ich nenn das jetzt mal so) ist schon in der Runtime drin. Kann man aber auch abschalten. Nur ist halt in C++ nicht der Reflectionumfang definiert, aber es gibt im C++ Commitee einen Vorschlag für umfassendes Reflection - trotzdem wird C++0x keine VM verlangen.

net 0

frenki schrieb:

Du brauchst sowieso alle Plattformen, für die du dein Programm rausgibst. Oder willst du mir erzählen, das du ein Programm, das du meinetwegen in Java unter Linux entwickelt hast einfach so für Windows freigibst, ohne es jemals getesetet zu haben?

ich kenn jemand der hat 'ne ziemlich fette anwendung in java unter windoofs gecodet. mit allem schnickschnack wie datenbankanbindung an'ne db2, client-zu-client kommunikation, client-server über's internet usw. bei der inbetriebnahme unter linux musste nur _eine_ programmzeile geändert werden (irgendwas mit der gui sah nicht so schick aus). ich schätze mal so easy geht portieren nur mit java

Termite

Hi

Nativ compiler für java gibts doch.

Java und .Net haben zumindest für BWL er den Vorteil, das da die sachen wie GC, Reflaction, GUI, Netzwer, ... bereits bestandteil der sprache sind. Andersrum müsste man sich das ja alles zukaufen oder seber entwickeln. Stichpunkt kosten und fehler.

Auserdem haben diese sprachen Marketingtechnische vorteile. Wenn jemand frägt ob man auch linux einsetzen könnte kann er antworten "kein problem wir setzen auf java. das läuft auf allen gängigen platformen."

Arber mir stellt sich gertade die Frage "Compile once, run anyware" hat ja mit java seine berechtigung. Die java vom gibts ja von sun für einige platformen.

Nur bei .Net frag ich mich was da eine VM Sinnmacht. Die gibts ja von MS ja nur für ihre eigenen Betriebsysteme. (Mono mal nicht betrachtet da nicht von MS) Oder ist das MS neue schnittstelle zum System? und sie haben das nur als VM entwickelt, damit die Leute sich drann gewöhnen können, wenn im nachfolger von longhorn z.B nur noch diese schnitstelle zur verfügung steht.

gruss

- Ich kann prozessorspezifisch optimieren.
- Compile once, run anywhere gewinnt heute an Bedeutung durch verschiedene Prozessorarchitekturen. Überlegt mal:
IA64, x86_64 und x86 mal Windows, Linux gibt schon mal 6 verschiedene Kombinationen.
- Sicherheit: Ich kann ein und das selbe Programm mit verschiedenen Sicherheitseinstellungen laufen lassen, ohne es dauernd überwachen zu müssen. Ich muss nicht bei jeder Anforderung nach einem Socket-Handle prüfen, ob das Programm das darf. Stattdessen start ich das Programm mit "no sockets!" und der JIT-Compiler pflanzt dann im native Code überall SecurityExceptions rein.
- Ich kann Code flexibler gestalten. Klassen dynamisch zur Laufzeit hinzuladen. Runtime-Reflection. Das sind Dinge, die immer mehr an Bedeutung gewinnen. Diese Flexibilität krieg ich ohne JIT-Compilierung fast nicht hin.

Artchi

Termite schrieb:

Nur bei .Net frag ich mich was da eine VM Sinnmacht. Die gibts ja von MS ja nur für ihre eigenen Betriebsysteme. (Mono mal nicht betrachtet da nicht von MS) Oder ist das MS neue schnittstelle zum System? und sie haben das nur als VM entwickelt, damit die Leute sich drann gewöhnen können, wenn im nachfolger von longhorn z.B nur noch diese schnitstelle zur verfügung steht.

Hem, du hast dich eben gerade unglaubwürdig gemacht. Warum muß die .NET VM von MS kommen? Das will mir nicht in mein Gehirn rein. C# und das .NET Baseframework sind in der ECMA zertifiziert: ein freier Standard, und somit kann und SOLL nicht nur MS die VM und das Framework auf anderen Plattformen implementieren. Ist also wie mit C++: jeder darf .NET implementieren. (nur WindowsForms und ein paar andere .NET-Teile sind nicht in der ECMA)

Bei Java ist das nicht so. Darfs nur deine JavaVM auch JavaVM nennen, wenn du ordentlich Kohle an SUN abgedrückt hast.

interpreter

BWL-Manager schrieb:

Dazu kommt, daß C++ bei den Führungskräften in dem Ruf steht schwer zu sein und Java/C# leichter zu sein.

Nicht nur bei "Führungskräften"

Artchi schrieb:

Bei Java ist das nicht so. Darfs nur deine JavaVM auch JavaVM nennen, wenn du ordentlich Kohle an SUN abgedrückt hast.

Sicher? Eclipse und JBuilder haben schon mal ihren eigenen Compiler und IBM ne eigene VM (1.4 glaub ich) und ich kann mir nicht so wirklich vorstellen, dass die dafür zahlen mussten.
Letztlich gibt es auch eine öffentlich einsehbare JVM specification.

mathik

Optimizer schrieb:

- Ich kann prozessorspezifisch optimieren.
- Compile once, run anywhere gewinnt heute an Bedeutung durch verschiedene Prozessorarchitekturen. Überlegt mal:
IA64, x86_64 und x86 mal Windows, Linux gibt schon mal 6 verschiedene Kombinationen.

eine VM muss auch für diese Plattformen irgendwie entwickelt und kompiliert werden. Und es gibt ja genug gute Compiler für diese Plattformen. Und wenn ich für den Kunden für jede Plattform eine Binärversion anbiete, was hat man da für einen Nachteil?

Optimizer schrieb:

- Sicherheit: Ich kann ein und das selbe Programm mit verschiedenen Sicherheitseinstellungen laufen lassen, ohne es dauernd überwachen zu müssen. Ich muss nicht bei jeder Anforderung nach einem Socket-Handle prüfen, ob das Programm das darf. Stattdessen start ich das Programm mit "no sockets!" und der JIT-Compiler pflanzt dann im native Code überall SecurityExceptions rein.

ja ok, aber wieso wird dafür dieser Bytecode benötigt? Man könnte doch auch den bereits vorhandenen native code mit SecurityExceptions versehen.

Optimizer schrieb:

- Ich kann Code flexibler gestalten. Klassen dynamisch zur Laufzeit hinzuladen. Runtime-Reflection. Das sind Dinge, die immer mehr an Bedeutung gewinnen. Diese Flexibilität krieg ich ohne JIT-Compilierung fast nicht hin.

Dieser ganzer "Schnickschnack" kann doch auch im native Code gemacht werden.
Klassen, die dynamisch nachgeladen werden sollen, könnten z.B. in dynamische Bibliotheken, wie DLLs, ausgelagert werden. Man bräuchte eine standardisierte Schnittstelle dafür.

@mathik: Warum schwer, wenn es auch einfacher geht? Bei der Entwicklung VM ist jemand anderes verantwortlich. Du sparst jede Menge Zeit und kosten.

Bei den anderen Punkten das selbe. Warum das Rad neu erfinden und viel Geld in die Entwciklung stecken?

Im Buiness läuft es halt immer nach dem selben Schema: Man muss den breakeven zwischen Kosten und Nutzen finden. Genau diesen Punkt haben Sun und MS erkannt. Eine VM erleichtert dem Programmierer die Arbeit ungemein.