Reminder: i18n strawman

[Bryan Atsatt]

ListResourceBundle cannot be demoted to second-class citizen status in
the module system (Perhaps you haven't seen my earlier response?).

There is a solution to the split package problem, and, while it does
change the development model slightly, I think that is in line with the
more significant model change of moving to a module system...

Introduce a package naming convention for resource bundles deployed as
modules. The convention would allow ResourceBundle.getBundle() to easily
map from the "base" name to the actual bundle package name.

For example, if we introduce the convention that resource bundle "base"
names are mapped such that "resources" is appended to the package name,
then calling ResourceBundle.getBundle with:

   "com.acme.MyResources"

Would actually search for resources with the base name:

   "com.acme.resources.MyResources"

thus sidestepping the split package issue.

Yes, this requires developers to actually define their resources using
this naming convention, but I don't see that as a significant burden.
Especially when you consider the benefit of not having to package all
translations in the primary module.

To avoid potential package name collisions, we should consider using a
more distinct name than simply "resources", e.g.:

   "com.acme.resource_bundle.MyResources"
   "com.acme.module_resources.MyResources"
   "com.acme._resources_.MyResources"

// Bryan



Stanley M. Ho wrote:
> On Tue, 15 May 2007 07:22:49 -0700, Michal Cierniak <cierniak at GOOGLE.COM> wrote:
>
>> Glyn, thanks for pointing this out!
>>
>> Stanley, do you think that we could restrict the uses of the
>> ResourceBundle API in this context to not load code?
>
> Michal, since we will define the actual requirements for the ResourceBundle
> API changes in Java SE 7, we could certainly restrict the usage of
> ListResourceBundle in the ResourceBundle API when the target module attempts
> to load resource bundles from the resource modules.
>
> I have briefly talked to the folks in the i18n team in Java SE, and their
> impression was that PropertyResourceBundle is much more commonly used than
> ListResourceBundle among developers. However, there are some applications
> (including the JDK) relying on ListResourceBundle, so supporting
> PropertyResourceBundle alone in the module system may not be a sufficient
> solution.
>
>> For the context: my recollection is that we had a consensus to not
>> allow split packages but since this discussion took place a long time
>> ago, it could be that I don't remember it well.
>>
>> Michal
>
> Right. The EG has the consensus on not to support split packages in the
> module system. So far, we have only enforced the policy on shallow
> validation, so module cannot import other modules with split packages. I
> don't think we want to alter this policy in type consistency validation, as
> it does simplify our general design a bit. That said, I think the question
> for the EG is whether we want to enforce the no-split-packages policy across
> the board (and drop the ListResourceBundle support as a result), or enforce
> the policy only during type consistency validation and make split packages a
> special case in loading class-based resource bundles through the
> ResourceBundle API.
>
> - Stanley
>
> P.S. This is a repost. Apparently, I have email problems with jcp.org again,
> and please ignore if you receive more than one copy of my reply.
>