Handling list decoding in custom formats requires internal api

What is your use-case and why do you need this feature? For decoding lists in the xml custom format it has a mode where lists are parsed incrementally (a list is parsed as a single element list with updates). While there is access to the previous value there is no obvious way to know how to merge them (especially with custom lists), except for the AbstractCollectionSerializer.merge function. Both functions are internal

The problem with the new approach is that formats don’t know about types (serializers do). While it is indeed correct to have decoders drive the merging, the actual way merging works can only depend on the (de)serializer. When a decoder sees a list it doesn’t even know whether it is immutable or mutable, or whether it doesn’t confirm to the List interface at all. Custom serializers could expose themselves as lists easily enough, but even in the libary, there are many different types supported by children of AbstractCollectionSerializer (whose internal state makes it even harder to write a custom serializer for this case).

Describe the solution you’d like I’m not sure what the best solution is. Perhaps the best solution would be to introduce a “MergeableDeserializerStrategy” interface with a merge function. Decoders could then check for this interface and merge appropriately. There may be a parameter for merge mode.

[pdvrieze]

I think that perhaps an interface (an similar interfaces for things like ByteArrays and others) would allow custom serializers a bit more freedom. Of course AbstractCollectionSerializer is quite broad already.

[elizarov]

Can you give an example of XML you are trying to (de)serialize? Do you need only merging of lists (collections)?