On 19.12.2016 16:50, Sergey Bylokhov wrote:
16 дек. 2016 г., в 9:35, Semyon Sadetsky <[email protected]>
написал(а):
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?
My point is that there are no secrets, but the bug description states that such
bundles can be added some day later.
But what secret can be here?
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.
There are no compatibility issues which contradicts the specification, because
all our resource bundles are private(unspecified), they are located in the
com.XXX packages and all of them can be changed/removed in any time.
The fix blocks resources form all desktop module packages not only from
"com.XXX", doesn't it?
