|Re: [cross-project-issues-dev] Observation: Frequent UI freezes when working with files|
I just want to share an insight I got from reviewing several ui freezes. One common cause for UI freezes are operations that touch the filesystem. For instance, File.isFile, File.lastModified, or WinNTFileSystem.getBooleanAttributes seem to be very expensive. From what I read on the internet it seems that some of these methods (e.g. getAttributes) may even take up to several seconds to return on windows systems.
This has been discussed elsewhere in the internet  and seems to be a long-standing issue in Java.
With this mail I’d like to make you aware of this (in case you did not know this before) and would like to encourage you to actually not execute file operations in the ui thread. We may also consider doing some kind of caching but such a discussion would by far be over my knowledge, and thus, should be left to discuss with the platform team.
For now, I think we would benefit very much if every project that accesses files/resources would review their code and think about refactoring some part of the FileSystem work (even if it’s only checking a file’s attributes) into background processes.
The knowledge transfer company
Robert-Bosch-Str. 7, 64293 Darmstadt
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top