[jira] [Commented] (THRIFT-1038) Generated Java code for structures containing binary fields (or collections thereof) are not serializable (in the Java sense) even though they implement java.io.Serializable

["ojciec pijo (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057369#comment-13057369 ] 

ojciec pijo commented on THRIFT-1038:
-------------------------------------

this change breaks basic java serialization rule - does not keep references after deserialization. I was using thrift objects in a bigger structure that was serialized using default java mechanism (by Spring Web Flow actually). since I didn't use ByteBuffer, it worked fine.

now, after upgrading to Thrift 6, instead of one instance of particular object, I get multiple instances after deserialization because readObject method that have been added.

> Generated Java code for structures containing binary fields (or collections thereof) are not serializable (in the Java sense) even though they implement java.io.Serializable
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: THRIFT-1038
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1038
>             Project: Thrift
>          Issue Type: Bug
>          Components: Java - Compiler
>    Affects Versions: 0.3, 0.4, 0.5
>         Environment: All
>            Reporter: Mathias Herberts
>            Assignee: Mathias Herberts
>            Priority: Blocker
>             Fix For: 0.6, 0.7
>
>         Attachments: THRIFT-1038.patch, thrift-1038-v2.patch
>
>
> Since THRIFT-830, binary fields are implemented using ByteBuffer instead of byte[], but ByteBuffer are not serializable (in the Java sense), therefore the generated Java classes are not serializable either.
> Even though one might expect the Thrift serialization to be used instead of Java serialization, there are situations where the serialization of the classes is not in the hands of the user (think for example about the HttpSession offline storage done in Tomcat), therefore we MUST generate Java classes that are serializable in the Java sense.
> I'm finishing up a compiler patch to generate writeObject/readObject methods that will make the generated classes Serializable again, will submit it tonight.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira