Skip to content

alternatives

Jump to bottom
Carlos Rueda edited this page Aug 9, 2017 · 5 revisions

How does tscfg compare to possible alternatives?

NOTE: Preliminary notes. No really careful investigation has been done. If you are already using tscfg and did some sort of assessment for your choice, we would certainly welcome your input!

Some general observations:

  • tscfg is a code generator to be executed at some point prior to the proper compile phase of your project. Some may see this as a limitation or drawback, others as a feature.

  • Although perhaps obvious, the appropriate strategy for dealing with configuration properties greatly depends on your application and programming practices/preferences. YMMV.

Although still based on a very cursory review of other wrappers, you may find the following comments useful at least to motivate some further discussion/exploration.

If there's anything mistakenly stated about any of the wrappers below, do please let me know and I will do a correction asap!

  • static-config

    • very interesting approach (in combination with sourcecode)
    • "it is important to fail early...": yes, tscfg does that;
    • "... and to avoid throwing exceptions": currently tscfg does throw exception, but could be changed to address this if really desired.

    EDIT 2017-07-21: I did some experimentation to extend this approach: https://github.com/carueda/stscfg

    EDIT 2017-08-07: During the process I ended up focusing on a Scalameta-based implementation from scratch: https://github.com/carueda/cfg. Check it out!

  • config-annotation

    • looks very interesting

  • Typesafe Config Guice

    • Follows "JavaBean conventions;" in other words, it deals with mutable objects.

  • Simple Scala Config

    • No compile time checking:

      The downside to using it is the configuration dereferencing looks like it is valid--due to the compiler accepting it--but in reality, dereferencing errors will be detected at runtime.

    • Not usable IDE code auto-completion feature.

  • PureConfig

    • definitions based on case classes (which is not bad per se, of course!), but this may become actually a sort of boilerplate especially when the level of configuration nesting increases.

  • Ficus

    • "... adds an as[A] method to a normal Typesafe Config..." so, seems like not actual check at compile time.

  • configz
    configs
    ScalaConfig

    • No checks at compile time.

  • Cedi Config

    • More dependencies (besides Typesafe Config)
    • seems too much for the goal at hand?
Clone this wiki locally