RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null'
Alexey Ivanov
aivanov at openjdk.org
Thu Dec 1 19:40:16 UTC 2022
On Wed, 30 Nov 2022 10:16:57 GMT, Tejesh R <tr at openjdk.org> wrote:
> > Do we need to wait a bit longer after creating JFileChooser as the test immediately ends after instantiating it? Also, doesn't JFileChooser needs headful keyword as it needs to show a file dialog? Does it work more reliably if its to run in headful CI systems?
>
> Should the test be headful even if we instantiate JFileChooser without showing the dialog.? I can check with a delay after its instantiated, but no sure if that might be causing the issue. Because the same issue is observed in another bug also which instantiates JFileChooser and does some tasks after that.
It doesn't need to be. It would've failed if it had required a headful system.
However, it may still be a valid concern. I faced some obscure failures on headless systems running Windows.
The exception is thrown on EDT when `JFileChooser` calculates its preferred size, so the test seem to work correctly. As such, I don't think the failure is related to the fact that the test exits after creating `JFileChooser`.
One of the options to fix the test is to add `@key headful`.
I wonder if the _Downloads_ folder is the first folder for which the icon is requested. Does fetching icons for other folders also fail? Does the host where the test fails have Windows Explorer? Windows Server systems can have minimal UI, if Windows Explorer is not available, then the `headful` keyword is the way to go.
So, we need to collect more data why it fails, why the icon of a folder is `null`.
In addition to that, we have to ensure `null` is returned directly to the caller rather than creating a `MultiResolutionImage` which doesn't even contain a base image.
-------------
PR: https://git.openjdk.org/jdk/pull/11104
More information about the client-libs-dev
mailing list