Probleme mit Java-Entwicklung unter Eclipse

[arrgghh]

derzeit versuche ich auf meinem notebook (debian lenny) java-programme zu schreiben und stoße leider auf einen großen haufen probleme. ich beginne mit den schwerwiegensten:

1. performance: eclipse sowie auch netbeans laufen dermaßen langsam, das es schon fast unmöglich ist damit zu entwickeln.

2. ein einfaches java programm [CODE1] erzeugt ein fenster, welches nicht mehr reagiert und zwanghaft beendet werden muß. das gleiche programm funktioniert unter windows ohne probleme

3. beim starten meiner anwendung wird eine exception geworfen [EXCE1]. dies hat vermutlich etwas mit dem von mit eingestellten theme unter "/usr/share/theme" zu tun. (eine mögliche wechselwirkung mit 2. habe ich schon getestet. das problem unter 2. tritt auch auf, wenn ein standard theme eingestellt ist, daher kann 3. als ursache für 2. ausgeschlossen werden.)

4. der eclipse workspace wird beim starten nicht ordnungsgemäß geladen. erst mit "switch workspce" und nochmals 60sec ladezeit werden die dort enthaltenen projekte geladen.

relevante informationen zu meinem system:
- linux: debian lenny 64-bit (kernel 2.6.24.1)
- java: sun-java5 (auch sun-java6 wurde schon getestet)
- eclipse 3.2.2-5
- auch getestet: eclipse europa (3.3.?) -> hier wirft eclipse die unter 3. beschriebene exception schon von selbst beim starten

[CODE1]

Code: Alles auswählen

import java.awt.Color;

import javax.swing.JFrame;

public class Start {

	public static void main(String[] args) {
		JFrame view = new JFrame(); // Zeile 8: Auslöser der Exception
		
		view.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		view.setSize(800, 600);
		view.setBackground(Color.WHITE);
		view.setVisible(true);
	}
}

[EXCE1]
(.:4467): Gtk-WARNING **: Im Modulpfad »ubuntulooks« konnte keine Themen-Engine gefunden werden,
java.lang.InternalError: Gtk: Im Modulpfad »ubuntulooks« konnte keine Themen-Engine gefunden werden,
at java.lang.reflect.Constructor.newInstance(libgcj.so.90)
at gnu.java.awt.peer.gtk.GtkToolkit.gtkInit(libgcj.so.90)
at gnu.java.awt.peer.gtk.GtkToolkit.<clinit>(libgcj.so.90)
at java.lang.Class.initializeClass(libgcj.so.90)
at java.lang.Class.forName(libgcj.so.90)
at java.awt.Toolkit.getDefaultToolkit(libgcj.so.90)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(libgcj.so.90)
at java.awt.Window.<init>(libgcj.so.90)
at java.awt.Frame.<init>(libgcj.so.90)
at javax.swing.JFrame.<init>(libgcj.so.90)
at Start.main(Start.java:8 )

[hupfdule]

Du benutzt nicht die genannte Java VM, sondern den gcj. Der ist nicht 100% kompatibel und führt zu den genannten Problemen.

Mit

Code: Alles auswählen

update-alternatives --config [java|javac]

kannst du die VM und den Compiler umstellen. Es gab glaub auch eine Möglichkeit alle für Java relevanten Alternativen auf einen Schlag umzustellen. Der ist mir aber entfallen. Wurde hier im Forum irgendwo aber schon mal beschrieben. Einfach mal danach suchen.

[arrgghh]

soweit so gut. die java maschine habe ich umgestellt. die ausgabe von "java -version":

java version "1.5.0_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_14-b03, mixed mode)

allerdings hat sich absolut nichts geändert. sämtliche probleme bestehen weiterhin. auch ein system neustart brachte keine verbessrerung.

ich suche inzwischen weiter nach deiner "alternativen möglichkeit"...
update: ich schätze ich hab den befehl gefunden: "update-java-alternatives"... keine verbesserung

wie schauts aus mit 64-bit system als mögliche ursache?

[hupfdule]

wie schauts aus mit 64-bit system als mögliche ursache?

Nein, die 64bit VM existiert schon recht lange und ist daher auch sehr gut getestet. Ich selbst hatte bisher auch nur das Problem, dass die Systemproperties nicht unbedingt korrekt waren. In derart einfachen Programmen wie deinem Beispielprogramm dürfte aber nun wirklich nichts schief laufen.

Wenn du aber tatsächlich noch die selbe Exception wie oben hast, dann war deine Umstellung noch nicht erfolgreich. Denn dort werden eindeutig gcj Klassen verwendet:

Code: Alles auswählen

at gnu.java.awt.peer.gtk.GtkToolkit.gtkInit(libgcj.so.90) 
at gnu.java.awt.peer.gtk.GtkToolkit.<clinit>(libgcj.so.90)

Du solltest in Eclipse noch mal schaun, welche VM dort eingestellt ist. Eclipse hat da noch eigene Einstellungen.

[arrgghh]

jo, das wars... eclipse hat die falsche java maschine verwendet. allerdings ist die performance immernoch ein problem. die code vervollständigung dauert ewig... teilweise bis zu 5sec und dann wird erst das fenster laaaangsam aufgebaut.

1. performance problem: bleibt bestehen

2. behoben

3. behoben

4. behoben (lag an eclipse 3.2), mit eclipse europa funktionierts

[hupfdule]

allerdings ist die performance immernoch ein problem. die code vervollständigung dauert ewig... teilweise bis zu 5sec und dann wird erst das fenster laaaangsam aufgebaut.

Das dürfte aber nicht wirklich an Java liegen. Hast du vlt. etwas zu wenig RAM? Sowohl Eclipse, als auch Netbeans benötigen quasi Unmengen davon. Und wenn davon nicht genug da ist, merkt man das schon.

[arrgghh]

ja, ich habe wenig ram. aber unter windows war das auch kein problem. ich glaube mal irgendwo gelesen zu haben, das 64-bit programme mehr speicher belegen (was ja auch logisch wäre)... evtl. liegt dort die ursache.

obwohl sich die performance nach einiger zeit leicht verbessert hat, könnte eclipse dennoch schneller laufen jedenfall wäge ich gerade die vor- und nachteile von 64-bit debian ab und überlege die 32-bit variante zu verwenden... aber das ist eine andere geschichte

[rolo]

ich habe nach performance problemen mit der 64 bit eclipse version aus den debian repositorys, eine aktuelle version (64 bit) von http://www.eclipse.org/downloads/ installiert, was die probleme beseitigt hat.
allerdings habe ich 2 gb ram zur verfügung. 1 gb solltest du aufjedenfall haben, damit eclipse vernünftig arbeitet.

[arrgghh]

ich verwende das ganze zeug auf meinem notebook. da mir die finanziellen mittel fehlen, um den speicher aufzurüsten, müssen 512 mb reichen ^^

die umstellung auf 32-bit debian war eine gute entscheidung denke ich. die speicherauslasung ist deutlich geringer. hier ein vergleich der resourcen-auslastung mit geöffnetem browser, eclipse, aktive java applikation im hintergrund:

vorher (64-bit): speicher 80%, swap (1,4 gb) 10-20%
jetzt (32-bit): speicher 60%, swap 0%

der gesamte arbeitsablauf ist deutlich flüssiger. immerhin hat mir das ganze gezeigt, das ein rechner mit 64-bit cpu nicht zwingend mit einem 64-bit betriebssystem betrieben werden muß, insbesondere dann, wenn der speicher knapp ist.

-> 1. behoben

/gelöst