Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
- Eclipse wurde von Release zu Release langsamer und ressourcenfreessender
- NetBeans wurde von Release zu Release schlanker und schneller
- SWT lahmt vor allem unter Linux mit GTK unerträglich auch auf heftigen Maschinen
Jetzt muss ich auch noch froh sein unter Windows zu entwicklen.. traurig aber wahr
eclipse mag ein bisschen langsam sein, aber für mich ist es noch lange nicht störend langsam. vorallem wenn ich es mit vb.net IDE vergleiche...
Die features in Eclipse sind einfach nur genial...
Ich glaube du hast Artikel/Zusammenfassung nicht richtig gelesen. Es geht darum, dass SWT und damit auch Eclipse unter Linux ätzend lahm ist, weil SWT offensichtlich lediglich auf Windows vernünftig optimiert ist.
die angaben auf die sich der Text stützt sind allesammt aus der Java Lobby, keine einzige andere Quelle habe ich gefunden, was nicht gerade einen seriösen eindruck macht.
Es sieht stark nach einem werbetext für NetBeans aus.
Etwas 10 mal ist zu NetBeans verlinkt, während kein Link zu Eclipse zu finden ist....
deine Eigenen KernAussagen:[quote="AlArenal]
- Eclipse wurde von Release zu Release langsamer und ressourcenfreessender
- NetBeans wurde von Release zu Release schlanker und schneller [/quote]
worauf ich geantwortet habe....
Für mich war die Kernaussage: "wechselt alle zu NetBeans, denn Eclipse ist scheisse"
Nicht gerade eine konstruktive Aussage....
Sehe ich nicht so. Die Aussagen zur Geschwindigekti von NetBeans und Eclipse sind rein relativ und natürlich subjektiv. Ich kann diese Eindrücke durchaus bestätigen.
Die Zitate sind teils aus Fragen von Usern in den einschlägigen Foren / der Java-Lobby. Das steht aber auch im Text erklärt. Es würde für JavaLobby keinen Sinn machen Propaganda zu betreiben, da Eclipse sicher die größere Userbase hat als NetBeans und warum sollten sie die vergraulen wollen?
Wer den Text liest (sollte man tun, ehe man darüber schreibt), kann man Aussagen und Zusammenfassung auch erfassen. Im Grunde läuft es nämlich auf Swing kontra SWT hinaus und das ist nunmal für Eclipse-User auf Nicht-Windows-Plattformen auch dann ein Thema, wenn sie selbst SWT nicht für eigene Anwendungen nutzen.
Dadurch wird es auch zum Thema bei strategischen Überlegungen. Wenn ich ne GUI-Anwendung zu entwickeln hätte, die auch auf Linux laufen müsste, würde ein deutliches Performance-Problem der Linux-SWT-Implementierung mir doch zu denken geben (neben allen weiteren Punkten, die es bei einer solchen Frage zu behandeln gibt)..
Das gilt aber auch für NetBeans und das ist schneller geworden. Im Artikel wird der gestiegene Ressourcenhunger und die gesunkene Geschiwndigkeit von Eclipse als Indiz dafür genommen, dass die SWT-Entwickler nun langsam in Bereiche kommen, wo SWT sich in der internen Komplexizität Swing immer weiter annähert und entsprechend ähnliche Charakteristiken im Laufzeitverhalten bekommt.
Hatten wir auch im Einsatz. Finde ich nicht so pralle damit GUI-Anwendungen zu entwickeln. Der Code ist echt gruselig und irgendwann streikt der GUI-Builder.
So, durchgelesen. Hört sich für mich immer noch wie ein Werbetext an, einfach, weil es sehr einseitig geschrieben ist. (Sorry, ich kann da wirklich ein Grundton "Beweisen wir mal, dass SWT langsam ist, hm, wo finde ich die richtigen Zitate..." raushören).
Als ich das letzte mal Eclipse auf einem Linux sah, konnte ich jedenfalls nix von dem feststellen, was der Autor hier beschreibt (zugegeben, statistisch gesehen hat das keine Aussagekraft).
Das gilt aber auch für NetBeans und das ist schneller geworden. Im Artikel wird der gestiegene Ressourcenhunger und die gesunkene Geschiwndigkeit von Eclipse als Indiz dafür genommen, dass die SWT-Entwickler nun langsam in Bereiche kommen, wo SWT sich in der internen Komplexizität Swing immer weiter annähert und entsprechend ähnliche Charakteristiken im Laufzeitverhalten bekommt.
Wenn Netbeans schneller wird heisst das noch lange nicht dass es besser ist als Eclipse :roll:
du musst das Eclipse von heute mit dem NetBeans von heute vergleichen. und nicht Eclipse alt und Eclipse neu. Das macht keinen Sinn
Du sagst ja auch nicht, di mototräder haben sich in den letzen 10 jahren mehr entwickelt als die autos, desshalb kauf ich mir n motorrad. Wichtig ist was besser ist und für welchen zweck.
Und wo habe ich gesagt, dass ich das nicht getan habe?
Wir haben kürzlich erst von JBuilder umgesattelt, da musste ich mich gezwungenermaßen mit Netbeans und Eclipse und deren Entwicklungen beschäftigen. Dazu habe ich aktuelle Projekte jeweils für Netbeans und Eclipse umgestellt (soweit nötig) und ich muss sagen, dass mir keine Hammer-Features begegnet sind, die mich nun eher auf eine als die andere Seite gezogen hätten. Am Ende war es eher ne Bauch-Entscheidung.
Ebenso wie bei der Frage nach der Wahl der richtigen Systemplattform, sollte man glaube ich nicht unnötig mit Glaubenskriegen anfagen, wo sie einfach unnötig sind. Netbeans und Eclipse lassen sich in etwa äquivallent bedienen. Ausschlaggebend für eine strategische Entscheidung sind womöglich eher gerade aktuell verfügbare und für die eigene Arbeit notwendoge Plugins. Mir bräche auch kein Zacken aus der Krone, würde ich nächste Woche wieder auf NetBeans umsatteln..
Die ganzen genannten Negativpunkte würden mich an Eclipse nicht stören. Es könnte von mir aus noch langsammer sein. Eclipse, so wie es standardmäßig kommt, kann m.E. garnichts was fürs Leben wichtig ist. Dann wühlt man sich erstmal durch einige verbuggte Plugins. Dann nimmt man die Standard-Plugins, die halt jeder hernimmt und jeder so schrecklich lobt und dann kommt der Hammer: Das Teil meckert ununterbrochen, erst braucht man 10 Plugins, damit das eigentliche Plugin überhaupt funktionieren kann. Dann werden Libs vermißt, die ich schon 10mal eingetragen hab. Zum Schluß stellt man heraus, daß das Plugin der Version X nur mit Eclipse X.Y funktioniert, aber das auch nur dann, wenn bestimmte andere Plugins der Konkurrenz nicht installiert sind ... Mit Eclipse mach ich nur ab und zu ein bissl Tuning an uralten PHPs, aber sonst hab ich es noch nicht zum funktionieren gebracht. Von intuitiv zu Bedienen bzw. überhaupt sinnvoll zu Bedienen ist es m.E. sehr weit entfernt.
Es steht eigentlich immer da unter welcher Version es läuft, das ist dazu da damit der User das vor der Installation schon nachlesen kann. :roll: Und meist wird auch die aktuellste Version unterstützt, außer die Weiterentwicklung wurde eingestellt oder die neuste Eclipse Version kam erst frisch raus.
bronks hat gesagt.:
aber das auch nur dann, wenn bestimmte andere Plugins der Konkurrenz nicht installiert sind
Klar gibt's Plugins mit macken aber ich denke man sollte unterscheiden von wem das Plugin ist und in welchem Stadium es sich befindet, bevor man solche pauschalen Aussagen macht. Meine Meinung.
Und ein Programm zu bewerten mit den man eigentlich gar nicht arbeitet ... :bahnhof: oder nich?
Leider nicht. Bei der Suche nach Lösungen für meine Probleme bin ich über Dokumente gestolpert in denen das drinstand. Ohne das Zeug fertig zu lesen meinte ich "Gute Nacht" und bin ins Bett gegangen nach dem die eine bestimmte Software zum wiederholten mal gelösch war.
stevg hat gesagt.:
Klar gibt's Plugins mit macken aber ich denke man sollte unterscheiden von wem das Plugin ist und in welchem Stadium es sich befindet, bevor man solche pauschalen Aussagen macht. Meine Meinung.
Also als Eclipse User muss ich zugeben, dass Netbeans seit Version 4 auch extrem attraktiv geworden ist. Was mir an Netbeans gefällt, ist die vielzahl der Features. Auch das ganze JSP/Servlet Development kommt mit und es ist alles "aus einem Guss".
Bei Eclipse fehlt mir das ein wenig. Es gibt einige sehr gute komerzielle Plugins und auch ein paar frei verfügbare. Aber irgendwie ist es halt eben nicht "aus einem Guss".
Und so kommt es, dass ich für Tomcatprojekte vermehrt Netbeans einsetze, weil es mich einfach überzeugt hat.
Ich wünsche mir, dass das Eclipse SDK Team vielleicht doch einmal von ihrem Eclipse Plugin SDK Leitfaden wegkommt und sich auch ein wenig auf die anderen Java Entwickler konzentriert.
Zu den im Artikel angeführten Dingen kann ich nur soviel sagen: Ich kenne Entwickler, die von NetBeans und JBuilder auf Eclipse gewechselt haben. Aber niemanden, der von Eclipse weg gewechselt. Es setzen auch immer mehr Firmen auf Eclipse. (Das soll jetzt nur meinen Eindruck wiederspiegeln, und keine Wertung Pro oder Contra NetBeans an sich sein).
das einzige was mich an eclipse definitiv stört, sind die qualitativ eher bescheidenen Plugins die man im Open-source Bereich findet (vor allem solche, die sich in das Hauptmenu einklinken); dabei gibts von IBM genaue Guidelines für das WSAD an die man sich halten könnte...
bei der reinen Quelltextbearbeitung IMHO das beste Werkzeug (neben IDEA), wenn man GUIs oder Webapps erstellen will ist Netbeans wohl besser
BTW
habe gerade versucht die akutellen RCs von netbeans und eclipse auf einem 1GHz Rechner mit 256MB RAM laufen zu lassen -> definitiv völllig unmöglich, beide sind totale Ressourcenfresser
[...]
BTW
habe gerade versucht die akutellen RCs von netbeans und eclipse auf einem 1GHz Rechner mit 256MB RAM laufen zu lassen -> definitiv völllig unmöglich, beide sind totale Ressourcenfresser
Mal ganz von der Diskussion Netbeans vs. Eclipse abgesehen: nach jedem Update ein "-clean" auszuführen, hebt die Eclipse-Performance deutlich an. Ab und zu sollte man es eventuell auch neu installieren. Ansonsten schwillt es durch Plugins und Updates so an, das es fast so langsam wird wie Netbeans
Na welche in Wunder aber auch... Fahr mal nur Windows hoch, starte den Taskmanager und dann lies mal nach, was unter "zugesicherter Speicher" angegeben ist. Wenn Windows schon komplett das Ram vollmacht, bleibt für keine Anwendung mehr viel übrig und das macht sich umso mehr bemerkbar, je hungriger die App ist. Ganz gleich ob diese nun in Java, C++ oder Sanskrit geschrieben wurde...
Mal so nebenbei:
Wenn ich meine 1992er SGI Iris Indigo Elan anwerfe (neben mir höre ich die SCSI-Platten sirren) und die komplett hochgefahren ist (X Windows mit 4WDM), dann habe ich noch 76 von 128 MB RAM frei..
