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

Software diversity: state of the art and perspectives

International audienceDiversity is prevalent in modern software systems to facilitate adapting the software to customer requirements or the execution environment. Diversity has an impact on all phases of the software development process. Appropriate means and organizational structures are required to deal with the additional complexity introduced by software variability. This introductory article to the special section "Software Diversity--Modeling, Analysis and Evolution" provides an overview of the current state of the art in diverse systems development and discusses challenges and potential solutions. The article covers requirements analysis, design, implementation, verification and validation, maintenance and evolution as well as organizational aspects. It also provides an overview of the articles which are part of this special section and addresses particular issues of diverse systems development

Jam-designing a Java extension with mixins

Methods. In a mixin it is possible to declare abstract methods (that is, methods without a body). For each of them the method, with the specified type, will be part of the mixin type. A class obtained by instantiating a mixin that contains abstract methods must necessarily be declared abstract (vice versa, like in Java, see JLS 8.1.1.1, it is allowed to declare an abstract class without any abstract method)