Hi Sergey/Semyon,
I have pushed webrev01 which simply fixes the bug as reported, and created a new issue JDK-8199400 to address the point of changing Hashtable to HashMap. Once we are clear about the changes, we can push them with this bug. Thanks, Krishna From: Krishna Addepalli Sent: Thursday, March 8, 2018 6:01 AM To: Semyon Sadetsky <[email protected]>; Sergey Bylokhov <[email protected]>; Philip Race <[email protected]> Cc: [email protected] Subject: RE: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString Hi Sergey, I understand the behavior change of raising an exception vs quietly returning null. As per my understanding, this happens only when someone passes a null for the locale key right? If so, how about explicitly checking for null, and throwing exception? @Semyon, I think we should address this change in a separate bug, since we want behavior question answered. Thanks, Krishna From: Semyon Sadetsky Sent: Thursday, March 8, 2018 1:05 AM To: Sergey Bylokhov <HYPERLINK "mailto:[email protected]"[email protected]>; Krishna Addepalli <HYPERLINK "mailto:[email protected]"[email protected]>; Philip Race <HYPERLINK "mailto:[email protected]"[email protected]> Cc: HYPERLINK "mailto:[email protected]"[email protected] Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString 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, HYPERLINK "mailto:[email protected]"[email protected] wrote: On 3/7/18 10:40 AM, Sergey Bylokhov wrote: On 07/03/2018 10:21, HYPERLINK "mailto:[email protected]"[email protected] 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.
