[ https://issues.apache.org/jira/browse/GEODE-10076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17564171#comment-17564171 ]
ASF subversion and git services commented on GEODE-10076: --------------------------------------------------------- Commit 8ca51af948de70070016acf804994819da02bdda in geode-native's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=8ca51af94 ] GEODE-10076. Align String serialization with Java client > Fix string codepoint detection > ------------------------------ > > Key: GEODE-10076 > URL: https://issues.apache.org/jira/browse/GEODE-10076 > Project: Geode > Issue Type: Improvement > Components: native client > Reporter: Mario Salazar de Torres > Assignee: Alberto Gomez > Priority: Major > Labels: pull-request-available > > *GIVEN* a PdxSerializable implementation with a string field > *WHEN* an ASCII string is written > *THEN* the string is serialized with the DSCode CacheableString > ---- > *Additional information.* In the Java client, whenever writing an string, the > string is parsed and the DSCode is assigned depending on the string > codification. In the native client, it's always set to CacheableString, > whenever for example in the case of an ASCII string should be > CacheableASCIIString > Also I've noticed the following scenario requires to fix the codepoint > detection: > # From a native client, I create an object using a PdxSerializable > implementation, which has an String field. > # After that, we are reading this object from a java client which cache has > readPdxSerialized=true and comparing it with a PdxInstance created locally > inside the Java client. > # As PdxInstanceImpl.equals method uses rawBytes for strings, if the string > is serialized using different DSCodes, the comparison will fail, even if the > length and content are the same. -- This message was sent by Atlassian Jira (v8.20.10#820010)