Statically safe program generation with SafeGen

Abstract

SafeGen is a meta-programming language for writing statically safe generators of Java programs. If a program generator written in SafeGen passes the checks of the SafeGen compiler, then the generator will only generate well-formed Java programs, for any generator input. In other words, statically checking the generator guarantees the correctness of any generated program, with respect to static checks commonly performed by a conventional compiler (including type safety, existence of a superclass, etc.). To achieve this guarantee, SafeGen supports only language primitives for reflection over an existing well-formed Java program, primitives for creating program fragments, and a restricted set of constructs for iteration, conditional actions, and name generation. SafeGen's static checking algorithm is a combination of traditional type checking for Java, and a series of calls to a theorem prover to check the validity of first-order logical sentences constructed to represent well-formedness properties of the generated program under all inputs. The approach has worked quite well in our tests, providing proofs for correct generators or pointing out interesting bugs.

Type checking annotation-based product lines

“…First, in an influential approach, Huang et al [2005] ensure that Java code generated by their tool SafeGen is well-typed. Though their tool is used for metaprogramming in general, not as productline technology, the basic idea is similar to our theorem generation preserves typing.…”

“…It builds on top of our prior efforts to prevent syntax errors with disciplined annotations in our tool CIDE and is inspired by prior work on type checking entire product lines [Czarnecki and Pietroszek 2006;Thaker et al 2007;Huang et al 2005;Delaware et al 2009;] (see Sec. 9).…”

Morphing: Safely Shaping a Class in the Image of Others

“…Yet more examples from the static reflection or generic aspects literature [10,11,13,19] can be viewed as instances of morphing and can be expressed in MJ. For instance, the CTR work [11] allows the user to express a "transform" that iterates over methods of a class that have a @UnitTestEntry annotation and generate code to call all such methods while logging the unit test results.…”

“…This is an invaluable property for generic code: it prevents errors that only appear for some type parameters, which the author of the generic class may not have predicted. This problem has been the target of some prior work, such as type-safe reflection [10], compile-time reflection [11], and safe program generation [13]. Yet none of these mechanisms offer MJ's modular type checking guarantees.…”

“…Yet none of these mechanisms offer MJ's modular type checking guarantees. For instance, the Genoupe [10] approach has been shown unsafe, as the reasoning depends on properties that can change at runtime; CTR [11] only captures undefined variable and type incompatibility errors, does not offer a formal system or proof of soundness, and has limited expressiveness compared to MJ (especially with respect to method arguments); SafeGen [13] has no soundness proof and relies on the capabilities of an automatic theorem prover-an unpredictable and unfriendly process from the programmer's perspective.…”