ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Handling collections in BinaryMarshaller
Date Tue, 08 Dec 2015 12:30:28 GMT

We have some very strange logic for collections in BinaryMarshaller:
Instead of writing them as any other objects, we treat them specially and
write in unified form:
[collection_flag] + [collection_type_flag] + [size] + [items].
I remember we introduced this in good old GridGain days to handle
interoperability issues between Java and .NET.

This design is badly wrong:
1) Users cannot use their custom collections without following some
ridiculous requirements.
2) We loose some important collection-specific data. E.g., comparators in
sorted collections, load factor, etc..

I think we must remove all this weird logic and always write collections as
any other objects. The only exception are
BinaryReader.readCollection/readMap and
BinaryWriter.writeCollection/writeMap methods. In this case we write
collections in unified format and it is user responsibility to explain how
exactly to deserialize such fields using either some factory or explicitly
provided class name.

If user needs interoperability - sorry, Java TreeMap is not interoperable
with .NET SortedDictionary - these are different types. But user can always
create a *wrapper over collection* and make it interoperable.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message