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

Mandy Chung mandy.chung at oracle.com
Mon Dec 19 16:14:54 UTC 2016


> On Dec 19, 2016, at 5:59 AM, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
>> Sergey,
>> 
>> I suggest to update the spec of UIDefaults::addResourceBundle to:
>> 
>> Adds a resource bundle to the list of resource bundles that are 
>> searched for localized values. Resource bundles are searched in 
>> the reverse order they were added, using the {@linkplain ClassLoader#getSystemClassLoader application class loader}. 
>> In other words, the most recently added bundle is searched first.
>> 

This suggests spec clarification not only applies to internal implementation but also reflects the resource encapsulation in JDK 9. java.desktop can’t access to any normal module besides itself unless they are open for it to access.

This spec clarification is useful.

Mandy

>> ——
>> 
>> Resource bundles in named module are encapsulated.  So resource
>> bundles in java.desktop can’t be accessed by user code.  The above
>> spec change will cover this change.   This API should be revisited
>> when there is a need to access resource bundles in user-defined 
>> module in the future (you may want to file a RFE for it).
> 
> I am not sure that we should update the spec to clarify its internal implementation, because right now it is unclear how it should work in modules world, when the custom look&feel will be stored in a separate module.
> This is only the fix for a theoretical security issue, if it is not critical then I prefer to leave the code as is. Or just apply the current change, and leave the possibility to future changes
> 
>> 
>> As for UIDefaults::removeResourceBundle, just an idea to address
>> Semyon’s concern of the inconsistency.  Perhaps we want to separate
>> the builtin java.desktop resource bundles from the resourceBundles 
>> list so that it can’t be removed.  In other words, only the ones
>> added by user code can be removed.
> 
> This change adds unnecessary limitation in UIDefault class, since the problem exists when the user can register internal model which cannot be accessed directly.




More information about the swing-dev mailing list