🚀 go-pugleaf

Peter:

Serialization is neat for small things and quickly becomes un-tenable
in real world situations.  For example, if a database object is
serializable and contains 4 million records, where do you persist
those 4 million records?  ;-)

You probably don't face that problem for program settings.  A
serialized singleton would provide you with a non-human readable
file.  As long as that persisted file could be shared across platforms
(assuming your user will be able to pick up their settings and stick
them on a new box), that could work.

Me, I think a textual settings file via Properties does the job with
the least amount of wheel re-inventing.  I just wish the stock
hashtable implementation in Java was better.

-Rich

Peter Steele wrote:
> 
> >Property files are the
> >way to go, as Rich pointed out.
> 
> I spoke to someone who has been developing in Java for two years (yes, he's
> a pioneer). He definitely prefers to use a serialized singleton class and
> save/restore the data using object I/O. He pointed out that the Properties
> class predates serialization and would probably have been implemented
> differently had serialization been defined first. For my money, the only
> advantage I can see in using the Properties class instead of serialization
> is the data is saved in textual form and can be edited outside of the
> program. Beyond that, I would tend to lean to serialization I suspect
> because it would be much more straightforward to use...

-- 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rich Wilkman
Senior Quality Assurance Engineer
Borland JBuilder Team

If you see something that looks like an opinion up there,
it's mine and mine alone.

Mail sent to me from the newsgroups won't bounce but will
be ignored.  If I have time, I'll respond, but you  have
a better chance if you confine your posts to the newsgroups
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=