The module system presented in this paper is an aspect-oriented extension of the module
system presented in \textit{Modules as Object-Oriented Types} \cite{modulesastypes}. It
provides the module instantiation, import and merge features that have been described in
this paper. The module instantiation concept was itself was first proposed in iJAM \cite{iJAM}, 
another module system proposed for Java.

The JastAdd compiler framework and the Java compiler \cite{jastadd, jastaddjavacompiler}
was used to implement the system, as well as providing the case study that demonstrated 
the advantages of the module system in terms of information hiding.

Open modules \cite{openmodules, openmodulesaj} has demonstrated that global scope for advice
has detrimental effects on information hiding, and can be solved by
the introduction of a module system that limited the extent of an aspect's effects. The
current module system is based on this philosophy, but has moved the specification of
the module's interface to the components themselves, in the form of access modifiers.
However, access control similar to open modules is still available in the form of the
\textbf{export package} declaration.

Classboxes \cite{classboxj} is a module system for Java that allows the refinement of classes
with mixins within the scope of a classbox, basically a module that is a collection of classes. 
It allows both the base and refined versions to coexist in a single system, even allowing
dispatch of either the base or refined ITD depending on the dynamic type of an object, which
the module system in this paper cannot do. However, classboxes does not address the issue of
module refinement and replacement, which is handled by the extend and merge features of
this paper's module system.

Expanders \cite{expanders} provide functionality similar to ITDs, but allows for finer control
by specifying which ITDs are to be applied to a class in a given context. This provides scope
to an ITD and aids information hiding. However, it does not address the issue of refinement of 
the ITDs themselves.

AspectJ \cite{overviewaspectj}, the current de-facto benchmark for aspect-oriented languages, 
provides ITD refinement through precedence and aspect subtyping. However, these methods are
global in scope, and as has already been discussed previously, does not allow for multiple
versions of the ITD to co-exist in the same system.

CaesarJ\cite{caesarj} is an aspect-oriented language that allows for fine-grained deployment
of aspects, as well as class and aspect refinement through virtual classes\cite{virtualclasses89}. 
The module system in this paper uses an aspect refinement that is similar to virtual classes, but
at the level of the module, instead of the enclosing class. Coupled with the module imports,
we believe that this gives a better extension and composition mechanism for aspect-oriented systems.

Several aspect-oriented languages have allowed for refinement of aspects and ITDs. 
Aspectual mixin layers \cite{aspectualmixinlayers} describes an integration of features from
feature-oriented programming \cite{fopstepwiserefinement} and aspects, and provides a method of 
aspect refinement. However, it does not address the issue of allowing multiple versions of the refined and unrefined 
Aspectual collaborations \cite{lieberherr03aspectual} provides a module-based method for
aspect composition through aspect maps, but again does not address the issue of multiple
ITD versions.

Hyper/J \cite{hyperj} provides the merge operator for the composition of hyperslices, and was
the inspiration behind the merge operation described in this paper. Hyperj's merge, however, addresses
the issue of mixin composition, and not module instance sharing, which is the rationale for
the merge operation in this paper.

%XPIs (in case interfaces come up) \cite{xpi}

