Q:

reading/writing a set to a .ser file compared to a .txt file in java

So I have this Java program, and at the moment it serializes my set object and saves it to a .ser file
 FileOutputStream fileOut = new FileOutputStream("hash.ser");
          ObjectOutputStream out = new ObjectOutputStream(fileOut);
          out.writeObject(mySet);
          out.close();
          fileOut.close();
          System.out.printf("Serialized data is saved in hash.ser");

The program also reads from the .ser file at start of program each time. I was just curious if someone can explain the differences in both speed, and how it works in general between reading/loading from a txt file compared to a .ser file. As I am not 100% sure it is actually faster to read/write to the .ser file like I did. Looked into this a bit and really couldnt find to much on this. Any help would be great, thanks.

A:

It's impossible to compare Java serialization to a "txt" file because the text file could be created and read in any number of different ways. For example, you could write XML, or JSON, or your own custom text format to a text file. These are all quite different and will potentially vary considerably in their performance and other characteristics.
Java serialization can be convenient under many circumstances, but there are also a lot of restrictions and other considerations that can make things complicated quite quickly.

To use serialization successfully, everything you serialize, and everything it points to, must be serializable. Primitives, strings, and core collections (ArrayList, HashSet, etc.) are all serializable. If you include something that isn't serializable, you have to declare it transient and deal with its absence upon deserialization, or you have to create a custom serialization format. This adds complexity.
Serialization preserves the object graph. Suppose your set contains obj1 and obj2, each of which has a reference to the same object obj3. Serializing and deserializing this structure will preserve this relationship, so afterwards both obj1 and obj2 will point to the same obj3 instance. Other serialization mechanisms might not do this, and you'd end up with some object pointing to a copy of obj3.
Serialization can be brittle. Unless deserialization is done on a system with the exact same classes that were used for serialization, you'll get serialization compatibility exceptions. The way to prevent this is to declare serialVersionUID in all of your classes, but then you might have to deal with evolution of this class, for example, if serialized fields are added or removed. Again, this adds complexity.

As for performance, I'd suggest that you try it out and see whether it performs acceptably. It might be faster or slower than alternatives, but you'd really have to implement those alternatives and benchmark them and compare the results to Java serialization.

