[
https://issues.apache.org/jira/browse/THRIFT-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072926#comment-14072926
]
ASF GitHub Bot commented on THRIFT-1827:
----------------------------------------
Github user ruijiang closed the pull request at:
https://github.com/apache/thrift/pull/161
> 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.
> Also, it makes methods like set__IsSet and get__IsSet inconsistent. For
> example:
> user.setName(null);
> user.setNameIsSet(true);
> boolean isNameSet = user.getNameIsSet() //false!
> 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 was sent by Atlassian JIRA
(v6.2#6252)
