<< | Contents | Language Constructs >>
Introduction
What is CaesarJ?
CaesarJ is a new aspect-oriented programming language, which addresses the most important goals of software design: modularity, reuse, flexibility and correctness. It is based on object-oriented concepts and fully integrates with the
Java programming language and
Eclipse IDE. All new language features are compiled to efficient byte-code.
Who can use CaesarJ?
CaesarJ is a general purpose programming language, which compiles to conventional Java byte code. So it can be used everywhere Java can be used. It provides powerful features, which can be used to improve design of existing Java projects as well for new development. CaesarJ does not prohibit conventional Java programming. Developers can freely choose how much of CaesarJ they want to use in their project.
How CaesarJ differs from other aspect-oriented languages?
Conventional aspect-oriented languages focus on physical separation of source code, implementing crosscutting concerns. CaesarJ takes a step further and ensures other important properties of modularity: abstraction, information hiding and minimization of dependencies. Aspects are designed as components, which have clear abstraction and can be reusable.
In order to achieve these goals CaesarJ slightly extends run-time conception of object-oriented systems by grouping objects to collaborations, using virtual types and bindings.
How CaesarJ achieves better modularity?
Firstly CaesarJ improves separation of concern in the same way as
AspectJ. AspectJ style pointcuts and advices can be used to intercept points, where component functionality should be integrated.
Secondly CaesarJ modularizes components, which consist of multiple collaborating classes. Developer can define collaboration interface, which is a set of related Java interfaces required and provided by the component. Then he/she implements the component in using collaboration interface. In a separate module he/she defines the binding of the component to the application. We achieve information hiding, because component implementation is abstracted from application specific concepts, and on the other hand component implementation details are hidden behind the collaboration interface.
Finally CaesarJ enables modularization of different features within a class collaboration. Using virtual classes developer can define base class collaboration and incrementally refine it with new features in its subcollaborations. Independently developed features can be smoothly merged by applying mix-in composition on the subcollaborations.
How CaesarJ achieves better reuse?
Better reuse is first of all a consequence of better modularity. Collaboration interfaces minimize interdependency between component and its integration to the application. In this way components can be reused with other bindings in other context within the application or in another application. On the other hand bindings can be reused for other components which are based on the same or very similar collaboration interface.
Another kind of reuse is achieved through virtual classes and mix-in composition. These language mechanisms enable factoring out common functionality of components. It gives similar advantages as flexible multiple inheritance mechanisms, but on the scale of class collaborations rather than on the scale of individual objects. This capability is very attractive for development of product lines.
Is it safe to use CaesarJ?
Yes, firstly the modularity qualities provided by CaesarJ improve source code stability. CaesarJ encourages development of properly abstracted components, which define explicit contract with the rest of application. Usage of pointcuts and advices is encapsulated in bindings. In this way a change in the application does not affect component implementation and the other way around.
Secondly CaesarJ provides more flexible type-checking mechanism, which is nevertheless fully type-safe. For example, developer can extend a class framework by overriding several classes. In Caesar these classes can safely use the new features of each other without any type-casts. In this way the type system of CaesarJ provides a safe alternative to type casts or arbitrary covariance.
Does CaesarJ produce less efficient code?
No, in CaesarJ we included only the features, which can be translated to efficient Java bytecode. CaesarJ uses the AspectJ weaver, which applies byte code manipulations to insert efficient advice calls.
Virtual classes and mix-in compositions are translated to conventional Java class hierarchies, so all method calls are as efficient as conventional Java calls.
Bindings are based on hash maps to retrieve wrapper from wrappee. Wrappers contain direct references to wrappees. So navigation to both sides is constant time. In the situations where bindings are used, conventional Java programs would also use hash tables. Virtual classes can be used instead of bindings where possible in order to avoid usage of hash tables.
<< | Contents | Language Constructs >>
