[
https://issues.apache.org/jira/browse/IGNITE-16229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy resolved IGNITE-16229.
----------------------------------------
Resolution: Won't Do
Currently, we have only two cases for which this might be used: SingletonList
and Proxy. For both cases, our 'hacky' way works well, does not seem to cause
any problems and it is very simple, so it seems that we can just leave it as is.
List.of(...) and friends added in Java 9 are not a problem because their
implementing classes use writeReplace()/readResolve() which we support, so
everything just works.
Hence, it looks like this task is simply not worth implementing as the 'correct
and less hacky way' to implement it would also be slower at runtime (and
produce more garbage) as it simply makes more work.
> Improve unmarshalling of immutable containers in the User Object
> Serialization component
> ----------------------------------------------------------------------------------------
>
> Key: IGNITE-16229
> URL: https://issues.apache.org/jira/browse/IGNITE-16229
> Project: Ignite
> Issue Type: Improvement
> Components: networking
> Reporter: Roman Puchkovskiy
> Assignee: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> At the moment, we support just one type of immutable containers
> (singletonList), but we'll probably want to support other types like
> List.of(), Set.of() and so on.
> Immutable built-in containers pose a challenge: on the one hand, they can
> participate in cycles and hence need to be read in two phases (instantiate,
> store reference, fill), but on the other hand, they cannot be modified after
> instantiation.
> Right now, we implemented a hack: we still read immutable containers in two
> phases, but for filling them we have a custom code that breaks their
> 'immutability' invariant and pushes the values by force via reflection to
> fill such containers. It seems to work, but it's ugly and potentially
> dangerous (as we are violating the immutability invariant).
> There is another possibility.
> # Handle all the values that are not built-in immutable containers in the
> same way they are handled now
> # For immutable containers, during instantiation phase, create mutable
> placeholders instead of the immutable container instances themselves
> # Such placeholders need to track the slots of other objects in the graph
> that reference them
> # They are filled normally on the 'fill' phase
> # After the graph is read into memory, it consists of (mainly) normal
> objects and placeholders; the placeholders need to be resolved and replaced
> with proper immutable container values
> # It is impossible to create a cycle of immutable containers (without using
> hacks like Reflection), so we can find connectivity components of the graph
> (each of such component will be a tree) and then instantiate immutable
> containers from placeholders in the leaf-to-root order
> # Placeholders need to be replaced with the instantiated immutable
> containers in the graph; here, the knowledge about the set of slots which
> reference a placeholder (mentioned in item 3) will be useful
> # If we encounter a cycle comprised completely of immutable containers (such
> cycle can only be creafted using some sort of a hack), we can either fail
> with an exception or use a hack (reflection) to forge just one connection of
> the cycle.
> This is a hybrid approach of
> * always having 'real' objects in the graph - which is not realistic when we
> have immutable containers
> * and always constructing a graph of placeholders first and then turning
> them into real objects (this is what Spring does with Bean Definitions and
> then Beans) - which seems to incur too much overhead, especially having in
> mind that most of the objects are not immutable containers and hence do not
> need placeholders to represent them in the intermediate graph
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
