<i18n dev> ResourceBundleProvider(s) design

[Peter Levart]

On 08/04/2016 11:21 AM, Peter Levart wrote:
> If the providing module declares the service type, then the consuming 
> module will have an explicit dependency on the providing module, which 
> also defeats the purpose of service provider's implicit coupling.

I take this back. The service type is resolved at runtime by the 
ResourceBundle code using the consumer module's class loader and then 
ResourceBundleProvider interface is used to invoke its method. But I 
still think that the "baseName" parameter to this method is superfluous.

I also see now that using resource bundle service providers is necessary 
if one wants to provide different modules for different languages 
covering a set of bundles - each language in its own module. Normally, 
for "java.class" format bundles, this would require per-language classes 
to be split among multiple modules and this is not possible as split 
packages are prohibited. With ResourceBundleProvider approach one can 
defined a ResourceBundleProvider service type in say "main language" 
module together with a default implementation and then various language 
implementations each in its own module with own package(s). For example:

module consumer {
     uses my.BundleProvider;
}
// containing:
package consumer;
public class Main {
     public static void main(String ... args) {
         ResourceBundle.getBundle("my.Bundle", Locale.getDefault());
     }
}


module my.bundle {
     exports my;
     provides my.BundleProvider with my.bundle.Bundle.Provider;
}
// containing:
package my;
public interface BundleProvider extends 
java.util.spi.ResourceBundleProvider {}


module my.bundle.en {
     requires my.bundle;
     provides my.BundleProvider with my.bundle.en.Bundle.Provider;
}


module my.bundle.de {
     requires my.bundle;
     provides my.BundleProvider with my.bundle.de.Bundle.Provider;
}


etc...


Regards, Peter