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