Reminder: i18n strawman

[Stanley M. Ho]

Hi Michal,

Yes, the i18n strawman currently assumes that the class-based resource
bundles in multiple modules are in the same Java package (but each with
different superpackage membership), and this is consistent with the
existing practice in using the java.util.ResourceBundle API.

Based on the earlier EG discussions, we have agreed to explicitly
disallow split packages during shallow validation so developers are not
encouraged to use them and we don't have to deal with all the issues
that split packages may cause. However, the existing i18n practice
somewhat contradicts what we encourage developers to do.

That said, this may not be a big problem after all, since split packages
would still be disallowed during module initialization. This also
implies that a target module can't import resource modules directly and
must rely on the ResourceBundle API to look up resources, and personally
I think this is acceptable (if other EG members have different opinions,
I would like to hear them). Therefore, we could still discourage split
packages in general and only let developers use them in this special case.

The obvious alternative is to require class-based resource bundles in
multiple modules to be in different Java packages. Unfortunately, this
is incompatible with the existing practice in translating resource
bundles, and I'm concerned that this would hurt adoption.

What do you think?

- Stanley


Michal Cierniak wrote:
> Stanley,
>
> It is not clear to me from the doc if i8n relies on the assumption
> that a package may be split across multiple modules.  Can you clarify?
>
> Thanks,
> Michal