[JAVA] Wieso finden viele Leute Java einen "Murks"?

zilti

Stammgast
Ich rege mich immer darüber auf, dass in Foren geschrieben wird, Java sei "Schrott", ein "Murks" u.s.w., aber nie werden Gründe angegeben. Wieso sind viele Leute dieser Meinung? Java ist eine klare Programmiersprache und viel sauberer als z.B. C++.
Bitte beginnt nicht, zu flamen oder so - es interessiert mich einfach mal, was es da für Gründe gibt.
 
A

abu

Guest
Ich kenne weder den erwähnten Vorwurf noch kann ich mir plausible Gründe dafür vorstellen. Ich finde Java gut.
 

pagefault

Inaktiv
Zu Java als Programmiersprache kann ich nichts sagen.

Solange ein Programm sauber läuft, seinen Zweck erfüllt und möglichst keine Sicherheitslücken aufweist, ist mir die Programmiersprache, in welcher es geschrieben wurde, ziemlich egal.

Hingegen habe ich einge (leider überwiegend negative) Beobachtungen zu Java-Umgebungen und Java-Anwendungen gemacht:
  • es wäre schön, auf verschiedenen Umgebungen mit demselben vertrauten Programm arbeiten zu können - manchmal gelingt das sogar :)
  • write once - run everywhere klingt zwar gut, stimmt aber nicht immer - obwohl in Java geschrieben, braucht man trotzdem für verschiedene Plattformen verschiedene Ausgaben einer Software
  • der Krieg von Java und "Mava" (Sun vs Microsoft) hat der Plattform sehr geschadet
  • Java Applikationen unter Windows sind spürbar "anders" als native Windows Anwendungen (Kurztasten, Mausrad, drag&drop, Window-Refresh beim Scrollen, Ziehen und vor allem bei Fernsteuerung via VNC / RDP sind verbreitete "Problemzonen")
  • die aktuellen (Intel) Prozessoren sind leider nicht für Java optimiert und Java Anwendungen laufen langsamer als native Anwendungen
  • die erstmalige Initialisierung der JRE kostet viel Zeit und Speicher
  • die Browser-Integration der Sun JRE in Firefox 2.x ist schwerfällig
  • mit Anwendungsprogrammen mitgelieferte JREs lassen sich nur sehr schwer pflegen
  • der Installer der Sun JRE / JDK ist ein "Idiot" und installiert immer nur neue Versionen, lässt aber die alte(n) Version(en) unverändert drauf, obwohl die neue Version ein Superset der alten sein soll
  • Kompatibilitätsgründe scheinen es nicht zu sein, denn auch bei vorhandenen älteren Java Versionen, ist doch immer nur die neuste aktiv (warum also die alten nicht gleich deinstallieren - oder das beim Update zumindest als Option anbieten?)
 

Gaby Salvisberg

Super-Moderator
Liegt es an der JRE?

Hi zilti

Ich code selber nicht und habe eigentlich nichts gegen die eine oder andere Programmiersprache (OK, auch wenn ich mich mit Schaudern an gewisse alte VB-Progis erinnere). Es schreckt mich auch nicht speziell ab, wenn eine Anwendung in Java geschrieben ist.

Was ich öfter mal lese: Java-Applikationen seien nicht besonders performant.

Vielleicht rührt die Kritik auch daher, dass Sun bei der Java-Runtimes-Engine immer wieder mal Mist baut.

Beispiele: Nach einem JRE-Sicherheits-Update (und solche gibt es mehrere jährlich) ist die alte (verwundbare) Version immer noch vorhanden. Das reisst unnötig Löcher ins System.
Und die JRE meldet dauernd Blödsinn: Wenn es tatsächlich ein Update gibt und man via Java-Systemsteuerungs-Element nach diesem sucht, lügt es einem vor, die vorhandene Version sei aktuell. Dafür meldet es umgekehrt via Systray immer wieder mal Updates, obwohl man die topaktuelle JRE bereits besitzt. Solches finde ich aus Anwendersicht schon ziemlich murksmässig. Für solches kann aber weder die Programmiersprache noch eine damit geschriebene Anwendung etwas.

Grüessli
Gaby
 
A

abu

Guest
Hier stimme ich zu, der Updater ist wirklich ein Murks, deshalb habe ich den auch deaktiviert. Und dass alte JRE generell liegen gelassen werden, ist auch irgendwie seltsam.
 

Gaby Salvisberg

Super-Moderator
Hier stimme ich zu, der Updater ist wirklich ein Murks, deshalb habe ich den auch deaktiviert. Und dass alte JRE generell liegen gelassen werden, ist auch irgendwie seltsam.

Einige argumentieren damit, dass sonst ev. ältere Java-Programme nicht mehr laufen. Aber ich gehe davon aus, dass eine JRE eigentlich rückwärtskompatibel sein sollte. Und bei der Installation einer neuen JRE-Version könnte der Installer ja den User einfach mal fragen, ob die alten Versionen entfernt werden sollen.

Gaby
 
A

abu

Guest
Das kann man nachvollziehen. Aber nach meiner Erfahrung bringen Anwendungen, die auf eine bestimmte Version angewiesen sind, diese in abgespeckter Version selbst mit. Diese wird dann lokal unter dem Programmverzeichnis abgelegt. Leider ist auch das irgendwie ein wenig absurd.
 

zilti

Stammgast
Also, man muss doch keine JRE zu seinem Programm mitliefern (Wieso das denn? 97% aller PCs haben Java installiert).
Die Tastenkürzel sowie Drag&Drop muss der Programmierer übrigens selbst festlegen - deshalb die Unterschiede.
Und Stichwort "Write once, run anywhere": Es wird in der Regel genau dasselbe Programm ausgeliefert - Bloss ist für den Normanwender das Programm i.d.R. in eine EXE (oder eine ausführbare Datei des jeweiligen Betriebssystems) verpackt, um es einfacher auszuführen (weil leider einige Entpackprogramme die Jar-Endung auf sich verlinken, und sich dann beim Anwender anstatt die Anwendung das Packprogramm öffnet). Stichwort: WebStart.
Stichwort Updater und Start-Performance: Darüber habe auch ich mich schon geärgert (nur über den Updater). Das Browser-PlugIn lädt allerdings spürbar schneller als das Java beim Starten einer Anwendung - obwohl doch schlussendlich dasselbe dahinter ist. Bezüglich dieser 2 Punkte soll sich mit der neuen Version 1.6.0_10 viel getan haben - ich bin gespannt, wie der Updater in der neuen Version laufen wird, die Start-Performance scheint leicht besser zu sein.
Danke für die bisherigen Beiträge!
 

pagefault

Inaktiv
Bezüglich dieser 2 Punkte soll sich mit der neuen Version 1.6.0_10 viel getan haben - ich bin gespannt, wie der Updater in der neuen Version laufen wird, die Start-Performance scheint leicht besser zu sein.

Ja, ist sie - dass die 1.6.0_10 aber (ungefragt!) einen neuen Windows-Dienst und ein (nicht deinstallierbares) Firefox-Plugin montiert hat, ist mir schon etwas sauer aufgestossen...
 
Java ?

Lieber C++ !

Mir ist Java und C++ viel zu kompliziert.

Sobald ich alleine ein Java Projekt starte [[ Eine Seltenheit ]] verzweifle ich schon nach 5 Minuten.

Java hat komplizierte Abkürzungen genau wie C++ !
Dies ist einer der brutalsten Gründe.

Ausserdem nervt mich das JRE dass man zuerst installieren muss.

Delphi ist einfacher !
 

Stromer92

Stammgast
Java ?

Lieber C++ !

Mir ist Java und C++ viel zu kompliziert.

Sobald ich alleine ein Java Projekt starte [[ Eine Seltenheit ]] verzweifle ich schon nach 5 Minuten.

Java hat komplizierte Abkürzungen genau wie C++ !
Dies ist einer der brutalsten Gründe.

Ausserdem nervt mich das JRE dass man zuerst installieren muss.

Delphi ist einfacher !


Als anfänger mag Delphi ja sehr geeignet sein, doch für komplexere Programme wirst du mit Delphi nicht mehr weit kommen.
 
Ich empfehle allen Anfängern, wie auch fortgeschrittenen Programmierern die Sprache C# unter Microsoft.NET.

Es ist zwar wiederum so, dass etwas zusätzlich installiert werden muss (.NET FX), jedoch bietet das eine riesige Plattform für unendlich viele Sprachen und man kann wirklich alles damit machen. Für die Spieleentwickler gibt es zusätzlich die Möglichkeit mit C# und XNA für die XBOX360 zu programmieren. Bald ist auch Mono.NET soweit und man kann dann schliesslich auch für Linux .NET Programme entwickeln.

.NET kann ich wärmstens empfehlen, es ist auch sicherer als JRE. Des Weiteren braucht das .NET FX auch reichlich weniger Updates.
 

zilti

Stammgast
Bitte nicht mit Halbwahrheiten flamen. .NET hat schon dutzende Updates, und die JRE ist aufgrund der Plattformunabhängigkeit von Natur aus sicherer. Die JRE unterstützt übrigens auch "unendlich viele Sprachen" - nämlich alle, die einen Bytecode-Compiler haben. Aber lassen wir das geflame (ob absichtlich oder nicht) bitte.
 
@ zilti: Sei nicht so empfindlich. Die meisten Updates die .NET bekommt sind Neuerungen der Bibliotheken. Sicherheitslücken werden nicht allzu oft gestopft.

Was die Sprachen angeht, so ist es eher daran abzumessen nach der tatsächlichen Anzahl unterstützter Sprachen. Im Moment und auch in Zukunft liegt hier .NET klar vorne, da schon eine Vielzahl von Programmiersprachen in .NET implementiert wurden.

Hier nur ein paar Beispiele:
PHP, Delphi, Java (J#), Python, Brainfuck, Ruby, Fortran, etc.

Klar ist es nicht gerade fürsprechend, dass .NET nicht ganz plattformunabhängig ist, wie man eigentlich möchte, aber dann wäre das Argument der Plattformunabhängigkeit für Java jedoch auch gegessen. Aber mit Mono.NET sieht das Ganze ohnehin wieder anders aus.


Java hat seine Stärken, aber gegenüber sehe ich in .NET mehr Vorteile als in Java. Dies hat nichts mit geflame zu tun, sondern mit meiner Meinung, und wenn sie dir nicht passt dann ist mir das auch egal.


EDIT: Plattformunabhängig heisst überhaupt nicht, dass die ganze JRE sicherer ist. Das ist völliger Schwachsinn, tut mir leid, aber auch du solltest nicht mit Halbwahrheiten rumposaunen. Plattformunabhängikeit heisst, dass es von der ein und derselben Plattform mehrere Varianten Code gibt. Da die JRE soweit ich weiss für die Einsicht in den Code freigegeben wurde, kann jeder mit ein bischen mehr Ahnung die Plattform knacken. Die Anzahl an Updates und Meldungen über kritische Sicherheitslücken sagen auch nicht wirklich etwas über die ach so tolle Sicherheit der Plattformunabhängigkeit aus.
 
Zuletzt bearbeitet:

pagefault

Inaktiv
.NET hat schon dutzende Updates, ...
Danke :) Ausserdem ist SxS (Side-by-Side) von .NET auch nicht gerade der Weisheit letzter Schluss.

Dass zig Varianten derselben DLL parallel vorgehalten werden, mag ja noch angehen. Aber spätestens bei den Anwendungsdaten, die Versions-spezifisch durchnumeriert in verschiedenen Verzeichnissen liegen, hört der Spass dann definitiv auf!

Nur weil Microsoft mit einer neuen Sub-Version von .NET Version xy niederkommt, dürfen wir händisch nach dem Patch-Day die Konfigurationsdateien umkopieren, weil sie die "fortgeschrittene" Software sonst nicht mehr findet - das grenzt imho, naja - an "Murks"?

Früher hatten wir .DLL - hell - heute sind wir einen Schritt weiter und haben configuration data hell.
 
@ pagefault: Hierbei muss ich dir zustimmen, wobei es ansich nicht ganz so schlimm ist wie man denkt. Als C++ Entwickler hat man es wahrscheinlich immernoch etwas schwerer denke ich mal.
 

zilti

Stammgast
Jah, sorry, aber du weisst gar nicht, was ich diesbezüglich (Flames) schon alles erlebt habe... n halbes Trauma :D
Zur Anzahl Sprachen in der JRE sei dir diese Seite ans Herz gelegt: http://www.is-research.de/info/vmlanguages/
Und noch was zur Plattformunabhängigkeit: Natürlich kann man die einzelnen Plattformen knacken, aber 1. muss der User dem Programm erlauben ausgeführt zu werden (Signaturen) (Ich weiss nicht, wie .NET das handhabt), und 2. kann man das nicht (mehr) über die Java-Sprache erledigen - Da muss man eigentlich im Bytecode rumpfuschen, weil Java selber ja nicht direkt auf die Kischte zugreifen kann (keine Zeiger & normalerweise keine Pufferüberläufe).
So, back to topic.
 
Oben