How to achieve the Kryo various functionality without registering the classes

[sandeep27st]

Hello,

Currently, in our application, we are using the XStream serializer to serialize classes and hierarchy of classes.

In XStream, we are not bothering about registering the classes. All the operations will perform on the serialized string later after the serialization process.
We can not register the class as our class hierarchy, as it can be n level deep and it also contains the user classes.

We are now, in the process of moving to Kryo for the performance purpose Can you please suggest the following:

1. How to use DeflateSerializer without registering the Class.
2. As per our requirement we will be using writeObjectAndClass and readObjectAndClass.
3. Also we are using our own security for the encryption, Is it safe to encrypt the bytes and how to use can you please point out the test cases which I can refer to.
4. How we can be achieved migration of our own classes, classes field change, and package change. Which we haven't registered with while serializing and deserializing as well.
5. Is there any guideline to move from XStream to Kryo.

Hope you will soon answer my queries and I appreciate the help in advance.

Thanks,

[theigl]

Hi @sandeep27st,

How to use DeflateSerializer without registering the Class.

You can simply switch to optional registration via Kryo.setRegistrationRequired(false).

Also we are using our own security for the encryption, Is it safe to encrypt the bytes and how to use can you please point out the test cases which I can refer to.

Kryo does not have any built-in encryption support. You can encrypt/compress the resulting bytes in any way you like.

How we can be achieved migration of our own classes, classes field change, and package change. Which we haven't registered with while serializing and deserializing as well.

Kryo has 3 built-in serializers that enable some degree of backwards/forwards compatibility:

• CompatibleFieldSerializer
• VersionFieldSerializer
• TaggedFieldSerializer

Please read the documentation and chose the serializer most appropriate for your use-case.

Is there any guideline to move from XStream to Kryo.

Not to my knowledge.

[sandeep27st]

Thanks @theigl

I appreciate this quick reply.

Can you please provide the test case of each of the following? I have checked your test cases I didn't find appropriate.
Consider the following cases, I have objects whose bytes are already saved, and in the next version following things happened on the third-party library.

1. Class package change

2. Field Name change: if in the wrong alphabetic order.

3. Field is added

4. Field is removed.

These classes of these objects are from the different library (saaj, java classes, jdom), I can not provide the annotation on them, I can provide the serializer if possible for the renaming the field and removing the field. But that too should not be required in case of multiple new fields added.

If we say we can serialize and deserialize without registering classes then, but when configuring the compatibility expects the class type. Which contradicts your first sentence. The addition of the field should be handle without an error.
do we need to define CompatibityFieldSerializer configuration upfront while serializing the class?

We have a requirement, where we persist in the user data. We have an automation solution, where we used to capture the user variables. User can generate any variable, it can be from other libraries as well, like JDOM document, w3c. Document., List, and many more. Once these are defect user can trigger the solution to generate the transaction. Generated transaction data we might require in many petty cases like e.g. retry the transaction.

Thanks,

[theigl]

Hi @sandeep27st,

I'm afraid your use case is too complex for current built-in serializers. If you cannot annotate your target classes, your only option is CompatibleFieldSerializer. It supports adding and removing fields. Rename and package change are not supported.

You will have to extend CompatibleFieldSerializer or implement your own extension of FieldSerializer and store additional metadata about your serialized classes. What information does XStream store to support field rename and package changes for arbitrary classes?

[sandeep27st]

You will have to extend CompatibleFieldSerializer or implement your own extension of FieldSerializer and store additional metadata about your serialized classes.

Do we need this upfront before serializing the object of a particular class? What if at the time of deserialization (Later changed of some library consumed as we previously on JDOM 1.1.x and in the newer version we upgrade to JDOM 2.x.x) we come to know the change in the class? Can we create our own serializer for the same?

Can we perform the post-processing on that deserialized object after Kryo completes its task for the object? because I have seen data of newly introduced field is lost when Kryo automatically handle this please check the following example:

the previous structure of class:

class SomeClass {
String field1;
String field2;
}

Later I have changed it to:

class SomeClass {
String field1;
String field2;
int int_field1 = 12;
} 

int_field1 becomes 0 after deserialization .

And if the Type of field change is not supported what should be a workaround. how we can skip and achieve this?

XStream serialized to plain text format and which is too in tag structure like <fullyQualifiedClassName><fields></fields></fullyQualifiedClassName> we can easily change the it by XML Document manipulation.

[krishna81m]

Would be nice if "Rename and package change are not supported" were added to the wiki as limitations in Compatibility section.

[theigl]

@krishna81m: If you have suggestions for the wiki, please edit the readme and create a PR. I'm always happy to merge documentation improvements.