RFR: 6616245: NullPointerException when using JFileChooser with a custom FileView [v2]

Alexey Ivanov aivanov at openjdk.org
Mon Oct 3 12:13:24 UTC 2022


On Mon, 3 Oct 2022 12:07:10 GMT, Tejesh R <tr at openjdk.org> wrote:

>> 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?
>
> In other L&F the same problem exist, but NPE is does not occurs because previous state check is not done, directly the clicked file is been set. 
> https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java#L1328

> 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?

This behaviour is specified. https://github.com/openjdk/jdk/blob/ccc1d3169691d066c08e294f5d989b007bfab114/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L576-L580

Yet it doesn't take into account a custom implementation of `FileSystem` which does not allow navigating up. It may be a problem in `FileSystem` implementation.

-------------

PR: https://git.openjdk.org/jdk/pull/10485



More information about the client-libs-dev mailing list