Abstract—A software product line (SPL) is an efficient means to generate a family of program variants for a domain from a single code base. However, because of the potentially high number of possible program variants, it is difficult to test all variants and ensure properties like type-safety for the entire SPL. While first steps to type-check an entire SPL have been taken, they are informal and incomplete. In this paper, we extend the Featherweight Java (FJ) calculus with feature annotations to be used for SPLs. By extending FJ’s type system, we guarantee that – given a well-typed SPL – all possible program variants are welltyped as well. We show how results from this formalization reflect and help implementing our own language-independent SPL tool CIDE. I.

Abstract. A software product line (SPL) is a family of related program variants in a well-defined domain, generated from a set of features. A fundamental difference from classical application development is that engineers develop not a single program but a whole family with hundreds to millions of variants. This makes it infeasible to separately check every distinct variant for errors. Still engineers want guarantees on the entire SPL. A further challenge is that an SPL may contain artifacts in different languages (code, documentation, models, etc.) that should be checked. In this paper, we present CIDE, an SPL development tool that guarantees syntactic correctness for all variants of an SPL. We show how CIDE’s underlying mechanism abstracts from textual representation and we generalize it to arbitrary languages. Furthermore, we automate the generation of plug-ins for additional languages from annotated grammars. To demonstrate the language-independent capabilities, we applied CIDE to a series of case studies with artifacts written in Java, C++, C, Haskell, ANTLR, HTML, and XML. 1

Software-product-line engineering is an efficient means to generate a family of program variants for a domain from a single code base. However, because of the potentially high number of possible program variants, it is difficult to test them all and ensure properties like type safety for the entire product line. We present a product-line–aware type system that can type check an entire software product line without generating each variant in isolation. Specifically, we extend the Featherweight Java calculus with feature annotations for product-line development and prove formally that all program variants generated from a well-typed product line are well-typed. Furthermore, we present a solution to the problem of typing mutually exclusive features. We discuss how results from our formalization helped implementing our own product-line tool CIDE for full Java and report of experience with detecting type errors in four existing software-product-line implementations.

cJ is an extension of Java that allows supertypes, fields, and methods of a class or interface to be provided only under some static subtyping condition. For instance, a cJ generic class, C<P>, may provide a member method m only when the type provided for parameter P is a subtype of a specific typeQ. From a practical standpoint, cJ adds to generic Java classes and interfaces the ability to express case-specific code. Unlike conditional compilation techniques (e.g., the C/C++ “#ifdef ” construct) cJ is statically type safe and maintains the modular typechecking properties of Java generic classes: a cJ generic class can be checked independently of the code that uses it. Just like regular Java, checking a cJ class implies that all uses are safe, under the contract for type parameters specified in the class’s signature. As a specific application, cJ addresses the well-known shortcomings of the Java Collections Framework (JCF). JCF data structures often throw run-time errors when an “optional ” method is called upon an object that does not support it. Within the constraints of standard Java, the authors of the JCF had to either sacrifice static type safety or suffer a combinatorial explosion of the number of types involved. cJ avoids both problems, maintaining both static safety and conciseness.

Abstract. In many domains, classes have highly regular internal structure. For example, so-called business objects often contain boilerplate code for mapping database fields to class members. The boilerplate code must be repeated per-field for every class, because existing mechanisms for constructing classes do not provide a way to capture and reuse such member-level structure. As a result, programmers often resort to ad hoc code generation. This paper presents a lightweight mechanism for specifying and reusing member-level structure in Java programs. The proposal is based on a modest extension to traits that we have termed trait-based metaprogramming. Although the semantics of the mechanism are straightforward, its type theory is difficult to reconcile with nominal subtyping. We achieve reconciliation by introducing a hybrid structural/nominal type system that extends Java’s type system. The paper includes a formal calculus defined by translation to Featherweight Generic Java. 1

Abstract. We present MJ: a language for specifying general classes whose members are produced by iterating over members of other classes. We call this technique “class morphing ” or just “morphing”. Morphing extends the notion of genericity so that not only types of methods and fields, but also the structure of a class can vary according to type variables. This offers the ability to express common programming patterns in a highly generic way that is otherwise not supported by conventional techniques. For instance, morphing lets us write generic proxies (i.e., classes that can be parameterized with another class and export the same public methods as that class); default implementations (e.g., a generic do-nothing type, configurable for any interface); semantic extensions (e.g., specialized behavior for methods that declare a certain annotation); and more. MJ’s hallmark feature is that, despite its emphasis on generality, it allows modular type checking: an MJ class can be checked independently of its uses. Thus, the possibility of supplying a type parameter that will lead to invalid code is detected early—an invaluable feature for highly general components that will be statically instantiated by other programmers. 1

Abstract. This paper reports the application of language metamodeling techniques to EJB3QL, the object-oriented query language for Java Persistence recently standardized in JSR-220. Five years from now, today’s EJB3 applications will be legacy. We see our metamodel as an enabler for increasing the efficiency of reverse engineering activities. It has already proven useful in uncovering spots where the EJB3QL spec is vague. The case study reported in this paper involved (a) expressing the abstract syntax and well-formedness rules of EJB3QL in UML and OCL respectively; (b) deriving from that metamodel software artifacts required for several language-processing tasks, targeting two modeling platforms (Eclipse EMF and Octopus); and (c) comparing the generated artifacts with their counterparts in the reference implementation of EJB3 (which was not developed following a language-metamodeling approach). The metamodel of EJB3QL constitutes the basis for applying model-checkers to aid in assuring conformance of tools claiming to support the specification. 1

Recently, language extensions have been proposed for Java and C# to support pattern-based reflective declaration. These extensions introduce a disciplined form of meta-programming and aspectoriented programming to mainstream languages: They allow members of a class (i.e., fields and methods) to be declared by statically iterating over and pattern-matching on members of other classes. Such techniques, however, have been unable to safely express simple, but common, idioms such as declaring getter and setter methods for fields. In this paper, we present a mechanism that addresses the lack of expressiveness in past work without sacrificing safety. Our technique is based on the idea of nested patterns that elaborate the outer-most pattern with blocking or enabling conditions. We implemented this mechanism in a language, MorphJ. We demonstrate the expressiveness of MorphJ with real-world applications. In particular, the MorphJ reimplementation of DSTM2, a software transactional memory library, reduces 1,107 lines of Java reflection and bytecode engineering library calls to just 374 lines of MorphJ code. At the same time, the MorphJ solution is both high level and safer, as MorphJ can separately type check generic classes and catch errors early. We present and formalize the MorphJ type system, and offer a type-checking algorithm.

Abstract: The increasing reliance on Model-Driven Software Development calls for model compilers to assume the role of today’s compilers, i.e., reliability of these components is of utmost importance. We describe how to certify model transformations in this context by bridging the gap between the languages in which such transformations are specified (e.g., Essential MOF, OCL, OO programs) and the decision procedures needed to verify properties expected of such transformations. Two major aspects are investigated in this paper: (i) valid output is obtained for each valid input, (ii) the output satisfies certain properties. Results from application projects validate our approach, which internally applies model-driven techniques to the certification process itself by mapping transformation specifications into the + CAL model-checking language. 1

We present MorphJ: a language for specifying general classes whose members are produced by iterating over members of other classes. We call this technique “class morphing ” or just “morphing”. Morphing extends the notion of genericity so that not only types of methods and fields, but also the structure of a class can vary according to type variables. This adds a disciplined form of meta-programming to mainstream languages and allows expressing common programming patterns in a highly generic way that is otherwise not supported by conventional techniques. For instance, morphing lets us write generic proxies (i.e., classes that can be parameterized with another class and export the same public methods as that class); default implementations (e.g., a generic do-nothing type, configurable for any interface); semantic extensions (e.g., specialized behavior for methods that declare a certain annotation); and more. MorphJ’s hallmark feature is that, despite its emphasis on generality, it allows modular type checking: a MorphJ class can be checked independently of its uses. Thus, the possibility of supplying a type parameter that will lead to invalid code is detected early—an invaluable feature for highly general components that will be statically instantiated by other programmers. We demonstrate the benefits of morphing with several examples, including a MorphJ reimplementation of DSTM2, a software transactional memory library, which reduces 1,484 lines of Java reflection and bytecode engineering library calls to just 586 lines of MorphJ code.