On 29.11.16 17:21, Alexandr Scherbatiy wrote:
On 11/28/2016 7:41 PM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk9.
This fix improve encapsulation of java.desktop module. After the fix
the method "UIDefaults::addResourceBundle()" will not be able to
register resource bundles which are located in the java.desktop
module. Only the java.desktop module itself will be able to use such
bundles.
- Will it break existed applications?
The risk exists, if the application(or custom l&f) uses resource bundle
from the java.desktop module. But these bundles were not a part of
specification(the are located in non-public packages) and a content is
not specified as well. The possible workaround for this is to have an
application/L&f specific bundle. Or to use UIDefault.put(key,value) to
use some non-default values.
- Is it a common case that some applications register resource bundles
from JDK?
I do not found the usage of UID.addResourceBundle() which register an
internal bundles.
- What is the reason that resource bundles from JDK are not supposed
to be registered by external applications?
This is internal data which are not exported by the public api in thd
java.desktop module.
- Is it applicable for all JDK bundles or it should be allowed to load
bundles for public L&Fs like Metal and not for internal (Windows)?
It is applicable for all, because we do not have the public bundles.
- Was there the similar issue before the modularization? For example
an application is not supposed to load internal Java resource bundles if
the security manager is set.
Yes, there was such restriction.
--
Best regards, Sergey.
