Support TOML?

[SentryMan]

I like how it looks.

[Mechite]

I personally dislike TOML due to syntactical complexity WRT things like arrays (will always be a controversial opinion). However, if you would undertake this I would imagine you would prefer not to have a dependency on a seperate parsing library.

In this case, I would take a look at night-config as they have their own parsing implementations and zero dependencies as a result, and it has worked fine for years already.

On the plus side, you can support formats like HOCON too if you like their parsing system, forking this parsing implementation would lead to a tiny file size increase for avaje-config as a whole while allowing more formats to be supported.

[SentryMan]

I was thinking more of creating a separate module for the different formats

[Mechite]

I was thinking more of creating a separate module for the different formats

If this then perhaps also add support for users to create their own parsers.

Also, probably an implementation of dotenv would be simple and useful, considering dotenv-java does it in one file, <100 LOC. I did dotenv myself in the past by parsing with Properties. The formats are almost identical.

proposed module structure?

im proposing here a LOT of formats, don't know if it fits the scope to support a lot of formats

• avaje-config - some kind of bundle that includes properties and yaml?

• avaje-config-core - common

• avaje-config-toml

• avaje-config-hocon

• avaje-config-json (with jsonb's simple inbuilt reader? i mean only a simple reading system is needed)

• avaje-config-json5

• avaje-config-properties

• avaje-config-yaml

• avaje-config-xml (key value with a root <application> element, using JAXP)

• avaje-config-hcl (familiar format for sysadmins or anybody who has used eg terraform, see hcl4j)

• avaje-config-dhall (this has been growing lately, would be the first good implementation, see dhallj)

• avaje-config-dotenv

light overview of syntactical differences between dotenv and properties

• Comments Before 2022, dotenv did not support comments at all. Modern parsing libraries support comments with #. Double quotes around a # for use in a key name ("#") are not treated like a comment. Properties files support both # and ! for comments.
• Whitespace In dotenv, leading and trailing whitespace around variable names and values is usually ignored. Properties files are very strict with this.
• Escape characters Not sure. Seems like dotenv does not support them while properties files do.

I looked at the differences a few years ago, didn't think much of it and implemented Properties for parsing .env files in order to make the JS guys happy. These projects are still in service, not sure if any custom logic is to be written when we can just add support for reading the file extension (in current working directory, search for *.env or just env)

[SentryMan]

That recent pr adds support for custom parsers

[SentryMan]

im proposing here a LOT of formats, don't know if it fits the scope to support a lot of formats

it probably does, but you won't find me writing a parser for them unless somebody actually needs one