A way to serialize and deserialize LDUser about java-server-sdk

[eli-darkly]

Hi. As you guessed, the issue is that there isn't (in that version of the SDK) a custom deserializer for LDUser. None was needed for the SDK's own use; the custom serializer was implemented because the SDK serializes user data as part of analytics events (and also because passing user data from back-end code to front-end code was a plausible use case).

In version 5.0.0 and above, there's a well-defined set of SDK classes that fully support JSON serialization and deserialization, including LDUser. I realize that you may not be at a convenient point to migrate to 5.x right now, but it's unlikely that we would be adding new features to 4.x at this point.

Does your code need to actually do things with the properties of the deserialized user, or are you just transferring it as-is to another service? If it's the latter then you could simply represent it as JsonElement so it would be treated as generic JSON data.

[davebarda]

As we use some data to evaluate flags, I'm revealing more data than I want to reveal in regular getAccount request on my account service, so I want to represent it as LDUser(or similar) in order to transfer it as a flag specific information(which is encapsulated)

[eli-darkly]

I'll take a look at what the current behavior is for deserializing with the default Gson behavior, and see if it's possible to make the SDK tolerate the result of that better (i.e. if it is really only a matter of whether it sees a null somewhere that it expects LDValue.null(), as you suggested, then maybe that piece of code could be made null-tolerant) in which case it would be a patch rather than a new feature. But I can't say off the top of my head whether that's the case. It depends on how closely the internal representation of the object corresponds to the JSON schema; they might have diverged once we started using a custom serializer.

[davebarda]

Well, I had a test that checks all the fields, the only differences I found were null fields, LDValue.null() was replaced with null on the serialization -> deserialization, Thank you!

[eli-darkly]

Released version 4.14.1 with a fix for this.

If you later migrate your code to the 5.x SDK, you'll want to look at this package.