<br><font size=2 face="sans-serif">The ResourceBundle API does not only
use resource (*.properties) lookups. It also attempts class loads
to find resource bundles, effectively needing to load classes from a split
package.</font>
<br><font size=2 face="sans-serif"><br>
Glyn</font>
<br>
<br><font size=1 face="sans-serif"><b>Michal Cierniak <cierniak@GOOGLE.COM></b></font><tt><font size=2>
wrote on 15/05/2007 00:36:51:<br>
<br>
> I think that it's reasonable if we decide that the only way that split<br>
> packages may manifest themselves is as resources via the<br>
> ResourceBundle API. I was worried about code for the same package<br>
> coming from multiple modules but it seems that you're not suggesting<br>
> this.<br>
> <br>
> Thanks!<br>
> Michal<br>
> <br>
> On 5/14/07, Stanley M. Ho <Stanley.Ho@sun.com> wrote:<br>
> > Hi Michal,<br>
> ><br>
> > Yes, the i18n strawman currently assumes that the class-based
resource<br>
> > bundles in multiple modules are in the same Java package (but
each with<br>
> > different superpackage membership), and this is consistent with
the<br>
> > existing practice in using the java.util.ResourceBundle API.<br>
> ><br>
> > Based on the earlier EG discussions, we have agreed to explicitly<br>
> > disallow split packages during shallow validation so developers
are not<br>
> > encouraged to use them and we don't have to deal with all the
issues<br>
> > that split packages may cause. However, the existing i18n practice<br>
> > somewhat contradicts what we encourage developers to do.<br>
> ><br>
> > That said, this may not be a big problem after all, since split
packages<br>
> > would still be disallowed during module initialization. This
also<br>
> > implies that a target module can't import resource modules directly
and<br>
> > must rely on the ResourceBundle API to look up resources, and
personally<br>
> > I think this is acceptable (if other EG members have different
opinions,<br>
> > I would like to hear them). Therefore, we could still discourage
split<br>
> > packages in general and only let developers use them in this
special case.<br>
> ><br>
> > The obvious alternative is to require class-based resource bundles
in<br>
> > multiple modules to be in different Java packages. Unfortunately,
this<br>
> > is incompatible with the existing practice in translating resource<br>
> > bundles, and I'm concerned that this would hurt adoption.<br>
> ><br>
> > What do you think?<br>
> ><br>
> > - Stanley<br>
> ><br>
> ><br>
> > Michal Cierniak wrote:<br>
> > > Stanley,<br>
> > ><br>
> > > It is not clear to me from the doc if i8n relies on the
assumption<br>
> > > that a package may be split across multiple modules. Can
you clarify?<br>
> > ><br>
> > > Thanks,<br>
> > > Michal<br>
> ><br>
</font></tt><font size=3 face="sans-serif"><br>
</font>
<br><font size=3 face="sans-serif"><br>
</font>
<hr><font size=2 face="sans-serif"><br>
<i><br>
</i></font>
<p><font size=2 face="sans-serif"><i>Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font>
<p><font size=2 face="sans-serif"><br>
</font><font size=3 face="sans-serif"><br>
</font>
<br>
<br><font size=3 face="sans-serif"><br>
</font>