Java vs. .NET

Echt? Ich kannte den noch nicht.

BTW: .net und C# & friends kenne ich nicht, aber schlechter als Java kann's eigentlich nicht sein. Immerhin sitzen einige der .net-Nasen bei Microsoft-Research mit einigen wichtigen Haskell-Entwicklern quasi auf dem gleichen Flur, da koennte zumindest irgendwann mal so etwas wie ein ordentliches Typsystem auch fuer die "Praxis" bei rauspurzeln (und nicht so ein halbherzige drangeklatschtes Zeugs wie die Generics in Java). Und eine Opensource-Implementierung gibt's mit mono ja auch. Wo also ist das Problem?
 
Die Generics in Java sind wirklich eine herbe Enttäuschung. Ich sehe hier echt keinen Sinn in den ganzen Einschränkungen die da drin stecken.

Mit dem ganzen .NET Kram habe ich auch noch keine Erfahrung. Vielleicht taugt's ja wirklich was ...

obwohl ich mir das nicht wirklich so recht vorstellen kann.
 
War ja nur eine Frage der Zeit, bis es auch hier im Forum landet -.-

soo toll fand ich es übrigens nicht.
 
Die Generics in Java sind wirklich eine herbe Enttäuschung. Ich sehe hier echt keinen Sinn in den ganzen Einschränkungen die da drin stecken.

Anscheinend wollte man Java-Programmierer nicht mit fortgeschrittlichen Konzepten verwirren. :rolleyes:
Praktischerweise brauchte man für die halbgare Generics-Lösung auch die JVM nicht anfassen...
Unterm Strich bleibt leider außer etwas Typsicherheit und schönerer Syntax kaum etwas übrig.

Mit dem ganzen .NET Kram habe ich auch noch keine Erfahrung. Vielleicht taugt's ja wirklich was ...

C# ist etwas eleganter als Java, die .NET-Bibliotheken zum Ausgleich im Allgemeinen aber nicht so gut wie die Java-Bibliotheken und manchmal nur ein dünner Wrapper um altes Win32-Zeug.
Das Umfeld von .NET ist dafür wesentlich schlechter (Community, Bibliotheken, etc.).

Mit Mono kann ich mich nicht so recht anfreunden, ich kann (für mich) beim besten Willen keine vernünftige Einsatzmöglichkeit erkennen.

Ich warte ja noch sehnsüchtig darauf, dass der Scala-Support für Eclipse und Netbeans wenigstens halbwegs brauchbar wird.

obwohl ich mir das nicht wirklich so recht vorstellen kann.

Microsoft hat unsere Erwartungen nicht enttäuscht, unterm Strich hätte man wesentlich mehr daraus machen können - insbesondere mit den Erfahrungen aus der Java-Welt.
 
Zuletzt bearbeitet:
Echt? Ich kannte den noch nicht.

BTW: .net und C# & friends kenne ich nicht, aber schlechter als Java kann's eigentlich nicht sein. Immerhin sitzen einige der .net-Nasen bei Microsoft-Research mit einigen wichtigen Haskell-Entwicklern quasi auf dem gleichen Flur, da koennte zumindest irgendwann mal so etwas wie ein ordentliches Typsystem auch fuer die "Praxis" bei rauspurzeln (und nicht so ein halbherzige drangeklatschtes Zeugs wie die Generics in Java). Und eine Opensource-Implementierung gibt's mit mono ja auch. Wo also ist das Problem?

Du redest von F# ?
Mit Mono konnte ich mich bisher nie wirklich anfreunden, finde da irgendwie etwas halbgar. Mag aber vielleicht auch an der Dokumentation des Projekts liegen.

Die .net Runtime kann schon paar coole sachen machen, die JVM aber auch ;-) . Sprachlich braucht man sich ja in beiden mittlerweile nichtmehr festzulegen. C# finde ich zwar recht cool, aber wer das nicht mag, der nehme z.B. Ruby oder Python oder $PutFavoriteLanguageHere. Gibt mittlerweile genug sprachen die auf beide VMs portiert worden sind.
Da finde ich es eher spannend wann mal der erste auf die Idee kommt Java auf das .net Framework zu portieren oder gar C# auf die JVM.

Was das Video angeht: alt :P
 
Der Aufwand lohnt nicht. Alles was Swing betrifft ist noch SEHR SEHR langsam. Und ansonsten führt das Teil nur Java-Code aus, was jetzt nichts ist, für was man extra Windows installieren muss ;)
 
Nen Windows brauch ich eh mal wieder ;-) Dann kann ich mal Dinge ausprobieren für die Arbeit. Käme irgendwie blöd wenn ich experimente direkt aufm DC auf Arbeit mache. Aber schön zu wissen. Das werd ich wohl mal weiterverfolgen.
 
Naja, der Hauptunterschied zwischen beiden ist, dass .NET auf Sprachunabhängigkeit und Java auf Plattformunabhängigkeit getrimmt ist.

Würden aber mehr Programme bzw. Bibliotheken in solchen Managed-Sprachen programmiert wären, gäbe es bei weitem nicht so viele Sicherheitslücken. Denn solche Sachen wie Buffer-Overflows sind dort nicht möglich.

Aber solange Programme/Bibliotheken noch in "nativen" Sprachen wie C oder C++ geschrieben werden, haben wir auch noch mit Bufferoverflows und den dazugehörigen Sicherheitslücken zu kämpfen.
 
Naja, der Hauptunterschied zwischen beiden ist, dass .NET auf Sprachunabhängigkeit und Java auf Plattformunabhängigkeit getrimmt ist.

Das mit der Plattformunabhaengigkeit ist doch nur graue Theorie, solange es nur ein oder zwei wirklich benutzbare Implementierungen gibt, die auf einer handvoll Plattformen laufen. Vor zehn Jahren, da gab''s noch JDKs fuer VMS/alpha und HPUX/hppa, wird das heute noch weiterentwickelt? Ich glaube nicht.

Würden aber mehr Programme bzw. Bibliotheken in solchen Managed-Sprachen programmiert wären, gäbe es bei weitem nicht so viele Sicherheitslücken. Denn solche Sachen wie Buffer-Overflows sind dort nicht möglich.

Doch, sind sie. Weil das ganze Geraffel, dass fuer die Laufzeitumgebung benoetigt wird, derart komplex ist, dass ihm die Fehler zu den Ohren rauskommen. Ich habe auch in Java von SIGSEGV ueber SIGILL bis hin zu SIGBUS schon alles erlebt. Das waren alles Bugs in der JVM, meistens im JIT (war aber kein JVM von Sun, um deren Ehre mal zu retten).

Aber solange Programme/Bibliotheken noch in "nativen" Sprachen wie C oder C++ geschrieben werden, haben wir auch noch mit Bufferoverflows und den dazugehörigen Sicherheitslücken zu kämpfen.

Es gibt durchaus kritische Bugs jenseits von Bufferoverflows. Ich sehe wirklich nicht, wo Sprachen mit impliziter Speicherverwaltung irgendwelche Verbesserungen bzgl. Sicherheit bringen.
 
Nicht wirklich. Wenn, dann musst Du die JVM mit .NET verglecihen. Oder Java mti C# (und was sonst noch so rumschwirrt, also Zeugs wie Scala fuer die JVM oder F# fuer .NET).

Ich dachte ja auch an Java als Plattform bzw. an garnichts, weil mich beides kaum interssiert. Ich weiß zwar über deren Stärken und Schwächen einigermaßen beschreibt, hatte allerdings bisher keinen Grund diese zwei Plattformen hür etwas (einigermaßen sinnvolles) zu nutzen.

Aber was ich zu dem Thema sagen könnte behalte ich lieber für mich. Diskussionnen über Programmiersprachen, sind meist deutlich schlimmer als Diskussionen über Betriebssyteme (und Kernels *g*) oder Politik. :ugly:

Ich bleibe einfach meiner kryptographisch sicheren Sprache treu *muss sich schon wieder ducken*

not exp log srand xor s qq qx xor
s x x length uc ord and print chr
ord for qw q join use sub tied qx
xor eval xor print qq q q xor int
eval lc q m cos and print chr ord
for qw y abs ne open tied hex exp
ref y m xor scalar srand print qq
q q xor int eval lc qq y sqrt cos
and print chr ord for qw x printf
each return local x y or print qq
s s and eval q s undef or oct xor
time xor ref print chr int ord lc
foreach qw y hex alarm chdir kill
exec return y s gt sin sort split

P.S:: Das Forum heißt 'Fun' ;)
 
kili schrieb:
Das mit der Plattformunabhaengigkeit ist doch nur graue Theorie, solange es nur ein oder zwei wirklich benutzbare Implementierungen gibt, die auf einer handvoll Plattformen laufen. Vor zehn Jahren, da gab''s noch JDKs fuer VMS/alpha und HPUX/hppa, wird das heute noch weiterentwickelt? Ich glaube nicht.

Natürlich wird das noch Entwickelt. Im 64-Bit Java bereich behauptet HP sogar führend zu sein.
Es gibt aktuelle JVMs für UX,Tru64,VMS und Nonstop von HP.
Wenn ich alleine mal bedenke dass man Java für das meiste SAP Geraffel und auch bei Oracle etc. braucht müssen sie das auch anbieten, sonst würde wohl keiner ihre teuren RISC büchsen kaufen.

kili schrieb:
Doch, sind sie. Weil das ganze Geraffel, dass fuer die Laufzeitumgebung benoetigt wird, derart komplex ist, dass ihm die Fehler zu den Ohren rauskommen. Ich habe auch in Java von SIGSEGV ueber SIGILL bis hin zu SIGBUS schon alles erlebt. Das waren alles Bugs in der JVM, meistens im JIT (war aber kein JVM von Sun, um deren Ehre mal zu retten).

Was die Bibiliotheken angeht kann ich dir nur bedingt recht geben. Nicht jede JVM hat einen Rattenschwanz an Bibliotheken. Es gibt auch JVM Implementierungen die bis auf den zum sich selbst übersetzen nötigten Code komplett in Java implementiert sind.
 
Doch, sind sie. Weil das ganze Geraffel, dass fuer die Laufzeitumgebung benoetigt wird, derart komplex ist, dass ihm die Fehler zu den Ohren rauskommen.

Trivial ist es nicht, aber wir beurteilen die Fehlerfreiheit von Unixen doch auch nicht anhand von SCO UnixWare, oder? :rolleyes:

Ich glaube, Nuke meinte Anwendungen, die innerhalb der JVM laufen, die keine Buffer Overflows haben (von "Java Native Interface" bzw. "Managed Code" unter .NET mal abgesehen), nachdem die Zugriffe auf sämtliche Arrays/Buffer überprüft werden.

Das die JVMs selbst (meist in C++ implementiert) mehr als genügend Buffer Overflows haben/hatten, ist ein anderes Thema...

Es gibt durchaus kritische Bugs jenseits von Bufferoverflows. Ich sehe wirklich nicht, wo Sprachen mit impliziter Speicherverwaltung irgendwelche Verbesserungen bzgl. Sicherheit bringen.

Sofern man von
  • Sandbox-Modell
  • keine Pointer-Arithmetik
  • keine dereferenzierbaren Nullpointer
  • typsicheren Casts
und dem Umstand absieht, es praktisch unmöglich sein dürfte, ein komplexes Real-World-C/C++-Programm ohne Buffer Overflows zu entwickeln.

Natürlich kann man auch in Java/C# noch reichlich Sicherheitslücken einbauen, aber es sind schon einmal erheblich weniger als in anderen Sprachen.
 
Das mit der Plattformunabhaengigkeit ist doch nur graue Theorie, solange es nur ein oder zwei wirklich benutzbare Implementierungen gibt

Mir fallen spontan 4 Stück ein. OpenJDK, Oracle/Sun JDK, Apache Harmony, IBM JDK. Und es gibt noch weitaus mehr (Excelsior, GJC, IKVM.NET). Allesamt benutzbar.


Nein, sind sie nicht. Mit Java oder C# kriegst du so schnell keine Sicherheitslücke fabriziert. Was durch manipulierten ByteCode etc. in der VM Auslösbar ist, ist eine andere Sache. Denn der Java-Compiler ist in C++ geschrieben und erbt somit auch seine Schwächen. Aber das betrifft nur ihn selbst und nicht den Java-Code.

Es gibt durchaus kritische Bugs jenseits von Bufferoverflows. Ich sehe wirklich nicht, wo Sprachen mit impliziter Speicherverwaltung irgendwelche Verbesserungen bzgl. Sicherheit bringen.

ca. 95% aller Sicherheitslücken sind Buffer-Overflows, die durch manipulierte Daten (z.B. ein PDF, oder ein Video) ausgelöst/genutzt werden. Mit einer Managed-Sprache geht das einfach nicht. Punkt aus. Die VM würde mit IndexOutOfBounds o.ä. einfach das Programm beenden und gut ist. Das würde die Sicherheit ENORM verbessern.
 
Zuletzt bearbeitet:
Nein, sind sie nicht. Mit Java oder C# kriegst du so schnell keine Sicherheitslücke fabriziert.
[citation needed]

Denn der Java-Compiler ist in C++ geschrieben [...]
Der Java-Übersetzer des OpenJDK ist in Java geschrieben (was auch seine unerträgliche Startzeit erklärt). Anders sähe es bei der HotSpot JVM aus. Die ist in C++ geschrieben.

ca. 95% aller Sicherheitslücken sind Buffer-Overflows, [...]
95% aller Statistiken werden spontan frei erfunden.

die durch manipulierte Daten (z.B. ein PDF, oder ein Video) ausgelöst/genutzt werden. Mit einer Managed-Sprache geht das einfach nicht. Punkt aus. Die VM würde mit IndexOutOfBounds o.ä. einfach das Programm beenden und gut ist. Das würde die Sicherheit ENORM verbessern.
Es gibt genügend andere Angriffsvektoren, nur sind die schlicht noch nicht so populär, z.B. logische Fehler bei der Implementierung oder gar Spezifikation von Sicherheitsabfragen oder arbeiten mit veralteten Daten (entspricht etwa use-after-free in Sprachen, die explizites Freigeben von Speicher erlauben: eigentlich will man nicht mehr mit einem Datum Arbeiten, aber irgendwer hat immer noch einen Zeiger[1] darauf).
Die Einstellung "Es kann nichts passieren, ich benutze schließlich eine sichere Sprache." ist eine gefährliche Illusion - es handelt sich weiterhin um Möchtergern-Turingmaschinen.

[1] Auch wenn es in Java-Neusprech Referenz genannt wird.


Edith:
Gerade gab es bei FreeBSD ein SA (Security Advisory), das ein Sicherheitsproblem beschreibt, das nichts mit einem Pufferüberlauf zu tun hat: http://security.freebsd.org/advisories/FreeBSD-SA-10:07.mbuf.asc. Ein Flag, das besagt, dass der Inhalt eines Puffers nicht geändert werden darf, wird an einer Stelle nicht kopiert. Dies hat zur Folge, dass jemand, der es eigentlich nicht dürfte, den Inhalt des Puffers ändern kann. Somit kann man Dateien verändern, auf die man eigentlich nur Lesezugriff hat.
 
Zuletzt bearbeitet:
Es gibt genügend andere Angriffsvektoren, nur sind die schlicht noch nicht so populär, z.B. logische Fehler bei der Implementierung oder gar Spezifikation von Sicherheitsabfragen oder arbeiten mit veralteten Daten (entspricht etwa use-after-free in Sprachen, die explizites Freigeben von Speicher erlauben: eigentlich will man nicht mehr mit einem Datum Arbeiten, aber irgendwer hat immer noch einen Zeiger[1] darauf).

Das ist doch aber kein Argument dafür, dass eine Sprache, die Buffer Overflows von vornerein vermeidet nicht schon vieles verhindert. Buffer Overflows sind einfach sehr häufige Sicherheitslücken. Ob jetzt 90 Prozent oder 20 Prozent ist doch im Prinzip egal. Wenn man sie einfach verhindern kann sollte man dies tun.

Ich will damit aber nicht sagen, dass das ein totschlag Argument für Java ist ;) Wenn z.B. c++ für den speziellen Einsatz besser ist sollte man auch dabei bleiben.
 
Zuletzt bearbeitet:
Zurück
Oben