[
https://issues.apache.org/jira/browse/IGNITE-15944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460769#comment-17460769
]
Roman Puchkovskiy edited comment on IGNITE-15944 at 12/16/21, 2:22 PM:
-----------------------------------------------------------------------
A couple of issues were found in the spec that need to be discussed and
resolved.
h3. Externalizable problem
Javadoc of Externalizable contains the following:
{quote}These methods [readExternal()/writeExternal()] must explicitly
coordinate with the supertype to save its state
{quote}
This seems to mean that Externalizable#writeExternal() must save the state of
the whole object, including the fields of its superclasses, not just the fields
defined on the current class.
But our IEP says the following:
{quote}For an {{Externalizable}} class descriptor, only fields from the non-
{{Externailzable}} hierarchy levels are included. The serialized layout is
split into built-in region with automatic serialization of
non-{{{}Externalizable{}}} levels, and the region produced by the
{{writeExternal}} method.
{quote}
So in our IEP an Externalizable object is treated as composed of fields of
(possibly non-Externalizable) superclasses plus the result of externalization
of the fields of the current class.
In a case when the superclass is non-Externalizable, this would lead to the
duplication of the superclass fields' data: they would be present in the
'non-Externalizable' region, and they would be somehow present in the
externalization blob (as it should contain fields of all superclasses).
This duplication would not help in the following schema change case:
{quote}If the local class does not implement {{Externalizable}} interface,
while remote class does, the externalizable region of the serialized class is
skipped and either an exception is raised, or the section is passed to the
optional handler that can initialize the skipped fields when possible. Note
that deserialization cannot proceed in this case without user intervention.
{quote}
But it could help in another case:
{quote}If, on the contrary, local class implements {{Externalizable}}
interface, but remote class does not, the {{readExternal}} method is ignored
and read fields are assigned to the local object instance as if the class did
not implement the {{Externalizable}} interface.
{quote}
Is it worth it to have this duplication just for this rare case?
h3. serialVersionUID
{quote}The serialization runtime associates with each serializable class a
version number, called a serialVersionUID, which is used during deserialization
to verify that the sender and receiver of a serialized object have loaded
classes for that object that are compatible with respect to serialization. If
the receiver has loaded a class for the object that has a different
serialVersionUID than that of the corresponding sender's class, then
deserialization will result in an InvalidClassException
{quote}
Should we support serialVersionUID or should we just ignore it completely?
was (Author: rpuch):
A couple of issues were found in the spec that need to be discussed and
resolved.
h3. Externalizable problem
Javadoc of `Externalizable` contains the following:
{quote}These methods [readExternal()/writeExternal()] must explicitly
coordinate with the supertype to save its state
{quote}
This seems to mean that `Externalizable#writeExternal()` must save the state of
the whole object, including the fields of its superclasses, not just the fields
defined on the current class.
But our IEP says the following:
{quote}For an {{Externalizable}} class descriptor, only fields from the non-
{{Externailzable}} hierarchy levels are included. The serialized layout is
split into built-in region with automatic serialization of
non-{{{}Externalizable{}}} levels, and the region produced by the
{{writeExternal}} method.
{quote}
So in our IEP an Externalizable object is treated as composed of fields of
(possibly non-Externalizable) superclasses plus the result of externalization
of the fields of the current class.
In a case when the superclass is non-Externalizable, this would lead to the
duplication of the superclass fields' data: they would be present in the
'non-Externalizable' region, and they would be somehow present in the
externalization blob (as it should contain fields of all superclasses).
This duplication would not help in the following schema change case:
{quote}If the local class does not implement {{Externalizable}} interface,
while remote class does, the externalizable region of the serialized class is
skipped and either an exception is raised, or the section is passed to the
optional handler that can initialize the skipped fields when possible. Note
that deserialization cannot proceed in this case without user intervention.
{quote}
But it could help in another case:
{quote}If, on the contrary, local class implements {{Externalizable}}
interface, but remote class does not, the {{readExternal}} method is ignored
and read fields are assigned to the local object instance as if the class did
not implement the {{Externalizable}} interface.
{quote}
Is it worth it to have this duplication just for this rare case?
h3. serialVersionUID
{quote}The serialization runtime associates with each serializable class a
version number, called a serialVersionUID, which is used during deserialization
to verify that the sender and receiver of a serialized object have loaded
classes for that object that are compatible with respect to serialization. If
the receiver has loaded a class for the object that has a different
serialVersionUID than that of the corresponding sender's class, then
deserialization will result in an InvalidClassException
{quote}
Should we support serialVersionUID or should we just ignore it completely?
> [Networking] User object serialization
> --------------------------------------
>
> Key: IGNITE-15944
> URL: https://issues.apache.org/jira/browse/IGNITE-15944
> Project: Ignite
> Issue Type: Epic
> Reporter: Semyon Danilov
> Priority: Major
> Labels: iep-67, ignite-3
> Fix For: 3.0.0-alpha4
>
>
> Arbitrary objects serialization must be provided by Apache Ignite. Unlike
> {{NetworkMessage}} descendants, user objects are not known to the system in
> advance, and serialization layout must be resolved at runtime.
> For more information look at the
> https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
