SOFTWARE—PRACTICE AND EXPERIENCE Softw. Pract. Exper. 2003; 33:461–480 (DOI: 10.1002/spe.516) Mechanisms for secure modular programming in Java Lujo Bauer ∗,† , Andrew W. Appel and Edward W. Felten Department of Computer Science, Princeton University, 35 Olden Street, Princeton, NJ 08544, U.S.A. SUMMARY We present a new module system for Java that improves upon many of the deficiencies of the Java package system and gives the programmer more control over dynamic linking. Our module system provides explicit interfaces, multiple views of modules based on hierarchical nesting and more flexible name-space management than the Java package system. Relationships between modules are explicitly specified in module description files. We provide more control over dynamic linking by allowing import statements in module description files to require that imported modules be annotated with certain properties, which we implement by digital signatures. Our module system is compatible enough with standard Java to be implemented as a source-to-source and bytecode-to-bytecode transformation wrapped around a standard Java compiler, using a standard Java virtual machine (JVM). Copyright c  2003 John Wiley & Sons, Ltd. KEY WORDS: information hiding; abstract data types; computer security; hierarchical module system; name- space management; dynamic linking; Java 1. INTRODUCTION The traditional method of providing software-based protection within a program is by using abstract data types and information hiding. These methods have been used extensively to make sure that objects can be written in ways that allow outsiders only carefully controlled access to their implementation details. Hiding the implementations and private interfaces of objects or classes provides for information hiding on too fine-grained a scale. We argue that the building blocks of today’s object-oriented software systems, however, are not objects or classes but modules. Modules must provide a framework for information hiding and should help structure the interaction between different parts of a program. They must do this not only to protect programs from non-malicious mistakes made by other parts of the same software system, but also to protect the entire software system from malicious attack. ∗ Correspondence to: Lujo Bauer, Department of Computer Science, Princeton University, 35 Olden Street, Princeton, NJ 08544, U.S.A. † E-mail: lbauer@cs.princeton.edu Contract/grant sponsor: National Science Foundation; contract/grant number: 9870316 Published online 5 March 2003 Copyright c  2003 John Wiley & Sons, Ltd. Received 15 May 2002 Revised 22 August 2002 Accepted 22 August 2002