migrate to antlr / javacc about config

[diwakergupta]

I agree; the hand crafted parser isn't very maintainable. One of the advantages of using a standard format like JSON or YAML is one could leverage off-the-shelf libraries like Jackson and/or Snakeyaml. Of course, that would add a dependency. As always, there are trade-offs to consider...

[viktorklang]

The entire idea behind Config was to use only JDK – otherwise we'd used Scala for it. So it needs to be 0 deps.

[havocp]

fwiw, I don't think we'd ever make back the time spent converting to a parser generator. There have been very few bugs reported in the parser and back compat concerns mean the format won't change much.

I personally find a recursive parser like the current code pretty straightforward (and it's also how some JSON libs I've seen are written), but I understand tastes differ on that.

If doing something like this, a concern of mine would be to retain at-least-as-good error messages.

The whole emphasis here (and why we don't just use JSON) is to put more work on us maintaining this config library, in order to put less work on people writing config files. So we don't want to have less maintenance work here if there's a cost in work for people using the library.

The maintenance work right now is essentially zero anyhow - there are hardly any commits, and the bugs are (as far as I remember) "this would be a nice enhancement" kind of things, not "it's broken" kind of things. But if there are some "it's broken" I'm ignoring please let me know ;-)

It's hard to do too much "would be nice" without broadening scope, adding complexity, adding code size, but I expect we'll do a few things here and there.

Some performance work might be nice, but then I'm not sure loading config files tends to be on the critical path.

just a reminder : you promised to do pull 32 after v 1 release :-)