<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