Greetings, I just stumbled upon the 1.4 Preferences class and its subclass AbstractPreferences. I like the scenario. But here are some questions for the kind souls who are familiar with this stuff: - would it be appropriate to call (the implemented) method exportNode() from within the (to be implemented) method flushSpi()? - how come that importPreferences() is implemented in the Preferences class itself, while exportPreferences() is implemented in the subclass AbstractPreferences()? As you'd probably noticed, Sun's Javadocs are puzzling me here on this subject. All I want to do/have, is a working Preferences subclass that allows me to add/delete/read preference values in a conforming way. Any ideas, tip, hints, anyone? All responses are truly appreciated. kind regards
Well, Ranch traffic is usually pretty slow on what is Friday afternoon/evening for those of us in the US. Also I suspect that most people who use Preferences haven't had any need to write their own implementation using AbstractPreferences - we just use the existing implementations. (Preferences.systemRoot(), Preferences.systemNodeForPackage(), etc.) That's true for me anyway. Are you sure that's not sufficient to your needs? You may want to check out this article from our own Thomas Paul for the basics of how to use Preferences (without creating your own implementation). Now if you really need to extends AbstractPreferences - well to be honest I only started using Preferences fairly recently, and never previously looked at AbstractPreferences. But of course I won't let that stop me from looking at the API and offering opinions anyway... - would it be appropriate to call (the implemented) method exportNode() from within the (to be implemented) method flushSpi()? Sounds reasonable to me, if you want to use the standard XML format for your backing store. (Not a requirement, but a reasonable default.) - how come that importPreferences() is implemented in the Preferences class itself, while exportPreferences() is implemented in the subclass AbstractPreferences()? I don't see exportPreferences() at all - but I see exportNode() and exportSubtree(). Which just raises further questions - why aren't the forms symmetric? I think this difference exists because at the time you decide to export, you need to choose whether to export just one Node, or all its subtrees as well. But when you import, you just specify the input stream, and the XML will specify exactly which Node(s) the data are associated with. I guess there's no way to say "import only the parts of this file that refer the system root node" for example - you just import everything in a file, into whatever Node it originally came from. Anyway, that seems to answer my question here (why not symmetric?) - but I still have no idea about the answer to your question (why in different classes?). Maybe someone else can help here.
Jim, thanks a bunch for your reply and the link to the article. After reading this article I came to realize that there is no need for writing my own Preferences implementation; I just missed the description of those static methods in Sun's JavaDocs. All problems solved ... thanks again and kind regards ps. sometimes I hate this catching up on 1.0 -- 1.1 -- 1.2 -- 1.3 -- 1.4 -- 1.5 (coming soon, more work to be done)
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop