The fix looks good to me.

I suggest to investigate the case where old applications can be broken and provide a public API for all valid cases.

Thanks,
Alexandr.

On 11/30/2016 7:30 PM, Sergey Bylokhov wrote:
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.




Reply via email to