`kotlinx.serialization.properties.Properties` object name conflicts with `java.util.Properties`

[joffrey-bion]

When dealing with serialization to Properties format, there is a high chance that we're using both Java's Properties type and Kotlin's Properties object. This is quite annoying import-wise.

Renaming to something different would be nice, although it would also unfortunately break the pattern of naming the serializer object like the format.

Alternatively, providing extensions like Properties.decodeFromFile<T>(path: Path) might solve the problem because we wouldn't have to first read the file into a java.util.Properties instance, convert it to a map, and then call the Properties deserialization.

[sandwwraith]

You can also use import ... as KProperties or import java.util.Properties as JProperties

[joffrey-bion]

Yes, sorry for not articulating this option explicitly. This is what I meant by "annoying import-wise". The declarations don't look natural in the code afterwards.

[pdvrieze]

@joffrey-bion As much sense as your point makes, it is not something that is by any means straightforward to change at this point (it breaks both source and binary compatibility). If you don't want the import alias, you can also use a type alias though.

[joffrey-bion]

The last suggestion in my initial message doesn't bring any compatibility issue, though. It's just an addition that makes the conflict less likely. But admittedly it's easy enough for users to write it themselves. It's just a slight inconvenience

[joffrey-bion]

Also, it's an experimental API, so it is technically possible to break source and binary compatibility. Not nice and easy, but the ship hasn't sailed

[pdvrieze]

The last suggestion in my initial message doesn't bring any compatibility issue, though. It's just an addition that makes the conflict less likely. But admittedly it's easy enough for users to write it themselves. It's just a slight inconvenience

There is certainly something to be said about adding the helper function for this case. (and maybe decodeFromString etc.)