Leonidas hat geschrieben:Das ist IMHO gerade für Desktopapplikationen der schlechteste Weg den man überhaupt nehmen kann.
Der konstante Speicherbedarf ist zugegeben suboptimal, doch wenn er jetzt beliebig wachsen würde (wie z.B. bei Python, Ruby, .NET, usw.), würden sich die Leute wahrscheinlich auch wieder beschweren. Und es macht den GC-Algorithmus einfacher (und damit schneller). Dennoch würde auch ich mir wünschen, es gäbe einen Client-Modus, wo ich Java einfach so viel RAM holt, wie es eben braucht, ohne einen OutOfMemoryError zu werfen, wenn das Betriebssystem noch RAM hat.
Burli hat geschrieben:Von meinen 4GB RAM sind immerhin 40% belegt
Wenn ich 4GB RAM habe, dann will ich auch, dass sie alle belegt sind. Was nützen 60% brach liegender Hauptspeicher? Somit kann ich nicht nachvollziehen, wieso dann ein Eclipse, welches nur einen Teil der benutzen 1.6 GB belegt, irgendwie stört.
Burli hat geschrieben:Eclipse komplett in C++ programmiert wäre doppelt so schnell und würde nur halb so viel Speicher brauchen. Und richtig programmiert wäre es genauso portabel
Das ist eine IMHO unhaltbare weil komplett unbewiesene Behauptung. Als Eclipse vor 8 Jahren noch relativ neu war, habe ich mich recht intensiv mit der Implementierung auseinander gesetzt und da sind mir keine Datenstrukturen aufgefallen, die nun ineffizient oder extra verschwenderisch gewesen wären. Und Java-Objekte verbrauchen (im Gegensatz zu z.B. Python-Objekten) nicht mehr Hauptspeicher als das selbe Objekt in C++, wenn man dort ebenfalls GC einsetzt. Die JVM hat einen Overhead, in dem sie den Bytecode für alle Java-Klassen vorhalten muss und eben selbst auch Platz im RAM verbraucht. Das mögen einige MB sein, doch wenn man in C++ z.B. Qt benutzen würde, käme auch hier eine nicht unerhebliche Menge RAM-Bedarf hinzu. Da Java und C++ auch von der Geschwindigkeit in der selben Größenordnung liegen, halte ich die Behauptung, dass ein Programm dann doppelt so schnell ablaufen würde, einfach nur für falsch.
Meine Behauptung wäre eher, dass das ganze in C++ deutlich schwerer gewesen wäre (man muss ja bedenken, dass Eclipse vornehmlich in Eclipse entwickelt wurde und das Anfang 2000 die beste und fortschrittlichste Java-IDE war und diese auch definitiv besser als alle C++-Editoren zu diesem Zeitpunkt war) und die große Gefahr da gewesen wäre, nie das Projekt abzuschließen und etwas zu "delivern".
Aber vielleicht beruhigt ja alle, zu wissen, dass der Parser-Generator, mit dem der Kern für den Java-Compiler von Eclipse gebaut wurde, ein C++-Programm war (vielleicht sogar immer noch ist). Das war großer Mist, denn so konnte man das JDT nicht direkt aus Eclipse heraus komplett neu bauen, sondern es war immer ein mühsam irgendwo auf IBMs Alphaworks-Seiten verstecktes komisches Prorgamm zu benutzen, wenn man den Parser hätte ändern wollen. Da hatte auch ein Researcher die Idee, C++ wäre eine gute Wahl.
Ich stimme Hyperion zu, bei Java ist die Entwicklung ohne eine IDE mit den funktionen von Eclipse bzw. dem JDT in Eclipse undenkbar. Das war damals ein Meilenstein, was die Unterstüzung angeht und der Abschied von einem Editor, aus dem man einfach Compiler und/oder Debugger heraus aufrufen kann zu einer Sprachmodell-getriebenen Code-Unterstützung (nicht dass es nicht sowas auch schon früher gegeben hätte - z.B. für Lisp - aber nix davon war Mainstream). Eines der Killer-Feature (die auch weder Netbeans noch IntelliJ aufgegriffen haben) ist und war, dass Eclipse inkrementell kompiliert. Eclipse war damals fast so bequem wie Smalltalk... seufz ;)
Noch ein Punkt zu dem IDE-Thema und der Client/Server-Diskussion, die IMHO immer noch nicht darum geht, ob man nun per X, NX oder VNC auf ein entferntes GUI zugreifen kann, sondern ob man sich an einen als Server laufendes Laufzeitsystem anflanschen kann und so während der Entwicklung auf (Typ-)Informationen aus dem laufenden Programm zugreifen kann: Das beste und vielleicht älteste Beispiel dafür ist natürlich der Emacs mit seinem Lisp-Mode. Ich weiß nicht genau, wie lange es SLIME schon gibt, aber damit ist genau dies möglich: Ich verbinde mich mit einem laufenden Lisp-System und kann dort interaktiv Codeschnipsel ausführen, habe dort Informationen, die für Code-Completion benutzt werden können und habe noch am ehesten das Gefühl, in einen lebenden System wie damals in Smalltalk zu arbeiten. Ich meine die zur selben Zeit wie Smalltalk erhältlichen Lisp-Maschinen arbeiteten genauso.
Irgendwann, vielleicht mit dem aufkommen von TurboPascal, hat sich dann die Idee festgesetzt, das beste, was man haben kann, ist ein Texteditor, aus dem man vielleicht einen Compiler aufrufen kann. Später kam dann als "Innovation" noch Syntaxhighlighting dazu. Eigentlich schade.
Stefan
)
, aber vielleicht sollte man wirklich mal aufraeumen.