P4
A DESCRIPTION OF THE REQUEST :
Currently the J2SE Preferences API has as a standard a persistent data storage delivered with it , e.g. WindowsPreferencesFactory.
I propose in addition a MemoryFactory (which would obviosly not be persistent) to be part of the standard J2SE.
JUSTIFICATION :
The Preferences API is a good implementation but the uptake is hindered by the fact that it *has* to be persistent in a place not liked by all: The registry. This causes various problems with lack of write permissions to the registry, etc. (the same is true for Unix, I guess, but to a lesser extent because most users have write access to their own home directory)
There are still many developers that favour a model where "configuration data" is something that sits in a flat file loaded by the application when it starts. This is of course especially true when the application is really a daemons. Suppose you are a system admin been given the task to look at a java daemon application and possibly change its configuration. Where would you start to look for the data it uses as its configuration?
Personally I would start by looking for a configuration file. Only after that I would look in the registry. But then I would have the problem that I wouldn't know where in the registry to look.
Well, what it all boils down to is that in some cases the config file approach is still the one favoured by some. Others may like the registry approach. Those that like the config file approach should simply use the Memory factory and use ImportPreferences() method to load the config file on startup.
All in all: addition of a memory factory would remove a reason for some *not* to use Preferences API.
To cater for such needs I pre
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The memory factory would store preferences in memory.
GNU Java already has an example of this as part of GNU Classpath.
---------- BEGIN SOURCE ----------
n/a (this is a RFE)
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
none.
(the Internet is filled with cases where people try to disable the Preferences. Personally I do not think that is the way to do it)
###@###.### 2005-05-24 05:33:22 GMT
Currently the J2SE Preferences API has as a standard a persistent data storage delivered with it , e.g. WindowsPreferencesFactory.
I propose in addition a MemoryFactory (which would obviosly not be persistent) to be part of the standard J2SE.
JUSTIFICATION :
The Preferences API is a good implementation but the uptake is hindered by the fact that it *has* to be persistent in a place not liked by all: The registry. This causes various problems with lack of write permissions to the registry, etc. (the same is true for Unix, I guess, but to a lesser extent because most users have write access to their own home directory)
There are still many developers that favour a model where "configuration data" is something that sits in a flat file loaded by the application when it starts. This is of course especially true when the application is really a daemons. Suppose you are a system admin been given the task to look at a java daemon application and possibly change its configuration. Where would you start to look for the data it uses as its configuration?
Personally I would start by looking for a configuration file. Only after that I would look in the registry. But then I would have the problem that I wouldn't know where in the registry to look.
Well, what it all boils down to is that in some cases the config file approach is still the one favoured by some. Others may like the registry approach. Those that like the config file approach should simply use the Memory factory and use ImportPreferences() method to load the config file on startup.
All in all: addition of a memory factory would remove a reason for some *not* to use Preferences API.
To cater for such needs I pre
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The memory factory would store preferences in memory.
GNU Java already has an example of this as part of GNU Classpath.
---------- BEGIN SOURCE ----------
n/a (this is a RFE)
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
none.
(the Internet is filled with cases where people try to disable the Preferences. Personally I do not think that is the way to do it)
###@###.### 2005-05-24 05:33:22 GMT