

%Versioning is done through constraints, usually flat

%Extension is specified without reference to versioning

%Limited and cumbersome support for constraints at the publisher side

%Scope: only the module system and constraints, not deployment/framework

There has been renewed interest in module systems for Java-like languages in recent
years, particularly with the adoption of OSGi \cite{OSGi4} for the Eclipse \cite{eclipse}
client platform and on several server applications, and the impending inclusion
of a module system \cite{JSR277, JSR294} in Java 7. The .NET Framework uses \textit{assemblies} \cite{netassemblies}
for the same purpose. In these systems, a module is
a collection of classes (and possibly resources) and a set of data and directives that specify how the collection
accesses or is accessed by other modules. 

A crucial feature that these systems have
is versioning: that is, the ability to handle multiple versions of the same module.
These module systems provide a mechanism for a module's client to specify which version
(or range of versions) of a dependency a client expects for it to function properly.
They provide a system to update a deployed module to a more recent version in case of upgrades or patches.

As it is possible for two client modules to share types from a dependency, these module systems also provide a way to ensure that these clients are connected to the same instance
of the dependency; that is, if modules \textit{X} and \textit{Y} use a class \textit{C} from \textit{Z}, the module system
must ensure that \textit{X} and \textit{Y} are connected to the exact same instance of \textit{Z}, 
otherwise assigning an instance of \textit{C} created in \textit{Y} to a reference declared in \textit{X}
would cause a type error. 

However, the constructs provided in these systems are cumbersome to use when maintaining
consistency of shared dependencies over large numbers of modules, or are too restrictive and
do not allow the coexistence of multiple versions of a module in order to maintain consistency.
These module systems also do not provide the ability to do a non-destructive extension or patch to a module.

This paper contains a proposed module system for Java-like languages that addresses these issues.
Versioning and extension will be accomplished by defining object-oriented relationships between modules akin
to those between object-oriented classes. We also define the operators \textbf{replace} and \textbf{merge}
to allow for updating modules and maintaining consistency of shared dependencies.

The contributions of this paper are:

\begin{enumerate}
\item  The definition of object-oriented relations and operations on modules to 
handle extension and versioning;
\item The implementation of the module system as a Java extension and a
small case study to demonstrate the system's features;
\item A translation from OSGi bundles to the proposed system's modules to
demonstrate that the proposed system can express OSGi's bundle composition constraints.
\end{enumerate}

The paper is organized as follows. First we describe the
usage and shortcomings of existing module systems in section \ref{moduleops}. 
We then follow with an example-driven description of the proposed module system in section \ref{moduletypes}. 
In section \ref{eval} we demonstrate that the module
system is able to express existing usage of modules while providing new
capabilities to handle module replacement and merging. The module system
itself is implemented in a compiler made using the JastAdd\cite{jastadd} compiler construction
framework, and is demonstrated on a small case study on JHotdraw 7.1 \cite{jhotdraw}.
To further demonstrate that the module system contains the functionality provided by existing
module systems, we provide a translation from OSGi bundles, a module system in widespread
use for Java, into the proposed module system in section \ref{translation}.
A short description of the implementation is included in section \ref{implementation}.
The paper then ends with sections on related work and conclusions.
