Consider different serialization libraries

[alisters]

Hi,

I'm working on an android app where jackson serializer is not being employed - we are using gson. Would you consider building variants that use gson or kotlinx serialization ? The first step for me is to try a fork that uses gson, and inject in a mapper

I'm a bit of a newbie in this space - if your interested i'd like to contribute this back "upstream" but i'm not sure how to best approach it

• build variants ?
• some form of dynamic dependency (https://github.com/googlesamples/android-dynamic-code-loading ?? ). Though since this doesn't target android alone, or spring, or ..... i'm

Interested in this ? Ideas or preference on how to implement ?

[serpro69]

Hi @alisters ,
This sounds like a good feature and I'm definitely interested in adding this. I'm not sure what could be the best approach here, but I'll give it some thoughts. I would prefer not to introduce more reflection (dynamic dependency) though, as I have plans to rid of any reflective calls to get support for other platforms (see #43).

I would love to move away from jackson to kotlinx.serialization to enable multi-platform support, but they don't have yaml supported and no plans for it as well. So I still haven't found a good way around this, though I haven't given it much thought either due to lack of time lately.

I'll think about this issue, but feel free to propose something as well.
I think if we close our eyes on multiplatform support, my preferred approach to this issue would be to split the serialization part into separate module(s) and having a separate dependency for each supported serialization library. So something like build variants, yes.

[alisters]

Now that you point out that all the embedded resources are yaml (which i think i saw i just didn't pay attention to) - i think i've jumped the gun on this a bit.

A quick search shows neither kotlinx nor gson support yaml, and won't (google/gson#327) - which i guess you knew !

I like the readability of yaml, but would you consider porting the embedded resources from yaml to json in the name of supporting the different serializers ? If you have strong reasons for choosing it then stick with it, otherwise i could script transforming the yaml to json ? Do you use multi-line strings, anchors ? This could be part of the build itself too i guess, though i'd have to investigate how to do that.

This would now be beyond the scope of what i can do for my work requirements, but i'd be happy to chip away at something outside of work time.

[serpro69]

Yes, I was also thinking about how to port the dictionaries to json, simply because json is supported by many more libraries natively (including kotlinx.serialization and gson). The "transforming" part is quite easy I think. The challenge here is that this has to be done dynamically (either by a sub-module, or in some other way during compilation) or at the very least should be reusable. Because I'm using the yaml dicts from the ruby faker gem (with a few minor tweaks where something does not work very well out of the box with a statically compiled language), so doing a "one-time-porting" from yaml to json would not solve it as it will become extremely hard to get new changes into the library from upstream. So the source will have to stay in yaml, but the output that is consumed by the faker can be in json.

[alisters]

https://github.com/castocolina/json2yaml has a pull request castocolina/json2yaml#2 offering yaml to json. I will attempt some gradle baby steps and see if i can, as part of the build, convert yaml to json prior to embedding them as resources

[alisters]

Also done a little bit of reading on gradle variants (https://docs.gradle.org/current/userguide/variant_model.html). This may allow consumers to stipulate the serializer they are using. Still in the stumbling around early research stage.

[serpro69]

Thinking to pick up this issue.

Just going to leave this here for now to see if feature variants can be used as (at least partial) solution: https://docs.gradle.org/current/userguide/feature_variants.html