Grob gesagt: Ich habe mir mit WindowsBuilder ein jFrame erstellt, welche Strings einliest, diese einem Objekt (einer selbstdefinierten Klasse) zuweist und diese anschließlich in ein txt-Dokument in ein Verzeichnis freier Wahl (unter Nutzung von jFileChooser) schreibt.
Das Ganze funktioniert einwandfrei sowohl in der IDE als auch als jar-Export.
Nun ist mir auf zwei meiner Rechnern (Windows 10, Netzzugriff AUS, Windows Sicherheit deaktviert) aufgefallen, dass der Aufruf des jFileChooser Objektes teilweise extrem verzögert bzw. manchmal gar nicht ausgeführt wird.
Großartig konkurriende Programme hatte ich zum Zeitpunkt der Ausführung nicht laufen.
Auf meinem Laptop funktioniert das Programm einwandfrei.
Ich kann überhaupt dieses Verhalten weder reproduzieren noch einwandfrei eingrenzen, woran das liegen könnte.
Hat jemand von euch eine Idee wo und wie ich hier am besten nachschaue ?
Muss man sich bei solchen kleinen Miniprogrammen bereits mit Dingen wie Threads und der Zusammenarbeit mit dem Betriebssystem beschäftigen ?
Nee, ist nicht aktiv auf den entsprechenden Rechnern. Aber danke für den guten Hinweis.
Es ist auch völlig crazy, der Rechner lief seit gestern nach Feierabend durch (keine aktiven Programme). Heute morgen läuft das Programm wieder pfeilschnell und alles erscheint wie ausgewechselt, ohne das ich das irgendwie nachvollziehen könnte.
1. Java-Version? (Es gab mal eine Zeit lang ein Problem mit dem JFileChooser, da war das Teil unglaublich langsam)
2. Betrifft das nur den JFileChooser oder auch den Windows-Explorer?
3. Ändert sich etwas, wenn Du ein anderes Start-Verzeichnis für den JFileChooser angibst?
4. Ändert sich etwas, wenn Du ein anderes Look and Feel verwendest?
1. Java-Version? (Es gab mal eine Zeit lang ein Problem mit dem JFileChooser, da war das Teil unglaublich langsam)
2. Betrifft das nur den JFileChooser oder auch den Windows-Explorer?
3. Ändert sich etwas, wenn Du ein anderes Start-Verzeichnis für den JFileChooser angibst?
4. Ändert sich etwas, wenn Du ein anderes Look and Feel verwendest?
1) Java-Version ist 15 rspt. 16 auf einem der Rechner. Auf dem Laptop 15.
2) Der Windows-Explorer fkt. einwandfrei
3) Sinn und Zweck der Anwendung ist ja die Speicherung einer Datei in einem Verzeichnis, welches der Benutzer frei wählen kann. Die Dateibezeichnung wird dabei von der Anwendung vorgegeben.
Hierzu habe ich dann folgende Hilfsmethode (Anm.: Die Methode stammt aus einer frei zugänglichen Webseite und nicht von mir, daher an dieser Stelle ein Dank an der Ersteller) genutzt um das entsprechende Verzeichnis durch den Nutzer einzulesen:
private static File getRootFile() { // Hilfsmethode zum Auslesen des Zielpfades
JFileChooser chooser = new JFileChooser();
chooser.setDialogTitle("Start-Verzeichnis auswählen");
chooser.setMultiSelectionEnabled(false);
chooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);
chooser.setAcceptAllFileFilterUsed(false);
FileNameExtensionFilter standardFilter = new FileNameExtensionFilter("Nur Verzeichnisse", "*.*");
chooser.addChoosableFileFilter(standardFilter);
int answer = chooser.showOpenDialog(null);
if (answer == JFileChooser.APPROVE_OPTION) {
return chooser.getSelectedFile();
}
return null;
}
Ich habs getestet als das Verhalten wieder aufgetreten ist.
Auch die "eingeschränkte" Nutzung von dem jFileChooser ergibt das gleiche zögerliche Verhalten (Es dauer 23 Sekunden bei der Dialog geöffnet wird). Und es läuft nichts parallel.
Vielleicht sollte ich mir den Rechner mal mit dem ProcessExplorer genauer anschauen ?
Gibst denn weitere Klassen für den Zugriff auf das Dateisystem, sodass ich den FileChooser umgehen könnte ?
Probier mal das hier vor dem Anzeigen, du brauchst dafür noch eine 16x16 png Datei. Es klappt vielleicht auch mit anderen Größen, aber sicher ist sicher.
ps: Ein weiteres Problem, über das ich im Laufe der Zeit gestolpert bin, sind nicht reagierende Netzwerkkomponenten. Die können den JFileChooser ebenfalls in die Knie zwingen. Sofern das Windows-Look & Feel aktiv ist, greift die Places-Bar links auf solche zu.
Ich hab dann für die betroffenen Kunden eine Option eingebaut, die bestimmt, ob die Places-Bar verwenet wird oder nicht. Mittlerweile bin ich aber komplett auf den nativen Dateidialog (JNA-Zugriff) umgestiegen. Ich hab zwar nach wie vor lieber den JFileChooser, aber die Leute arbeiten lieber mit dem, was sie kennen.
Deshalb: Was du noch probieren solltest: Stell dein Look&Feel z.B. mal auf Nimbus um, mal sehen ob der Zugriff dann immer noch so lange dauert.
ps: Ein weiteres Problem, über das ich im Laufe der Zeit gestolpert bin, sind nicht reagierende Netzwerkkomponenten. Die können den JFileChooser ebenfalls in die Knie zwingen. Sofern das Windows-Look & Feel aktiv ist, greift die Places-Bar links auf solche zu.
Ich hab dann für die betroffenen Kunden eine Option eingebaut, die bestimmt, ob die Places-Bar verwenet wird oder nicht. Mittlerweile bin ich aber komplett auf den nativen Dateidialog (JNA-Zugriff) umgestiegen. Ich hab zwar nach wie vor lieber den JFileChooser, aber die Leute arbeiten lieber mit dem, was sie kennen.
Deshalb: Was du noch probieren solltest: Stell dein Look&Feel z.B. mal auf Nimbus um, mal sehen ob der Zugriff dann immer noch so lange dauert.
Demnach scheint ja der Wechsel des Look&Feel dass Mittel der Wahl zu sein, anstatt auf den jFileChooser zu verzichten ? Ich probiere das jetzt mal aus. Danke für den Tipp.
Ja, das war die einfachste Lösung. In meinem Fall aber wollte der Projektleiter, dass alles Windows Native ausschaut.
Zwischendurch hatte ich auch mal die Places Bar durch was Anderes ersetzt, was keine Netzwerkprobleme verursacht (mit eigenen Hotlinks). Aber nachdem sich die Leute dann auch noch darüber beschwerten, dass im Dateidialog nicht die gleichen Kontextmenüs wie im Windows Explorer verfügbar sind, sind wir dann einfach umgestiegen.
Vielleicht kann man ja auch irgendwie die Timeouts der Netzwerkzugriffe beeinflussen, aber ich hab nicht rausgefunden wie.
Ja, das war die einfachste Lösung. In meinem Fall aber wollte der Projektleiter, dass alles Windows Native ausschaut.
Zwischendurch hatte ich auch mal die Places Bar durch was Anderes ersetzt, was keine Netzwerkprobleme verursacht (mit eigenen Hotlinks). Aber nachdem sich die Leute dann auch noch darüber beschwerten, dass im Dateidialog nicht die gleichen Kontextmenüs wie im Windows Explorer verfügbar sind, sind wir dann einfach umgestiegen.
Vielleicht kann man ja auch irgendwie die Timeouts der Netzwerkzugriffe beeinflussen, aber ich hab nicht rausgefunden wie.
Ich habe das Look and Feel nun auf Nimbus geändert und noch ein paar Verbesserungen an der Eingabemaske vorgenommen. Gefühlt läuft das FileChooser-Objekt nun tatsächlich schneller aber (leider) besteht mir noch der "Härtetest" auf der Arbeit bevor. Im Übrigen finde ich auch dass der Nimbus-Look natürlich wesentlich fortschrittlicher aussschaut als der Standard. Danke nochmal.
Im Test auf den besagten Rechnern hat auch das neue LookAndFeel leider nichts geändert. Es ist zum ......
Auch wenn ich die jar-Datei(en) als Ausnahme in Windows Sicherheit einfüge klappt das nicht.
