Netbeans Update funktioniert nicht

R

ralli

Guest
Ich arbeite mit:

openjdk version "1.7.0_65"
OpenJDK Runtime Environment (build 1.7.0_65-b17)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

und der IDE NetBeans 8.0.

Netbeans möchte immer auf die Version 8.01 updaten, aber das funktioniert nicht, es läßt sich (trotz funktionierender Internetverbindung) nicht updaten, weil die Verbindung zum Update Server zwar versucht wird, er aber immer antwortet, keine Verbindung möglich, ich soll es später noch Mal versuchen. Das ist aber schon seit Tagen so. Das ist insofern lästig, da ich bei jedem Neustart von NetBeans daran erinnert werde, das Updates vorliegen. Wie kann ich Autoupdate abschalten oder deaktivieren? Ich habe lange danach gesucht, aber nichts gefunden.
 
So, ich habe es gefunden, unter dem Menu Tools - Module und dem Reiter Settings läßt sich das automatische Updaten konfigurieren und deaktivieren. Natürlich ist das keine wirklich befriedigende Lösung. Was passiert denn, wenn beim Updaten keine root Rechte vorliegen?
 
Die Updates sollten aus deinem Paketsystem kommen, nicht von NetBeans direkt. Es sei denn Du hast am Paketsystem vorbei installiert.
 
Es geht noch weiter, ich habe über weitere Erfahrungen mit Java unter FreeBSD zu berichten. Leider sind sie eher negativer Natur. Ich habe mir natürlich Eclipse angeschaut, weil mein mittlerweile in die Jahre gekommene PC mit NetBeans noch gerade so zurecht kommt. Nachdem ich das Plugin eclipse-windowbuilder installiert habe, wollte ich mit einer einfachen GUI Anwendung loslegen. Und was passiert? Ich bekomme gerade noch einen Butten auf einen Frame. Und sogleich friert Eclipse ein und es geht nichts mehr, so das ich sogar FreeBSD neu starten mußte. Ich habe extra dafür FreeBSD 9.3 installiert, weil es unter der Version FreeBSD 10 keine fertigen Binärpakete gibt und ich stundenlanges Bauen aus den Ports vermeiden wollte. Danach Eclipse runter und NetBeans nachinstalliert. Und jetzt? Bei NetBeans bleibt kein angeklicktes Menü auf, so das damit kein arbeiten möglich ist. Das selbe Phänomen trat bereits unter FreeBSD 10 und JEdit auf. Also, woran das liegt, weiß ich nicht wirklich. Es könnte aber möglich sein, das es zwischen OpenJDK und dem Original doch noch Unterschiede gibt, die sich in der Praxis gravierend auswirken können. Schade, Eclipse machte ansonsten einen guten Eindruck auf mich, das Startverhalten war deutlich flotter. Allerdings kommt mir NetBeans auch etwas aufgeräumter und übersichtlicher vor. Eclipse hingegen scheint mir doch noch nicht so ausgereift zu sein, denn wenn ich nach NetBeans in Verbindung mit einfrieren google, dann gibt es unheimlich viele Treffer, so das es nicht an meiner Hradwarearchitektur liegen kann. Es wäre schön, wenn Ihr auch über Eure Erfahrungen posten würdet, denn ich kann mir nicht vorstellen, das das alles nur Probleme sind, die ich habe.
 
zuglufttier schrieb:
Also ich habe Eclipse unter FreeBSD 10 schon seit einer Weile am Laufen... Keine Probleme zu vermelden. Ich nutze openjdk7.
Zum Vergrößern anklicken....
Nun, es bleibt seltsam und leider für meine Begriffe nicht nachvollziehbar. Nutzt Du einen Desktop oder einen Windowmanager? Dann könnte es noch sein, das das irgendwie mit dem Mate Desktop zu tun hat. Es scheint, als ob plötzlich der Datenfluß unterbrochen würde und Änderungen, wie die Neubeschriftung dieses Button nicht mehr durchgereicht würden. Wenn diese mutmaßliche Theorie stimmen würde, dann könnte es auch was mit dbus zu tun haben, der eventuell nicht sauber arbeitet. Da sicherlich viele tausend Entwickler mit Eclipse arbeiten, wird es nicht an Eclipse selbst liegen, das schließe ich aus. Aber sicher bin ich mir da nicht, denn wie ich schon schrieb, gib mal bei Tante Google "Eclipse friert ein" als Suchbegriff ein, und Du wirst ziemlich viele Treffer bekommen, aber keine wirkliche Lösung.
 
Na ja, Eclipse ist eine ziemlich fette Anwendung. Wenn da mal was im Hintergrund läuft gerät das bei mir auch ins Stocken. Eine richtige Desktopumgebung habe ich aber nicht laufen. Irgendwann mal xfce, das gab auch keine Probleme.
 
In den letzten Jahren sind die Java IDE ziemlich schwergewichtig gewurden. Selbst ein i3 mit 6GB zwingt man mit Android Entwicklung in die Knie. Ist also kein spez. Linux/BSD Problem aber ohne Syntax Highlightning, Autocompletion, Code Formatierung will man heute nicht Java nutzen. Also entweder bessere Hardware oder Sprache wechseln.
 
darktrym schrieb:
In den letzten Jahren sind die Java IDE ziemlich schwergewichtig gewurden. Selbst ein i3 mit 6GB zwingt man mit Android Entwicklung in die Knie. Ist also kein spez. Linux/BSD Problem aber ohne Syntax Highlightning, Autocompletion, Code Formatierung will man heute nicht Java nutzen. Also entweder bessere Hardware oder Sprache wechseln.
Zum Vergrößern anklicken....
Gut das ist mir schon bewußt, aber das das Einfrieren von Eclipse etwas mit der Hardware oder mit den bei mir für heute spärlichen 2GB RAM zu tun haben sollte, offenbart sich mir trotzdem nicht. NetBeans ist ja auch immer fetter geworden, trotzdem läuft es noch erträglich, wenn einige Bremsen gelöst werden. Code Folding ist so ein Beispiel, das ich sofort nach der Installation abschalte. Und wie kommt es, das dann plötzlich unter NetBeans ein angewähltes Menü nicht auf bleibt? Das hat sicherlich auch nichts mit meiner Harwarearchitektur zu tun. Und da dieses Phänomen dann auch mit JEdit auftritt, das ich für einfachere Anwendungen nutze, ist doch ein Beleg dafür, das hier noch andere Störenfriede am Werk sind, oder? Das passiert unter FreeBSD 9.3. Unter FreeBSD 10 läuft NetBeans gut, aber JEdit trotzdem nicht. Ja, da weiß ich dann auch leider nicht weiter. Aber wenn der Erwerb eines neuen PC ansteht, werde ich mich nicht mit 4 GB RAM zufrieden geben, sondern gleich 8 GB ordern, das ist sicher. Ich wollte mir halt einen Eindruck von Eclipse machen, aber das werde ich jetzt nicht weiter verfolgen, denn ob es flott, normal oder zäh läuft ist nicht alleine ausschlaggebend, sondern es muß laufen!
 
ralli schrieb:
Es könnte aber möglich sein, das es zwischen OpenJDK und dem Original doch noch Unterschiede gibt, die sich in der Praxis gravierend auswirken können.
Zum Vergrößern anklicken....

Seit Java 7 ist OpenJDK das "Original". :)

ralli schrieb:
Allerdings kommt mir NetBeans auch etwas aufgeräumter und übersichtlicher vor.
Zum Vergrößern anklicken....

Das ist kein Wunder, Eclipse ist im Endeffekt ein gigantisches Sammelsurium an Plugins. Netbeans hat zwar auch eine Plugin-Architektur, die Kernfunktionalität wird aber zentral entwickelt.

ralli schrieb:
Es wäre schön, wenn Ihr auch über Eure Erfahrungen posten würdet, denn ich kann mir nicht vorstellen, das das alles nur Probleme sind, die ich habe.
Zum Vergrößern anklicken....

Die bist nicht allein; ich hatte das Verhalten mit FreeBSD und allen Window Managern im Multi-Monitor-Betrieb, nicht nur - aber vor allem - bei Java-Anwendungen. Unter Linux lief es out of the box völlig problemlos. :mad:

Du kannst noch die Tipps aus diesem Beitrag probieren, der zwar für OpenJDK 6 ist, aber trotzdem Abhilfe schaffen könnte. Letzten Endes haben solche Phänomene aber dazu geführt, dass ich das Abenteuer FreeBSD-Desktop verworfen habe.

darktrym schrieb:
Selbst ein i3 mit 6GB zwingt man mit Android Entwicklung in die Knie.
Zum Vergrößern anklicken....

Das liegt am extrem langsamen Android-VM-Emulator, der eine ARM-CPU emuliert. Nimm Android-x86.

Ansonsten kostet ein i5 mit 8 GB RAM soviel wie 3 Entwicklerstunden, daran sollte es nicht scheitern.

darktrym schrieb:
ohne Syntax Highlightning, Autocompletion, Code Formatierung will man heute nicht Java nutzen.
Zum Vergrößern anklicken....

Ohne das sowie statische Code-Analyse, Refactoring-Support, etc. möchte man heute keine Sprache nutzen.
 
ralli schrieb:
Aber wenn der Erwerb eines neuen PC ansteht, werde ich mich nicht mit 4 GB RAM zufrieden geben, sondern gleich 8 GB ordern, das ist sicher.
Zum Vergrößern anklicken....
Kleiner Ratschlag am Rande. 4GB reichen vielleicht für ein Telefon oder ein NAS ohne ZFS (dafür reichen wahrscheinlich auch 1 oder 2). Aber für einen Desktop würde ich im Moment 32GB veranschlagen für ein Notebook 16GB. 8GB laufen auch ohne Probleme. Aber die betrachte ich als angezählt.
 
Azazyel, natürlich benutze ich openJDK7. Und ich bleibe bei NetBeans. Das läuft jetzt sauber und einwandfrei unter Gnome2. Ja, nicht immer ist das Ältere schlecht, gut abgehangen und ausgereift. Ja, ein Abenteuer bleibt der Desktop unter FreeBSD, denn da weiß Du nie genau, wa Dich erwartet.;) Aber bisher habe ich immer noch alle Probleme in den Griff bekommen. Neue Harware wird es geben, aber ich gehöre nicht zu der Wegwerfgeneration. Wenn mein jetziger Arbeitsrechner seinen Geist aufgibt, dann wird ein aktueller PC seinen Platz einnehmen. Und nun werde ich mich wieder in Java vertiefen.
 
Kamikaze schrieb:
Kleiner Ratschlag am Rande. 4GB reichen vielleicht für ein Telefon oder ein NAS ohne ZFS (dafür reichen wahrscheinlich auch 1 oder 2). Aber für einen Desktop würde ich im Moment 32GB veranschlagen für ein Notebook 16GB. 8GB laufen auch ohne Probleme. Aber die betrachte ich als angezählt.
Zum Vergrößern anklicken....
Kein Problem, das ist dann ja auch sinnvoll und RAM kostet ja nicht wirklich mehr viel.
 
NetBeans 8.x ist für mich eine überdimensionierte IDE, deren Leistungsumfang ich nie gänzlich nutzen kann und will. Deshalb habe ich mir die Version 6.5 installiert mit dem Original von Sun 1.7.0_01., was gerade mal 3 Jahre alt ist. Und siehe, es läuft wunderbar, denn ich will die DE wirklich nur für Java SE nutzen. Beim Original ist im übrigen auch bereits die Java DB (Derby) an Bord, als Server als auch als embeddet Database. In der OpenJDK Version fehlen diese und müssen nachgerüstet werden. Mit dieser Version ist es auch möglich, mal schnell eine Desktop Anwendung mit Datenbankanbindung zu erstellen, was ich mir immer wünschte. So für mich ist diese Thematik abgeschlossen, NetBeans startet auch mit meinem älteren Rechner sehr schnell, läuft stabil und wirklich flüssig. Die ganzen Teamfähigkeiten und Code Folding und was auch immer wie das Refactoring sind für große Projekte ein Segen aber ich brauche es nicht wirklich.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben