A framework for building type-safe configurations for JVM using code generation techniques

One of the common errors in software development is a configuration mistake. This type of error can have a wide range of severity levels. Consequences of a wrong configuration can be small and insignificant such as a website showing an incorrect font type, or large and consequential such as deleting customer data, incorrect price calculation, or charging a fee twice. In addition, an incorrect configuration may introduce subtle and lurking vulnerabilities into a system. Statically typed programming languages generally can mitigate these kinds of problems to some extent. At compile time, a compiler can detect incorrect types as well as other common mistakes such as some typographical errors, invalid type coercions, and invalid object references. It goes without saying that developers need to correct all compile-time errors before a project can be built. However, hardcoded configurations are not desirable since the input data cannot be changed without rebuilding a project. Due to this inflexibility, external configuration files are needed, but they bring back some thorny issues since the compiler cannot validate the types in those files. Adding validation logic does not substantially mitigate this problem because it is activated at runtime, and errors may not be discovered until a project is deployed to production servers. An external configuration file somewhat lessens the benefit of static type-checking that a compiler provides. Furthermore, string keys are needed for linking the variables in the source code to the values in configuration files. If a key is required to be renamed, it should be renamed in both configuration file and source code. Otherwise, the link will be broken. We propose a new framework that can generate source code from configuration files during development. Many configuration file formats support basic data types and nested object structure which can be mapped to Java types and the Java static nested class. The configuration library that we used is config by typesafehub. The library supports the Human-Optimized Config Object Notation (HOCON) file format which is a superset of the JavaScript Object Notation (JSON). The library's objects are encapsulated in the generated configuration object, which cannot be directly accessed by developers. We discovered that this method can prevent some types of human errors, and it also takes advantage of the validation provided by a compiler. The configuration key is no longer a string, rather a chain of methods or attributes, which is more flexible and type-safe. The configuration objects and their values are immutable. The complexity of how mutable values are converted to immutable ones is hidden from the developers. There are a number of other subtle details that are addressed in the paper, as well as some limitations and enhancements.