Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
0.9
-
None
-
CentOS 5 Mac OS X
Description
Genereated java code is different depending on the environment.
Example Service:
service IssetService
{
bool test()
}
CentOS 5 result:
private void readObject(java.io.ObjectInputStream in) throws java.io.IOException, ClassNotFoundException { try { read(new org.apache.thrift.protocol.TCompactProtocol(new org.apache.thrift.transport.TIOStreamTransport(in))); } catch (org.apache.thrift.TException te) { throw new java.io.IOException(te); } }
Mac OS X result:
private void readObject(java.io.ObjectInputStream in) throws java.io.IOException, ClassNotFoundException { try { // it doesn't seem like you should have to do this, but java serialization is wacky, and doesn't call the default constructor. __isset_bitfield = 0; read(new org.apache.thrift.protocol.TCompactProtocol(new org.apache.thrift.transport.TIOStreamTransport(in))); } catch (org.apache.thrift.TException te) { throw new java.io.IOException(te); } }
The inconsistency is a problem as we have a hybrid env. Also we are unsure which is correct.
I have dug around in the code and is seems to come down to this method "tstruct->is_union()". On CentOS the struct is a union so the 'isset' code is omitted. While the opposite is true for Mac OS X. I am still unsure as to the cause but before I submit a patch I need to know which is correct.