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.
