CentiJ: An RMI Code Generator

The CentiJ system synthesizes Java source code that funnels invocations through an RMI (Remote Method Invocation) based transport layer for distributed computation. The technique generates bridge pattern code (i.e., interfaces and proxies) that automate the creation of virtual proxies for message forwarding. We examine the tradeoffs between bridge implementations based on manual static delegation, automatic static delegation, and dynamic proxy classes. Advantages of the CentiJ technique include improved performance, type safety, transparency, predictability, flexibility and reliability. We then look at various methods for solving the disambiguation problem that arises when delegates have conflicting method signatures. Disambiguation can be automatic, semi-automatic or manual. CentiJ can automatically create a class that alters the interface to the bridge (using the adapter pattern)

Towards safe and flexible object adaptation

In this paper, a programming language NextEJ is proposed. NextEJ is based on Epsilon model, which realizes object adaptation to contexts. The novelty of Epsilon model is its ability to make objects be able to freely enter or leave contexts dynamically and belong to multiple contexts at a time. However, such kind of flexibility also easily brings type-unsafety. NextEJ tackles this problem by introduc-ing a new feature called context activation scope. Inside a context activation scope, it is assured that an object is al-ways bound with the role activated so that no method-not-understood errors occur at run-time. Furthermore, context activation scope can be nested so that multiple contexts can be activated at a time. A role instance has a pre-defined field thisContext which refers to its enclosing context instance. In the case of multiple context activations, the reference of thisContext is interpreted as a composite context whose behavior is determined by the order of activations

Schémas de développement d'adaptateurs à l'aide de B

ISBN=978-2-87037-559-4National audienceDans une approche composants pour le développement de logiciels, les composants sont considérés comme des boîtes noires qui communiquent via leurs interfaces. L'interface fournie d'un composant peut être connectée à l'interface requise d'un autre composant si l'interface du premier composant implante les fonctionnalités requises par le second composant. Une description formelle de ces interfaces est nécessaire pour s'assurer de leur compatibilité. En général, les interfaces ne sont pas directement compatibles et un adaptateur doit être introduit. Nous proposons des schémas pour développer des adaptateurs et vérifier l'interopérabilité des composants

Trustworthy interface compliancy: data model adaptation using B refinement

International audienceIn component-based software development approaches, components are considered as black boxes, communicating through required and provided interfaces which describe their visible behaviors. Each component interface is equipped with a suitable data model defining all the types occurring in the signature of interface operations. The provided interfaces are checked to be compatible with the corresponding required interfaces, by the way of adapters. We propose a method to develop and verify these adapters when the interface data models are different, using the formal method B. The use of B assembling and refinement mechanisms eases the verification of the interoperability between interfaces and the correctness of the component assembly

Développement formel par composants : assemblage et vérification à l'aide de B

26 pages. Numéro spécial de la conférence AF ADL 2007Soumission à la revue TSI, numéro spécial AFADL'07.National audienceDans une approche composants pour le développement de logiciels, les composants sont considérés comme des boîtes noires. Une application consiste en un assemblage de composants qui communiquent via leurs interfaces. Une description formelle de ces interfaces est nécessaire pour s'assurer de leur compatibilité. En général, les interfaces ne sont pas directement compatibles et un adaptateur doit être introduit. Nous proposons des schémas pour assembler des composants de manière systématique et vérifier leur interopérabilité; ces schémas sont définis à l'aide de concepts issus de la méthode B. L'assemblage est un raffinement des interfaces requises qui inclut les interfaces fournies; la correction du processus est validée par les obligations de preuves usuelles

Evolving Software with Extensible Modules

We present the design of the programming language Keris, an extension of Java with explicit support for software evolution. Keris introduces extensible modules as the basic building blocks for software. Modules are composed hierarchically revealing explicitly the architecture of systems. A distinct feature of the module design is that modules do not get linked manually. Instead, the wiring of modules gets infered. The module assembly and refinement mechanism of Keris is not restricted to the unanticipated extensibility of atomic modules. It also allows to extend fully linked systems by replacing selected submodules with compatible versions without needing to re-link the full system. Extensibility is type-safe and non-invasive; i.e. the extension of a module preserves the original version and does not require access to source code

Delegation by Object Composition

AbstractClass inheritance and method overriding, as provided by standard class-based languages, are often not flexible enough to represent objects with some dynamic behavior. In this respect, object composition equipped with different forms of method body lookup is often advocated as a more flexible alternative to class inheritance since it takes place at run time, thus permitting the behavior of objects to be specialized dynamically. In this paper, we illustrate Incomplete Featherweight Java (IFJ), an extension of Featherweight Java with a novel linguistic construct, the incomplete object. Incomplete objects require some missing methods which can be provided at run time by composition with another (complete) object. Furthermore, we present two mechanisms for the method body lookup on (composed) objects, one based on delegation and the other based on consultation. Thanks to the design of the language, the consultation-based lookup is a simple extension of the delegation-based one. Both mechanisms are disciplined by static typing, therefore the language enjoys type safety (which implies no “message-not-understood” run-time errors) and avoids possible accidental overrides due to method name clashes