Vincent Massol wrote:
Ok. Here is my use case :
<configurationFactory>
<bundle id="short name1"
[language="language1"]
[country="Country1"]>
/path/to/bundle1
</bundle>
</configurationFactory>
In the implementation code I'd like to take one action if no
language/country are specified and another if they are (because behind
the scenes I need to call an API which has 2 signatures, one with a
Locale and one without - I don't want to get the default locale and only
use the signature that accepts a locale as this would mean I override
the default implementation of the API I'm referring to as I would
introduce my own logic).
The single parameter method is only a shortcut for what you are really
doing. It is not your "own" logic per se.
In your case, the ResourceBundle.getBundle(String) method is exactly the
same as:
getBundle(baseName, Locale.getDefault(), this.getClass().getClassLoader())
As it says directly in the JavaDocs. The Locale is a bit different if
you are not using the default because you have to have a language, but
can further specify it with a country or variant.
In this particular case, I might do something like this:
Locale defLocale = Locale.getDefault();
String language = conf.getAttribute("language", defLocale.getLanguage());
String country = conf.getAttribute("country", defLocale.getCountry());
Locale usedLocale = new Locale(language, country);
getBundle(baseName, usedLocale);
Ideally, you would have a static constants interface that would define your
default language/country:
interface Constants
{
String DEFAULT_LANGUAGE = Locale.getDefault().getLanguage();
String DEFAULT_COUNTRY = Locale.getDefault().getCountry();
}
I can imagine lots of cases where you would need to verify if an
attribute exists because you may want to do something different if it
does than if it does not.
We would have to vote on adding the "boolean attributeExists()" method
to Configuration. It might not happen, and I am +0 on it. I'm not
going to stand in it's way, but not totally convinced it's necessary.
Ok about immutability :)
Forget about hashtable. Isn't there an ImmutableHashtable in a utility
class anywhere that would have the same API save for the write methods ?
java.util.Collections.unmodifiableMap(Map)
And for this purpose is a hack.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
