how to save data in java

[stickybytes]

I am currently writing a simple salary program that calculates how much money you have worked so far. In my program, each individual node in a doubly linked list represents a day. Each node/day, contains the month, the day, and the number of hours worked for that day. How can i go about storing this data into a file so that each time the user runs the program, it remembers the data?

 

[Ken g6]

Well, first of all, if every node in your linked list is not listed individually in a data structure in some class (and it probably isn't), you can't use serialiaztion (at least not directly).

Once you get past that, there are almost innumerable ways of saving and restoring the data. All involve converting your linked list to something else, and then rebuilding the linked list when reloading the file. Two ways that come to mind are:

1. Just walking the linked list and writing out each record manually. You can write it as text or binary; whatever strikes your fancy.
2. Pushing each node into a Vector, and serializing that.

I highly recommend the first:
- It's smaller.
- There are no compatibility problems if you tweak the class. (Though if it's a true Vector there shouldn't be problems anyway.)
- You know exactly how the file is stored.

 

[HigherGround]

implement Serializable on the list and the nodes. Implement readObject/writeObject if needed. you might want to post your list implementation.

 

[Ken g6]

There's that, too; though I wouldn't like it because if you change your list or node code even slightly, you wouldn't be able to read data saved by an older version. YMMV.

 

[HigherGround]

Originally posted by: Ken_g6
There's that, too; though I wouldn't like it because if you change your list or node code even slightly, you wouldn't be able to read data saved by an older version. YMMV.

.. and how does writing/reading data manually via custom written marshallers protects you from version incompatibilities? magic numbers, some other convoluted approach, which just adds unnecessary complexity.

 

[Ken g6]

I'm just saying, during unit testing of the module, it's a real pain that all the old data is lost with every code tweak. Not to mention that it doesn't lend itself to backward compatibility at all.

But I get the feeling we're not dealing with a professional senior Java developer here, so he might be happier if he can tweak his code without losing data. Considering the data structure, it's not that much more work.

P.S. If you do know a way of importing data from an old class into a new one, please let me know. I'd love to get that functionality into my SBQueue program.

P.P.S. At the moment I'm noncommittally looking over a library called XStream for that purpose. It might be worth it here, but probably not.

 

[HigherGround]

... 'every code tweak'. You make it sound like you can't touch the serializable classes, but that's simply not true. You can still add/remove classes, add fields, modify read/writeObject methods, change accessor value of any field, change static fields to nonstatic. Java serialization is immune to all of those changes. Granted, you can't delete fields or touch the class hierarchy, but those actions are bound to break most custom serializers. What I'm saying is that reinventing the wheel is not something the OP should get involved in.

 

[Ken g6]

Java serialization is immune to all of those changes.

I'm really very surprised by that assertion. Has this changed since Java 1.4? Looking back at what I did, I believe the following changes caused serialization to break for me:

- Added a public static final int (constant).
- Removed a private transient String
- Removed a private void function
and possibly:
- Removed a constructor with no parameters
but I'm not sure that was done when serialization first broke for me.

Which of these actions would have caused the problem?

Thanks!