Old Sample Planner cannot be imported

[Aashishkebab]

I can no longer open the previous StudyPlanner.dat file. It seems like either the method to import previous files has been modified or the StudyPlanner.dat file has been modified.

Either way, we need to look through the commit history and figure it out. Also we should add all .dat files to gitignore.

[cameronroudebush]

So I began to look at this one to find what exactly was going on. After some searching I managed to find the exception it was hitting on line 144 in MainController.java and found it was due to an IOException. I printed the stack trace out and found the following error occurring multiple times:

java.io.InvalidClassException: Model.TimetableEvent; local class incompatible: stream classdesc serialVersionUID = 939793921119553866, local class serialVersionUID = 1
	at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
	at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
	at java.io.ObjectInputStream.readClassDesc(Unknown Source)
	at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
	at java.io.ObjectInputStream.readObject0(Unknown Source)
	at java.io.ObjectInputStream.readObject(Unknown Source)
	at java.util.ArrayList.readObject(Unknown Source)
	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at java.io.ObjectStreamClass.invokeReadObject(Unknown Source)
	at java.io.ObjectInputStream.readSerialData(Unknown Source)
	at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
	at java.io.ObjectInputStream.readObject0(Unknown Source)
	at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
	at java.io.ObjectInputStream.readSerialData(Unknown Source)
	at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
	at java.io.ObjectInputStream.readObject0(Unknown Source)
	at java.io.ObjectInputStream.readObject(Unknown Source)
	at javax.crypto.SealedObject.getObject(SealedObject.java:302)
	at Controller.MainController.initialise(MainController.java:105)
	at View.Main.start(Main.java:32)
	at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$162(LauncherImpl.java:863)
	at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$175(PlatformImpl.java:326)
	at com.sun.javafx.application.PlatformImpl.lambda$null$173(PlatformImpl.java:295)
	at java.security.AccessController.doPrivileged(Native Method)
	at com.sun.javafx.application.PlatformImpl.lambda$runLater$174(PlatformImpl.java:294)
	at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
	at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
	at com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:191)
	at java.lang.Thread.run(Unknown Source)

After some research I found it was due to a serializable issue and in some parts of the project they had serialVersionUID hard coded as 1. I changed it to the values it was looking for in the stack trace (i.e. 939793921119553866 for TimetableEvent.java.)

Technically this fix works fine for loading the StudyPlanner.dat file but I am just not sure if this will be a permanent fix because im not sure if they might change in the future. Care to weigh in @rsanchez-wsu @Alienturnedhuman ? This one seems a little out of my pay grade.

[rsanchez-wsu]

@cameronroudebush This is interesting. As I have been going through and making CheckStyle fixes I have added a serialVersionUID to the classes that I have touched. Generally, the serialVersionUID value is used to manage compatibility between different versions of a class when, for example, one version serializes itself and then that representation is deserialized into a different version of the class.

My change clearly introduced the breakage where the default StudyPlanner.dat would not load. I completely blanked on the fact that loading that file would be affected by me adding a serialVersionUID.

Are all of the occurrences of serialVersionUID that you changed in b0a4054 related to the loading of StudyPlanner.dat?

[cameronroudebush]

@rsanchez-wsu Yes all the changes in that commit are in relation to fixing the StudyPlanner.dat. All I did was gave it the serialVersionUID numbers that it was looking for.