On 30.11.2016 20:25, Mandy Chung wrote:

On Nov 30, 2016, at 8:55 AM, Semyon Sadetsky <semyon.sadet...@oracle.com> wrote:



On 30.11.2016 19:34, Sergey Bylokhov wrote:
On 30.11.16 9:52, Semyon Sadetsky 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.
I'm just curios. The UIDefaults::addResourceBundle() violates
encapsulation but UIDefaults::removeResourceBundle() doesn't?
The fix changes encapsulation of resources bundles inside java.desktop module. 
The UIDefaults::addResourceBundle() is a way to expose internal bundles(if the 
user requests the internal bundle he will be able to read it). The fix does not 
change the state of UIDefaults, the users will be able to register/put/remove 
everything they want.
I didn't mean state of UIDefaults. I meant loading/unloading of an internal 
resources bundle externally.
The fix disables the loading of internal bundle outside the java.desktop module 
to improve module encapsulation, but it is still allowed to remove internal 
bundle externally. That looks odd.
Would anyone do that?  I suppose if the java.desktop resource bundles are 
removed, things would be broken in some ways.
Not sure that it brakes something. LnF usually has defaults values for all properties or values from another bundle may be used. But if encapsulation is the purpose of the bug the fix should not allow to remove an internal module bundle if called outside the module.

Mandy

Reply via email to