Currently, the best documentation for the ArchJava language is the material in the publications section. In addition, a list of frequently asked questions is below. If your ArchJava-related question is not included, please send it to Jonathan Aldrich.
What makes ArchJava unique?
Don't advanced module systems like ML or Units enforce
communication integrity?
What about shared data?
To what domain is ArchJava applicable?
What are the benefits of ArchJava?
What are the limitations of ArchJava?
Is there any performance penalty for using ArchJava?
ArchJava is the only general-purpose language or system that verifies that a program conforms to an architecture in a strict technical sense known as communication integrity. By "general-purpose" we mean that it includes standard language features such as objects/function pointers and shared mutable references. Communication integrity means that the components in a program only communication along declared communication channels in their architecture. ArchJava enforces communication integrity for control flow: a component may only invoke the method of another component if it is connected to the other component in the architecture. The AliasJava extensions discussed in our OOPSLA '02 paper also allow programmers to specify how objects can be shared between components. These extensions aid in the specification of data flow between components, but are not completely sufficient to enforce communication integrity for data flow--a subject of our current work.
ArchJava is also the only extension to a mainstream language that explicitly describes a very general class of software architectures. There are other "component-oriented" or "connection-oriented" languages, including ComponentJ, ACOEL, and Cells. While these languages allow programmers to connect components using a linking construct similar to ArchJava's connect statement, these languages do not include a declarative software architecture. Parameterized module systems such as Standard ML's functors, Units, Jiazzi, and Knit can be used to describe a static software architecture. However, these module systems specify a fixed architecture at compile time; ArchJava allows the precise number and configuration of components to vary based on run-time information. Furthermore, existing module systems do not enforce communication integrity.
Module systems enforce encapsulation by hiding the names of internal functions and data that are not exported to the outside world. Furthermore, parameterized module systems (such as Units and Jiazzi) allow modules to be linked together in a structure that closely resembles a software architecture. Closely related to these module systems are Module Interconnection Languages, from which Architecture Description Languages developed.
In the presence of common features like mutable references, unbound variables within a module, first-class functions, or objects, these module systems do not enfoce communication integrity. For example, consider the case of a first-class function. Assume we have a pipeline of three components, A, B, and C, such that there are connections in the architecture from A to B and from B to C. Now, assume A defines a lambda f that invokes one of its functions. A then passes f down the pipeline to B, and B passes it on to C. If C invokes the lambda, the lambda will invoke one of A's functions. This last function call represents direct communication between C and A--however this is not allowed by communication integrity, since A and C are not directly connected in the architecture.
Consider this same example in ArchJava. An object is a lot like a first-class function: it can be passed around throughout the system, and it contains methods that can be invoked later to accomplish some task. However, objects in ArchJava may not store references to a component in their fields. Therefore, the component A in the example above could create an object and pass it down the pipeline, just as described before. However, since the object cannot store a reference to A, when C invokes one of the object's methods the object cannot invoke any of A's methods. Thus, ArchJava preserves communication integrity in this case.
We are currently developing an extension to the Standard ML module system that is able to enforce communication integrity, by adding a type channel construct to the language, and by placing a few minor restrictions on module composition. See this paper for a more thorough discussion.
ArchJava allows objects to be freely shared between components. The AliasJava language extension allows programmers to specify this sharing in the architecture using alias annotations. The components in an architecture may observe changes to the state of shared objects. However, since objects may not store references to components in their fields, objects cannot be used as surreptitious conduits for method calls that would violate communication integrity.
ArchJava is applicable to any application written in Java that is intended to run on a single JVM. For applications written in multiple languages and spanning multiple machines, the portion of them written in Java and running locally may still benefit from ArchJava. Note also that the techniques used in ArchJava could be applied to any other typed language (such as C#), although our current system supports only Java.
See also the domains in which ArchJava is applicable.
The main cost of our implementation technique is that calls through connections are routed through connection objects, adding a layer of indirection to the system. Our current compiler is a prototype and does not perform any optimizations; however, future implementations could use well-known techniques like specialization to eliminate this indirection in many cases. Thus far, the only applications of significant size to which we have applied ArchJava are interactive, and thus it is difficult to benchmark their performance.
An independent evaluation
of ArchJava on a microbenchmark that exhibited a very fine-grained
architecture measured an overhead of about 10% relative to Java code with
a similar decomposition. We expect that most realistic applications
would use architectural features at a more coarse grain, and so this estimate
is probably close to the worst case in practice.
Don't see your question here? Email it to Jonathan Aldrich.