<Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

[Semyon Sadetsky]

On 14.12.2016 20:11, Sergey Bylokhov wrote:

>>> Interesting. Does it mean that if I register some custom resource bundle
>>>>>>>> it will not affect any UI values because all the values is already
>>>>>>>> cached in some UIDefaults map, is that what you mean?
>>>>>>>
>>>>>>> The cache will be cleared when you register a new bundle.
>>>>>> And if bundle remove the cache is not cleared?
>>>>>
>>>>> If bundle is removed from the list of bundles then the cache will 
>>>>> be cleared as well.
>>>> Nice. Why the remove method is not modified in the fix?
>>>
>>> Why it should be modified? It does not expose an internal resource 
>>> bundles and allow the user to modify the list of bundles in the 
>>> UIDefaults.
>> Then why addResourceBundle() is modified to ***not***
>> > allow the user to modify the list of bundles in the UIDefaults.
>> ?
>
> Because addResourceBundle() was modified to «not» allow the users to 
> expose internal resource bundles(for example the users are not able to 
> read content of some random bundle), only if internal bundles were 
> registered already by java.desktop the user will be able to 
> change/override/remove the data in UIDefauls since this data is 
> accessible already to him(via custom resource bundle or via 
> UIDefault.put(key,value) or via removeResourceBundle()).
Why not to allow user to load any resource bundle from the java.desktop 
module assuming that we allow user to modify UIDefaults resource bandles 
arbitrary? Which violation may take place because of still enabling this?

Why specification of the addResourceBundle() doesn't reflect this 
limitation? It is obvious that the fix bears impact in compatibility.


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