[ https://issues.apache.org/jira/browse/THRIFT-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987180#action_12987180 ]
Mathias Herberts commented on THRIFT-1038: ------------------------------------------ I agree we can settle on TCompact and not worry about detecting the used protocol. LGTM. > 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 > > Attachments: thrift-1038-v2.patch, THRIFT-1038.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. - You can reply to this email to add a comment to the issue online.