[
https://issues.apache.org/jira/browse/THRIFT-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-1827:
--------------------------------------
Fix Version/s: (was: 1.0)
> 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
> Priority: Major
>
> 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
(v7.6.3#76005)
