On Mon, 3 Oct 2022 11:42:36 GMT, Tejesh R <t...@openjdk.org> wrote: >> Why is it bad to modify `JFileChooser` class itself? >> >> I think setting the current directory to `null` while it displays a >> directory kind of breaks the invariant. >> >> `JFileChooser` navigated to a directory and the current directory is set to >> it. You tried navigating to another directory, `FileSystem` didn't allow the >> navigation, so `JFileChooser` continues to display the files in the >> directory that is showed before. Thus, the current directory hasn't changed. >> From this point of view, the current directory should remain unchanged. > > https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L608 > Here the above logic checks if the current selected directory is traversable > and if not it goes up to parent directory till top level and when every check > fails then null is set to `currentDirectory`. Should we think of modifying > this logic to not to set to null, rather remain in previously valid > folder......?
Well, the logic there tries to prevent the current directory from becoming `null`. Yet it traverses up the tree: https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L603-L607 Probably, if `dir` becomes `null` in the end, it should resort to its default behaviour: `getFileSystemView().getDefaultDirectory()`. Or not change at all? Then, you can handle the situation here: if `getFileChooser().getCurrentDirectory()` returns `null`, restore the previous current directory. And what about other L&F? If the same code runs in Windows L&F, Nimbus L&F, any other? ------------- PR: https://git.openjdk.org/jdk/pull/10485
