Forcing serialization of transient fields

687 views
Skip to first unread message

Mark D.

unread,
Sep 7, 2012, 3:30:18 PM9/7/12
to kryo-...@googlegroups.com
I know, this already sounds like a dumb request, but I have a very reasonable use case for wanting to be able to force serialization of a field that's transient.  Specifically, the Java class javax.swing.tree.DefaultMutableTreeNode (later referred to as DMTN) has it's userObject field marked as transient (but only so the Java serialization code can give it special treatment).

By default, Kryo just ignores the userObject field (a very reasonable thing to do since it's marked transient).

I was looking for a good way to serialize a DMTN including its userObject field, and the best I could come up with is to write my own serializer that just delegated to the FieldSerializer.  Then after serializing my DMTN, I would also serialize the userObject.  Is there a better solution to this problem?

If not, think it might make sense to implement some kind of method on FieldSerializer that would allow me to indicate that a field should be serialized regardless of its being marked transient?  Kind of like the opposite of FieldSerializer.removeField(String).

Thanks!
Mark

Nate

unread,
Sep 7, 2012, 8:40:00 PM9/7/12
to kryo-...@googlegroups.com
On Fri, Sep 7, 2012 at 12:30 PM, Mark D. <drew...@gmail.com> wrote:
I know, this already sounds like a dumb request, but I have a very reasonable use case for wanting to be able to force serialization of a field that's transient.  Specifically, the Java class javax.swing.tree.DefaultMutableTreeNode (later referred to as DMTN) has it's userObject field marked as transient (but only so the Java serialization code can give it special treatment).

By default, Kryo just ignores the userObject field (a very reasonable thing to do since it's marked transient).

I was looking for a good way to serialize a DMTN including its userObject field, and the best I could come up with is to write my own serializer that just delegated to the FieldSerializer.  Then after serializing my DMTN, I would also serialize the userObject.  Is there a better solution to this problem?

I think this is the best solution. You can extend FieldSerializer to do the extra work.

-Nate

 

If not, think it might make sense to implement some kind of method on FieldSerializer that would allow me to indicate that a field should be serialized regardless of its being marked transient?  Kind of like the opposite of FieldSerializer.removeField(String).

Thanks!
Mark

--
You received this message because you are subscribed to the "kryo-users" group.
http://groups.google.com/group/kryo-users

Mark Drew

unread,
Sep 7, 2012, 11:09:25 PM9/7/12
to kryo-...@googlegroups.com
Thanks--my workaround seems to be working fine.  -Mark

Mark D.

unread,
Sep 7, 2012, 11:17:14 PM9/7/12
to kryo-...@googlegroups.com
BTW, if you think the feature I suggested would apply generally enough to include in FieldSerializer, let me know, and maybe I'll submit a patch (but I don't want to go to the trouble of writing it if you don't think it's worth including).  If, on the other hand, you don't think it would apply widely enough to include, no hard feelings.  Thanks for your quick responses.  -Mark

Nate

unread,
Sep 8, 2012, 1:23:00 PM9/8/12
to kryo-...@googlegroups.com
I think it is rarely needed, if ever. Likely if a class has a transient field, special handling of that field is needed. If you end up needing it for more situations we can add it. :)

-Nate
Reply all
Reply to author
Forward
0 new messages