Bug InvalidClassException for Mafia r20602 and openjdk 14.0.2

[xKiv]

I don't understand what you're suggesting. RollingLinkedList doesn't implement Serializable, does it? And I know I didn't change JDKs. Can you show me exactly what you think happened.

RollingLinkedList inherits the interface from LinkedList, which explicitly implents it. All subclasses of Serializable classes are Serializable.
You said you "only checked it against OpenJDK 15", is that the jdk you use for everything? For some reason I was under the impression that you used a "newer" jdk to check this.
But JDK version is just one of a myriad of things that can make a build generate a different serialVersionUID. It's possible java is free to just ... generate a different one *whenever*. I am not even sure if it must be generated during compile time at the latest, or if can depend on runtime environment ...

 

[MCroft]

so, this is a problem mainly for devs who switch JREs? It might be that I just happened to and didn't notice it (last build was in the IDE, this one was from the CLI or something similar). I haven't seen any other reports of this issue, either.

We shouldn't need to rollback the import then. Should we give RollingLinkedList a UID?

 

[fronobulax]

Neither of the serialVersionIDs in the stack trace are the one embedded in the code. So regardless of the stack trace, the class with the problem has to be AdventureSpentDatabase.java, which would use a calculated value.

RollingLinkedList is the canary. It was the first thing that actually tried to access the improperly serialized class.

Given that not using a static serialVersionID is a known problem that can be triggered by a change in environment, I am content to not try and explain the stack trace.

I think the import was a red herring.

The only way to see the problem would be to write a file with one ID and then read it with another.

So if the ID is changed and mafia is run, it will generate the error, But then it will write the file with the "new" ID and subsequent attempts to read the file will not fail.

 

[fronobulax]

so, this is a problem mainly for devs who switch JREs? It might be that I just happened to and didn't notice it (last build was in the IDE, this one was from the CLI or something similar). I haven't seen any other reports of this issue, either.

We shouldn't need to rollback the import then. Should we give RollingLinkedList a UID?

No. This is only a problem for users of versions before r20604. This is an unsafe implementation of serializable that was discovered by a change in environments.

If you want to develop a test that shows the imports had nothing to do with it (or prove me wrong since I am subject to hubris) make two files, each one of which was serialized with a different ID. Make versions of mafia that match one of the IDs. One has the unused import. One doesn't. Run various combinations of mafia reading the file. When mafia and the file don't have the same ID an error will occur. When they have the same ID the error won't occur. The presence or absence of the import does not change the expected behaviour.

 

[xKiv]

so, this is a problem mainly for devs who switch JREs? It might be that I just happened to and didn't notice it (last build was in the IDE, this one was from the CLI or something similar). I haven't seen any other reports of this issue, either.

We shouldn't need to rollback the import then. Should we give RollingLinkedList a UID?

Untill RollingLinkedList has an explicit UID, it can be a problem for anyone who uses different builds of mafia at all - for example because they are updating daily to daily builds. Any build is free to just randomly decide to generate a different UID.

Neither of the serialVersionIDs in the stack trace are the one embedded in the code. So regardless of the stack trace, the class with the problem has to be AdventureSpentDatabase.java, which would use a calculated value.

RollingLinkedList is the canary. It was the first thing that actually tried to access the improperly serialized class.

Given that not using a static serialVersionID is a known problem that can be triggered by a change in environment, I am content to not try and explain the stack trace.

Please, read the actual error message. It says that the serialized instance of RollingLinkedList has a different UID than what the running applications's RollingLinkedList has. UIDs in other classes are completely irrelevant to this specific instance of the error.
Stack trace will tell you where the serialization was started from, and there you will find which is the topmost serialized class, but it will not tell you anything about the entire set of all objecst that are being serialized in the call. You would need to inspect the objects at runtime (or make a complete dump of application state at the time of the error).
The only thing you can do in other classes that will prevent this is to not use any instances of RollingLinkedList (and of any other class without explicit UID).

 

[fronobulax]

I'll concede that we interpret the stack trace differently and eventually accept that I am wrong

Since RollingLinkedList is serializable and lacks an ID, which is wrong, whether it causes an error or not, I will add one momentarily.

Since the only field in RollingLinkedList was made final about the time this problem appeared, is it possible that the calculated UUID for the class with a field and the class with a final field is different? If so would that point the finger at changing private int limit; to private final int limit; rather than imports or environments?

 

[xKiv]

Since the only field in RollingLinkedList was made final about the time this problem appeared, is it possible that the calculated UUID for the class with a field and the class with a final field is different? If so would that point the finger at changing private int limit; to private final int limit; rather than imports or environments?

Maybe, but it's not intended to be sensitive to private fields ...
It's still a more likely candidate for causing this than an import in a different class file. Imports should be *completely* irrelevant to runtime.