Foreign function interfaces (FFIs) allow components in different languages to communicate directly with each other. While FFIs are useful, they often require writing tricky, low-level code and include little or no static safety checking, thus providing a rich source of hard-to-find programming errors. In this paper, we study the problem of enforcing type safety across the OCaml-to-C FFI and the Java Native Interface (JNI). We present O-Saffire and J-Saffire, a pair of multilingual type inference systems that ensure C code that uses these FFIs accesses high-level data safely. Our inference systems use representational types to model C’s low-level view of OCaml and Java values, and singleton types to track integers, strings, memory offsets, and type tags through C. J-Saffire, our Java system, uses a polymorphic, flow-insensitive, unification-based analysis. Polymoprhism is important because it allows us to precisely model user-defined wrapper functions and the more than 200 JNI functions. O-Saffire, our OCaml system, uses a monomorphic, flow-sensitive analysis, because while polymorphism is much less important for the OCaml FFI, flow-sensitivity is critical to track conditional branches, which are used when “pattern matching ” OCaml data in C. O-Saffire also tracks garbage collection information to ensure that local C pointers to the OCaml heap are registered properly, which is not necessary for the JNI. We have applied O-Saffire and J-Saffire to a set of benchmarks and found many bugs and questionable coding practices. These results suggest that static checking of FFIs can be a valuable tool in writing correct multilingual software. 1

Abstract. We present a multi-lingual type inference system for checking type safety of programs that use the Java Native Interface (JNI). The JNI uses specially-formatted strings to represent class and field names as well as method signatures, and so our type system tracks the flow of string constants through the program. Our system embeds string variables in types, and as those variables are resolved to string constants during inference they are replaced with the structured types the constants represent. This restricted form of dependent types allows us to directly assign type signatures to each of the more than 200 functions in the JNI. Moreover, it allows us to infer types for user-defined functions that are parameterized by Java type strings, which we have found to be common practice. Our inference system allows such functions to be treated polymorphically by using instantiation constraints, solved with semi-unification, at function calls. Finally, we have implemented our system and applied it to a small set of benchmarks. Although semi-unification is undecidable, we found our system to be scalable and effective in practice. We discovered 155 errors and 36 cases of suspicious programming practices in our benchmarks. 1

Abstract. Superimposition is a composition technique that has been applied successfully in several areas of software development. In order to unify several languages and tools that rely on superimposition, we present an underlying language-independent model that is based on feature structure trees (FSTs). Furthermore, we offer a tool, called FST-Composer, that composes software components represented by FSTs. Currently, the tool supports the composition of components written in Java, Jak, XML, and plain text. Three nontrivial case studies demonstrate the practicality of our approach. 1

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.

Software product lines (SPL) usually consist of code and non-code artifacts written in different languages. Often they are created by decomposing legacy applications into features. To handle different artifacts uniformly (code, documentation, models, etc.), current SPL technologies either use an approach that is so general that it works on character or token level, but can easily introduce subtle errors; or they provide specialized tools for a low number of languages. Syntax errors that only occur in certain variants are difficult to detect, as the exploding number of variants makes a manual testing unfeasible. In this paper, we present CIDE, an generic SPL tool that can ensure syntactic correctness for all variants. We show CIDE’s underlying mechanism that abstracts from textual representation and generalize it from

kevin.bierhoff @ cs.cmu.edu Architectural mismatch results from implicit and conflicting assumptions that designers of components make about the environments in which these components should operate. While architectural mismatch was extensively studied in monolithic and distributed applications, it has not been applied to Service-Oriented Architectures (SOAs). A major contribution of this paper is the analysis of how architectural mismatch affects SOAs. We study how implicit and conflicting assumptions that designers make about web services and their compositions affect the quality of resulting SOA-based systems. We support our analysis with empirical data that we collected from a large-scale SOA-based project within Accenture and other smaller projects. 1.

Feature-Oriented Software Development (FOSD) is a paradigm for the development of software product lines. A challenge in FOSD is to guarantee that all software systems of a software product line are correct. Recent work on type checking product lines can provide a guarantee of type correctness without generating all possible systems. We generalize previous results by abstracting from the specifics of particular programming languages. In a first attempt, we present a reference-checking algorithm that performs key tasks of product-line type checking independently of the target programming language. Experiments with two sample product lines written in Java and C are encouraging and give us confidence that this approach is promising.