On Mon, 12 Dec 2022 17:30:14 GMT, Alexey Ivanov <aiva...@openjdk.org> wrote:
>> Observation found when JFileChooser is instantiated in WindowsLookAndFeel >> which invokes getSystemIcon() from WindowsFileChooserUI class. Could not >> find the exact root cause so predicting it to be an issue with icons not >> loaded where resolutionVariants map is empty in _public Image >> getResolutionVariant(double width, double height) _. Hence proposing a null >> check before accessing getWidth(). Fix is tested in CI system. > > At the same time, I suggest filing another bug to track the issue where the > code could return a `MultiResolutionImage` with no base image. It should > never happen. > > Or you can address it here along with making the test _headful_. > > @aivanov-jdk I just run some test samples by making the test as headful > > instead as headless as @prsadhuk suggested. I found out that making it as > > headful works just fine and no NPE occurred (Headless always showed issue, > > 8/200 test). And debugging to the root cause of Image not loading is also > > quite difficult. I guess it's better to modify the test as headful since > > the reliability of the test is better in it? > > Let's go for it. A headless system could lack something that the test uses > even though it doesn't show the UI. > > If _headful_ systems never reproduce the problem, then it's _the fix_. So far, from the analysis it is found that the backup mechanism to get default Icon is failing when icon extraction fails. Not able to get the trigger point for the failure since it is unpredictable. Failure rate also seems to be dependent on system, last week used to get consistent failures for every test run, this week the issue is not much. So I guess making the test headful is better option now. ------------- PR: https://git.openjdk.org/jdk/pull/11104
