I have a java application - it's A.I. & is entirely local to one machine. There are a couple of arrayLists that hold objects used by everyone in the program. I need to save them (the contents of the Containers) to disk, reload, keep different versions, etc. (The objects are shallow and simple in terms of inheritance etc, and hold fields of primitive data types, and an arrayList of int2, for example.)

Serialization works 95% of the time, perfectly (that is, when it works, it does exactly as it should.) I used code from one of the tutorials, and it was easy to set up.

It fails when trying to de-serialize the disk file data. It always fails in this process - but, as I say, 5% of the times I run the program.

Having read every relevant post I could find, I am aware that one must not change the classes involved with the serialized objects - and I don't. I have also tried hard-coding the serialVersionUID. The books I have go into the kind of code I use, but don't discuss this pitfall.

One way to make it fail is to declare a file handle globally - that is, above/outside 'main', or inside main. Such file handles can be used, and are themselves (apparently) legal, but its inclusion causes the failure to de-serialize. Apparently declaring an unrelated text file changes something. (Other things can cause the same problem.)

I could use guidance about useful diagnostics, and opinions about the cause/fix. If anyone has any ideas I'll try to post the relevant code. Unfortunately, the serialization code is boilerplate, and the problem is in some aspect of the whole program. BTW I happen to be using NetBeans.

Here's a bit of info. This is the exception that gets thrown, and a bit about it:

Thrown when a class cannot be used to restore objects for any of these reasons:
The class does not match the serial version of the class in the stream.
The class contains fields with invalid primitive data types.
The Externalizable class does not have a public no-arg constructor.
The Serializable class can not access the no-arg constructor of its closest non-Serializable superclass.

This is from oracle docs:

Note - It is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected serialVersionUID conflicts during deserialization, causing deserialization to fail.

Chris lanz