Upgrade to 5.2, error lucee.runtime.type.util.ArraySupport; local class incompatible

I just upgraded from 4.5.2.018 to 5.2.2.71. My application uses ObjectSave to serialize a structure and then saves the result to a MySQL database. It will then pull this object from the database and use ObjectLoad to convert it back to a struct upon request. After upgrading to 5.2.2 I now receive the following error when calling ObjectLoad,

lucee.runtime.type.util.ArraySupport; local class incompatible: stream classdesc serialVersionUID = 4627055450171831282, local class serialVersionUID = -4719112018351392079

Any thoughts on what could be causing this?

So after doing so more research, I found the following StackOverflow article. It appears the signature of what I’m guessing is the ArraySupport class has changed between 4.5 and 5.2, thus causing the exception. I’m assuming this means I’ll need to come up with a new way to persist these structs in the DB, then run a script in Lucee 4.5 to migrate all the objects to this new persistence format, then I can migrate to 5.2 in production.

However, if anyone has any better options, or some suggestions for good persistence techniques, I’d certainly appreciate hearing them

Can’t you use the serialize(object) built-in function and then use evaluate(serialized) to deserialize it?

That will give you a textual data but you can always encode that in Base64 or whatnot if you don’t want to save it in plain text.

I can, but my issue is I have a bunch of objects in my database that were serialized using ObjectSave. Passing the binary created by ObjectSave to Evaluate does not work. So regardless I have to use Lucee 4.5 to load in all the objects that were serialized using ObjectSave and then serialize them again using something different. I’m planning on using SerializeJSON and then encoding that in Base64 as that seems less like to break on future Lucee updates, where Serialize may.

SerializeJSON() is a good choice if all of your data is of supported types. Serialize() should work with any CFML/Java objects. Since you were serializing to binary I thought that you had some custom data types there, but if SerializeJSON can get the job done then it’s definitely the better choice here.