> On Dec 19, 2016, at 5:59 AM, Sergey Bylokhov <sergey.bylok...@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.
