<Swing Dev> [12] RFR JDK-8192888: AllSwingComponentsBaselineTest fails with NullPointerException for NimbusLookAndFeel

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Wed Oct 31 15:36:49 UTC 2018


On 31/10/2018 03:19, Prasanta Sadhukhan wrote:
> I tested on windows 10 and mac10.13 and the test passed. Not sure why it will fail on mach5 system. It complains about NPE which can be checked and prevented but am not seeing it locally so should I fix it blindly?

Is it possible that the reason in the headless mode which is used in mach5? note that this is not necessary a test issue.

> 
> Regards
> Prasanta
> On 31-Oct-18 3:04 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> Looks like this test started to fail on our mach5 systems, please take a look.
>>
>> On 22/10/2018 11:39, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Thank you for investigation, the fix looks fine.
>>>
>>> On 21/10/2018 22:52, Prasanta Sadhukhan wrote:
>>>> Hi Sergey,
>>>>
>>>> I saw that in *ButtonUI class for all lookandfeels, we are caching the ui object and returning
>>>> AquaButtonUI - createUI() caches buttonUI via RecyclableSingletonFromDefaultConstructor<AquaButtonUI>(AquaButtonUI.class) which is returned everytime.
>>>> MotifButtonUI - createUI() caches in the same way as this fix
>>>> BasicButtonUI - createUI() caches in the same way as this fix
>>>> MetalButtonUI - createUI() caches in the same way as this fix
>>>> WindowsButtonUI - createUI() caches in the same way as this fix
>>>>
>>>> so I guess we should do the same for SynthButtonUI too as has been done in webrev.2 below.
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 15-Sep-18 5:39 AM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>> I have checked some other UI delegates(in Synth and others L&F), and found that sometimes result of createUI is cached, but sometimes not. Can you please describe some logic when to use or not to use cache?
>>>>>
>>>>> On 13/09/2018 00:20, Prasanta Sadhukhan wrote:
>>>>>> Yes. So, it seems getBaseline() gets null style because of this reason:
>>>>>>
>>>>>> When JButton is created, it calls JButton.updateUI() which calls UIManager.updateUI() which calls UIDefaults.getUI and it calls SynthButtonUI.createUI() which created a new SynthButtonUI everytime. SynthButtonUI.installDefaults() updates the style for this SynthButtonUI object.
>>>>>>
>>>>>> But in testcase, we again call UIManager.getUI(JButton) which again triggers the same flow culminating in SynthButtonUI.createUI which creates a new SynthButtonUI object with null style.
>>>>>>
>>>>>> Like in other look and feel ButtonUI for ex, MetalButtonUI, WindowsButtonUI, createUI should be updated not to create a new object everytime but to cache the object in appcontext and retrieves that instead of recreating everytime.
>>>>>> Modified webrev: http://cr.openjdk.java.net/~psadhukhan/8192888/webrev.2/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 13-Sep-18 1:18 AM, Sergey Bylokhov wrote:
>>>>>>> On 11/09/2018 22:03, Prasanta Sadhukhan wrote:
>>>>>>>>> Why SynthLookAndFeel.updateStyle() which is called in SynthButtonUI.updateStyle(AbstractButton b) did not update the context which is passed to it? Is it possible that SynthButtonUI.installDefaults() was not called before getBaseline()?
>>>>>>>>>
>>>>>>>> SynthButtonUI.updateStyle() called from SynthButtonUI.installDefaults() creates a new context whereas in getBaseline() we again calls getContext() in l207 which creates a new SynthContext, so the style was not updated to the context currently being queried in getBaseline()
>>>>>>>
>>>>>>> SynthButtonUI.updateStyle() creates a new context and at the same time updates the "SynthStyle.style", so the new SynthContext created in getBaseline() should use non-null "SynthStyle.style", no?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.


More information about the swing-dev mailing list