> On Dec 15, 2016, at 10:35 PM, Semyon Sadetsky <semyon.sadet...@oracle.com>
> wrote:
>
> On 15.12.2016 13:19, Sergey Bylokhov wrote:
>
>>>> 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?
>> Because it is a way to read the data from internal resource bundle. The user
>> can load this data to UIDefaults and read it. This is unrelated to the
>> modification of UIDefault itself, it is related to the fact that private
>> data can be read.
> If this private data can be loaded to the UIDefaults or to other class then
> it will be read anyway. Are the Swing/AWT properties files content really
> secret?
>
>>> Why specification of the addResourceBundle() doesn't reflect this
>>> limitation? It is obvious that the fix bears impact in compatibility.
>> The current spec will allow us to revert back the fix, if the impact on the
>> applications will be hight, but for now it is not expected.
> This is not a correct approach. If you are really sure that the method should
> have this restriction to not allow to load any internal resources externally,
> please present it in the spec. Potential compatibility issues you can address
> by introducing a new system property.
Sergey,
I suggest to update the spec of UIDefaults::addResourceBundle to:
Adds a resource bundle to the list of resource bundles that are
searched for localized values. Resource bundles are searched in
the reverse order they were added, using the {@linkplain
ClassLoader#getSystemClassLoader application class loader}.
In other words, the most recently added bundle is searched first.
——
Resource bundles in named module are encapsulated. So resource
bundles in java.desktop can’t be accessed by user code. The above
spec change will cover this change. This API should be revisited
when there is a need to access resource bundles in user-defined
module in the future (you may want to file a RFE for it).
As for UIDefaults::removeResourceBundle, just an idea to address
Semyon’s concern of the inconsistency. Perhaps we want to separate
the builtin java.desktop resource bundles from the resourceBundles
list so that it can’t be removed. In other words, only the ones
added by user code can be removed.
Mandy
