Usually, we turn towards polyglot programming when we want to create an application that is more flexible and more configurable. Applications that get installed in many instances, usually, at different customer sites have some configurations. These configurations can be XML files, properties files, and INI files (those come from Windows). As the programs develop sooner or later, these static configuration possibilities reach their limits. Application developers soon see that they need to configure some functionality that is cumbersome to describe using these technologies. Configuration files start being larger and, also, the code that reads and interprets the configuration files grow large. Good developers have to realize that this is the situation, and before the configuration files and the code handling them become unmanageable, some scripting configuration, polyglot programming has to be implemented.

Decent developer teams may reach a point when they develop their configuration language and the interpreter of that language. It can be based on XML, or it can just be any other language. After all, writing a language is fun; I have done it a few times myself. Most of these were, however, hobbies and not professional projects. Usually, there is no customer value in crafting another language. We can better use an existing one.

In the case of configuration, Groovy is a very handy language that supports complex closure and meta-class syntax and implementation. This way, the language is extremely suitable to create a domain-specific language. Since Groovy is compiled to JVM, Groovy classes can be invoked directly from Java, and in the other way round, reading the configuration is essentially invoking the class compiled from the configuration file. The compilation can be during application build time, but in the case of configuration, it makes more sense to do it during application startup. We have already seen that the Groovy implementation of the scripting API or the special API that Groovy provides is absolutely capable of doing that.

Have we seen examples of this in our book? It may be a surprise to you, but we have in fact used Groovy to describe some configuration many times. Gradle build files are nothing more than Groovy DSL developed mainly in Groovy to support project build configuration.