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