Support encode/decode java.time.Duration and ConfigMemorySize in HOCON

[alexmihailov]

• Many use cases require serialization support for java.time.Duration. It is not possible to implement a custom serializer in user code, since private methods from kotlinx.serialization.hocon.Hocon and kotlinx.serialization.hocon.AbstractHoconEncoder are required. To do this, I implemented the JDurationSerializer serializer, which can be used in user code.

• Hocon supports the memory size format. Documentation.
  In the com.typesafe.config library, the ConfigMemorySize class is responsible for this functionality. There is no way in user code to implement a serializer for this class. So I've implemented a ConfigMemorySizeSerializer that allows to serialize ConfigMemorySize.

• The com.typesafe.config library can create configuration using Java Bean notation. The com.typesafe.config.ConfigBeanFactory.create method is used for this. To support this functionality, I've implemented a JBeanSerializer that can only be used to decode configuration into a Java Bean class.

This PR depends on the previous PR

[ihostage]

Hi, Leonid @sandwwraith! 👋
FYI, this PR very useful to migrate from directly using Typesafe Config to Kotlinx.Serialization, because until now Kotlinx.Serialization don't have a few built-in Typesafe Config functionality 🤷‍♂️
Thanks, Alex @AlexMihaylov! 👍

[sandwwraith]

Hi! I've scanned through this and your other PRs. It seems the key problem here is, as you said, It is not possible to implement a custom serializer in user code, since private methods from kotlinx.serialization.hocon.Hocon and kotlinx.serialization.hocon.AbstractHoconEncoder are required. — for all the serializers you propose. All of them share the same piece of code:

when (decoder) {
            is Hocon.ConfigReader -> decoder.getValueFromTaggedConfig(decoder.getCurrentTag(), valueResolver)
            is Hocon.ListConfigReader -> decoder.getValueFromTaggedConfig(decoder.getCurrentTag(), valueResolver)
            is Hocon.MapConfigReader -> decoder.getValueFromTaggedConfig(decoder.getCurrentTag(), valueResolver)
            else -> throw UnsupportedFormatException("ConfigMemorySizeSerializer")
        }

Which uses internal classes and internal function getValueFromTaggedConfig. I suggest making some public API out of it. You can take interface JsonDecoder as an inspiration: it allows to hook into the deserialization process and the raw value — exactly what is needed here. So you can introduce some HoconDecoder that all readers would implement and some function to get current value, like this (names are up to later consideration):

if (decoder is HoconDecoder) 
  (config, path) = decoder.currentValue() 
else
  error("Can be decoded only by Hocon")

I'm unsure if both config and path are needed or if one is enough. Also, maybe the current lambda valueResolver is better than returning a pair — it's up to you to find out. But I'm sure by making this API it would be possible to uncouple serializers from internal Hocon implementation details. Also, it would enable users to work with various classes, such as Java Duration, without a need to add their serializers to kotlinx-serialization-hocon library or without a need to wait for a new release. It'll allow keeping changes small and adding one serializer at a time if it is really need (for now, I think maybe it's better to left them outside this library, but I'm up to discussion).

[alexmihailov]

Hi, Leonid @sandwwraith !
I have implemented a public api: HoconEncoder, HoconDecoder. It really does look a lot better and expands the possibilities for writing custom serializers.
In many cases java.time.Duration is used, so I would like to have a serializer for it in the library.
ConfigMemorySize is also often used. I also want the serializer for it to be in the library.
Java Bean notation is rarely used and the serializer for it can be removed from the library.

[sandwwraith]

(i haven't reviewed the tests yet)

[sandwwraith]

I'm sorry, I can't quite understand what you mean here. Are you saying decoding accepts all possible values from the spec (including powers of two and ten)? And encoding always emits powers of two?

[alexmihailov]

Yes, when decoding, can use all formats from the specification. For encoding, I selected on one option - to use powers of two, as it is easier to implement.

[sandwwraith]

Then please rewrite the documentation as in JavaDurationSerializer

[sandwwraith]

Bump: Rewrite as 'All possible Hocon size formats....'

[alexmihailov]

Fixed

[sandwwraith]

OK, only file name and minor comments left (please re-check Github's hidden converstaions section)

[sandwwraith]

Bump: Rewrite as 'All possible Hocon size formats....'

[sandwwraith]

Same here: why don't write function similar to testMemorySize?

[alexmihailov]

Implemented the testJavaDuration function

[sandwwraith]

@alexmihailov Hi, do you have time to finish this on this week? I plan to release 1.5.0 soon.

[alexmihailov]

Hello! Thursday/Friday I will try to finish

[alexmihailov]

@sandwwraith Hi! I checked the hidden sections of conversations and made corrections. I'm sorry I didn't notice right away.

[sandwwraith]

Thank you very much for all your time!