Diskussion:Java Virtual Machine

Bytecode "parsen"

Kurze Frage: Ist es nicht vielmehr so, dass die JVM Objektcode in Bytecode "umrechnet", damit der Prozessor den Bytecode ausführen kann ?? --DaB. 18:44, 10. Feb 2003 (CET)

Uh, Vorsicht mit den Begriffen. Bytecode ist ein neu erfundener Begriff, er bezeichnet direkt den Code, den die JavaVM ausführt. Objektcode ist IMHO jede binäre zum Linken vorbereitete Form von Code, also auch Bytecode. Zur Frage: Die VM führt den plattformunabhängigen Bytecode aus, dabei kann sie JIT's verwenden, die den Bytecode in den jeweiligen Maschinencode übersetzen. Ich hoffe Dir wurde geholfen. :-) -- Dishayloo 23:13, 2. Jun 2003 (CEST)

propagandakram... der java-bytecode ist NICHT plattformunabhängig! im gegenteil - er läuft ausschliesslich auf java-vms. --217.84.59.38 13:18, 20. Aug. 2008 (CEST)

Quatsch, dann könnte man ja auch argumentieren, dass ein C-Quellcode es auch nicht sei, weil er ja nur auf einem C-Compiler läuft... Das Java-Programm lässt sich auf jeder Maschine und jedem Betriebsystem ausführen, auf dem eine JVM zur Verfügung steht. Und das geht vom ARM-Nettop über alle gebräuchlichen Unixe auf so ziemlich jedem Prozessor, der Windows-Welt bis zum Super-Computing oder 'ner Playstation... --arilou 16:13, 5. Okt. 2010 (CEST)

---

Eine Bemerkung zum "sinnfreien Satz": Wie soll ein Computer denn _irgendetwas_ auswerten, wenn er es nicht parst, zumal wir hier von einem _Interpreter_ sprechen, der Bytecode in Maschinencode umsetzt... Darüber hinaus führte _exakt dieser Parseroverhead_ zur Entwicklung der dynamisch optimierenden Hotspot-Engine, welche Bytecode in Maschinencode umsetzt und somit das wiederholte Parsen des Bytecodes überflüssig machte.

Gruß HbJ

siehe Parser (Informatik) oder http://www.wikipedia.org/wiki/Parser (ausführlicher). Hier wird von Quelltexten, bzw. einer grammatischen Struktur gesprochen. Bytecode hat keine grammatische Struktur, er wird einfach sequentiell abgearbeitet. Ein JPG-Bild wird ja auch nicht geparst. Der Bytecode wird interpretiert oder dekodiert, das stimmt. :-) Das mit dem Geschwindigkeitsnachteil stimmt so nicht einmal, da mit JITs heute die VMs schneller arbeiten als kompilierter Java-Code. Schliesslich war es ein langer Satz mit wenig Substanz. Aus all diesen Gründen habe ich ihn gelöscht, und nur den letzten genannt (Bequemlichkeit). Ist so klarer, was ich meinte? -- Dishayloo 00:28, 3. Jun 2003 (CEST)

Schon klar. Mir ging es um die (Stein)zeit, als der Java-Bytecode noch vollständig und ohne Optimierungen interpretiert wurde (so wie die Token beim seligen Locomotive BASIC) und somit Rechenzeit für das "Verarbeiten" (whatever) des Bytecodes und das Auswerfen des Maschinencodes draufging, was der Hauptapplikation Rechenzeit stahl (Soweit ich weiß, gab es Mitte der 90er einige böse Artikel zur schlechten Performanz verschiedener VMs, was unter anderem diesem Umstand angelastet wurde). Mein Verweis auf Hotspot sowie die modernen JIT-Architekturen (mit dynamischer Optimierung inklusive Profiling und "Einstellen" auf die Stärken und Schwächen des jeweiligen Prozessors!) zeigt wohl, dass ich die modernen Ansätze keinesfalls verurteilt habe. Darüber hinaus muss zumindest der Verifier parsen, weil er mittels seiner Sicherheitsrichtlinien (die man durchaus als Meta-Grammatik sehen könnte) illegalen Code fernhalten muss. Zum Parsen von JPEG empfehle ich LinuxSecurity.
Vielleicht ist der Begriffsgebrauch nicht 100-prozentig korrekt, aber durchaus üblich.
(Mental note to myself: Bin schon wieder dabei, mich umbeliebt zu machen). Sorry ;-)

EDIT: Die Suchworte java bytecode parser ergeben viele schöne Links. Hier einige davon:
Jadcentral C#-based parser for Java bytecode
Sourceforge (Class file reader and parser) Class-Files sind Bytecode, oder?
gcc.gnu.org Bytecode parser fails on 64-bit systems

Gruß HbJ 00:53, 3.Juni 2003 (CEST)

Hmm, da scheint der Begriff doch unterschiedlich verwendet zu werden. Entschuldigung, ich kannte 'parsen' nur für Quelltexte. Tut mir leid. (ô_ô) -- Dishayloo 09:18, 3. Jun 2003 (CEST)

Kein Problem ;-) Es gibt sogar eine (logische?) Erklärung, warum auch Bytecode "geparst" wird: Das Prinzip der Statusmaschine (Hurra, zwei Status: Okay und Fehler). Selbst der Bytecode-Parser muss zwischen legalen und illegalen Codeworten unterscheiden. Außerdem erfolgt ja eine Substitution des Bytecode durch Maschinencode, was nach formalen Ersetzungsregeln geschieht, in die _theoretisch_ sogar die Elimierung redundanter Anweisungen eingeschlossen sein _könnte_ (für händisch erzeugten oder schlecht optimierten Bytecode).
Im Endeffekt stehen wir hier vor dem gleichen Problem wie in der OOP: Gleiche Begriffe für unterschiedliche Sachverhalte (zwei Bücher, drei Terminologien. Argh!).
Ach ja: Frieden! ;-)
HbJ 14:15, 3. Jun 2003 (CEST)

Andere JVMs

Müsste im Artikel nicht auch kurz die JVM von Microsoft und der damit verbundene Streit mit "Sun" erwähnt werden?(nicht signierter Beitrag von 131.246.137.121 (Diskussion) )

Nun, andere JVMs neben der Sun VM kommen im Artikel sowieso viel zu kurz.. bei Siehe Auch gibt's ein größtenteils scheinbar eher zufälliges Sammelsurium von alternativen VMs, aber so richtig bringt's das irgendwie nicht. Ich vermisse zum Beispiel die sich wohl recht gut verkaufende Kertasarie VM (OK, da bin ich wohl vom Lokalpatriotismus beeinflusst Oo), die an der TU Dresden lebt und sich dort ganz gut vermarktet, wie man hört. Hier ist dann sogar noch das Alleinstellungsmerkmal, dass diese VM konkret für Eingebettete Systeme entwickelt wurde und wird. Ja genau, Java in Eingebetteten Systemen. Wenn ihr wieder zu euch kommt könnt ihr ja mal googeln ;) --Schmiddtchen 说 03:08, 27. Sep. 2007 (CEST)

Abschottung der Threads

Dieser Absatz sollte gestrichen werden. Er beginnt gleich mit einer (später widerrufenen) Behauptung, die seit langer Zeit nicht mehr gültig ist, dass Java nämlich Green Threads verwende. Diese zeichnen sich auch mehr dadurch aus, dass sie von der JVM betrieben werden, nicht vom Betriebssystem; und weniger durch ihre "Abschottung".

Genau, wollte das hier auch erwähnen. Greenthreads sind Nachbildungen von Threads innerhalb der Java VM wenn das OS keine Threads kann oder die implementierung unter der Java VM noch nicht erfolgte. Die ersten Javaversionen bildeteten so Threading nach, mittels preemptivem Verhalten, sprich jeder Thread bekam ne Zeitscheibe zugewiesen wo er mal drann kam, wenn er logisch angehalten war hat er trotzdem die entspr. Zeit verbraucht.

Warum diese Abschottung schlecht sein soll, kann in dem Absatz auch nicht überzeugend dargelegt werden. Wer möchte schon Threads, die von außen beliebig beendet werden können - was eine drastische Beeinträchtigung der laufenden Applikation nach sich ziehen würde? Wann immer ein willkürlicher Abbruch eines Threads sinnvoll ist, sollte das die Applikation ausdrücklich ermöglichen.

Der entspr. Teil sollte entfernt werden und hat mit VM sowieso nichts zu tun.

OSGi

Was soll dieser Satz bezüglich OSGi in diesem Artikel? OSGi ist ein Framework, wie es viele andere gibt. Mit der virtuellen Maschine für Java hat es nicht das geringste zu tun. Klingt für mich eher nach Werbung als nach sinnvoller Information. (nicht signierter Beitrag von 84.189.8.46 (Diskussion) )

Stimmt. Ich entferne den Satz. --j ?! 15:34, 8. Jan. 2009 (CET)

Es fehlen noch Informationen zur Lizenz.

Pufferüberlauf-Angriff / Sicherheit

Die Möglichkeit von Pufferüberläufen, und damit (Rücksprung-)Zeiger oder sogar Code zu überschreiben, und wie Java dies bzgl. des Programms in Bytecode verhindert, würd' ich dann doch gerne noch etwas genauer erklärt bekommen... so weit hab' ich mich mit selbigem nämlich noch nicht auseinander gesetzt...

Zumindest wird hier ein direktes Maschinencode-Problem bei C/C++ u.ä. mit einem Bytecode-Problem der JVM verglichen - und selbst wenn man den Bytecode "knackt" und aus der aktuell laufenden Applikation "ausbricht", läuft's ja immernoch in der JVM; ein Java-Bytecode kann schließlich trotzdem nur über die JVM Betriebsystem-Aufrufe absetzen...

Irgendwie hat das was vom Vergleichen von Äpfeln mit Birnen. --arilou 16:29, 5. Okt. 2010 (CEST)

Ist Dalvik wirklich eine Java-VM?

Dalvik führt keinen Java-Bytecode aus sondern ein eigenes Format. Macht alleine die Tatsache, dass man Java-Bytecode in Dalvik-Bytecode konvertieren kann, Dalvik zur Java-VM? Prinzipiell könnte man doch für jede Programmiersprache einen Compiler schreiben, der den entsprechenden Quellcode in Dalvik-Bytecode übersetzt.--Trockennasenaffe 19:24, 9. Feb. 2011 (CET)

Jasmin

Jasmin sollte u.a. in Liste der JMV-Sprachen eingearbeitet werden. (nicht signierter Beitrag von 80.121.63.162 (Diskussion) 17:45, 25. Jul 2011 (CEST))

Abgrenzung JVM von JRE bzw. JVM-Implementationen

Durch eine Forumsdiskussion bin ich auf eine Begriffsungenauigkeit aufmerksam geworden, die auch hier im Artikel nicht sauber getrennt wird: http://www.coderanch.com/t/410895/java/java/JRE

Bei Oracle findet man dann noch diese Definition des JVM-Begriffs: http://docs.oracle.com/javase/7/docs/technotes/guides/index.html

Demnach ist die JVM nur eine abstrakte Definition, wie Bytecode verarbeitet wird. Daher vermutlich auch der Begriff "virtuelle Maschine". Es ist dann an den JRE-Dienstleistern diese abstrakte Definition konkret zu implementieren. Das sind dann die JREs bzw. "JVM-Implementationen", wie z.B. Hotspot. Diese konkreten Laufzeitumgebungen aber nur "JVM" zu nennen, scheint mir dann aber zu unscharf. Der Artikel sollte diese Doppeldeutigkeit bzw. Unschärfe benennen. 212.59.44.4 12:13, 27. Aug. 2013 (CEST)

JVM-Sprachen

Macht es Sinn den Absatz JVM-Sprachen in ein extra Kapitel Liste von JVM-Sprachen auszulagern? Misi DE (Diskussion) 16:15, 25. Jun. 2020 (CEST)