Original von below

Original von Amin Negm-Awad
Leuzte

Java-Programm -> Java-Compiler -> Zwischencode -> virtuelle Maschine -> nativer Code
Objective-C-Programm -> Clang -> Zwischencode -> LLVM -> nativer Code

Wo war gleich der Unterschied?

Bei Java muss eine kompatible VM zur Laufzeit auf dem System vorhanden sein.

Bei Objective-C muss diese VM zur Laufzeit nicht mehr vorhanden sein.

Stichwort: Rückwärtskompatiblität

Für mich in der Praxis schon ein grosser Unterschied.

Alex

Abgesehen davon, dass das kein Unterschied der Sprache ist, kann man doch wohl auch Java unmittelbar in nativen Code übersetzen. Bitte verwechsele nicht erneut Objective-C-RTE und Java-RTE einerseits und LLVM Java-VM andererseits. Die erstemuss bei beiden vorhanden sein, das zweite bei keinem.

Original von Amin Negm-Awad

Original von Lucas de Vil

Original von Amin Negm-Awad
Java-Programm -> Java-Compiler -> Zwischencode -> virtuelle Maschine -> nativer Code
Objective-C-Programm -> Clang -> Zwischencode -> LLVM -> nativer Code

Wo war gleich der Unterschied?

So wie ich die Sache sehe, sind Clang -> Zwischenchode -> LLVM bei Objective-C optional.

Was willst du damit sagen?

a) Es hängt von der Sprache ab, in welchen Code sie übersetzt wird?
b) Es gibt keine nativen Compiler für Java?
c) Du hast etwas im Auge?

Ich schwanke noch zwischen b) und c).
Zumindest kenne ich keinen nativen Compiler, der aus Javacode ein nativ laufendes Progrämmchen zaubert. Jedenfalls keines, welches ohne irgend eine zusätzliche Java Runtime (JRE, Tomcat) auskommt. Objective-C Progrämmchen laufen auch nativ auf Rechnern, denen es an einer zusätzlichen Objective-C RTE fehlt.

Na, ich werd mal flink nen Spiegel suchen gehen.

Original von Amin Negm-AwadAbgesehen davon, dass das kein Unterschied der Sprache ist, kann man doch wohl auch Java unmittelbar in nativen Code übersetzen. Bitte verwechsele nicht erneut Objective-C-RTE und Java-RTE einerseits und LLVM Java-VM andererseits. Die erstemuss bei beiden vorhanden sein, das zweite bei keinem.

So, ich glaube jetzt haben wir uns verstanden

Als nicht-Java Entwickler habe ich einfach die Native-Compiler bei Java vergessen. Aber es ist doch richtig, dass für zum Beispiel Java Browser Applets normalerweise Bytecode ausgeliefert wird?

Und -- Implementierungsdetail hin oder her -- ich fand es schon wichtig zu wissen, wie LLVM für Objective-C jetzt im Moment tatsächlich und konkret verwendet wird.

Und kann ich da für den Laien zusammenfassen:

Java: Üblicherweise als Bytecode ausgeliefert -> VM zur Laufzeit notwendig

Objective-C: Wird als Maschinencode ausgeliefert (wenn man keine verrückten Experimente mit LLVM im Keller macht), keine VM zur Laufzeit nötig.

Ja?

Alex

Original von below

Original von Amin Negm-AwadAbgesehen davon, dass das kein Unterschied der Sprache ist, kann man doch wohl auch Java unmittelbar in nativen Code übersetzen. Bitte verwechsele nicht erneut Objective-C-RTE und Java-RTE einerseits und LLVM Java-VM andererseits. Die erstemuss bei beiden vorhanden sein, das zweite bei keinem.

So, ich glaube jetzt haben wir uns verstanden

Als nicht-Java Entwickler habe ich einfach die Native-Compiler bei Java vergessen. Aber es ist doch richtig, dass für zum Beispiel Java Browser Applets normalerweise Bytecode ausgeliefert wird?

Und -- Implementierungsdetail hin oder her -- ich fand es schon wichtig zu wissen, wie LLVM für Objective-C jetzt im Moment tatsächlich und konkret verwendet wird.

Und kann ich da für den Laien zusammenfassen:

Java: Üblicherweise als Bytecode ausgeliefert -> VM zur Laufzeit notwendig

Objective-C: Wird als Maschinencode ausgeliefert (wenn man keine verrückten Experimente mit LLVM im Keller macht), keine VM zur Laufzeit nötig.

Ja?

Alex

Ja, üblich ist das. Ich kann bloß nicht sehen,

a) was das mit deinen bisherigen Beiträgen zu tun hat und
b) wieso das einen Sprachunterschied darstellen soll.

Wenn er auf die Frage, was der Unterschied zwischen Java und Objective-C sei, antwortet, dass Java üblicherweise in virtuellem Code ausgeliefert wird, Objective-C üblicherweise in nativem Code, dann sollte er schon mal die Wiederholungsrunde einplanen.

Einen praktischen Unterschied kann ich übrigens immer noch nicht erkennen.

Original von Lucas de Vil

Original von Amin Negm-Awad

Original von Lucas de Vil

Original von Amin Negm-Awad
Java-Programm -> Java-Compiler -> Zwischencode -> virtuelle Maschine -> nativer Code
Objective-C-Programm -> Clang -> Zwischencode -> LLVM -> nativer Code

Wo war gleich der Unterschied?

So wie ich die Sache sehe, sind Clang -> Zwischenchode -> LLVM bei Objective-C optional.

Was willst du damit sagen?

a) Es hängt von der Sprache ab, in welchen Code sie übersetzt wird?
b) Es gibt keine nativen Compiler für Java?
c) Du hast etwas im Auge?

Ich schwanke noch zwischen b) und c).

Schade, a) hätte den Vorteil der Einfachheit gehabt.

Original von Lucas de Vil
Zumindest kenne ich keinen nativen Compiler, der aus Javacode ein nativ laufendes Progrämmchen zaubert.

Hotspot-Optimierung?

Original von Lucas de Vil
Jedenfalls keines, welches ohne irgend eine zusätzliche Java Runtime (JRE, Tomcat) auskommt. Objective-C Progrämmchen laufen auch nativ auf Rechnern, denen es an einer zusätzlichen Objective-C RTE fehlt.

Das glaubst du hoffentlich nicht wirklich.

Kein aus einem Objective-C-Programm erzeugter Code läuft ohne RTE.

Du scheinst erneut virtuelle Maschine mit Laufzeitumgebung zu verwechseln.

Also noch einmal:
Beides lässt sich in virtuellen Zwischencode übersetzen. Bei beidem muss dann wenig überraschend eine virtuelle Maschine vorhanden sein, die das ausführt. Wie auch immer.

Beide benötigen unabhängig davon, in welchem Code es vorliegt, noch zusätzliche ein RTE.

Na, ich werd mal flink nen Spiegel suchen gehen.

Besser ist das. Am Ende entzündet es sich noch.

Ich bin ratlos

Original von kressevadder
Ein wesentlicher Unterschied ist wohl auch, das Java Programme in Java Bytecode übersetzt werden, der dann in einem "Abstraction Layer" auf der Zielarchitektur ausgeführt wird. Sowas wie ein emulierter Standardprozessor.

ObjC wird direkt in Maschinencode der Zielplattform übersetzt.

Klare Aussage, will der jemand widersprechen?

Original von mattik
Die JVM ist ja grundsätzlich unabhängig von Java. Theoretisch ist die OBJC-Runtime auch unabhängig von Objective-C, aber so richtig sinnreich ist das nicht

Kann man so sehen.

Dann kam

Original von Amin Negm-Awad
Na ja, auch für Objective-C existieren Clang und LLVM. Die virtuelle Maschine würde ich auch eher mit LLVM vergleichen denn mit dem RTE. Und da kommt man ja auch nicht "drunter".

Was hat jetzt Clang/LLVM mit der JVM bzw. Runtime zu tun? Das ist mir immer noch nicht klar? Genausoviel wie GCC, weil dieser auch Bytecode erzeugt?
Oder ist der Punkt, dass beide "VM" im Namen haben?

Original von Amin Negm-Awad
Dynamic-Typing
Late-Binding

Late-Binding hat Java auch.

@raegtime: Wenn zwei Programmiersprachen verglichen werden sollten, würde ich das zuerst auf der Sprachebene machen. Aus Sicht von Obj-C ist das Dynamic-Typing, Kategorien. Java ist strenger typisiert als Objective-C.

Wenn Du einzelne Punkte nennst, solltest Du immer auch ein Beispiel parat haben, an dem der Unterschied greifbar wird. Außerdem solltest Du Dich nicht zu religiösen Debatten hinreißen lassen

Original von zermelo
Ich bin ratlos

Original von kressevadder
Ein wesentlicher Unterschied ist wohl auch, das Java Programme in Java Bytecode übersetzt werden, der dann in einem "Abstraction Layer" auf der Zielarchitektur ausgeführt wird. Sowas wie ein emulierter Standardprozessor.

ObjC wird direkt in Maschinencode der Zielplattform übersetzt.

Klare Aussage, will der jemand widersprechen?

Original von mattik
Die JVM ist ja grundsätzlich unabhängig von Java. Theoretisch ist die OBJC-Runtime auch unabhängig von Objective-C, aber so richtig sinnreich ist das nicht

Kann man so sehen.

Dann kam

Original von Amin Negm-Awad
Na ja, auch für Objective-C existieren Clang und LLVM. Die virtuelle Maschine würde ich auch eher mit LLVM vergleichen denn mit dem RTE. Und da kommt man ja auch nicht "drunter".

Was hat jetzt Clang/LLVM mit der JVM bzw. Runtime zu tun? Das ist mir immer noch nicht klar? Genausoviel wie GCC, weil dieser auch Bytecode erzeugt?
Oder ist der Punkt, dass beide "VM" im Namen haben?

Nein, der Punkt ist der, dass du Sourcen beider Sprachen in virtuellen Zwischencode übersetzen und ausliefern kannst. Dann kann das ja irgendwie nicht der Unterschied sein.

Original von macmoonshine

Original von Amin Negm-Awad
Dynamic-Typing
Late-Binding

Late-Binding hat Java auch.

@raegtime: Wenn zwei Programmiersprachen verglichen werden sollten, würde ich das zuerst auf der Sprachebene machen. Aus Sicht von Obj-C ist das Dynamic-Typing, Kategorien. Java ist strenger typisiert als Objective-C.

Das kann Java?

Original von macmoonshine
Wenn Du einzelne Punkte nennst, solltest Du immer auch ein Beispiel parat haben, an dem der Unterschied greifbar wird. Außerdem solltest Du Dich nicht zu religiösen Debatten hinreißen lassen

Ich kann nichts Religöses an der Frage feststellen, ob RTE und VM dasselbe sind. Vor allem: Das hat nun gar nichts mit Java und und Objective-C zu tun, auch wenn das einige wollen.


Und auch, wenn bei manchen gleich die Reflexe losgehen.

Original von Amin Negm-Awad
Das kann Java?

Hmm, das Thema hatten wir vor ein paar Monaten schon mal (OjbC: Messages und Methodcalls

Original von Amin Negm-Awad

Original von macmoonshine
Wenn Du einzelne Punkte nennst, solltest Du immer auch ein Beispiel parat haben, an dem der Unterschied greifbar wird. Außerdem solltest Du Dich nicht zu religiösen Debatten hinreißen lassen

Ich kann nichts Religöses an der Frage feststellen, ob RTE und VM dasselbe sind. Vor allem: Das hat nun gar nichts mit Java und und Objective-C zu tun, auch wenn das einige wollen.

Das habe ich nicht darauf bezogen. Mit religiösen Debatten meinte ich eher sowas wie: Meine Programmiersprache ist besser, schöner und bunter als Deine.

Die Frage nach der Laufzeitumgebung ist eine ganz andere Geschichte. Das ist aus meiner Sicht ein Glatteis, was ich in einer Prüfung meiden würde, wenn ich es beeinflussen könnte.

Original von macmoonshine

Original von Amin Negm-Awad
Das kann Java?

Hmm, das Thema hatten wir vor ein paar Monaten schon mal (OjbC: Messages und Methodcalls

Siehste, meine Vergesslichkeit.

Original von macmoonshine

Original von Amin Negm-Awad

Original von macmoonshine
Wenn Du einzelne Punkte nennst, solltest Du immer auch ein Beispiel parat haben, an dem der Unterschied greifbar wird. Außerdem solltest Du Dich nicht zu religiösen Debatten hinreißen lassen

Ich kann nichts Religöses an der Frage feststellen, ob RTE und VM dasselbe sind. Vor allem: Das hat nun gar nichts mit Java und und Objective-C zu tun, auch wenn das einige wollen.

Das habe ich nicht darauf bezogen. Mit religiösen Debatten meinte ich eher sowas wie: Meine Programmiersprache ist besser, schöner und bunter als Deine.

Die Frage nach der Laufzeitumgebung ist eine ganz andere Geschichte. Das ist aus meiner Sicht ein Glatteis, was ich in einer Prüfung meiden würde, wenn ich es beeinflussen könnte.

Ich nicht, macht es die Sache doch gerade spannend.

BTW und für für das Protokoll:
Objective-C typisiert nicht schwächer, sondern dynamischer. Objective-C ist sogar außerordentlich stark typisiert. Leider werden beide Begriffe häufig durchmengt. Irgendwo in den Untiefen des Internet fand ich mal eine Tabelle mit Felder stark/schwach bzw. statisch/dynamisch typisiert. Für jede Kombination gab es ein Beispiel. Ich habe leider kein Bookmark darauf gesetzt.

Original von Amin Negm-Awad

Original von macmoonshine
Die Frage nach der Laufzeitumgebung ist eine ganz andere Geschichte. Das ist aus meiner Sicht ein Glatteis, was ich in einer Prüfung meiden würde, wenn ich es beeinflussen könnte.

Ich nicht, macht es die Sache doch gerade spannend.

Ein Bleigürtel macht das Schwimmenlernen auch viel spannender
Für Bachelorstudenten, die in einer mündlichen Prüfung ein zusätzlichen Kick brauchen, ist das bestimmt ein super Thema. Danach geht er in die finnische Sauna zum Abkühlen

Original von Amin Negm-Awad
BTW und für für das Protokoll:
Objective-C typisiert nicht schwächer, sondern dynamischer. Objective-C ist sogar außerordentlich stark typisiert. Leider werden beide Begriffe häufig durchmengt. Irgendwo in den Untiefen des Internet fand ich mal eine Tabelle mit Felder stark/schwach bzw. statisch/dynamisch typisiert. Für jede Kombination gab es ein Beispiel. Ich habe leider kein Bookmark darauf gesetzt.

Wenn ich das hier als Definition nehme, hast Du sicherlich recht.

Original von macmoonshine

Original von Amin Negm-Awad

Original von macmoonshine
Die Frage nach der Laufzeitumgebung ist eine ganz andere Geschichte. Das ist aus meiner Sicht ein Glatteis, was ich in einer Prüfung meiden würde, wenn ich es beeinflussen könnte.

Ich nicht, macht es die Sache doch gerade spannend.

Ein Bleigürtel macht das Schwimmenlernen auch viel spannender
Für Bachelorstudenten, die in einer mündlichen Prüfung ein zusätzlichen Kick brauchen, ist das bestimmt ein super Thema. Danach geht er in die finnische Sauna zum Abkühlen

Mit dem Prof? Ist der so etwas wie Schiedsrichterbeobachter?

Original von macmoonshine

Original von Amin Negm-Awad
BTW und für für das Protokoll:
Objective-C typisiert nicht schwächer, sondern dynamischer. Objective-C ist sogar außerordentlich stark typisiert. Leider werden beide Begriffe häufig durchmengt. Irgendwo in den Untiefen des Internet fand ich mal eine Tabelle mit Felder stark/schwach bzw. statisch/dynamisch typisiert. Für jede Kombination gab es ein Beispiel. Ich habe leider kein Bookmark darauf gesetzt.

Wenn ich das hier als Definition nehme, hast Du sicherlich recht.

Na ja, die Unterscheidung ist ja schon üblich. Man kann natürlich argumentieren, dass id, also die Objekt-ID, schwach typisiert ist. Das ist aber etwas schräg und würde etwa für C auch bei void* gelten.

Original von Amin Negm-Awad
Na ja, die Unterscheidung ist ja schon üblich. Man kann natürlich argumentieren, dass id, also die Objekt-ID, schwach typisiert ist. Das ist aber etwas schräg und würde etwa für C auch bei void* gelten.

So in etwa hatte ich das bei meinem Hinweis an raegtime auch im Hinterkopf.

Du kannst sicherlich in Objective-C sehr, sehr krude Dinge mittels Casting machen. Das geht in Java nicht, weil auch zur Laufzeit die Typen überprüft werden.

Original von macmoonshine

Original von Amin Negm-Awad
Na ja, die Unterscheidung ist ja schon üblich. Man kann natürlich argumentieren, dass id, also die Objekt-ID, schwach typisiert ist. Das ist aber etwas schräg und würde etwa für C auch bei void* gelten.

So in etwa hatte ich das bei meinem Hinweis an raegtime auch im Hinterkopf.

Du kannst sicherlich in Objective-C sehr, sehr krude Dinge mittels Casting machen. Das geht in Java nicht, weil auch zur Laufzeit die Typen überprüft werden.

So ist es in Objective-C. Das Dispatching läuft ausschließlich während der Laufzeit. Ein Casting verändert den Programmlauf nicht einen Deut. Es ist schlicht ohne Wirkung.

Original von Amin Negm-Awad

Original von macmoonshine

Original von Amin Negm-Awad
Na ja, die Unterscheidung ist ja schon üblich. Man kann natürlich argumentieren, dass id, also die Objekt-ID, schwach typisiert ist. Das ist aber etwas schräg und würde etwa für C auch bei void* gelten.

So in etwa hatte ich das bei meinem Hinweis an raegtime auch im Hinterkopf.

Du kannst sicherlich in Objective-C sehr, sehr krude Dinge mittels Casting machen. Das geht in Java nicht, weil auch zur Laufzeit die Typen überprüft werden.

So ist es in Objective-C. Das Dispatching läuft ausschließlich während der Laufzeit. Ein Casting verändert den Programmlauf nicht einen Deut. Es ist schlicht ohne Wirkung.

Du bist doch ein Fan von gespaltenen Haaren, oder?

Original von zermelo

Original von Amin Negm-Awad

Original von macmoonshine

Original von Amin Negm-Awad
Na ja, die Unterscheidung ist ja schon üblich. Man kann natürlich argumentieren, dass id, also die Objekt-ID, schwach typisiert ist. Das ist aber etwas schräg und würde etwa für C auch bei void* gelten.

So in etwa hatte ich das bei meinem Hinweis an raegtime auch im Hinterkopf.

Du kannst sicherlich in Objective-C sehr, sehr krude Dinge mittels Casting machen. Das geht in Java nicht, weil auch zur Laufzeit die Typen überprüft werden.

So ist es in Objective-C. Das Dispatching läuft ausschließlich während der Laufzeit. Ein Casting verändert den Programmlauf nicht einen Deut. Es ist schlicht ohne Wirkung.

Du bist doch ein Fan von gespaltenen Haaren, oder?

Quellcode

1. NSObject *obj = ...;
2. char q = (char)obj;
3. NSObject *obj2 = (NSObject*)q;

das wird aber nicht funktionieren!

sprich obj wird nicht auf das gleiche objekt zeigen wie obj2

Original von gritsch

Original von zermelo

Original von Amin Negm-Awad

Original von macmoonshine

Original von Amin Negm-Awad
Na ja, die Unterscheidung ist ja schon üblich. Man kann natürlich argumentieren, dass id, also die Objekt-ID, schwach typisiert ist. Das ist aber etwas schräg und würde etwa für C auch bei void* gelten.

So in etwa hatte ich das bei meinem Hinweis an raegtime auch im Hinterkopf.

Du kannst sicherlich in Objective-C sehr, sehr krude Dinge mittels Casting machen. Das geht in Java nicht, weil auch zur Laufzeit die Typen überprüft werden.

So ist es in Objective-C. Das Dispatching läuft ausschließlich während der Laufzeit. Ein Casting verändert den Programmlauf nicht einen Deut. Es ist schlicht ohne Wirkung.

Du bist doch ein Fan von gespaltenen Haaren, oder?

Quellcode

1. NSObject *obj = ...;
2. char q = (char)obj;
3. NSObject *obj2 = (NSObject*)q;

das wird aber nicht funktionieren!

sprich obj wird nicht auf die gleiche adresse zeigen wie obj2

Original von zermelo

Original von Amin Negm-Awad

Original von macmoonshine

Original von Amin Negm-Awad
Na ja, die Unterscheidung ist ja schon üblich. Man kann natürlich argumentieren, dass id, also die Objekt-ID, schwach typisiert ist. Das ist aber etwas schräg und würde etwa für C auch bei void* gelten.

So in etwa hatte ich das bei meinem Hinweis an raegtime auch im Hinterkopf.

Du kannst sicherlich in Objective-C sehr, sehr krude Dinge mittels Casting machen. Das geht in Java nicht, weil auch zur Laufzeit die Typen überprüft werden.

So ist es in Objective-C. Das Dispatching läuft ausschließlich während der Laufzeit. Ein Casting verändert den Programmlauf nicht einen Deut. Es ist schlicht ohne Wirkung.

Du bist doch ein Fan von gespaltenen Haaren, oder?

Quellcode

1. NSObject *obj = ...;
2. char q = (char)obj;
3. NSObject *obj2 = (NSObject*)q;

verstehe ich nicht. Ich kann in den Zeilen kein Dispatching erkennen. Mein Beitrag lautete:

So ist es in Objective-C. Das Dispatching läuft ausschließlich während der Laufzeit. Ein Casting verändert den Programmlauf nicht einen Deut. Es ist schlicht ohne Wirkung.

Original von below
Und kann ich da für den Laien zusammenfassen:

Java: Üblicherweise als Bytecode ausgeliefert -> VM zur Laufzeit notwendig

Objective-C: Wird als Maschinencode ausgeliefert (wenn man keine verrückten Experimente mit LLVM im Keller macht), keine VM zur Laufzeit nötig.

Ja?

Naja, wenn du es so sehen willst, kannst du Cocoa als VM ansehen, die nötig ist. Und die ist, wie Java, ja bereits installiert. Denn gerade wenn man Sachen wie Grand Central verwendet, benötigt man ja im Hintergrund auch laufende Dienste.

Oder der Garbage-Collector von Objective-C 2.0. Den kompilierst du ja auch nicht mit ein, der muss auch da sein. Den liefert dir ja die Objective-C 2 Runtime mit.

Im Prinzip würde ich schon sagen, dass alles was einen Garbage-Collector hat, schon gar nicht mehr "nativ" sein kann, da immer ein externer Dienst die Anwendung überwacht.

Und bei heutigen Prozessorgeschwindigkeiten ist es mittlerweile total egal, ob die Anwendung von zur Laufzeit von Bytecode in Maschinensprache übersetzt wird, oder direkt in Maschinensprache vorliegt. Meine Versuche mit GCC und LLVM/Clang zeigen genau das. Rein mathematische Sachen sind nur unwesentlich langsamer.

Was VM-Sprachen wie Java oder C# langsamer macht ist eigentlich mehr die recht umfangreiche Sicherheitsprüfung. Jedes Array wird bei jedem Zugriff geprüft, ob der Bereich korrekt ist. Somit verhindert man effektiv Buffer-Overflows (#1 Ursache für Sicherheitslücken).

Auch bleiben bei C# z.B. generische Klassen auch im Bytecode generisch. Da wird nicht wie bei anderen generischen "nativen" Sprachen der ganze Code durchforstet, um dann die konkrete Klasse zu erstellen.