JST: An Object Synchronization Aspect for Java Lionel Seinturier University Paris 6, Lab. LIP6, 4 place Jussieu, 75252 Paris cedex 05, France Email:
[email protected] Abstract
The JST language introduces an object synchronization aspect for the Java language. More precisely, JST provides developers with a way to de ne synchronization classes for Java classes. JST implements a state-based, statechart-like, syntax for synchronization classes. The aspect weaver of JST takes advantage of the OpenJava re ective language.
keywords: object synchronization, Java, statecharts, OpenJava
1 Introduction
As applications become more and more complex, many functionalities need to be integrated (just to name a few, distribution, migration, replication, synchronization). This leads to a situation where the code implementing these functionalities ends up being tangled and hard to understand. The aspect-oriented programming approach [KLM+ 97] pioneered by languages such as D [LK97] or AspectJ [LK98], answers this problem: it provides developers with a way of achieving a clear separation of concerns in their programs. It suggests to tackle each functionality (i.e. each aspect) in a separate language. Even if these aspects are not always completely orthogonal, the application is obtained by combining them with a so called aspect weaver. This paper reports on JST, an object synchronization aspect language for Java. Section 2 presents its functionalities and the weaver implementation. Section 3 gives the status of the project and some trends for future works.
2 Object Synchronization Aspect
The object synchronization aspect of JST is based on a state/transition language. The basic idea is to de ne in a synchronization class (called a behaviour in JST), all the states a concurrent class can be in, and next, to de ne what are the methods that can be executed when the system is in these states. This idea of adding states to synchronize a concurrent class is not new and was implemented in a number of concurrent object-oriented languages (for instance Act++ [KL89] and Rosette [TS89]). Nevertheless, the bene ts of JST are (i) to separate the synchronization code from the rest of the application, (ii) to provide a language where states and transitions are syntactic elements and, (iii) to provide a statechart [HG96] like approach to write synchronization classes. Paragraph 2.1 summarizes the main elements of the JST language. Paragraphs 2.2 and 2.3 provide some information about respectively, the semantics of states and transitions in JST, and inheritance. Next, an example is given in paragraph 2.4. Finally, paragraph 2.5 reports on some implementation details of the JST weaver.
2.1 JST Syntax
Figure 1 presents some elements of the JST grammar. Synchronization classes are called behaviours. A behaviour implements a Java interface and can extend another behaviour. Each behaviour de nes some states. The initial state is the state the object is in at creation time. A state may be partitioned or may be basic. In the former case, entry actions and sub-states are provided. In the latter case, transitions are needed. A transition is composed of a guard and of some statements. Two elements may be speci ed in a guard: the name of a method to wait for, and a boolean expression. Any kind of Java statements may be associated with a transition. Furthermore, JST introduces two extra statements: become to specify the next state, and base to provide a reference to the base level class associated with the behaviour. Synchronization behaviours are transparently applied to Java classes by the JST weaver. ::= behaviour id '{' '}' ::= ( subbehav of id ) | _ ::= implements id ::= initial state ':' id ::= ( state id '{' '}' | state id '{' '}' )* ::= ',' ::= null | join ::= sequential | parallel | server while '(' ')' ::= entry '{' '}' ::= ( id '{' '}' )* ::= ::= ( invocation '(' id ')' ) | _ ::= ( require '(' ')' ) | _ ::= ( | base '.' | become '(' id ')' )*
Figure 1: Syntax of JST Synchronization Classes
2.2 States and Transitions Semantics
This paragraph provides some information about the JST semantics1. A transition in a synchronization behaviour can be seen as a guarded command: if the root state of a transition is active and, if the guard is true, then the transition is enabled. The guard is true if the condition speci ed in the invocation statement of the transition is invoked and, if the condition speci ed in the require statement is true. Both statements are optional. At any given time during its execution, one or more than one state of a JST behaviour may be active. Even if the latter case may seem odd, this translates the fact that several concurrent threads are being executed and, that each of them is at a di erent control point. This situation is roughly similar to the AND-decomposition of a super-state into several sub-states for statecharts. Six types of states are de ned in JST. They provide ways of controlling how states are entered and exited. The type of a state is divided into two elements: one for entering the state (null or join) and one for exiting the state (sequential, parallel or server). The de nition of these rules follows: 1 A more formal semantics for behaviours was de ned using Temporal Logic of Actions [Lam94], but its presentation is beyond the scope of this position paper.
2
Rules for Entering a State null: as soon as a transition ends, the system moves to the target state of the transition, join: the system moves to this type of state, only if all the ingoing transitions of this state have been executed. The semantics of the null rule is similar to the one found for basic transitions in statecharts. The join rule corresponds to a compound transition with an AND-connector. Rules for Exiting a State Assuming that the system is in a state S, we provide the following rules for exiting state S: sequential: as soon as a transition is enabled, the system exits state S, parallel: the system exits state S only if all the outgoing transitions of this state have been enabled, server: the system stays in this state as long as a condition (provided by the developer) is true. The sequential and parallel rules corresponds respectively, to the basic transition and to the compound transition with an AND-connector in statecharts.
2.3 Behaviour Inheritance
Inheritance in JST works much like class inheritance: a child behaviour inherits all the states and all the transitions of its parent behaviour. Only simple inheritance is supported2 . States and transitions may be rede ned. Others may be added. Finally, states may be partitioned. This feature allows to re ne a state into some sub-states. Entry actions may be speci ed. They are executed as soon as the system moves to the super-state, and before moving to the sub-states. The reuse of synchronization code introduces the well-known "inheritance anomaly" problem that is described by [MY93]. Many solutions have been proposed in the literature to tackle this problem. JST deals with it at the language level by, for instance, allowing developers to explicitly partition states.
2.4 Example
Figure 2 illustrates the use of JST with the de nition of a synchronization class for a two phases commit protocol [BHG87]. This protocol allows a coordinator object to commit or rollback a transaction on some participant objects. First, the coordinator asks the participants if they can perform the transaction. If all answer yes, then the coordinator commits the transaction, and if not, she/he rollbacks it. Hence, the synchronization scheme is that a participant executes rst, the Vote method, and then, either the Commit method, either the Rollback method (no other pattern of execution is feasible). As shown in the example, the link between the synchronization aspect and the base level object is implemented with a metaobject relation. This mechanism is detailed in paragraph 2.5. Several other synchronization policy have been developed using JST (for instance, the wellknown bounded bu er, the readers/writer policy, or some other shared variable synchronization policies). 2
The semantics of an operator for merging several inherited behaviours is a non-trivial problem.
3
behaviour TPC implements TPCInterf { initial state : S1; state S1 null, sequential { tvote { invocation(Vote()); base.Vote(); become(S2); return; } } state S2 null, sequential { tcommit { invocation(Commit()); base.Commit(); become(S3); return; } tabort { invocation(Rollback()); base.Rollback(); become(S3); return; } } state S3 null, sequential {} } metaobject moTPC instanceof TPC; public class TransactionParticipant implements TPCInterf { void Vote() { : : : } void Commit() { : : : } void Rollback() { : : : } }
Figure 2: Two Phases Commit Protocol Synchronization Class
2.5 Implementation
The aspect weaver of JST is implemented in C++. Given as an input a JST behaviour, it produces as an output an OpenJava [TC98] meta-class. OpenJava is a compile-time re ective extension of the Java language. The generated OpenJava meta-class rei es method calls and adds the synchronization de ned by the JST behaviour3 . Next, the link between the synchronization policy and the code to synchronized is obtained by declaring that the generated OpenJava code is a meta-object of the base level Java object. This feature is implemented with the OpenJava metaobject keyword (see Figure 2, metaobject moTPC instanceof TPC).
3 Status of the Project and Future Works
The object synchronization aspect of JST is now implemented4 and has been tested on a number of basic synchronization policies. Our rst reports show the bene ts of using a re ective language for aspect-oriented programming: many features of the weaver should have been (re)developed if OpenJava hadn't been used. The next step of the project is to introduce debug facilities as an aspect. One of the diculties in dealing with synchonization policies such as the one shown in paragraph 2.4, is that errors such as deadlocks or cycles in the transactional dependencies graph are hard to detect at a local (i.e. object) level. Some extensions [PDFS95][DJ99] to the Lamport's happened-before relation for distributed runs have been proposed to perform this task. We plan to incorporate this work in our current aspect weaver.
References
[BHG87] P.A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987. 3 4
Some features such as parsing inherited methods are performed with the Java Re ection API [Sun97]. The weaver is available for download at http://www-src.lip6.fr/homepages/Lionel.Seinturier/JST/.
4
[DJ99]
L. Duchien and E. Jeury. Observation in CORBA Java applications. In Proceedings of the Session on Coordination at PDPTA'99, June 1999. To appear. [HG96] D. Harel and E. Gery. Executable object modeling with statecharts. In Proceedings of the 18th International Conference on Software Engineering, pages 246{257. IEEE Computer Society Press, March 1996. [KL89] D.G. Kafura and K.H. Lee. Inheritance in actor based concurrent object-oriented languages. The Computer Journal, 32(4):297{304, 1989. [KLM+ 97] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.M. Loingtier, and J. Irwin. Aspect-oriented programming. In Proceedings of ECOOP'97, volume 1241 of Lecture Notes in Computer Science, pages 220{242. Springer, June 1997. [Lam94] L. Lamport. The temporal logic of actions. ACM Transactions on Programming Languages and Systems, pages 872{923, May 1994. [LK97] C. Lopes and G. Kiczales. D: A language framework for distributed programming. Technical Report SPL97-010 P9710047, Xerox Palo Alto Research Center, February 1997. [LK98] C. Lopes and G. Kiczales. Recent developments in AspectJ. In Workshop on AspectOriented Programming at ECOOP'98, July 1998. http://wwwtrese.cs.utwente.nl/aop-ecoop98/. [MY93] S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In Research Directions in Concurrent ObjectOriented Programming, pages 107{150. MIT Press, 1993. [PDFS95] P. Placide, L. Duchien, G. Florin, and L. Seinturier. A consistent global state algorithm to debug distributed object-oriented applications. In Proceedings of the 2nd Intl Workshop on Automated and Algorithmic Debugging (AADEBUG'95), May 1995. [Sun97] Sun Microsystems. Java Core Re ection, API and Speci cation, February 1997. [TC98] M. Tatsubori and S. Chiba. OpenJava 1.0 API and Speci cation. Programming Language Lab., University of Tsukuba, 1998. http://www.softlab.is.tsukuba.ac.jp/~mich/openjava. [TS89] C. Tolimson and V. Singh. Inheritance and synchronization with enabled sets. In Proceedings of OOPSLA'89, volume 24 of SIGPLAN Notices. ACM Press, October 1989.
5
