Vielleicht ist hier was für dich dabei.

Chris

Dynamic-Typing
Late-Binding

Original von raegtime- Java hat nen autom. Garbage Collector > Obj. C nur optional ... dadurch schneller

Als Prüfer würde ich fragen: Warum ist es dadurch schneller?

Original von raegtime- anderer Syntax z.B. Dot notation nur fuer Zugriff auf Eigenschaften bei Obj. C
naja und halt ne menge unterschiede in der Namensgebung wie z.B. Protokoll ist in etwa das selbe wie ein Interface in Java...

Als Prüfer würde ich sagen: "Naja, das hätten sie jetzt auch sagen können, wenn ich sie nach den Unterschieden von Objective-C und Cobol gefragt hätte..."

Da ist es wichtiger, auf die GEMEINSAMKEITEN hinzuweisen. Java und Objective-C sind beides Single Inheritance Sprachen, daher haben sie Konstrukte wie Protocol bzw. Interface.

Ich persönlich halte hier Dinge wie das Laufzeitverhalten für wichtiger, dazu gehört beispielsweise Introspektion

Leider kenne ich Java nicht genug, um mehr zu sagen

Alex

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.

Aber alles in allem ist die Frage Quatsch. Warum muss man Java mit ObjC vergleichen? Warum nicht mit Flash/Actionscript? Und was ist überhaupt der Unterschied zwischen Cocoa und Ajax?

Übrigens wurde Cocoa, besser gesagt Next, zu alter Väter Zeiten in Zusammenarbeit mit Sun entwickelt. Ziel war es, eine API zu bauen, die möglichst gut auf die verschiedensten Plattformen portiert werden kann. Dann hat man bei Sun Java entdeckt. Da ging es dann darum, etwas zu haben, was leicht für das Zielsystem compiliert werden kann, oder eben immer den selben Code in einem Bytecode Prozessor auszuführen, welcher dann für die jeweilige Zielplattform vorhanden sein muss.

Sun hat sich gegen Next und für Java entschieden. Auf den Servern von Sun gibt es aber irgendwo im Keller noch eine Next Implementation als OpenSource.

Tja, wer falsche Grundsatzentscheidungen trifft, wird von Oracle geschluckt

Original von raegtime
"Nennen Sie wesentliche Unterschiede und Gemeinsamkeiten von JAVA und Objective C" ...

Meine erste Reaktion wäre die Gegenfrage, ob sich die Frage auf die Sprache oder die Laufzeitumgebung bezieht. 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.

Wenn man mal von der Liste der Sprach- und Laufzeitfeatures absieht, die es entweder auf der einen oder der anderen Seite gibt (wie below schon sagte, da gibt's eine ganze Menge Gemeinsamkeiten) ist für mich der wichtigste Unterschied, dass ObjC nach unten transparent ist - man kommst problemlos runter auf C und, wenn man will, direkt auf den Prozessor. Java ist nach unten opak. Man kommt mit Pure-Java-Mitteln nicht unter die Abstraktionsebene der VM. Bewerten würde ich das nicht. Es sind zwei verschiedene Paradigmen.

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".

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".

Wir schweifen etwas ab, aber erzeugt LLVM für Objective-C denn Bytecode? Ich dachte, LLVM wäre auf OS X nicht für die RunTime zuständig.

Alex

Original von below

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".

Wir schweifen etwas ab, aber erzeugt LLVM für Objective-C denn Bytecode?

Nein, LLVM führt den aus – wie die virtuelle Maschine bei Java: " Die virtuelle Maschine würde ich auch eher mit LLVM vergleichen"

Erzeugt wird der Bytecode von Clang.

Ich dachte, LLVM wäre auf OS X nicht für die RunTime zuständig.

Alex

Das ist richtig. Deshalb schrieb ich ja auch, dass ich die virtuelle Maschine von Java nicht mit dem RTE vergleichen würde.

Original von Amin Negm-Awad

Original von below

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".

Wir schweifen etwas ab, aber erzeugt LLVM für Objective-C denn Bytecode?

Nein, LLVM führt den aus – wie die virtuelle Maschine bei Java: " Die virtuelle Maschine würde ich auch eher mit LLVM vergleichen"

Erzeugt wird der Bytecode von Clang.

Ich dachte, LLVM wäre auf OS X nicht für die RunTime zuständig.

Alex

Das ist richtig. Deshalb schrieb ich ja auch, dass ich die virtuelle Maschine von Java nicht mit dem RTE vergleichen würde.

Ich dachte immer, zumindest unter MacOS X wird LLVM nur als Compiler verwendet. Der Bytecode der zwischendurch entsteht, wird dann in Maschienencode uebersetzt, ohne grossartig was anderes damit anzustellen. Also eigentlich genauso wie GCC, nur etwas andere Herangehensweise (GCC erzeugt auch eine intermediaeren Bytecode..)
Das einzige, was LLVM auf dem Mac tatsaechlich ausfuehrt, sind gewisse Teile von OpenGL/GLSL/OpenCL, dachte ich zumindest immer. Kann mich da jemand aufklaeren?

Original von zermelo

Original von Amin Negm-Awad

Original von below

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".

Wir schweifen etwas ab, aber erzeugt LLVM für Objective-C denn Bytecode?

Nein, LLVM führt den aus – wie die virtuelle Maschine bei Java: " Die virtuelle Maschine würde ich auch eher mit LLVM vergleichen"

Erzeugt wird der Bytecode von Clang.

Ich dachte, LLVM wäre auf OS X nicht für die RunTime zuständig.

Alex

Das ist richtig. Deshalb schrieb ich ja auch, dass ich die virtuelle Maschine von Java nicht mit dem RTE vergleichen würde.

Ich dachte immer, zumindest unter MacOS X wird LLVM nur als Compiler verwendet. Der Bytecode der zwischendurch entsteht, wird dann in Maschienencode uebersetzt, ohne grossartig was anderes damit anzustellen. Also eigentlich genauso wie GCC, nur etwas andere Herangehensweise (GCC erzeugt auch eine intermediaeren Bytecode..)

Das verstehe ich nicht. Wo siehst du den Widerspruch?

Der Bytecode wird vom Clang erzeugt.

Das einzige, was LLVM auf dem Mac tatsaechlich ausfuehrt, sind gewisse Teile von OpenGL/GLSL/OpenCL, dachte ich zumindest immer. Kann mich da jemand aufklaeren?

Es ist doch ein Implementierungsdeteil des LLVM, ob der JIT-C oder Interpretierung vornimmt. Das weißt du bei der virtuellen Maschine von Java auch nicht. Meines Wissens erzeugen die meisten doch auch inzwischen nativen Code. Aber wie gesagt: Ohnehin Implementierungsdetail.

Original von zermeloIch dachte immer, zumindest unter MacOS X wird LLVM nur als Compiler verwendet. Der Bytecode der zwischendurch entsteht, wird dann in Maschienencode uebersetzt, ohne grossartig was anderes damit anzustellen. Also eigentlich genauso wie GCC, nur etwas andere Herangehensweise (GCC erzeugt auch eine intermediaeren Bytecode..)
Das einzige, was LLVM auf dem Mac tatsaechlich ausfuehrt, sind gewisse Teile von OpenGL/GLSL/OpenCL, dachte ich zumindest immer. Kann mich da jemand aufklaeren?

Ja, genau das war auch mein Kenntnisstand.

Amin, kannst Du uns schlaumachen?

Alex

Original von below

Original von zermeloIch dachte immer, zumindest unter MacOS X wird LLVM nur als Compiler verwendet. Der Bytecode der zwischendurch entsteht, wird dann in Maschienencode uebersetzt, ohne grossartig was anderes damit anzustellen. Also eigentlich genauso wie GCC, nur etwas andere Herangehensweise (GCC erzeugt auch eine intermediaeren Bytecode..)
Das einzige, was LLVM auf dem Mac tatsaechlich ausfuehrt, sind gewisse Teile von OpenGL/GLSL/OpenCL, dachte ich zumindest immer. Kann mich da jemand aufklaeren?

Ja, genau das war auch mein Kenntnisstand.

Amin, kannst Du uns schlaumachen?

Alex

Siehe oben

Original von Amin Negm-AwadSiehe oben

Jaja, Post überschnitten.

Also für mich ist es schon ein Unterschied, ob wirklich fertiger Maschinencode rauskommt, oder ob da dann noch eine Zwischenschicht greift.

Wenn ich das richtig verstanden habe, dann kann LLVM ja auch eine Ausgabe zur JIT-C machen. Oder eben nicht.

Aber vielleicht sollten wir einen anderen Thread dafür aufmachen.

Alex

Original von Amin Negm-Awad

Original von zermelo

Original von Amin Negm-Awad

Original von below

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".

Wir schweifen etwas ab, aber erzeugt LLVM für Objective-C denn Bytecode?

Nein, LLVM führt den aus – wie die virtuelle Maschine bei Java: " Die virtuelle Maschine würde ich auch eher mit LLVM vergleichen"

Erzeugt wird der Bytecode von Clang.

Ich dachte, LLVM wäre auf OS X nicht für die RunTime zuständig.

Alex

Das ist richtig. Deshalb schrieb ich ja auch, dass ich die virtuelle Maschine von Java nicht mit dem RTE vergleichen würde.

Ich dachte immer, zumindest unter MacOS X wird LLVM nur als Compiler verwendet. Der Bytecode der zwischendurch entsteht, wird dann in Maschienencode uebersetzt, ohne grossartig was anderes damit anzustellen. Also eigentlich genauso wie GCC, nur etwas andere Herangehensweise (GCC erzeugt auch eine intermediaeren Bytecode..)

Das verstehe ich nicht. Wo siehst du den Widerspruch?

Der Bytecode wird vom Clang erzeugt.

Das einzige, was LLVM auf dem Mac tatsaechlich ausfuehrt, sind gewisse Teile von OpenGL/GLSL/OpenCL, dachte ich zumindest immer. Kann mich da jemand aufklaeren?

Es ist doch ein Implementierungsdeteil des LLVM, ob der JIT-C oder Interpretierung vornimmt. Das weißt du bei der virtuellen Maschine von Java auch nicht. Meines Wissens erzeugen die meisten doch auch inzwischen nativen Code. Aber wie gesagt: Ohnehin Implementierungsdetail.

Ja sicherlich. Ich habe nicht verstanden, wie LLVM ueberhaupt ins Gespraech gekommen ist, weil man eben genauso argumentieren koennte, dass GCC Bytecode erzeugt - Ein Parallele zur JVM sehe ich da aber nur schwer.
Nichtsdestotroz bleibt halt die JVM eine VM - ob sie nun zur Steigerung der Geschwindigkeit nativen Code erzeugt ist, wie Du schon gesagt hast, Implementierungssache. IIRC gibt es auch Hardware, auf der mehr oder minder nativ Java-Bytecode laeuft. Dem gegenueber sehe ich Objective-C stehen als eine Sprache, die primaer in Maschienen-Code einer konkreten Hardware uebersetzt wird. Das zwischendrin eine VM stehen kann, ist in meinen Augen unerheblich. Du kannst ja gerne ein GCC/LLVM Backend schreiben, was Objective-C in Java-Bytecode compiliert, das ist aber halt nicht uebliche Praxis.

Die Java-Runtime bzw. JVM findet, so wie ich das sehe, in Objective-C keine direkte Entsprechung. Jedoch koennte man sagen, in Java kuemmert sich die JVM um den Aufruf von Methoden, Reflektion etc., was auf der Gegenseite von der Objective-C Runtime uebernommen wird. Aber ob das ueberhaupt jemanden interessiert?

Leuzte

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

Wo war gleich der Unterschied?

Original von zermelo

Original von Amin Negm-Awad

Original von zermelo

Original von Amin Negm-Awad

Original von below

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".

Wir schweifen etwas ab, aber erzeugt LLVM für Objective-C denn Bytecode?

Nein, LLVM führt den aus – wie die virtuelle Maschine bei Java: " Die virtuelle Maschine würde ich auch eher mit LLVM vergleichen"

Erzeugt wird der Bytecode von Clang.

Ich dachte, LLVM wäre auf OS X nicht für die RunTime zuständig.

Alex

Das ist richtig. Deshalb schrieb ich ja auch, dass ich die virtuelle Maschine von Java nicht mit dem RTE vergleichen würde.

Ich dachte immer, zumindest unter MacOS X wird LLVM nur als Compiler verwendet. Der Bytecode der zwischendurch entsteht, wird dann in Maschienencode uebersetzt, ohne grossartig was anderes damit anzustellen. Also eigentlich genauso wie GCC, nur etwas andere Herangehensweise (GCC erzeugt auch eine intermediaeren Bytecode..)

Das verstehe ich nicht. Wo siehst du den Widerspruch?

Der Bytecode wird vom Clang erzeugt.

Das einzige, was LLVM auf dem Mac tatsaechlich ausfuehrt, sind gewisse Teile von OpenGL/GLSL/OpenCL, dachte ich zumindest immer. Kann mich da jemand aufklaeren?

Es ist doch ein Implementierungsdeteil des LLVM, ob der JIT-C oder Interpretierung vornimmt. Das weißt du bei der virtuellen Maschine von Java auch nicht. Meines Wissens erzeugen die meisten doch auch inzwischen nativen Code. Aber wie gesagt: Ohnehin Implementierungsdetail.

Ja sicherlich. Ich habe nicht verstanden, wie LLVM ueberhaupt ins Gespraech gekommen ist, weil man eben genauso argumentieren koennte, dass GCC Bytecode erzeugt - Ein Parallele zur JVM sehe ich da aber nur schwer.
Nichtsdestotroz bleibt halt die JVM eine VM - ob sie nun zur Steigerung der Geschwindigkeit nativen Code erzeugt ist, wie Du schon gesagt hast, Implementierungssache. IIRC gibt es auch Hardware, auf der mehr oder minder nativ Java-Bytecode laeuft. Dem gegenueber sehe ich Objective-C stehen als eine Sprache, die primaer in Maschienen-Code einer konkreten Hardware uebersetzt wird. Das zwischendrin eine VM stehen kann, ist in meinen Augen unerheblich. Du kannst ja gerne ein GCC/LLVM Backend schreiben, was Objective-C in Java-Bytecode compiliert, das ist aber halt nicht uebliche Praxis.

Die Java-Runtime bzw. JVM findet, so wie ich das sehe, in Objective-C keine direkte Entsprechung. Jedoch koennte man sagen, in Java kuemmert sich die JVM um den Aufruf von Methoden, Reflektion etc., was auf der Gegenseite von der Objective-C Runtime uebernommen wird. Aber ob das ueberhaupt jemanden interessiert?

Ich muss den nicht schreiben, weil es den Compiler gibt.

Unerheblich ist, ob das Bytecode oder LLVM-Code ist. Es ist virtueller Code. Hü wie Hott.

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.

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

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?