Reminder: i18n strawman

Michal Cierniak cierniak at
Mon May 14 16:36:51 PDT 2007

I think that it's reasonable if we decide that the only way that split
packages may manifest themselves is as resources via the
ResourceBundle API.  I was worried about code for the same package
coming from multiple modules but it seems that you're not suggesting


On 5/14/07, Stanley M. Ho <Stanley.Ho at> wrote:
> 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

More information about the jsr277-eg-observer mailing list