Reminder: i18n strawman

[Stanley M. Ho]

Michal Cierniak 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.

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 the 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 this policy 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 beyond type consistency validation (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