Plattformunabhängigkeit?

Dieses Thema beschäftigt mich nun schon einige Tage und ich würde darum bitten, dass nur die erfahrenen Leute antworten.

Als einer der großen Vorteile von Java wird immer die Plattformunabhängigkeit genannt. Doch ist diese wirklich gegeben bzw. ist sie bei anderen Sprachen nicht gegeben?
Java läuft in einer virtuellen Maschine, auf jeder Plattform wo diese VM läuft, läuft auch ein Java Programm.
.Net kennen die Meisten wohl nur unter Windows. Läuft allerdings auch unter Linux/Mac OS ( Common Language Infrastructure ).
C/C++ läuft bis auf wenige Ausnahmen, wie z.b. die Win(dows)API, problemlos unter Linux und ich denke auch unter Mac OS. Und dies sogar ohne extra VM.

Die Java-VM ist in der Regel auf jedem Rechner installiert und somit gibt es dort keine Probleme. Die verschiedenen CLI-Implementationen sind dies meines Wissens nicht unbedingt. Aber das .Net-Framework sollte normalerweise auf jedem Windows Rechner vorhanden sein. Unter Linux/Mac OS lässt sich Mono installieren.

Java benötigt die VM, .Net die CLI-Implementation. Ist das ein unterschied in der Plattformunabhängigkeit? In meinen Augen nicht. Beide laufen ohne weiteres nicht. Jede Sprache ist mit der entsprechenden VM bzw. Implementation 'Plattformunabhängig'.

Ich würde nun gern eure Meinung dazu hören und bitte bezieht dies nur auf Hardware mit entsprechender Leistung. Das man auf einem kleinen Microcontroller mit wenigen KB Speicherplatz kein Java/.Net zum laufen kriegt ist mir klar :p

xNopex wird sich zwar dagegen äußern (gibt ne nette Diskussion auf meinem Profil ;O), aber ich sehe es ähnlich wie du und Stroustrup.
Ist für micht nicht plattformunabhängig, denn man brauch die VM.

Zwar mag man dagegen argumentieren, dass ja Scriptsprachen auch als crossplattform angesehen werden und die brauchen auch eine VM bzw. einen Interpreter, aber genau das sehe ich auch anders.
Denn diese Sprache benötigen einen Interpreter bzw. eine VM, sie sind also abhängig von den Gegebenheiten auf dem System, wie kommt man darauf, sowas plattformunabhängig zu nennen?

C++ "läuft" nicht nur auf Win/Unix/Mac, es läuft auf jedem Prozessor. Man muss halt nur für den entsprechenden Befehlssatz den richtigen Compiler haben, aber die Sprache selbst ist mit jedem System kompatibel; Java nur mit der JVM, die auch benötigt wird, um sie auf anderen System ausführen zu können.

Wenn man für die entsprechende Systeme einen entsprechenden Compiler hat, kann man den java sourcecode auch nativ kompilieren, dann hat man das gleiche Resultat und die gleichen Probleme wie in C++. Nur ist es halt einfach wesentlich bequemer den Crap einmal zu kompilieren und ihn dann via einer VM laufen zu lassen, als 10.0000mal für jede Kackplattform einzeln.

Das verstehe ich unter Plattformunabhängigkeit. Einmal kompilieren -> läuft auf allen Systemen. Dabei ist es doch unerheblich, ob eine VM/ein Interpreter benötigt wird oder nicht. Man kann sich jetzt natürlich streiten inwiefern die VM jetzt eine eigenständige plattform darstellt oder nicht. Aber allein die tatsache, dass die VM i.d.R. nicht eigenständig läuft lässt mich zu dem Schluss kommen, dass es keine eigenständige Plattform ist, sondern die notwendige Schnittstelle zwischen Bteriebssystem und Anwendung.

Dann kannst du natürlich auch eine C++ VM schreiben, wie es ja teilweise (Wine) auch manchmal gemacht wird.

Also sind entweder beide Sprachen crossplattform oder keine, aber Java nicht mehr als C++.

Solange der Herr Stroustrup (oder wer auch immer dafür zuständig ist) sich nicht bemüht eine standardmäßige C++ VM (+entsprechenden Compiler) für diverse Plattformen zu entwickeln, ist Java plattformunabhängiger als C++.
Sollte da aber nachgebessert werden, gebe ich dir recht, aber sicher gibt es da wieder "Konsens-Probleme" ;O

c/c++ ist der nachteil, dass du für jedes betriebssystem neu kompilieren musst.
unter java gibt es ein programm, dass dann in der vm läuft, die immer/überall gleich aussieht für das programm.
Dass die vm dann betriebssystemspezifisch ist, ist dem programm schließlich egal.
Die java standard-lib bietet außerdem schon eine menge an funktionen, die auf jedem unterstütztem betriebssystem funktionieren, während die verschiedenen APIs für den c/c++ programmierer teilweise nur unzureichend dokumentiert sind.

Stimme xNopex zu, plattformunabhängigkeit ist gegeben sobald 1x kompilieren -> läuft überall.
(natürlich muss die nötige infrastruktur aka VM gegeben und ausreichend verbreitet sein.)

Ist ne Grundsatzdiskussion. Für mich ist es plattformunabhängig, wenn es von keinen äußeren Bedingungen abhängt :>

Ich sehe das auch wie MrSm!th. Recht haben natürlich alle mehr oder weniger.
Java läuft, solange die VM läuft. So eine VM kann aber für jede Sprache geschrieben werden. Ich sehe das neu kompilieren bei C/C++ (und vergleichbaren Sprachen) nicht als sonderlich störend an. Es gibt nur 3 große Betriebssysteme(selbstverständlich auf normale Rechner bezogen).

Quote:

Für mich ist es plattformunabhängig, wenn es von keinen äußeren Bedingungen abhängt :>

Wie soll das technisch umsetzbar sein? Nach eurer Definition kann es keine Plattformaunabhängigkeit geben, weil die Plattformen eben verschieden sind, weil es sonst keine verschiedenen Plattformen wären.. Man müsste dann auf einer großen Konferenz es schon zum neuen BlaBlub-Standard erklären, dass eine gewisse VM auf jeder Plattform verfügbar sein soll, dann wäre es keine äußere Bedingung mehr.
Aber wie realistisch ist das denn, wenn sie sich nichtmal auf eine Standard-GUI einigen können :rolleyes: Und dann müsstet ihr auch eingestehen, dass eine VM keine eigenständige Plattform an sich ist, weil sonst würde es formal ja immer noch nicht stimmen. Eure Argumente sind für mich nicht stimmig und logisch.

Quote:

Ich sehe das neu kompilieren bei C/C++ (und vergleichbaren Sprachen) nicht als sonderlich störend an

Mitunter empfinde ich es als störend dauernd den Quellcode abzuändern weil gewissen Compilerspezifische Zeilen mit dem Compiler einer anderen Plattform nicht kompilierbar sind. Sicher kriegt man das mit entsprechenden Präprozessoranweisungen o.Ä. in den Griff aber es ist einfach umständlich und auch umständlicher zu warten. V.a. wenn das Programm auf vielen Plattformen laufen soll. Es ständig bei jeder Änderung für alle Systeme neu zu kompilieren ist v.a. bei großen Projekten zeitintensiv und nervt.

Und dass man für jede Plattform das Programm einzeln kompilieren muss ist sicher keine vollständige Plattformunabhängigkeit.. Das führt vollkommen an der Idee vorbei.

Ich argumentiere nicht, das ist meine Meinung.

Für mich zählt es als plattformunabhängig, wenn der Source Code so auf jedem OS läuft und man ihn nur für den entsprechenden Befehlssatz neu compilen muss.
Bei Java trifft das im nativen Modus zwar auch zu, allerdings verstehe ich nicht, was der ganze Witz dann soll, wenn man nichtmal die VM nutzt kann man gleich in was vernünftigem Programmieren; die VM ist soziemlich der einzige Vorteil gegenüber anderen OO Sprachen oder C++.
Und die VM sehe ich halt nicht als crossplattform an, denn man muss zwar nichtmal neukompilieren, dafür muss diese VM dann aber auf dem anderen System vorhanden sein.

Sonst könnte man ja genau so sagen, wie WinAPI ist crossplattform, da es ja auch Wine für Linux gibt.

Quote:

Mitunter empfinde ich es als störend dauernd den Quellcode abzuändern weil gewissen Compilerspezifische Zeilen mit dem Compiler einer anderen Plattform nicht kompilierbar sind. Sicher kriegt man das mit entsprechenden Präprozessoranweisungen o.Ä. in den Griff aber es ist einfach umständlich und auch umständlicher zu warten.

Selbstverständlich gilt das alles nur, wenn man vom C++ Standard ausgeht.
Und den muss jeder C++ Compiler so unterstützen.

Quote:

Und dass man für jede Plattform das Programm einzeln kompilieren muss ist sicher keine vollständige Plattformunabhängigkeit.. Das führt vollkommen an der Idee vorbei

Wenn man nun von einer Art "vollständigen Plattformunabhängigkeit" spricht, also das Neukompilieren jene verfehlt, dann greift imho btw. genau das:

Quote:

Wie soll das technisch umsetzbar sein? Nach eurer Definition kann es keine Plattformaunabhängigkeit geben, weil die Plattformen eben verschieden sind, weil es sonst keine verschiedenen Plattformen wären

Eine VM ist auch nur eine äußere Gegebenheit. Wenn du mein erste Ansicht auf keinen Fall einsehen kannst, versuch es halt mit der ;O Dann gibt es eben keine Plattformunabhängigkeit, denn man ist davon abhängig, dass Sun Java für die Plattform entwickelt.
Java läuft schließlich auch längst nicht auf allen Plattformen.

Und da wären wir wieder bei:

Quote:

Also sind entweder beide Sprachen crossplattform oder keine, aber Java nicht mehr als C++.

Ist halt meine Meinung :>

Quote:

Dann gibt es eben keine Plattformunabhängigkeit, denn man ist davon abhängig, dass Sun Java für die Plattform entwickelt.

So gesehen bist du auch in C++ davon abhängig, dass entsprechende Compiler für die Zielplattform existieren. Also läuft es schlussendlich darauf hinaus:

Keine Sprache ist plattformunabhängig.


Damit mag ich mich nicht anfreunden, aber ist scheinbar Interpretationssache.

Quote:

Bei Java trifft das im nativen Modus zwar auch zu, allerdings verstehe ich nicht, was der ganze Witz dann soll, wenn man nichtmal die VM nutzt kann man gleich in was vernünftigem Programmieren; die VM ist soziemlich der einzige Vorteil gegenüber anderen OO Sprachen oder C++.

Wird halt dann nur schneller ;O Sinnvoll ist es kritische Stellen nativ zu kompilieren und den Rest als Bytecode zu belassen. Geht halt wirklich dann auch DER Vorteil von Java, nämlich die viel diskutierte und unterschiedlich ausgelegte "Plattformunabhängigkeit" verloren.

Naja, aber eine Plattform, für die du keinen Compiler bzw. Assembler hast, für die musst du normalerweise auch nicht entwickeln ;O
Ebenso wird für die JVM ein Compiler für das entsprechende System benötigt.

Ergo

Quote:

Keine Sprache ist plattformunabhängig.

haben wir nen Konsens :>

Oder wir drehen meine Kernaussagen um (dass die Sprache von nichts abhängig sein darf) und sagen, so ziemlich alle (bis auf wirklich an das OS gebundene) Sprachen sind crossplattform, denn im Grunde ist eine Highlevel Sprache dazu da, das System vom Programmierer zu abstrahieren; er sollte sich also nicht mit dem System rumschlagen müssen.

Wenn er also standardkonform programmiert und der reine Code (nicht das Assembly) so auf jeder Plattform ausführbar ist (wenn die entsprechenden äußeren Bedingungen erfüllt sind), dann ist die Sprache crossplattform.

Das würde für C, C++, Java und viele weitere zutreffen.
Für Scriptsprachen wie Batch allerdings nicht, da sie im Grunde nur von Windows angeboten werden.

sprachen wie java oder .net, sind definitiv "allgemein abhängiger" als sprachen wie c++, da sie abhängig sind von einer software (interpreter), welche wieder für jede plattform (übrigens meist in c/c++ :P) extra entwickelt werden muss.

letztendlich kommt es bei der plattformabhängigkeit doch aber auf den grad eben dieser an, welcher durch die kosten der umwandlung für die jeweilige plattform beschrieben wird.

hierfür macht es durchaus sinn, code zunächst in binärcode umzuwandeln, und dann für die jeweiligen plattformen nurnoch einmalig eine software zu entwickeln, welche diesen code verarbeiten kann. auch wenn hierrunter die effizienz etwas leidet, so ist der gewinn durch sinkende portabilitätskosten doch gerade bei großen mengen von code, in der heutigen zeit deutlich wichtiger.

wobei man dazu wieder sagen muss: wie wurde der erste c compiler programmiert? bestimmt nicht in c ;)

meine meinung zum ganzen thema:
java - c/c++ sind alle plattformunabhängig

java: man hat seine vm wo man seinen code für compiled
c/c++: man hat seinen cpu (die in den meisten fällen gleichen instructions verwenden) wo man seinen code für compiled

java funktioniert allerdings auch nicht ohne die vorher in (wahrscheinlich) c++ geschriebene vm ;)

da man nen kernel in c/c++ schreiben kann, ist das meiner meinung nach wirklich plattformunabhängig :p

Was hat die erste Frage mit dem Thema zu tun?

Btw. mal eine OT Frage an die Java Kenner:

Was genau passiert mit der Garbadge Collection, wenn man nativ kompiliert?
Die VM, die jene bereitstellt, fällt dann ja weg. Wird einmal allozierte Speicher dann nicht wieder freigegeben?
Immerhin kann der Compiler zur Compile Time ja noch nicht wissen, wann ein Objekt keine Verweise mehr haben wird, also kann er das schlecht da schon einbauen.

Und ein explizites delete gibt es nicht (aus etwas anderen Gründen einer meiner größten Kritikpunkte an Java).