[
https://issues.apache.org/jira/browse/THRIFT-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Clawson updated THRIFT-1827:
----------------------------------
Description:
This issue was mentioned previously in THRIFT-1394. The reporter suggested a
fix at that time which would have resolved it. Instead, the fix that was
actually applied did not fix the real issue.
The issue is that code relies on 2 different mechanisms to determine "isSet"
state. On the one hand, bit fields are kept for primitivies, on the other
"isSet" is determined if the value is null or not. The latter part is
incorrect considering one may wish to set a value to null.
Consider the use case where a Thrift payload is used to send delta's of changed
information. A client can determine which fields were "set" by using the
"isSet" mechanism. This will not work for String / Struct types due to the
inconsistent behavior. Client code will be unable to determine if a String
type was: a) just not provided b) or was explicitly set to null.
My proposal to fix is the same as the original proposal in THRIFT-1394:
We already use a BitSet to track primitive types in Java. The compiler should
extend the bit vector to also guard nullable types, to be consistent with C++.
was:
This issue was mentioned previously in THRIFT-1394. The reporter suggested a
fix at that time which would have resolved it. Instead, the fix that was
actually applied did not fix the real issue.
The issue is that code relies on 2 different mechanisms to determine "isSet"
state. On the one hand, bit fields are kept for primitivies, on the other
"isSet" is determined if the value is null or not. The latter part is
incorrect considering one may wish to set a value to null.
Consider the use case there a Thrift payload is used to send delta's of changed
information. A client can determine which fields were "set" by using the
"isSet" mechanism. This will not work for String / Struct types due to the
inconsistent behavior. Client code will be unable to determine if a String
type was: a) just not provided b) or was explicitly set to null.
My proposal to fix is the same as the original proposal in THRIFT-1394:
We already use a BitSet to track primitive types in Java. The compiler should
extend the bit vector to also guard nullable types, to be consistent with C++.
> Inconsistent behavior in isSet mechanism
> ----------------------------------------
>
> Key: THRIFT-1827
> URL: https://issues.apache.org/jira/browse/THRIFT-1827
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
> Affects Versions: 0.9
> Reporter: Jason Clawson
> Fix For: 1.0
>
>
> This issue was mentioned previously in THRIFT-1394. The reporter suggested a
> fix at that time which would have resolved it. Instead, the fix that was
> actually applied did not fix the real issue.
> The issue is that code relies on 2 different mechanisms to determine "isSet"
> state. On the one hand, bit fields are kept for primitivies, on the other
> "isSet" is determined if the value is null or not. The latter part is
> incorrect considering one may wish to set a value to null.
> Consider the use case where a Thrift payload is used to send delta's of
> changed information. A client can determine which fields were "set" by using
> the "isSet" mechanism. This will not work for String / Struct types due to
> the inconsistent behavior. Client code will be unable to determine if a
> String type was: a) just not provided b) or was explicitly set to null.
> My proposal to fix is the same as the original proposal in THRIFT-1394:
> We already use a BitSet to track primitive types in Java. The compiler should
> extend the bit vector to also guard nullable types, to be consistent with C++.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
