@wilbit @fredericDelaporte would it be feasible to create a new class and use it?

@wilbit @fredericDelaporte would it be feasible to create a new class and use it?

Well, I see that LinkedHashMap is not used in public properties/fields/methods, so, technically it is feasible.
But also, LinkedHashMap implements IDeserializationCallback interface, and I'm not really sure what it brings. If nothing, that we are good to go and the only thing which is left is a new name and/or namespace for the internal class.

Another suggestion from me:

1. keep the changes from this PR for a next major release (after some PR fixes, making LinkedHashMap internal and a rebase, see point 2)
2. for an upcoming minor release fix the major part of LinkedHashMap creates enormous amount of memory traffic #3486 by casting LinkedHashMap to IDictionary<TKey, TValue> in BatchFetchQueue.GetCollectionBatchAsync (this should do a trick and foreach will use generic IEnumerator<> instead of non-generic IEnumerator).

Obsoleting LinkedHashMap entirely and adding an internal replacement seems to me as the best way to handle this.

But also, LinkedHashMap implements IDeserializationCallback interface, and I'm not really sure what it brings.

It is for supporting binary serialization. See also the Serializable attribute of the class. That thing is obsoleted in .Net Core for security reasons, but it is still used by many users especially under .Net Framework. The replacement class will have to be binary serializable too, because it will serve as state of many other classes which are serializable too. This allows to serialize the whole session and restore it later, by example.

@fredericDelaporte

1. OK, where to put the new internal class and how to name it?
2. about serialisation: would it work if somebody serialize a session with the current LinkedHashMap and deserialize with internal LinkedHashMap (which is, basically, would be a copy of the current LinkedHashMap in terms of fields...)?

1. Why not LinkHashMap, same place?
2. That will not work and will be a possible breaking change, but neither a binary one nor a source one, which is acceptable for a minor. We will have to warn in the release notes about the incompatibility of states serialized by version prior to the next minor with this next minor, and vice-versa.

added LinkHashMap, @hazzik , @fredericDelaporte

Master branch protection requires the PR to be up-to-date with master. This PR has not edits for maintainers enabled, so, we cannot update it ourselves. Can you update it?

rebased, @fredericDelaporte