Properties should support String encoding/decoding

[sandwwraith]

What is your use-case and why do you need this feature?

Currently, Properties allow to parse Map<String, Any> object to a Kotlin class. Usually, such properties are loaded from configuration file. While we do not have multiplatform IO or files, we still can parse properties from a string contents of such file, since parsing line breaks/separators/etc is an additional amount of work.

Originally reported here: https://youtrack.jetbrains.com/issue/KT-42716

Note: it is relatively easy task though with common collection operations.

[daniel-jasinski]

I think it would be a good intermediate step to provide API for parsing Map<String,String> before moving to full File/IO support. At the moment I have to handle this case "manually".

[RaphaelTarita]

Hi, here's the original creator of the YouTrack issue. Thank you very much for taking care of this. While work was actually done here, I was also working on a personal implementation of this functionality. However, I was not aware of the fact that there already exist ways of resolving the required primitive types of the model classes in the core lib. You may imagine that I had quite a struggle trying to implement the type resolving on my own. Anyway, I'm now somewhat relieved to see that I don't have to use my own version for this.

Apparently, the current issue is to get from the Map<String, String> to an actual properties format string (and vice versa). If it is any help, here's what I've tried; I've written this quite a while ago. But as far as I can tell, even this part has already been taken care of, which is wonderful.

Can we expect this feature to appear in a new version in the near future?

PS, a few notes on the gist:

• I tried to stick to the design of kotlinx.serialization.json.Json.kt
• I also tried to conform to the properties format spec from the Java Properties class
• Due to the format description, I added support for the different accepted "flavors" of .properties, most notably the different key-value separators. There is also an option specifying the comment char, which is currently not in use.
• The gist has an earlier revision which just uses java.util.Properties to do the encoding/decoding.

[hfhbd]

I would love to see this support:

1. to create a properties files from multiplatform targets, mostly (node) JS
2. the Java implementation always stores the current date as comment which is useless and annoying in tests