Reminder: i18n strawman

Stanley M. Ho stanley.ho at Sun.COM
Tue May 15 23:35:31 PDT 2007


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.



More information about the jsr277-eg-observer mailing list