I am working on a very ambitious project, in which I have loads of services, that will be loaded using instances of a class; let's call it Tag. You could compare this architecture to how formats, calendars, currencies, etc. are loaded by providers (e.g. NumberFormatProvider, CurrencyNameProvider) using Locale.
Now, I'm in a situation where I'd like to use Properties, depending on a Tag. The thing is, I want to make these Properties default to ancestor Properties. Basically what I need, is a class that's to Tag what ResourceBundle is to Locale. So why not use Locale and ResourceBundle? The mechanics are exactly what I need, but Tag simply has nothing to do with languages or countries.
I would really have liked that ResourceBundle worked with Strings, rather than Locales, but here we are. Now, to avoid making the same mistake, I'm thinking of writing a class PropertiesBundle that takes Strings, rather than Tags, and have my Tag class return a tag String.
I'm curious what you think of this approach, if you have better ideas, suggestions or hints, or if you know if someone already made something like this. What I found so far online were poorly written classes that I really don't want to add to my project.
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
Maybe I'm missing an important detail, but a Properties object can contain another Properties object which it uses for defaults. (After 30 seconds of thinking) I don't see any reason why this can't be used hierarchically -- i.e. the Properties object which is used for defaults could itself use a third Properties object for defaults? And no, I haven't thrown together the sample code to test this theory either.
Yes, I am going to use a chain of Properties instances, but I want to wrap it in a class that hides the chain, and initializes it using a tag String such as "com.example.a_b_c". It will have the exact same functionality as PropertiesResourceBundle.
Do you suppose it's nicer to supply the application with my own (or preferably a third party's) version of PropertiesResourceBundle, or just a class that provides a Properties instance based on a Tag instance?
Personally I prefer the former, because I don't like the mutable nature of Properties, nor the bogus methods that come with it, which I'd like to abstract away. I'm guessing it's a matter of taste, but I'm building my application with opinions of others in mind.
If you need a subclass of ResourceBundle, I still don't think I would subclass PropertyResourceBundle to do what you want. Unless you actually need its built-in capability to read a Properties file from an InputStream or Reader, that is. If you're going to have a customized way of initializing the object then I think I would just subclass ResourceBundle. Or maybe even just invent your own class which is like Properties and/or ResourceBundle but only has the methods you really need. And yeah, I agree with you that I would probably wrap my chain of Properties objects into something less Java-1-like.