JFileChooser ist sehr langsam

[Tommy135]

Hallo Community,

Ich habe schon wieder ein Problehm jedoch ist das etwas komplizierter. Wie im Titel schon beschrieben ist mein Problehm das der JFileChooser sehr langsam öffnet und ich weiß nicht warum. Ich nutz JDK 14 habe es jedoch auf einer externen festplatte liegen. Darunter finden sich auch noch Version von JDK 1.6 bis 1.14. Das war bis her nie ein Problehm die Programme starten auch ganz normal, nur wenn ich den JFileChooser öffner kommt es zu längeren Wartezeiten, auch das wechseln von verzeiniessen im JFileChooser wird da zu einer Qual. Die Beiträge die ich gefunden hatte waren was älter und bezogen sich auf JDK 1.6 jedoch nutze ich JDK 1.14 mit maven. Falls jemand da eine Idee hat wo ran es liegen könnte wäre ich sehr Dankbar. Meine System ist wie folgt:

Betriebsystem: Win10 x64
Processor: Intel Core i5-72004 Kerne
Arbeitsspeicher: 8GB
Java Version: JDK 14
IDE: NetBeans 3.0
Maven: 3.6.3

Vielen Dank schon mal im vorraus

Mit freundlichen Grüßen

Tommy135

 

[mihe7]

Mach mal ein minimales, kompilier- und ausführbares Beispiel fertig, bei dem das Problem bei Dir (gerade noch) auftritt.

 

[Tommy135]

public class Test {
    public void main(String[] args) {
        FileNameExtensionFilter TheCatColorFile = new FileNameExtensionFilter("The Cat Color File", "tccolor");
        JFileChooser jfc = new JFileChooser();
        jfc.setAcceptAllFileFilterUsed(false);
        jfc.setFileFilter(TheCatColorFile);

        int i = jfc.showOpenDialog(null);

        if (i == JFileChooser.APPROVE_OPTION) {
            //Hier kommt dann nur der Teil zum lesen der Datei.
        }
    }
    
}

So ist der Aufbau im kleinen Style wo das Problehm auftrit.

 

[M.L.]

Zum Vergleich (wobei sich in keinem Fall ein langsames Öffnen und Arbeiten mit JFileChooser hat feststellen lassen. Es kann sein, dass Java 14, Windows 10 (irgendein optischer oder verwaltungstechnischer Vorgang) oder ein anderer aktiver Prozess bremsende Faktoren sind)

Betriebsystem: Win7 x64
Processor: Intel Core i5-2 Kerne
Arbeitsspeicher: 6GB
Java Version: JDK 8, 10, Open JDK 12
IDE: NetBeans 8.2 + Java 8, IntelliJ CE 2018+ OpenJDK 12, Kommandozeile + Java 10

 

[looparda]

Ich konnte ähnliches vor kurzem feststellen in einer älteren Swing Anwendung bei der Auswahl einer Datei.
Ich habe Java 1.8 und 11 drauf und kann nicht genau sagen mit welchem ich die Applikation ausgeführt habe (Windows 10x64).
Ich habe eine Reihe alter Projekte für eine Recherche angeschaut und kann mich leider nicht mehr erinnern bei welchem das Problem auftrat. Einige davon musste ich auch mit Netbeans öffnen, meist habe ich aber IntelliJ genutzt (somit leider die nächste Variable). Ich versuche es aber herauszufinden.
Das Minimalbeispiel macht bei mir so keine Probleme mit Java 1.8.

 

[looparda]

Ich bin mir wieder ziemlich sicher, dass ich das Problem mit spotbugs-3.1.12 hatte (https://repo.maven.apache.org/maven2/com/github/spotbugs/spotbugs/3.1.12/spotbugs-3.1.12.zip). Im bin Ordner die spotbugs.bat ausführen. Datei > Neues Projekt und dann Hilfsklassen auswählen. Ich hab gelesen, dass es in der Vergangenheit Bugs gab, wenn Netzlaufwerke verbunden waren (gerade mit Netzlaufwerk getestet), Dateikomprimierung (NTFS-Kompression) aktiv ist (war damals aktiv, jetzt nicht mehr) oder ein Verzeichnis mit vielen Archiven geöffnet wird (gerade getestet). Allerdings tritt das Problem heute nicht auf mit Java 1.8 und 11.
Bleibt theoretisch nur Dateikomprimierung. Hast du das aktiv?

 

[mihe7]

So ist der Aufbau im kleinen Style wo das Problehm auftrit.

OK, dazu zwei Nachfragen:

1. D. h. ohne den Filter gibt es kein Problem?
2. wie viele Dateien befinden sich in dem Verzeichnis?

Win10 könnte ich höchstens am Dienstag testen.

 

[Tommy135]

OK, dazu zwei Nachfragen:

1. D. h. ohne den Filter gibt es kein Problem?
2. wie viele Dateien befinden sich in dem Verzeichnis?

Win10 könnte ich höchstens am Dienstag testen.

Zum ersten punkt. Nein dies hat das Problehm nicht behoben. Zum zweiten Punkt, 107 elemente war aber bis her kein Problem.

 

[Tommy135]

Ich bin mir wieder ziemlich sicher, dass ich das Problem mit spotbugs-3.1.12 hatte (https://repo.maven.apache.org/maven2/com/github/spotbugs/spotbugs/3.1.12/spotbugs-3.1.12.zip). Im bin Ordner die spotbugs.bat ausführen. Datei > Neues Projekt und dann Hilfsklassen auswählen. Ich hab gelesen, dass es in der Vergangenheit Bugs gab, wenn Netzlaufwerke verbunden waren (gerade mit Netzlaufwerk getestet), Dateikomprimierung (NTFS-Kompression) aktiv ist (war damals aktiv, jetzt nicht mehr) oder ein Verzeichnis mit vielen Archiven geöffnet wird (gerade getestet). Allerdings tritt das Problem heute nicht auf mit Java 1.8 und 11.
Bleibt theoretisch nur Dateikomprimierung. Hast du das aktiv?

Ja die Dateien Komprimierung ist Aktiv. Jedoch enthält der Ordner in dem ich aus führe keine Archive und mit Netzlaufwerken habe ich derzeit nicht viel am hut.

 

[krgewb]

@Tommy135 Wenn ein Ordner komprimiert ist, erkennt man das an dem blauen Symbol oben rechts. Das sind zwei Pfeile, die aufeinander zeigen.

@mihe Das Wechseln des Verzeichnisses im JFileChooser geht bei ihm auch sehr langsam.

 

[mihe7]

Sorry, habe ganz vergessen, den Spaß zu testen. @Tommy135 kannst Du mal im Taskmanager schauen, ob es Prozesse gibt, die beim Verzeichniswechsel viel CPU benötigen?

 

[Tommy135]

Ich mach es mir erstmal einfach, die Grafischen projecte stelle ich hinten an.Dank aber für die hilfen.

 

[Blizzsnake80]

Hey, hallo zusammen.

Ich habe das gleiche Problem:

Probleme mit Zugriff auf Dateisystem Windows 10 ( jFileChooser)

Hallo zusammen, 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...

www.java-forum.org

Ich konnte bislang nicht feststellen, woran dieses verzögerte Verhalten liegen könnte.

 

[Neumi5694]

Ich hatte das Problem mit dem Windows Look and Feel und zwar beim Laden der Dateiicons. JFC kann da sehr langsam sein, besonders auf Netzwerklaufwerken.

Ich hab dann als Lösung den View überschrieben und nur noch ein selbst definiertes Icon für den Typ anzeigen lassen, der für mich relevant war, alle anderen haben das Standard-Icon erhalten - also ohne auf die Methoden zuzugreifen, die das Icon aus dem Betriebssystem auslesen.
Damit ging alles ratzfatz.


ps: Irgendwas scheint Java da allerdings zu cachen. Ich hatte den oben geposteten Code so geändert, das "All files" sichtbar ist, hab ein Verzeichnis mit ca. 1200 Dateien verschiedenster Art gewählt. Das Programm hab ich dann mit aktivem Filter gestartet und hab dann nach "All FIles" umgeschaltet.
Beim ersten Aufruf des Programms gab es beim Umschalten nach "all files" eine ziemliche Verzögerung, mehrere Sekunden.
Beim zweiten Aufruf des Programms ging's mit minimaler Verzögerung.
d.h. der Cache oder was auch immer den Unterschied gemacht hat, blieb auch über mehrere Aufrufe hinweg erhalten.
Ich vermute mal, wenn ich mein Temp-Verzeichnis leere, ist's beim nächsten Mal wieder verzögert.