#2 JPreference architecture, are we going the right way?

[Gudapati Praveen Kumar]

Presently Jpreference is unable to load any preferences
from flat files, unless we initiate default preferences in
PreferenceManager.
Problem domain:
We cannot load any preferences until unless we define
them before calling load method. This is quite painful, as
the application developer should code lots of code to
initiate all the default preferences.
It also raises other concerns apart from coding, why we
need to initalize preference objects without knowing
whether we need them really?
Basic idea behind preference: It is to give more power
to the user, so that he can save his setting for his next
uses. (This is just my idea)
So if the user really didn't use the default initalized
preference objects then they are eating memory without
reason.

Could be solution:
load method loads all preferences as String values.
What does that really mean?
So load method does 2 jobs:
1. Creates new preference objects when they are not
created by application.
2. If preference object already created by application,
then replaces the old value with newly read value.

The next question, What will happen to Object types?
Preferences are specific to the components which use
them, then let them try to cast them to their required
types. (As any type values should be written to a file as
a String)