Geschwindigkeit vs. Sicherheit
-
Erfrischend wär mal eine "Deutsch-vs-Französisch-Diskussion" (ich will ja nicht Flamewar sagen), aber ansonsten lerne, bzw. favorisiere ich einfach jene Sprache, die mir Arbeit und in Folge daraus Geld verschafft. Java ist für mich mehr als nur eine Sprache, bzw. für die Klugscheisser unter uns eine Runtime, sondern viel mehr auch sämtliche Tools, Frameworks und Communities, die dahinter stehen. Etwas ideologisch betrachtet ist es für mich momentan einfach der Ursprung der Innovation.
groovemaster schrieb:
Gute Frage. Schon mal aufgefallen, dass solche Sachen meistens von Java Anhängern ins Leben gerufen wird? Man mag ja 'ne Menge guter Sachen an Java finden, eine tolerante Community scheint wohl eher nicht dazu zu gehören.
Ein Troll hat diese Diskussion ins Leben gerufen, kein Java Anhänger. Außerdem habe ich eher den Eindruck, dass Java eher von allen Seiten angegriffen wird (Java - C++, Java - C#, neuerdings auch Java - Groovy, bzw. Java - Ruby, ...).
-
java anhänger schrieb:
Außerdem habe ich eher den Eindruck, dass Java eher von allen Seiten angegriffen wird (Java - C++, Java - C#, neuerdings auch Java - Groovy, bzw. Java - Ruby, ...).
Java vs. Groovy? Soetwas habe ich noch nicht gesehen. Wo gibt es denn solche Diskussionen?
-
java anhänger schrieb:
Java ist für mich mehr als nur eine Sprache, bzw. für die Klugscheisser unter uns eine Runtime, sondern viel mehr auch sämtliche Tools, Frameworks und Communities, die dahinter stehen.
Nicht zu vergessen die Firmen die fröhlich Lüg... äh... Unwahrheiten wie "Plattformunabhängigkeit" propagieren und den Managern ins Ohr legen... Toll gemacht
-
TactX schrieb:
Nicht zu vergessen die Firmen die fröhlich Lüg... äh... Unwahrheiten wie "Plattformunabhängigkeit" propagieren und den Managern ins Ohr legen... Toll gemacht
Mir kommt es immer so vor, als ob die C++ler bei allen möglichen Vorteilen von Java sagen: "Aber da habe ich ein Beispiel, bei dem das nicht so gut klappt. Also ist der ganze Vorteil zu negieren, nicht vorhanden."
Das stimmt natürlich nicht. Die Vorteile, die Java bietet, sind nicht als "absolute Vorteile" zu verstehen, sondern nur relativ im Vergleich zu anderen Sprachen, wie zum Beispiel C++. Ein Negativ-Beispiel macht den Vorteil nicht zu nichte. Was viel mehr zählt, ist die Wirksamkeit des Vorteils im Gesamten. Wenn so ein Vorteil viele Probleme behebt, dann ist es immer noch ein Vorteil, auch wenn er nicht alle Probleme behebt.
Das kann man auf Sicherheit beziehen, das kann man auf Plattformneutralität beziehen und auch noch auf andere Eigenschaften, die Java von deren Befürwortern gerne zugeschrieben werden. Es mag auch Probleme geben, Javaprogramme für verschiedene Plattformen verfügbar zu machen. Diese sind aber viel geringer als die Probleme, die sich einem da beispielsweise mit C++ stellen. ...solange eine entsprechende JRE für die entsprechenden Plattformen existiert.
-
Gregor schrieb:
TactX schrieb:
Nicht zu vergessen die Firmen die fröhlich Lüg... äh... Unwahrheiten wie "Plattformunabhängigkeit" propagieren und den Managern ins Ohr legen... Toll gemacht
Mir kommt es immer so vor, als ob die C++ler bei allen möglichen Vorteilen von Java sagen: "Aber da habe ich ein Beispiel, bei dem das nicht so gut klappt. Also ist der ganze Vorteil zu negieren, nicht vorhanden."
Es geht darum, dass einfach falsche Begriffe benutzt werden. Da gibt es kein "bißchen falsch", "ziemlich falsch" oder "total falsch". Plattformunabhängigkeit ist eine Lüge. Sie wird auch nicht wahrer wenn man sie "Plattformneutralität" nennt.
PS: So, ich gehe jetzt mal Eclipse auf meinem Handy starten...
PPS: Ich bin kein C++ler. Tut hier aber nichts zur Sache.
-
TactX schrieb:
Es geht darum, dass einfach falsche Begriffe benutzt werden. Da gibt es kein "bißchen falsch", "ziemlich falsch" oder "total falsch". Plattformunabhängigkeit ist eine Lüge. Sie wird auch nicht wahrer wenn man sie "Plattformneutralität" nennt.
PS: So, ich gehe jetzt mal Eclipse auf meinem Handy starten...
Musst aber ein gut ausgerüstetes handy haben. Wenn jetzt Doom 3 auf meinem Rechner nicht läuft heißt das also, dass bei mir nix was in C/C++ geschrieben wurde läuft
-
TactX schrieb:
Es geht darum, dass einfach falsche Begriffe benutzt werden. Da gibt es kein "bißchen falsch", "ziemlich falsch" oder "total falsch". Plattformunabhängigkeit ist eine Lüge. Sie wird auch nicht wahrer wenn man sie "Plattformneutralität" nennt.
Du hast da halt bestimmte Begriffsvorstellungen und andere Leute haben andere Begriffsvorstellungen. "Plattformunabhängigkeit" sehe ich zum Beispiel immer als Gegensatz zur "Portierbarkeit". Javaprogramme werden nicht auf andere Plattformen portiert. Wenn es da eine entsprechende JRE gibt, dann laufen sie da halt. Ich kann als Nutzer das Javaprogramm auf die neue Plattform mitnehmen. Beim Portieren spielt hingegen der Entwickler eine deutlich wichtigere Rolle.
-
Gregor schrieb:
Es mag auch Probleme geben, Javaprogramme für verschiedene Plattformen verfügbar zu machen. Diese sind aber viel geringer als die Probleme, die sich einem da beispielsweise mit C++ stellen. ...solange eine JVM für die entsprechenden Plattformen existiert.
Inwiefern sind denn die Probleme "viel geringer"?
-
Gregor schrieb:
TactX schrieb:
Es geht darum, dass einfach falsche Begriffe benutzt werden. Da gibt es kein "bißchen falsch", "ziemlich falsch" oder "total falsch". Plattformunabhängigkeit ist eine Lüge. Sie wird auch nicht wahrer wenn man sie "Plattformneutralität" nennt.
Du hast da halt bestimmte Begriffsvorstellungen und andere Leute haben andere Begriffsvorstellungen. "Plattformunabhängigkeit" sehe ich zum Beispiel immer als Gegensatz zur "Portierbarkeit". Javaprogramme werden nicht auf andere Plattformen portiert. Wenn es da eine entsprechende JRE gibt, dann laufen sie da halt. Ich kann als Nutzer das Javaprogramm auf die neue Plattform mitnehmen. Beim Portieren spielt hingegen der Entwickler eine deutlich wichtigere Rolle.
Deswegenn ist Java selbst auch ne Platform *g*
-
finix schrieb:
Inwiefern sind denn die Probleme "viel geringer"?
Oh, lass uns doch mal gucken, was da auf den C++-Entwickler zukommt:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1014628.html
Der Rest der Arbeit läuft so ähnlich ab, wie als wenn man eine Library wrappt – denn etwas anderes tut man ja nicht. Das Schöne daran ist, dass man gleich ein OO-Interface über diese Funktionen legen kann. Da dies aber viel Arbeit ist, ist es oft sinnvoll etwas nur "on demand" zu wrappen (das heißt nur dann, wenn man es wirklich braucht). Stlsoft stellt dafür eine gute Anlaufstelle dar.
Wenn man für zwei oder mehr Plattformen entwickelt, wird man an verschiedenen Stellen ein Problem verschieden lösen müssen, auch wenn die Bibliotheken alle plattformunabhängig sind (wir leben ja leider nicht in einer perfekten Welt). Dann ist es wichtig, den Code nicht durch viele #ifdefs unleserlich zu machen. Eine gute Lösung hierbei ist es, für jede Plattform eine eigene Source Datei anzulegen. Dadurch hat man zwar mehr Code zu warten und man muss etwaige Bugfixes auf andere Plattformen übertragen, aber man erkauft sich dafür leichter zu lesenden Code. Denn bei vielen #ifdefs kann man leicht den Überblick verlieren, und was wohl am schlimmsten ist: auf eine neue Plattform Portieren kann unnötig kompliziert werden (weil wir schon wieder an 100.000 einzelnen Stellen den Code ändern müssen).
Um die Transparenz zu wahren, kann man Proxy-Dateien verwenden. Man erstellt pro Plattform einen eigenen Verzeichnisbaum (zum Beispiel code/programm/win32, code/programm/linux, ...) und legt an der zentralen Stelle (bei uns zum Beispiel code/programm) eine Proxy-Datei ab. Diese inkludiert lediglich die richtige Plattformdatei. Dank des Präprozessors kann man hier recht simpel #ifdefs machen, um die richtige Plattform auszuwählen. Der Clientcode bekommt davon nichts mit.
...usw.
Bei Java sähe das so aus: "Du musst darauf achten, dass Du nicht künstlich irgendwelche Plattformabhängigkeiten in den Code einbaust."
Das Problem dreht sich also komplett um.
-
TactX schrieb:
PS: So, ich gehe jetzt mal Eclipse auf meinem Handy starten...
Wenn Du wenigstens wissen würdest, wie Eclipse - im speziellen SWT - funktioniert, dann hättest Du damit sogar eine ansatzweise sinnvolle Kritik in Sachen Plattformunabhängigkeit anbringen können. Aber so wars ja wohl ein Schuss in den Ofen.
-
byto schrieb:
TactX schrieb:
PS: So, ich gehe jetzt mal Eclipse auf meinem Handy starten...
Wenn Du wenigstens wissen würdest, wie Eclipse - im speziellen SWT - funktioniert, dann hättest Du damit sogar eine ansatzweise sinnvolle Kritik in Sachen Plattformunabhängigkeit anbringen können. Aber so wars ja wohl ein Schuss in den Ofen.
Ich weiss, dass ich Eclipse nicht auf meinem Handy starten kann. Warum das so ist ist doch total nebensächlich.
-
Gregor schrieb:
finix schrieb:
Inwiefern sind denn die Probleme "viel geringer"?
Oh, lass uns doch mal gucken, was da auf den C++-Entwickler zukommt:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1014628.html
[SNIP]
...usw.
Bei Java sähe das so aus: "Du musst darauf achten, dass Du nicht künstlich irgendwelche Plattformabhängigkeiten in den Code einbaust."
Das Problem dreht sich also komplett um.
Um. Ja.
Soll ich jetzt die JNI-Dokumentation zitieren um zu zeigen was auf den Java-Entwickler so alles zukommt? ( )Was meinst du eigentlich mit diesem ominösen "usw"? Was, außer dem wrappen von plattformspezifischem Code, wenn überhaupt (Stichwort: Libraries), kommt denn noch alles auf den C++ Entwickler zu?
-
finix schrieb:
Um. Ja.
Soll ich jetzt die JNI-Dokumentation zitieren um zu zeigen was auf den Java-Entwickler so alles zukommt? ( )Oh man. Du willst mir bei einem "Java ist plattformunabhängig" vorhalten, dass man auch mit Java fremden Code nutzen kann, der in anderen Programmiersprachen geschrieben ist? Das ist echt kreativ!
finix schrieb:
Was meinst du eigentlich mit diesem ominösen "usw"? Was, außer dem wrappen von plattformspezifischem Code, wenn überhaupt (Stichwort: Libraries), kommt denn noch alles auf den C++ Entwickler zu?
mit "usw." meinte ich, dass der Artikel von Shade noch deutlich länger ist. Ich habe ihn nicht ganz gelesen. Weiß nicht, was da noch kommt.
-
Lasst mich mal die Diskussion zusammen fassen.
Also was wir hier haben:
* Java hat Gegenüber C++ den Vorteil, das Index-Probleme nicht erlaubt sind
* C++ kann man so programmieren, das Index-Probleme nicht erlaubt sind
* Java hat Sicherheitsprobleme in seinen Werkzeugen
* Java hat irgend einen Sicherheits-Manager, der Java-Programmen spezielle Verbote auflegen kann (wenn er nicht gerade eine Sicherheitslücke hat) und das soll Java gegenüber C++-Programmen sicherer machen
* Jedes beliebige Programm (sowohl C++, als auch Java) kann man in einer VM betreiben um sich vor Schadhaften verhalten zu schützenGut. Das kann man ja auch wunderbar als Ende der Diskussion nehmen.
Mein Fazit: Es wurde nicht gezeigt, das Java mehr Sicherheit bietet.
-
Gregor schrieb:
finix schrieb:
Um. Ja.
Soll ich jetzt die JNI-Dokumentation zitieren um zu zeigen was auf den Java-Entwickler so alles zukommt? ( )Oh man. Du willst mir bei einem "Java ist plattformunabhängig" vorhalten, dass man auch mit Java fremden Code nutzen kann, der in anderen Programmiersprachen geschrieben ist? Das ist echt kreativ!
Genau, ebenso kreativ wie zu übersehen das C/C++ an sich auch plattformunabhängig sind und dass es für den überwiegenden Teil der Aufgaben die man im Normalfall so bewältigen möchte plattformunabhängige Bibliotheken gibt.
Gregor schrieb:
finix schrieb:
Was meinst du eigentlich mit diesem ominösen "usw"? Was, außer dem wrappen von plattformspezifischem Code, wenn überhaupt (Stichwort: Libraries), kommt denn noch alles auf den C++ Entwickler zu?
mit "usw." meinte ich, dass der Artikel von Shade noch deutlich länger ist. Ich habe ihn nicht ganz gelesen. Weiß nicht, was da noch kommt.
Ach so. Tschuldigung, ich dachte du wüsstest worüber du sprichst und hättest selber Argumente.
(Nicht dass wir uns missverstehen, Java ist toll, und bei z.B. Applets hat es durchaus einen gewaltigen Vorteil, aber viel weiter geht's auch nicht in Sachen Plattformunabhängigkeit.)
-
BTW: Ich möchte nochmal betonen, dass mögliche Sicherheitslücken in der JVM keinerlei Auswirkungen haben, wenn man dem Programm vertraut. Was ich damit meine, ist folgendes: Wenn man einen Browser in Java schreibt, ist es praktisch unmöglich, dass irgendwer durch eine manipulierte Homepage oder so Code einschleust, der dann ausgeführt wird. Die Sicherheitslücken der JVM betreffen nur Programme, die man direkt auf der JVM laufen lässt, denen man nicht vertraut. Solche Programme könnten rein theoretisch so eine Sicherheitslücke ausnutzen, um vielleicht aus der Sandbox auszubrechen. Für einen "Java-Browser" ist das aber irrelevant. Man kann in den Browser ansich keinen Code einschleusen, da dieser ja in Java geschrieben wäre und entsprechend keine Buffer overruns usw. vorkommen können. Entsprechend kann man von außen auch nicht zur JVM durchdringen und deren Sicherheitslücken ausnutzen. Naja, ok: Wenn man dem Browser vertraut, lässt man ihn ja eh nicht in einer Sandbox laufen, was aber auch nicht nötig ist. Wie schon gesagt: Soetwas wie diese JPG-Sicherheitslücke wäre in Java nicht möglich.
-
Mein Fazit: Es gibt Leute, die sind anderen Sprachen/ Technologien gegenüber aufgeschlossen. Und dann gibt es Leute, die sind es nicht.
In diesem Sinne...
-
rüdiger schrieb:
C++ kann man so programmieren, das Index-Probleme nicht erlaubt sind
Wobei das irgendwie zu wenig Leute machen, denn Sicherheitslücken in C++ Programmen sind real. Und das spricht dafür, dass es gut ist, einen entsprechenden Zwang für solche Index-Checks von der Sprache her vorzugeben.
-
Ich weiss jetzt nicht, ob das C++ ist, aber das letzte prominente Opfer, dass mir jetzt spontan einfällt, ist das hier: