[
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)
