<Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString

semyon.sadetsky at oracle.com semyon.sadetsky at oracle.com
Wed Mar 7 19:34:40 UTC 2018


I just noticed that null returning scenario only possible when locale 
independent state name is null but the latter should never happen. So we 
simply may ignore this null/NPE worry.

--Semyon


On 3/7/18 11:17 AM, semyon.sadetsky at oracle.com wrote:
>
> On 3/7/18 10:40 AM, Sergey Bylokhov wrote:
>
>> On 07/03/2018 10:21, semyon.sadetsky at oracle.com wrote:
>>>> That's not ok, since we change a behavior without discussion that 
>>>> the benefits of change outweigh the disadvantages, when we 
>>>> implemented some unrelated fix.
>>> That's not true. You may find the discussion in the current thread. 
>>> Fill free to provide your arguments to it.
>>
>> I found nothing related to the behavior, only some conclusion about 
>> possible performance difference.
> So you agree?
>>
>>>>> It is an improvement. NPE is not expected result according to the 
>>>>> toDisplayString() method spec.
>>>>
>>>> It also changed result of toDisplayString(), previously it did not 
>>>> returned null. I think .01 is better and simpler.
>>>>
>>> Returning null is better than throwing NPE especially in the case 
>>> when NPE doesn't correspond to the spec. Krishna kindly agreed to 
>>> fix both issues at once. I didn't get what is the problem?
>>
>> Nope, if the method start to return null means that all its usage 
>> should be checked for null return value. 
> You always should check for null return if the spec does not say that 
> null is never returned. In this specific case if null check is absent 
> the NPE will be thrown in the user code instead of JDK code, so there 
> is no degradation.
>> As I said it is better to use version .01 which fixed the problem w/o 
>> side effects.
>>
> Thanks for your advice. Try to provide more arguments next time.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180307/93762ac6/attachment.html>


More information about the swing-dev mailing list