<Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

<Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Sergey Bylokhov
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.

Bug: https://bugs.openjdk.java.net/browse/JDK-8149879
Webrev can be found at: http://cr.openjdk.java.net/~serb/8149879/webrev.01

--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Alexandr Scherbatiy
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?
   - Is it a common case that some applications register resource
bundles from JDK?
   - What is the reason that resource bundles from JDK are not supposed
to be registered by external applications?
   - 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)?
   - 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.

   Thanks,
   Alexandr.

>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8149879
> Webrev can be found at:
> http://cr.openjdk.java.net/~serb/8149879/webrev.01
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Mandy Chung
In reply to this post by Sergey Bylokhov
Looks okay to me.

Mandy

> On Nov 28, 2016, at 8:41 AM, Sergey Bylokhov <[hidden email]> 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.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8149879
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8149879/webrev.01
>
> --
> Best regards, Sergey.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Phil Race
In reply to this post by Sergey Bylokhov
+1

-phil.

On 11/28/2016 08:41 AM, 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.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8149879
> Webrev can be found at:
> http://cr.openjdk.java.net/~serb/8149879/webrev.01
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Semyon Sadetsky
In reply to this post by Sergey Bylokhov
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?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8149879
> Webrev can be found at:
> http://cr.openjdk.java.net/~serb/8149879/webrev.01
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Sergey Bylokhov
In reply to this post by Alexandr Scherbatiy
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Sergey Bylokhov
In reply to this post by Semyon Sadetsky
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.


--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Semyon Sadetsky


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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Mandy Chung

> On Nov 30, 2016, at 8:55 AM, Semyon Sadetsky <[hidden email]> 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.

Mandy
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Sergey Bylokhov
In reply to this post by Semyon Sadetsky
On 30.11.16 19:55, Semyon Sadetsky wrote:

>> 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.

The user cannot remove internal bundle from the java.desktop, but he can
modify the UIDefaults so the data which was loaded from the internal
bundle will not be used. The user can:
  - put key/value pair which override internal data.
  - register other bundle which override internal bundle.
  - Clear the list of bundles.

--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Semyon Sadetsky
In reply to this post by Mandy Chung
On 30.11.2016 20:25, Mandy Chung wrote:

>> On Nov 30, 2016, at 8:55 AM, Semyon Sadetsky <[hidden email]> 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 | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Semyon Sadetsky
In reply to this post by Sergey Bylokhov
On 30.11.2016 20:33, Sergey Bylokhov wrote:

> On 30.11.16 19:55, Semyon Sadetsky wrote:
>>> 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.
>
> The user cannot remove internal bundle from the java.desktop,
Why user cannot remove it? The method is exported.
> but he can modify the UIDefaults so the data which was loaded from the
> internal bundle will not be used. The user can:
>  - put key/value pair which override internal data.
>  - register other bundle which override internal bundle.
>  - Clear the list of bundles.
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Sergey Bylokhov
On 30.11.16 20:39, Semyon Sadetsky wrote:
>> The user cannot remove internal bundle from the java.desktop,
> Why user cannot remove it? The method is exported.

Do we talking about UIDefaults.removeResourceBundle()? This method
removes the name of the bundle from the Vector in UIDefault, so when the
data will be requested via UIDefaults.get() an internal resource bundle
will not be used. This method can be used in situations when the
application/L&F want to remove predefined data for some reason. The
bundle itself will be available in java.desktop module, and will be
registered again when some of our l&f will be set.
The purpose of the fix is to encapsulate the java.desktop module itself,
not the data which were loaded already to the UIDefaults map.

>> but he can modify the UIDefaults so the data which was loaded from the
>> internal bundle will not be used. The user can:
>>  - put key/value pair which override internal data.
>>  - register other bundle which override internal bundle.
>>  - Clear the list of bundles.
>>
>


--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Semyon Sadetsky


On 30.11.2016 20:51, Sergey Bylokhov wrote:

> On 30.11.16 20:39, Semyon Sadetsky wrote:
>>> The user cannot remove internal bundle from the java.desktop,
>> Why user cannot remove it? The method is exported.
>
> Do we talking about UIDefaults.removeResourceBundle()? This method
> removes the name of the bundle from the Vector in UIDefault, so when
> the data will be requested via UIDefaults.get() an internal resource
> bundle will not be used. This method can be used in situations when
> the application/L&F want to remove predefined data for some reason.
> The bundle itself will be available in java.desktop module, and will
> be registered again when some of our l&f will be set.
> The purpose of the fix is to encapsulate the java.desktop module
> itself, not the data which were loaded already to the UIDefaults map.
Interesting. Does it mean that if I register some custom resource bundle
it will not affect any UI values because all the values is already
cached in some UIDefaults map, is that what you mean?

>
>>> but he can modify the UIDefaults so the data which was loaded from the
>>> internal bundle will not be used. The user can:
>>>  - put key/value pair which override internal data.
>>>  - register other bundle which override internal bundle.
>>>  - Clear the list of bundles.
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Sergey Bylokhov
On 30.11.16 21:12, Semyon Sadetsky wrote:

> On 30.11.2016 20:51, Sergey Bylokhov wrote:
>> On 30.11.16 20:39, Semyon Sadetsky wrote:
>>>> The user cannot remove internal bundle from the java.desktop,
>>> Why user cannot remove it? The method is exported.
>>
>> Do we talking about UIDefaults.removeResourceBundle()? This method
>> removes the name of the bundle from the Vector in UIDefault, so when
>> the data will be requested via UIDefaults.get() an internal resource
>> bundle will not be used. This method can be used in situations when
>> the application/L&F want to remove predefined data for some reason.
>> The bundle itself will be available in java.desktop module, and will
>> be registered again when some of our l&f will be set.
>> The purpose of the fix is to encapsulate the java.desktop module
>> itself, not the data which were loaded already to the UIDefaults map.
> Interesting. Does it mean that if I register some custom resource bundle
> it will not affect any UI values because all the values is already
> cached in some UIDefaults map, is that what you mean?

The cache will be cleared when you register a new bundle.

>>
>>>> but he can modify the UIDefaults so the data which was loaded from the
>>>> internal bundle will not be used. The user can:
>>>>  - put key/value pair which override internal data.
>>>>  - register other bundle which override internal bundle.
>>>>  - Clear the list of bundles.
>>>>
>>>
>>
>>
>


--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Semyon Sadetsky


On 01.12.2016 02:52, Sergey Bylokhov wrote:

> On 30.11.16 21:12, Semyon Sadetsky wrote:
>> On 30.11.2016 20:51, Sergey Bylokhov wrote:
>>> On 30.11.16 20:39, Semyon Sadetsky wrote:
>>>>> The user cannot remove internal bundle from the java.desktop,
>>>> Why user cannot remove it? The method is exported.
>>>
>>> Do we talking about UIDefaults.removeResourceBundle()? This method
>>> removes the name of the bundle from the Vector in UIDefault, so when
>>> the data will be requested via UIDefaults.get() an internal resource
>>> bundle will not be used. This method can be used in situations when
>>> the application/L&F want to remove predefined data for some reason.
>>> The bundle itself will be available in java.desktop module, and will
>>> be registered again when some of our l&f will be set.
>>> The purpose of the fix is to encapsulate the java.desktop module
>>> itself, not the data which were loaded already to the UIDefaults map.
>> Interesting. Does it mean that if I register some custom resource bundle
>> it will not affect any UI values because all the values is already
>> cached in some UIDefaults map, is that what you mean?
>
> The cache will be cleared when you register a new bundle.
And if bundle remove the cache is not cleared?

>
>>>
>>>>> but he can modify the UIDefaults so the data which was loaded from
>>>>> the
>>>>> internal bundle will not be used. The user can:
>>>>>  - put key/value pair which override internal data.
>>>>>  - register other bundle which override internal bundle.
>>>>>  - Clear the list of bundles.
>>>>>
>>>>
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Alexandr Scherbatiy
In reply to this post by Sergey Bylokhov

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 | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Sergey Bylokhov
In reply to this post by Semyon Sadetsky

30 нояб. 2016 г., в 23:11, Semyon Sadetsky <[hidden email]> написал(а):



On 01.12.2016 02:52, Sergey Bylokhov wrote:
On 30.11.16 21:12, Semyon Sadetsky wrote:
On 30.11.2016 20:51, Sergey Bylokhov wrote:
On 30.11.16 20:39, Semyon Sadetsky wrote:
The user cannot remove internal bundle from the java.desktop,
Why user cannot remove it? The method is exported.

Do we talking about UIDefaults.removeResourceBundle()? This method
removes the name of the bundle from the Vector in UIDefault, so when
the data will be requested via UIDefaults.get() an internal resource
bundle will not be used. This method can be used in situations when
the application/L&F want to remove predefined data for some reason.
The bundle itself will be available in java.desktop module, and will
be registered again when some of our l&f will be set.
The purpose of the fix is to encapsulate the java.desktop module
itself, not the data which were loaded already to the UIDefaults map.
Interesting. Does it mean that if I register some custom resource bundle
it will not affect any UI values because all the values is already
cached in some UIDefaults map, is that what you mean?

The cache will be cleared when you register a new bundle.
And if bundle remove the cache is not cleared?

If bundle is removed from the list of bundles then the cache will be cleared as well.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Semyon Sadetsky



On 06.12.2016 23:00, Sergey Bylokhov wrote:

30 нояб. 2016 г., в 23:11, Semyon Sadetsky <[hidden email]> написал(а):



On 01.12.2016 02:52, Sergey Bylokhov wrote:
On 30.11.16 21:12, Semyon Sadetsky wrote:
On 30.11.2016 20:51, Sergey Bylokhov wrote:
On 30.11.16 20:39, Semyon Sadetsky wrote:
The user cannot remove internal bundle from the java.desktop,
Why user cannot remove it? The method is exported.

Do we talking about UIDefaults.removeResourceBundle()? This method
removes the name of the bundle from the Vector in UIDefault, so when
the data will be requested via UIDefaults.get() an internal resource
bundle will not be used. This method can be used in situations when
the application/L&F want to remove predefined data for some reason.
The bundle itself will be available in java.desktop module, and will
be registered again when some of our l&f will be set.
The purpose of the fix is to encapsulate the java.desktop module
itself, not the data which were loaded already to the UIDefaults map.
Interesting. Does it mean that if I register some custom resource bundle
it will not affect any UI values because all the values is already
cached in some UIDefaults map, is that what you mean?

The cache will be cleared when you register a new bundle.
And if bundle remove the cache is not cleared?

If bundle is removed from the list of bundles then the cache will be cleared as well.
Nice. Why the remove method is not modified in the fix?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> [9] Review Request: 8149879 Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation

Sergey Bylokhov
Interesting. Does it mean that if I register some custom resource bundle
it will not affect any UI values because all the values is already
cached in some UIDefaults map, is that what you mean?

The cache will be cleared when you register a new bundle.
And if bundle remove the cache is not cleared?

If bundle is removed from the list of bundles then the cache will be cleared as well.
Nice. Why the remove method is not modified in the fix?

Why it should be modified? It does not expose an internal resource bundles and allow the user to modify the list of bundles in the UIDefaults.
12
Loading...