Deserialized containers.Map keys exceed max name length

While trying to desirialize a containers.Map I get a cell2struct error in matlab.internal.json.makeStructure due to duplicate field names. The duplicate field names stem from Map keys which are more than 70 chars long and differ only in the last chars (I have no influence on the length of these keys). I use jsonencode/jsondecode to de/serialize the Map. Is there a simple workaround for this problem or am I missing an option or s.th.?

[Adam]

If containers.Map allows keys longer than the maximum length of a struct field then that will always lead to a problem if you want to convert one to the other. I don't quite see why json gets involved in converting map keys to fields of a struct, but I assume that is something to do with the map values instead?

[Björn Plewinski]

The Map is part of a larger object which needs to be de/serialized. The deserialization to a struct is done by jsondecode. Is there a way to directly deserialize to a Map?

Answer 1

[Guillaume]

To put it kindly, the json serialisation and deserialisation code in matlab is not very mature nor very thoroughly tested. For a while it did not even always generate json compliant code.

I guess you found another bug with that code, so you ought to report it to mathworks (or I'll do it later today). From past experience, it won't be fixed until the next version at least.

I doubt that there is any settings/options to avoid the bug. The only thing I can suggest is to serialise and deserialise the keys and values yourself:

%serialisation
jsonencode(struct('keys', yourmap.keys, 'values', yourmap.values);

%deserialisation
kvp = jsondecode(somejson);
restoredmap  = containers.Map(kvp.Keys, kvp.Values);

Obviously if the map is part of a larger object it is a problem as you can't pass the object directly to jsonencode anymore. Whereas in earlier version the jsondecode/encode code was implemented as m files so you could fix the bugs yourselves, it is now built-in leaving you no chance to override the behaviour for maps.

[Björn Plewinski]

Thanks! That is also the workaround I had in mind, but hoped for s.th. "better".

[Guillaume]

Actually, I just realised that I was testing in R2017a. The root cause of the error has been fixed in R2017b.

The bug was in matlab.internal.json.makeStructure which incorrectly created duplicate variable names even though it should not have.

However, it still wouldn't help you due to the fact that jsondecode always deserialise to a structure (whether the original data was a structure, an object, a map, or anything else). Since it uses structures, matlab is forced to make all keys valid variable names.

So even though R2017b does not error, you still don't get your original keys back. That's true for any key longer than namelengthmax or any key containing characters not allowed in variable names.

In conclusion, never pass your map directly to jsonencode. You can't be sure you'll get it back.