support for the basic Java `.properties` config format

[mhsemcheski]

Problem: Lots of applications are configured from the .properties format.
Currently, there is no concise way to deal with these types of files and configurations without pulling in lots of new and exciting external dependencies.

Describe the solution you'd like Cue should be able to read in these types of files and write out to them (though this may be a lossy operation).

Describe alternatives you've considered There are libraries and tools that can handle these types of files and purport to produce json or yaml. Adding dependencies of unknown pedigree is less desirable.

Additional context This .properties files have a basic form like:

service.feature.xyz.enabled=true
service.feature.tuv.enabled=false
service.otherfeature.abc.flag=ABC
service.map.abomination.imho={\
  abc = "xyz"; \
  omg = "fml"; \
}

which I would expect to yield cue like:

service: feature: xyz: enabled: true
service: feature: tuv: enabled: false
service: otherfeature: abc: flag: "ABC"
service: map: abomination: imho: abc: "xyz"
service: map: abomination: imho: omg: "fml"

[antong]

I'd expect it to yield:

service: {
    feature: {
        xyz: {
            enabled: "true"
        }
        tuv: {
            enabled: "false"
        }
    }
    otherfeature: {
        abc: {
            flag: "ABC"
        }
    }
    map: {
        abomination: "{abc = \"xyz\"; omg = \"fml\"; }"
    }
}

I don't believe there is any real specification of the properties file format, but all the references I've seen seem quite explicit about keys and values always being strings.

[mhsemcheski]

I'd like to have a consistent and repeatable way to deal with these files that maximizes compatibility with the things that read them natively. If I were to implement this, I would be a bit more exhaustive in figuring out all the details of this format.

[mpvl]

Not unreasonable in principle. This would be in the list of TOML, INI, and Apple's property list, I guess.

It is a messy format, but given the sheer prevalence of these files in Github compared to the related formats, it seems like a good thing to explore.

[mpvl]

One possibility would be to use github.com/magiconair/properties, or some stripped version of it, which seems to implement this. The API of this package doesn't seem quite appropriate, though. Ideally, the package would have a factored out parser that allows for direct translation into CUE.

https://pkg.go.dev/github.com/rickar/props API is a bit better in that respect.

Overall, the lack of a standard seems somewhat problematic.

Anyway, lots of research work to do here. But would certainly be welcoming a good proposal around this that lays out

• how to deal with compatibility issues regarding the lack of a good standard (or is there one)?
• which technologies to use maintenance
• how to map properties to CUE (e.g. preserve string interpolation)?
• do we use an existing parser or write our own?
• if we write our own, is there at least an existing tokenizer?

[mhsemcheski]

For reference, after consulting with some Java devs, I believe that the standard for this format is described here:

https://docs.oracle.com/cd/E23095_01/Platform.93/ATGProgGuide/html/s0204propertiesfileformat01.html

[mpvl]

That "standard" leaves much to be desired:

• what is whitespace?
• what does "generally terminated" mean?
• what is a newline?
• what is the ATG Control Center window that it talks about?
• What are the nucleus properties files?

Also, given the unclarity of the above, to what extent do different implementations vary?

And the remaining question is to what extent this is the de facto standard? I've seen references to other mechanisms:

• substitution of placeholders ${}
• file overlays
• key paths (a.b.c : foo, a.b[3]) do not seem to be defined in the spec, but your example does seem to depend on its semantics. So there is an assumption on the semantics of property files that goes beyond the spec you provided.
• same things holds for the use of =\{

So I suspect the interpretation of property files is a lot more involved than this "spec" seems to suggest, which only defines tokenization of key and value strings. And if so, then is there any gold standard / reference?

And without a spec or standard, things can get very messy, as different people expect different things and there is no way to resolve any disputes.

Anyway, not against this but it needs some research and design.